Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 23 down vote favorite

Which is the most hated C++ feature that C++ programmers can't avoid using?

share|improve this question
3  
Good question, +1 from me! – sbi Dec 12 '10 at 9:22
3  
Reading through these answers, it seems like what most people hate about C++ is that it's based on C. – chrisaycock Dec 12 '10 at 19:51
5  
I wonder how many downvotes the answer "C++. All of it." would get me? – user281377 Dec 12 '10 at 21:51
1  
@ammoQ: at least you'll get an upvote, from me. – M.H Dec 12 '10 at 23:02
show 1 more comment

closed as not constructive by Aaronaught, Walter, Mark Trapp Jul 2 '11 at 8:20

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.

19 Answers

up vote 30 down vote accepted

I have learned to hate implicit conversions in every form. In the long run, they are a PITA and not worth at all the 'simplifications' they offer. Having to type a few characters more is well worth the added clarity of code.

Yet, I have to deal with all built-in ones and those (knowingly and unknowingly) added by class designers.

share|improve this answer
8  
I agree, even the built-in conversions don't seem to be worth it. It's hard to remember when they kick in... and certainly not obvious at a glance. – Matthieu M. Dec 12 '10 at 16:12
up vote 28 down vote

I am no C++ expert, but this is what I find problematic:

Preprocessor Directives

Why?

When header guard name collisions happen, they lead to hard to understand errors for which the compiler typically provides worse than useless diagnostics.

share|improve this answer
4  
@Job that is not portable. – alternative Dec 12 '10 at 14:57
7  
@haylem: no don't, you've just use a reserved identifier... Identifiers containing two consecutives underscores or beginning by an underscore followed by an uppercase are reserved to the compiler implementers (for the Standard Library). – Matthieu M. Dec 12 '10 at 16:10
2  
LOL, this is why the compiler is BEST at managing this. Manual guards have a chance of failure, and introduce a maintenance nightmare. – Job Dec 12 '10 at 16:26
13  
I'd nominate the preprocessor as a whole. It's a pile of junk, and the only useful parts for C++ are file includes and conditional compilation. – David Thornley Dec 12 '10 at 17:26
4  
@David Thornley, wouldn't you miss the challenge of discovering that MSFT had redefined large/small/min/max somewhere deep in a header file? – Martin Beckett Jun 13 '11 at 16:49
show 11 more comments
up vote 19 down vote

For me, easily the fact that pointers are a type but the syntax makes it look like a property of the variable name.

int x, y;

creates two ints. Great!

int* x, y;

creates ... an int pointer and an int. WTF?!?

Thus good practice is to associate the pointer with the variable name, like so:

int *x, *y;

Just plain stupid.

share|improve this answer
2  
The int *x, *y form is confusing, because the type information is split ("pointer to an int"). – fish Dec 12 '10 at 18:43
8  
That's one reason I've taken to usually having one declaration per line, to avoid the problem (note the use of "avoid" rather than "solve"). – David Thornley Dec 13 '10 at 16:10
2  
It can also be viewed as both *x and *y are int, so its not terribly bad. I actually like it. In any case, you probably shouldn't be declaring two pointers on the same line for clarity. – alternative Dec 13 '10 at 16:14
1  
Declarations in C are expression-centric (as opposed to object-centric), so declarations in C++ are also expression-centric. Probably not the best paradigm for an OOPL, but once you figure it out it does make sense. If you have a pointer to an int and you want to get at the int value, you use the * operator to deference the pointer; IOW, the type of the expression *x is int, so the declaration of the pointer is int *x. – John Bode Jun 13 '11 at 18:23
show 2 more comments
up vote 15 down vote

None.

Seriously, I can't think of a C++ feature that would be both (1) hated and (2) unavoidable. As C++ is a language with which many different paradigm can be used, many of its features can be avoided: you don't have to use the STL, you don't even have to write classes (although you're then mostly back to C, etc.

share|improve this answer
5  
You do have a point, but it's certainly not true for all of the language. There are things that are only there for backwards compatibility, but which no one in their right mind would design into a new language. For starters, there's C's insane declaration syntax. (With type modifiers belonging to the variable declared, not the type. How stupid is that?) And what about one-argument constructors being implicit conversion operators unless forbidden by explicit? Who in their right mind would actually want this in new code? C++ is one big a compromise and has certainly many quirks like this. – sbi Dec 12 '10 at 16:44
show 1 more comment
up vote 11 down vote

I'm not an expert, but I find it very hard using string manipulation/processing libraries.

