The hidden cost of C++

General Discussions
#81

The hidden cost are your headaches if you get C++ code from someone who uses a different set of C++ features to achieve some effect than you use to use. C++ has so many ways to do something, and different people will use different approaches. To read, understand and extend foreign C++ code you really must have coverage all of C++ features :expressionless:

I like Java for the fact that it is leaner and simpler than C++, syntax-wise.

Templates and overloaded operators are perfect tools to code pitfalls for other programmers. You never will know if an operator symbol is overloaded for the types left and right, or if it really means what it seems to mean.

#82

Broken compiler?

Cas :slight_smile:

#83

Broken spec. It’s ambiguous in current C++ whether it should be parsed as multiple nested <> or an insertion operator >>

They’ve fixed it in 0x I believe.

#84

What I don’t like about C++

  • string doesn’t have standard upper/lower case functions? I remember I had to port Microsoft C++ code to UNIX, and a simple upper case (with full internationalization) required completely different implementations on different compilers and OSs.
  • string isn’t immutable! Why on earth would they have a mutable non-thread safe string?!?
  • Collections library is overly complex, and lacking in features. No persistent immutable?
  • Basic multi-threading + networking aren’t in standard library or language. Usually involves platform specific tools.
  • No outer variable capture for inner functions. Even Java has allowed final outer variable capture since 1.1 I believe.
  • Extremely confusing syntax for lambdas and first order functions.
  • Macro system.
  • Most production code must be littered with vendor specific language hacks like __declspec and #pragma.
  • Language syntax, particularly, the wide open macro system, is very unfriendly to fancy IDE features and tool supprt.
  • Build tools are extremely primitive by Java standards. They have nothing close to even basic Maven, much less SBT or Gradle.
  • Array syntax is counterintuitive. int array[] rather than int[] array.
  • Array system is completely separate and disjoint from the template system.
  • Has both structs and classes.
  • Internal name mangling. Many times I had to learn and parse the internal name mangling system of Microsoft C++ tools to understand a build error.
  • Separate primitive and class types.
  • Marshalling memory across DLL boundaries.
#85

Want to see something really weird? C++ lets you write the array access backwards. ie.


char[] array = "hello";
int index = 4;

char ch1 = array[index]; // 'ch1' is 'o'
char ch2 = index[array]; // same as above

No, I have never found a use for this.

#86

If my understanding is correct, that only holds true for when the sizeof() the datatype of the array is equal to 1?
Otherwise the pointer arithmetic would be wrong.

#87

That would make sense. Unsurprisingly I’ve only ever used it in a toy example to prove to myself someone wasn’t yanking my chain.

It’s quite illustrative of the half-assed ‘features’ C++ is riddled with though. And you kinda have to know about them all even if you never use them, just in case you find someone who’s actually used it.

#88

I think it’s actually interpreted as “+” operator between the operands, and the array name is a pointer to the element type. So you have “int” + “pointer” or “pointer” + “int” and that should work for type sizes other than 1 too … anyways, one more reasons to be suspicious about C++ syntax :-\

#89

That’s actually one of the reasons I do and don’t like c/c++, pointers are “open access.” You can type cast anything to anything, but you have to remember what you’ve cast something as or you’ll access part of something else … maybe even part of another program.

I think you’re looking for “pointer + sizeof class,” but I’m late into the conversation so I could be wrong.

#90

I think that doesn’t make sense at all. :-\

#91

The ambiguity of the >> and >>> is a fault of the overriding of operators, this is both a strength and a weakness. Java avoids this by not allowing operator overriding, one of the many aspects of Java I like. Overriding operators does make more compact source code, but in reality it doesn’t make things more readable and just offers certain flaws such as the above nuance.

#92

Operator overloading isn’t the problem. An ambiguous syntax is.

#93

C++ is actually fairly strict about that sort of thing with normal casts (C-style or static_cast<>), much more so than C is. Now there is reinterpret_cast<> which really is an anything-to-anything cast, but it’s got a clunky distinctive name like that for a reason.

What does kill me about C is stuff like slicing, which you can only seem to avoid by using pointers. That and implicit copy constructors – at least Scala’s implicit conversions require an ‘implicit’ keyword, C++ forces you to opt out with ‘explicit’.

#94

It doesn’t have to, because it’s not the case anymore. GCC fixed it a long time ago, and it’s part of the C++ standard. It’s also got jack shit to do with operator overloading, it’s ambiguity at the lex/parse level. Incidentally, the ambiguity is with >>, C++ does not have a >>> operator.

#95

Now, it is certainly inconvenient when a parser/compiler does this kind of thing, but it isn’t hard to understand why.

If you have trouble understanding the reason why these inconveniences happen, then maybe you are the problem?

Not trying to be smug or anything. In my experience with different languages, a big part of the development process is finding ways to work around limitations (usually cursing all the way through).

#96

Recognising ones own limitations as well as others is a very positive attitude to have in life, though. I recognised years ago that C++ was basically too difficult for me to get anything done in, in any reasonable length of time. So I picked something much simpler to work with.

Cas :slight_smile:

#97

Indeed.

I personally have an irrational love for C++, but still prefer to start development in Java until I have a good idea of what I’m doing, before even attempting to get knee-deep in segmentation faults.

#98

It’s good to be lazy sometimes :wink: