views:

537

answers:

11

I've heard lots of times that phrase of Bjarne Stroustrup "C++ makes it harder to shoot yourself in the foot; but when you do, it takes off the whole leg" and I don't really know if it is as terrible as it sounds.

What's the worst thing that has ever happened to you (or more properly, to your software) while programming in C++? In which ways can it be more dangerous than say plain C, for example?

+1  A: 

Its implementation of exception handling is an easy inroad for memory leaks.

eduffy
How so? Are you thinking of the case of exceptions thrown by pointer instead of reference?
Steven Sudit
With proper RAII, this isn't an issue, i think
Johannes Schaub - litb
Disagree. I see no reason for memory to be leaked with exceptions. The standard is very clear in how the exception is propogated.
Martin York
+6  A: 
delete [] array;

can sometimes become

delete array;

in the hands of someone who doesn't know. Tracking that bug down can suck horribly, and doesn't happen when you're doing malloc and free.

mmr
As you probably know, why it doesn't happen with malloc and free is because it doesn't make a distinction between an array or a single item.
Skurmedel
Exactly. So I got rid of the 'seem to' clause there; I was being cautious because it's been so long since I've used C...
mmr
Hehe same here :)
Skurmedel
+6  A: 

buffer overflows have to be the most dangerous things in both c and c++. This is also the reason that Microsoft announced that they have added memcpy() to their list of banned functions

multiple inheritance is another

SQLMenace
Most dangerous thing of any language without overrun protection.
Skurmedel
+1  A: 

Probably the most dangerous aspect of C++ that doesn't exist in C is the ability to override operators for complex types. It can be very easy to make subtraction addition (and vice versa), for example.

It's stupid that anyone would do that, but it can be done. Making it dangerous.

Randolpho
+1  A: 

The virtual destructor requirement is easy for new comers to miss (although I think most compilers are smart enough to point this one out).

eduffy
What virtual destructor requirement?
Magnus Skog
@Magnus: If you destroy an object via a pointer to its base (or any ancestor), then if the destructor is not virtual the incorrect destructor will be called. Thus classes that are designed to be overridden should probably have a virtual destructor.
Martin York
+3  A: 

Operator overloading. Very easy to make things difficult to understand what's going on. It's easy to overlook the fact that an overload is going on, even for experienced C++ developers.

Jared Oberhaus
Overloaded operators have their place. I wouldn't say the feature is inherently bad--it can be quite useful. It's when people start defining them to do things counter-intuitively that the difficulties emerge. Overloaded operators, when used properly, can make code simpler and cleaner.
Jeff L
A: 

If you're going to compare the safety of C++ versus C, then you've missed the point of that phrase. C++ is arguably no safer than C.

Where the comparison can really be made is with a language such as Java. Essentially, Java handles your memory for you, so you won't end up with undefined behavior when calling memory outside of the memory your program is currently using (going out of bounds on arrays, etc.).

To address your question though, the worst thing that's happened to me was a buffer overflow to override my own password (I did it purposefully, however).

AlbertoPL
Very true. The most dangerous aspects of C++ are actually holdovers from C. There are a few features in C++ that don't exist in C (like operator overloading); I believe the question is asking about those.
Randolpho
In fact the static type checking can be enforced more strictly in C++ than in C, I think (the typedefs are in the end something like "anything goes")
fortran
C++ gives you the choice, you can use checked array bounds if you want - but you don't have to (and pay the performance penalty) if you don't need to
Martin Beckett
C++ is certainly safer than C in the sense that it gives you the tools to avoid pitfalls such as out of bounds memory accesses.
jalf
A: 

I've always wondered about that quote. I can't think of any way in which C++ is more dangerous than C.

In any case, I have to say the most dangerous "feature" is that there is nothing to stop you from accessing unallocated memory. It is an error that is almost impossible to debug, causes all sorts of random behavior, from crashes to nothing at all to just weird behavior.

jalf
+2  A: 

I passed this to a helper function in another object from a constructor. The helper function added the pointer to a list of objects it was maintaining. Of course, after the constructor finished and returned, the object was located in a very different location in memory and the pointer stored in the other object was no longer valid. Yikes!

Nick Lewis
Is that true? :-|
fortran
It's never safe to leak "this" out of a constructor. Particularly not in a multi-threaded environment, in which case the object may be partially constructed or only partially visible.. Objects cannot be assumed to be fully constructed until after the constructor has returned (this is also true of Java and C#).
Nick Lewis
Sounds like you have had a bug.
Artem Barger
True passing a 'this' of a partially constructed object can be dangerious, but I have never considered (nor currently believe) that the object will be moved during construction. That would have too many implications on member variables that have already been constructed (As part of the address change the members would need to be copy constructed to new locations [simply byte copy is not suffecient in C++]).
Martin York
I don't know for certain that the object was moved, only that the 'this' pointer referred to a different location after the constructor had returned. The pointer I passed and stored referred to a very low memory address, and after returning from the constructor, 'this' referred to a much more ordinary location. This from the VS debugger. In any case, it failed when we tried to call a method with it! I may explore this more thoroughly.. At the time, we just raised our eyebrows, fixed it, and moved on.
Nick Lewis
With multiple inheritance, the address in "this" depends on what class you're currently in. So maybe the call was implicitly casting around a hierarchy, and the conversion used a hidden value that hadn't been initialised?
Steve Jessop
@Nick - this sounds like a potentially interesting problem. Consider posting it as a question here.
Michael Burr
A: 
  • Operator overload if not correctly implemented
  • multiple inheritance (easy to misuse)
  • buffer overflow
Burkhard
+1  A: 

I would have say automatic type conversion. C++ can create temporary variables in unintuitive ways through automatic type conversion.

BeWarned