share|improve this answer
2  
Especially if you've used to dynamic languages like Python where string manipulation is extremely powerful. – Oliver Weiler Dec 12 '10 at 11:58
4  
How about using the boost library? – Job Dec 12 '10 at 14:40
6  
2  
... and boost::xpressive are all to some extent string manipulation libraries. – Billy ONeal Dec 19 '10 at 4:19
show 2 more comments
up vote 11 down vote

The C bit. Unfortunately that's the best bit too.

Clarification.

Bad

  • C++ is an OO language without an object model.
  • You can mess about with objects by accessing the memory that holds them.
  • Refactoring tools are impossible because you can't guarantee that the type of an 'object' hasn't been changed.
  • The builtin types aren't objects.
  • Accessing 'nil' will crash your program.
  • C programmers think it's just like C.

Good

  • C++ would never have caught on if it wasn't so familiar to C programmers.
  • And it's fast
share|improve this answer
6  
@nayan: actually OOP is not what I prefer in C++, generic programming replacing macros on the other seems very worthy. – Matthieu M. Dec 12 '10 at 16:13
show 1 more comment
up vote 10 down vote

Header files. What's the point?

share|improve this answer
1  
Efficient single-pass compilation is impossible without headers (or rather, pre-declaration/something similar). – Matthew Read Apr 4 '11 at 19:36
3  
C++ has the slowest compilation time of all the languages I have ever used. Can someone explain why? – Davor Ždralo Jun 13 '11 at 16:05
2  
@Davor: It's because you have to repeatedly parse the same files, just incase someone re-defined a macro earlier. This massively expands the real size of a program's source code. @Matthew Read: Single-pass compilation isn't any faster than multiple-pass compilation. Infact, C++ compiles a good deal slower than many other languages because of single-pass compilation, and it's impossible to measure the quantity of dicking around that it requires. – DeadMG Jun 13 '11 at 16:37
show 4 more comments
up vote 9 down vote

Uninitialized memory

It's crazy that variables and memory allocations can have random data in them. I hate when programs behave non-deterministically.

share|improve this answer
1  
Sadly same is the case with C. – nayan Dec 12 '10 at 10:40
16  
@nayan: C++ must behave this way in order to keep up with C's performance. If C++ did away with uninitialized memory, it would be tempting to use C instead. One of C++'s design goals was to leave no space for another language between C++ and assembly language, so there is no choice but to have the core language features be as fast and unsafe as C. – FredOverflow Dec 12 '10 at 14:34
7  
well, es, it is annoying, but this is after all a systems language. If it starts doing stuff for you, that you don't necessarily want, then you'll pay it in performance and complexity of the compiled code. – haylem Dec 12 '10 at 16:01
1  
@FredOverflow: "there is no choice" - yes there is, it's called a compiler switch. Problem solved. In many cases those kind of "high level design decisions" are important not because people making them are smart, but because all smart people are already booked for programming tasks, and have no time to implement two different solutions at once. – AareP Dec 12 '10 at 17:35
6  
Downvoted for several reasons: 1) "random data" is only partially true. Variables with static storage duration are initialized to zeros on startup. 2) C++ allows for arbitrary mixing of declarations+initializations with code. There is no need to first declare a variable, and initialize it later on. 3) Auto-initialization is often unnecessary overhead. And compiler switch would make the compiler behave in a non-standard way. – zvrba Dec 12 '10 at 17:56
show 4 more comments
up vote 7 down vote

The whole single-dispatch class-crap. I much prefer how LISP-style "classes" [CLOS] work (in a nutshell: multiple-dispatch 'methods' as freestanding functions).

share|improve this answer
3  
Upvoting to counter the downvote. Just because most common O-O languages use single dispatch doesn't mean you can't dislike it in C++. – David Thornley Dec 13 '10 at 16:08
up vote 7 down vote

Several:

  • It's 2011, and we still need to write #include guards in header files.
  • Compiler spew from templates.
  • You essentially need to learn another programming language (Make, cmake, etc) to build any nontrivial program.
share|improve this answer
show 6 more comments
up vote 6 down vote

Exceptions.

I'm not arguing against them, it's just that they exist, and most programmers ignore them, but buying into them has a ripple effect that most programmers don't want to even think about.

Example: floating point exceptions. Does your code handle them explicitly? What happens if it doesn't? Most some programmers just put guard code to prevent divide-by-zero and then hope for the best.

Edit: Overly optimistic statement corrected.

share|improve this answer
up vote 5 down vote 
delete[]

