BIG problem. How do I find a bug in so much code?

This is a discussion on BIG problem. How do I find a bug in so much code? within the C++ Programming forums, part of the General Programming Boards category; >> What advantage do I gain by using them? Lots. Especially in terms of array growth and no remembering to ...

  1. #31
    The superhaterodyne twomers's Avatar
    Join Date
    Dec 2005
    Location
    Ireland
    Posts
    2,262
    >> What advantage do I gain by using them?
    Lots. Especially in terms of array growth and no remembering to delete.
    Plus strings.
    More lots.

  2. #32
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,589
    What advantage do I gain by using them?
    Dealing with memory leaks
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #33
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Quote Originally Posted by Yarin View Post
    >> Is there a reason you don't use vectors and smart pointers?
    What advantage do I gain by using them?
    With smart pointers, you can use a reference count to delete memory only when no longer in use. In other words, you'll be guaranteed that you aren't causing memory bugs by freeing memory to be used later and you guarantee there will be no memory leaks.
    By using std::vector.at, you can make sure the code doesn't do any out-of-bounds since it will throw an exception if you try to access out-of-bounds elements.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #34
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605
    Oh. Is the advantage really worth revamping my code though?
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  5. #35
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    OF course it is. No major changes needed. For the most, at least
    You'll be better protected and you'll see if you can get rid of catch some bugs!
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  6. #36
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Code:
    TORP torp[MAX_TORPS + 2];
    While this may prevent going over bounds with this array, it is still a horrible fix. The reader of the code won't either understand it or realize that the original coder was seriously confused about arrays.

    The fix for the algorithm was already suggested. If you want to access this and the next item, don't loop up to the very end.

    In addition, vector has the erase method, so that you wouldn't even need to write the DestroyTorpedo function yourself. (And thanks to this and other things, such as a vector knowing its own size rather than relying on a global(?) variable, you're code would contain less bugs and be a bit shorter than 1300 lines. )
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  7. #37
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    1,605
    I guess I'll do that. Thank you all for the help.
    A class that doesn't overload all operators just isn't finished yet. -- SmugCeePlusPlusWeenie
    A year spent in artificial intelligence is enough to make one believe in God. -- Alan J. Perlis

  8. #38
    CSharpener vart's Avatar
    Join Date
    Oct 2006
    Location
    Rishon LeZion, Israel
    Posts
    6,484
    Quote Originally Posted by Yarin View Post
    Okay, now I've set all my arrays to have 2 more than the max, so an overrun is out of the question, right?
    Wrong. You can still access members before 0.
    The first 90% of a project takes 90% of the time,
    the last 10% takes the other 90% of the time.

  9. #39
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    Yarin, I suggest you use linked lists for your game objects.
    It's more efficient for removing (or inserting) things from the middle.
    They are also efficient when accessed sequentially, which I
    assume is another kind of access you need.
    So if you don't need so-called "random access", it's might be best.
    Anyone else agree?

  10. #40
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,537
    Yes, but it will also require a rewrite. It would probably be a good idea if speed is a concern.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #41
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Also, look up the discussion I had with Bubba a few months ago about linked lists vs vectors.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #42
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Quote Originally Posted by CornedBee View Post
    Also, look up the discussion I had with Bubba a few months ago about linked lists vs vectors.
    I looked it up (again) and while carfully reading it, I run into two questions. Maybe you want to answer them.


    Unless copying of the individual elements is expensive (std::string is one case - but not once we get r-value references in C++09), it takes a lot of elements to overcome the consider- ably greater overhead that, say, a list has.
    I tried to find out what problem exist with using expensive copy constructor and vector. I found, that the copy constructor is called twice while adding to the end of a vector, if I dont't call reserve() before insertion. Why does it need to be called twice? And why does an explizit call to reserve can do a similar job (reserving memory) without calling the copy constructor?

    An could you explain please what exactly will change with the r-value-reference thing?


    The other question:
    When you're dealing with primitives,
    it's most noticeable. On a 64-bit system, for example, a list<int> needs 5
    times as much space to store a single element as a vector.
    Why does the list need more space?

    Thank you in advance!

  13. #43
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Basically, the vector has to reallocate every now and then, and for that it needs to copy its elements around. Furthermore, insertion and deletion in the middle of the vector involves moving all elements after this position around - this, too, involves a lot of copying. That's why, if the copy constructor and copy assignment operator are slow, std::vector takes a performance hit.

    If, on the other hand, copying is fast - some vector implementations recognize POD types and use straight memmove() then - the overhead is considerably lower.

    With r-value references, the vector will be able to use move semantics. Moving is a destructive copy - the target gets the value of the source, but unlike copying, the value of the source after the operation doesn't matter. For classes like std::string, which allocate memory dynamically and keep a pointer to it, this means that the ownership of the memory can simply be passed to the target object, leaving the source object with an empty value. Obviously this is much faster than allocating a new block and copying the contents over.


    The list needs more space because every element needs pointers to the next and previous node. There's two pointers overhead for every single element stored. In a vector, there's zero overhead per element, only some constant overhead for managing the memory.
    Last edited by CornedBee; 01-31-2008 at 05:33 AM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  14. #44
    Registered User
    Join Date
    Nov 2006
    Posts
    519
    Nice, thank you. Maybe someone should move this together with the post I quoted from to the FAQ board, because this container releated questions are asked very often (directly or indirectly) and few people seems to have such in depth knowledge about it.

  15. #45
    - - - - - - - - oogabooga's Avatar
    Join Date
    Jan 2008
    Posts
    2,808
    It should also be made clear that although with 64-bit words a list<int> may need 5 times the space, a list<sixety_four_byte_object> will only need 1.25 times the space.

    You also must consider how much faster the list may (or may not) be for your most common operations. In particular, lots of insertions and deletions might mean a list is faster overall, particularly if they are mostly in the middle (but your case sounds like insertions may all be at the end). The vector may have faste sequential access, and adding to the end _should_ be efficient (if you reserve lots of space beforehand).

Page 3 of 3 FirstFirst 123
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Problem Code: Inline
    By CodingFleet in forum C++ Programming
    Replies: 6
    Last Post: 07-25-2007, 11:19 AM
  2. Someone having same problem with Code Block?
    By ofayto in forum C++ Programming
    Replies: 1
    Last Post: 07-12-2007, 08:38 AM
  3. Quicksort problem, now with clear code
    By rvanbeusichem in forum C Programming
    Replies: 1
    Last Post: 11-25-2004, 12:54 PM
  4. Big Code, Little Problem
    By CodeMonkey in forum Windows Programming
    Replies: 4
    Last Post: 10-03-2001, 05:14 PM
  5. can anyone find the problem in my code
    By ArseMan in forum C++ Programming
    Replies: 2
    Last Post: 09-20-2001, 09:02 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21