I loathe that, its not nice, its not big and its not clever. Its only there because it was in C, and I think it was broken in C too. The compiler could easily have determined the type of the variable being deleted and free the entire array rather than the first element - especially as the array variable is (obviously) a pointer and the compiler already knows the size to delete.

share|improve this answer
2  
The compiler wouldn't know the size of the array if it needs to be delete[]d in a separate compilation unit from where it's new[]ed. It's a necessary evil because C++ doesn't have a standard GC. (And thank FSM it doesn't.) – greyfade Jun 13 '11 at 15:57
show 2 more comments
up vote 4 down vote

I only worked with C++ briefly in the 90's and i would have to say multiple inheritence. combining several unrelated objects into one and still have a logical and consistent interface to it was too mind bogling for me. I'm much happier with single inheritence with interfaces.

share|improve this answer
18  
I disagree. MI is probably mainly used for a class to implement multiple interfaces, something which is done in languages like Java or C# all the time. MI definitely isn't a blunt tool, but when I need a sharp tool, I'm happy C++ offers me on in its toolbox. – sbi Dec 12 '10 at 9:17
1  
Multiple inheritance may be tricky if you directly use it. But it allows some cool patterns when metaprogramming. See the scattered class hierarchy for example. – happy_emi Dec 12 '10 at 16:47
2  
Why do you have to use MI? You can always use pure abstract base classes as interfaces, and do whatever you'd do in Java or C# from there. I consider it to be extremely useful at times, and to be avoided when not specifically indicated. – David Thornley Dec 12 '10 at 17:22
1  
@Ken: Yup. I've heard so many times about how MI isn't in Java or C# because people didn't like it in C++, when it's just there is a do-it-yourself form. – David Thornley Dec 20 '10 at 15:12
show 1 more comment
up vote 3 down vote

From what I learnt, using unnecessary templates can make debugging hell. But they are required for abstraction.

share|improve this answer
3  
A particular use of templates can't be both "required for abstraction" (a design issue that's entirely up to you) and "unnecessary" at the same time. – Ken Bloom Dec 19 '10 at 0:51
show 1 more comment
up vote 3 down vote

Mixing up C and C++

share|improve this answer
up vote 3 down vote

Templates. For me they are C++ incarnation of C strings; the idea in principle is nice, but they:

  • provoke stupid overuses; I often see complex templates either carefully optimized for months or full of hacks only to handle situations that for sure will never happen
  • make debugging a hell
  • are static and there is no clean way to easy migrate them to a dynamic solution
share|improve this answer
6  
Templates are extremely useful and powerful. My own annoyance comes from the fact that they don't mix well with inheritance, but this will be slightly better in C++0x. – Matthieu M. Dec 12 '10 at 16:15
4  
Templates take some getting used to, but once you get used to them, you find yourself wondering how you ever lived without them. – Stargazer712 Dec 12 '10 at 18:12
1  
@Stargazer712 You've missed my point. – mbq Dec 12 '10 at 21:28
1  
@mbq: If you're referring to other people's code, there's a lot worse they can do than overcomplicated templates, so I still don't see that as a "have to use" problem. Debugging when using library templates is not that hard, in my experience, although you do sometimes have to parse error messages carefully. I still don't understand what you mean by static vs. dynamic here. – David Thornley Dec 13 '10 at 16:07
2  
I think templates elegantly solve a class of problems that in other languages requires horrible hacks to half-way work around. In my mind, only functional languages like Lisp and Haskell surpass C++ templates in power and elegance. But then maybe something is wrong with me. :) – greyfade Jun 13 '11 at 15:54
show 4 more comments
up vote 3 down vote

Pointer and reference idiosyncrasy. I found to have to think extra hard tO figure out if a reference or a pointer is most appropriate.

share|improve this answer
5  
Really? const & to pass a value-only parameter (usually), * if what you're passing can be NULL, & otherwise generally works well. – David Thornley Dec 13 '10 at 16:09
show 1 more comment
up vote 2 down vote

Inheritance should have been better thought I think. There are C++ performance losses due to multiple inheritance.

I don't really know what compromises there could have been on the C++ language, or what could replace class inheritance, but sometime I wonder if is has such a good purpose.

When thinking about the KISS principle, templates and high level class usage makes me wonder...

share|improve this answer
show 1 more comment
up vote 0 down vote

The fact that C and C++ are very different languages.

share|improve this answer
show 2 more comments

Not the answer you're looking for? Browse other questions tagged or ask your own question.