12 ms·

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases

The bullet list near the end closely matches my own experience with C++. There's an inordinate number of features creating an even worse profusion of edge cases where they interact. Then the "solutions" for those edge cases usually add even more complexity. Worse, they force programmers to coddle their compilers. The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. That's why every C++ codebase I've ever seen is full of code to do things that shouldn't be necessary, and goes through all sorts of contortions to avoid doing things that should be OK, lest the compiler spew out an un-debuggable mess. I'm perfectly happy managing my own complexity in C, or avoiding it entirely in Python. C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Every other "systems programming language" from D to Objective-C to Go to Rust to Nim presents a more coherent face to the programmer.

clishem 9y ago
Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'. > The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. As is the case for any programming language. > C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.
- repsilat 9y ago
  Disclaimer: I don't program in C++ day to day, so maybe my experience is atypical. Moves and rvalue references (and whatever a PR-value is) and even RVO scare me. They make me want to pass pointers around, because at least I know for sure what'll happen then. (And, funnily enough, C++ seems worse than dynamic languages for this -- more magic around function calls and returns than C or Python or JavaScript.)
  - banachtarski 9y ago
    They really aren't that bad... in fact, they're pretty useful. Source: your everyday C++ programmer
    - stochastic_monk 9y ago
      They’re great, really. Yes, it takes effort to master, but then you can generate faster, safer, generic code with much less effort. Source: Another everyday C++ programmer. There are dozens of us. Dozens!
      - verall 9y ago
        It's unfortunate when your codebase is C++03 only and intends to remain that way for compatabillity with other vendors. Yay for consumer electronics!
        banachtarski 9y ago
        Out of curiosity what breaks compatibility?
        verall 9y ago
        My understanding is that there are partner venders who have old toolchains set up only for C++03 and thus would have to upgrade their toolchains to build our API if we upgraded.
  - stinos 9y ago
    scare me ... because at least I know for sure what'll happen then. Which is just because once you learned how pointers behave. Similarly, if you'd just take the time to learn the basics of rvalues, moving, RVO, ..., you won't be scared by them anymore. Might thake longer than pointers, sure, but it's worth it.
    - zach43 9y ago
- snarfy 9y ago
  > C++ is designed by its standards committee... When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.
  - maxxxxx 9y ago
    Definitely agree about the ABI. In C# it's a pleasure to write libraries for others and use other libraries whereas in C++ it's almost always a pain.
    - gpderetta 9y ago
      Standard ABI only makes sense if you are targeting a single system (.NET for C#). That's not the case for C++.
      - snarfy 9y ago
        It would definitely making interop between C# and C++ much easier. It would make interop between C++ and any language much easier. The only way to do it today is to extern "C" everything. It's ugly.
        gpderetta 9y ago
        How would exactly an library compiled for 32 bit big endian POWER interoperate with a program written for 64 bit little endian ARM?
        maxxxxx 9y ago
        This doesn't work with C either or does it? C has a reasonable ABI so maybe we should get to the point where exchanging C++ libraries is as easy as doing this with C
        gpderetta 9y ago
- mannykannot 9y ago
  > I'm interested to hear examples of what you call 'profusion of edge cases'. For one example, look at the profusion of cases in type deduction, depending on whether one is dealing with a value, an array, a pointer, or one of two different references, and whether qualified as const or volatile. One might argue that these cases are too prevalent to be called 'corner' cases, but that doesn't exactly help! In C++11 and C++14 there was the indisputable corner case where auto and template type deduction differed with regard to braced initializer lists, though in a rare case of backwards-compatibility-breaking, it has now been fixed [1]. Scott Meyers, for one, has given examples of particular cases in the use of braced initialization, especially in the context of templates, that can be considered corner cases in that they are probably not likely to arise very often in most of the C++ code that is being written for applications. [1] https://isocpp.org/blog/2014/03/n3922 https://isocpp.org/blog/2014/03/n3922 [2] Scott Meyers, 'Effective Modern C++', pp 52-58.
- zach43 9y ago
  One fairly common example of a bad C++ design edge case is the “Most Vexing Parse” problem [0]. I frequently find myself constructing objects using the () syntax will produce parse errors as the compiler is expecting a function declaration. Then replacing the () with {} just fixes it. It’s really frustrating that bad design like this is just maintained as a stumbling block for new users, instead of being fixed. [0] https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse
api 9y ago
C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.
- convolvatron 9y ago
  just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming. every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good' and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice. i've actually seen some really* clever mixin/metaprogramming with templates. it was a total disaster, and in a different environment it could be a really great approach. i could never understand it in complete detail, but if C is a 38 that you can use to blow your foot off, C++ is a 20ga shotgun with a pound of c4 strapped to your head.
  - WalterBright 9y ago
    > and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice. To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness! I used to do that too, as a young programmer. It took about 10 years to grind that out of me. One advantage of us older programmers is we show how clever we are by writing amazingly simple and understandable code. :-)
    - dingo_bat 9y ago
      > To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness! To be fair, C++ metaprogramming with templates makes C preprocessor look like an insignificant ant in front of a truck.
pjmlp 9y ago
Regarding D, it looks like that, but any big code base enjoys meta-programming (mixins), templates. They have a ton of warts regarding annotations, usually worked around by using templates, because on that case they are inferred. The semantics of shared are still being worked on. The way const/immuatable works, makes some devs just give up and remove them from their code. I can equally tell some Objective-C issues. Yes, in general they are better than C++, but not without their own warts.
- WalterBright 9y ago
  > The way const/immuatable works, makes some devs just give up and remove them from their code. That's true. The thing with D const/immutable is they are transitive, and the compiler means it. It's not a suggestion. The advantage of enforced transitive const/immutable is, of course, is it's foundational if you want to do functional style programming.
WalterBright 9y ago
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to let go of the old decisions. (There's always some major and vocal user who has build their entire store around some ancient feature.) For example, why does C++ still support EBCDIC?
- pjmlp 9y ago
  > For example, why does C++ still support EBCDIC? Because there are companies like Unisys and IBM that want to sell C++ compilers to their mainframe customers.
  - WalterBright 9y ago
    IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-) Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.
    - jcelerier 9y ago
      > No need to burden the rest of the community with it. yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2910.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291...
      - gpderetta 9y ago
hux_ 9y ago
Oh give me a break. Following this logic, why aren't you writing your code in English? The real world is complex. Don't confuse hiding complexity with minimizing complexity.
- coldtea 9y ago
  >Following this logic, why aren't you writing your code in English? Because slippery slope arguments never shone light on any situation. >The real world is complex. Which is neither here, nor there. We're talking about programming languages -- where you can be 10x as complex as another, but as long as you're both Turing Complete, you can't really do anything substantially more. So, this is not about more power to handle "the real world", but about ergonomics. Which nobody ever said were C++ strong point. >Don't confuse hiding complexity with minimizing complexity. Well, we should also not confuse adding complexity with adding expressiveness.
- jejones3141 9y ago
  See Brooks's "No Silver Bullet". C++'s complexity is accidental.
  - mar77i 9y ago
    I thought of Brooks when I saw the title; as I mentioned in my other comment, I see a kind of amusing pendant to Conway's law here: a complex programming language will produce a complex codebase.
anfilt 9y ago
>"C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security." It's not what a compiler writer would want by any stretch. Having helped write a C++ compiler I can a test to that. I will agree that C is a nice language. It does exactly as you tell it. The complexity I would say is what you get when you "design by committee" Web standards have a similar problem they keep growing and getting more complex. Try to write a browser from the ground up these days.
mikevm 9y ago
How is Rust less complicated than C++? I don't use it, but from what I read it seems to be even more complicated, and getting even more so with the myriad of features they are adding each release.
- isido 9y ago
  A good, but difficult question - it's difficult to quantize complexity. Both languages have aim that their users can have much as much control as possible, even if it entails complexity in the language desing. Perhaps one answer could be, that much of Rust's complexity arises from the concepts of 'borrowing' and 'lifetimes' and how they are encoded in the language. In C++, complexity much of the complexity arises from the copy/reference semantics, and the possibility of overriding standard behaviour. You need to have wider context to understand local code. So you need to understand how the C++ works on quite a low level and you might need to know more specifics on your C++ codebase than might be the case in Rust.
- masklinn 9y ago
  > How is Rust less complicated than C++? In pretty much all senses of the word? > getting even more so with the myriad of features they are adding each release. It's far from adding a "myriad of features" with each release, and most of those it adds are library stuff, see for 1.23: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1230-2018-01-04 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... And with respect to non-library features currently in-flight, by and large they are "playing catch-up" to C/C++ for compatibility or to fulfil use cases for which the language is not currently convenient or sufficient e.g. generics-over-values, const functions, allocators. Rust has an upfront feeling of complexity in lifetimes and the borrow checker, but here's the ugly truth: pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them.
  - jhasse 9y ago
    > pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them. There's also the case though where the Rust compiler isn't helping you, but is just wrong. Must of them are going to be fixed by non-lexical lifetimes soon though.
jejones3141 9y ago
> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. If that were the case, the Edison Design Group (https://en.wikipedia.org/wiki/Edison_Design_Group https://en.wikipedia.org/wiki/Edison_Design_Group) wouldn't exist. It exists because compiler writers don't want to have to deal with parsing C++. (Then there's Dinkumware, which serves the same purpose for library functions.)
cageface 9y ago
C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.
- TheArcane 9y ago
  Robotics is pretty much exlusively in C++ as well.
- pjmlp 9y ago
  Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.
  - Gibbon1 9y ago
    I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded. The thing with embedded is you have two cases, hard real time and just don't care.
    - pjmlp 9y ago
      They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time. Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java. Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things. Then there are some OEMs still selling Basic, Pascal and Oberon compilers. But in what concerns embedded domains where only Assembly and C get used, currently C++ seems to be the only one that they care to adopt. Specially given that it already enjoys the same kind of safety regulations (MISRA, DOJ and similar). And not everyone mind you, C++ conferences keep having sessions on how to advocate to those devs.
osullivj 9y ago
Strongly agree on the inordinate number of features point. Which other mainstream OO language supports dynamic & static dispatch, single & multiple inheritance, interface inheritance via abstract classes, generic types and functions via templates, lambdas, type inference, and operator overloading? Roll that up with C compatibility, a 30 year history of evolution, and the complexity of commonly adopted libraries like STL & Boost, and there's simply no avoiding it. There's a lot of C++ out there, and I'm confident that will pay the bills for years to come for this 50 something 25 year C++ veteran!
- nextos 9y ago
  I think that's spot on. I coded quite a lot of C++ in the early 2000s. Now I'm considering to jump onboard again. C++11 and successors are almost a different language. More importantly, for my niche I don't see anything that can readily replace C++. Rust has very little support for scientific computing. Julia is great, and will replace my high level statistical inference code, but it's not designed to let me design low-level close-to-the-metal data structures. Scala has memory issues, which will be hopefully less problematic once value types are implemented in the JVM. OCaml and F# look interesting, I haven't evaluated these carefully.
  - poster123 9y ago
    If you are doing scientific computing, have you considered Fortran? The gfortran (GCC Fortran) compiler supports Fortran 2003, which has object-oriented features, and since Fortran 90 the language has had array operations and syntax similar to Matlab or Python with numpy.
    - nextos 9y ago
      I'm not a big fan of Fortran for my particular domain, which includes lots of strings (biological sequences). Here Fortran is not as quick. See for example the k-nucleotide benchmark: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide https://benchmarksgame.alioth.debian.org/u64q/performance.ph...
oselhn 9y ago
I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of undefined behavior (almost the same as C++)
- stinos 9y ago
  Never really had a problems with the lack of namespaces actually (and not due to insanely prefixed names), if everything is properly seperated there just doesn't seem to be enough chances for name clashes: headers should have only things which really are publicly needed, sources should only include headers they need, and one of the design targets should be high cohesion/low coupling. Though it probably depends on the project.
- notacoward 9y ago
  All your complaints about C are valid, except I'd say defined but stupid behavior buried somewhere in a gargantuan language spec is effectively the same as undefined behavior. The difference is, C lets you control how much baggage you carry along and C++ doesn't. If I want a higher-level abstraction in C, I can usually implement it pretty well using inlines and macros, void and function pointers. Will it be pretty? Hell no. Will it have all of the syntactic sugar that the C++ version does? Nope. But it will work and be usable and most importantly the complexity/risk that it carries along will be exactly what I asked for (because I know how to manage it). Using a feature in C++ means carrying along all of the baggage from its dependencies and interactions with every other feature. If programming languages were cars, it's like the dealer saying I can't add one option to the base model. No, I have to buy the top-of-the-line model with dozens of features I don't actually care about and will never use, costing far more and oh by the way that model has door handles that will cut you. That's about when I go to the Python dealership down the street, or just stick with good old C.
  - AnimalMuppet 9y ago
viperscape 9y ago
Not to do the c vs c++ thing, I too prefer c. For over 20 years actually I have preferred c to c++; all the while learning and enjoying other languages like rust. c still is missing some crucial stuff in my opinion-- there are times where I wish generics existed, and when you tie that to a trait system like in rust it's really a pity to not have something like that in c. Couple that with really great package managers for libraries in other languages, and a coherent way to use the libraries, makes one long for more when working in c; it's really missing great and easy code sharing that so many other languages have at their front and center.
- earenndil 9y ago
  > there are times where I wish generics existed They kinda do...

clishem 9y ago

Sure, it's a large and complex language that takes time to master. But I'm interested to hear examples of what you call 'profusion of edge cases'. > The ratio between what a C++ compiler will accept and what it will produce sane code for is huge. As is the case for any programming language. > C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. C++ is designed by its standards committee... If you know anything about the struggles compiler writers have had with implementing the standard, you'd know the standards committee definitely does not consist of compiler writers! It's really cheap to summarize their efforts as motivated by advancing their own job security if you ask me... I can recommend you to attend a meeting or to read some proceedings to convince yourself otherwise.

repsilat 9y ago
Disclaimer: I don't program in C++ day to day, so maybe my experience is atypical. Moves and rvalue references (and whatever a PR-value is) and even RVO scare me. They make me want to pass pointers around, because at least I know for sure what'll happen then. (And, funnily enough, C++ seems worse than dynamic languages for this -- more magic around function calls and returns than C or Python or JavaScript.)
- banachtarski 9y ago
  They really aren't that bad... in fact, they're pretty useful. Source: your everyday C++ programmer
  - stochastic_monk 9y ago
    They’re great, really. Yes, it takes effort to master, but then you can generate faster, safer, generic code with much less effort. Source: Another everyday C++ programmer. There are dozens of us. Dozens!
    - verall 9y ago
      It's unfortunate when your codebase is C++03 only and intends to remain that way for compatabillity with other vendors. Yay for consumer electronics!
      - banachtarski 9y ago
        Out of curiosity what breaks compatibility?
        verall 9y ago
        My understanding is that there are partner venders who have old toolchains set up only for C++03 and thus would have to upgrade their toolchains to build our API if we upgraded.
- stinos 9y ago
  scare me ... because at least I know for sure what'll happen then. Which is just because once you learned how pointers behave. Similarly, if you'd just take the time to learn the basics of rvalues, moving, RVO, ..., you won't be scared by them anymore. Might thake longer than pointers, sure, but it's worth it.
  - zach43 9y ago
snarfy 9y ago
> C++ is designed by its standards committee... When it comes to design, C++ is a good example of why having a benevolent dictator is better than a committee. I still think it's a huge mistake to not have a standard ABI and rely on C's ABI.
- maxxxxx 9y ago
  Definitely agree about the ABI. In C# it's a pleasure to write libraries for others and use other libraries whereas in C++ it's almost always a pain.
  - gpderetta 9y ago
    Standard ABI only makes sense if you are targeting a single system (.NET for C#). That's not the case for C++.
    - snarfy 9y ago
      It would definitely making interop between C# and C++ much easier. It would make interop between C++ and any language much easier. The only way to do it today is to extern "C" everything. It's ugly.
      - gpderetta 9y ago
        How would exactly an library compiled for 32 bit big endian POWER interoperate with a program written for 64 bit little endian ARM?
        maxxxxx 9y ago
        This doesn't work with C either or does it? C has a reasonable ABI so maybe we should get to the point where exchanging C++ libraries is as easy as doing this with C
        gpderetta 9y ago
mannykannot 9y ago
> I'm interested to hear examples of what you call 'profusion of edge cases'. For one example, look at the profusion of cases in type deduction, depending on whether one is dealing with a value, an array, a pointer, or one of two different references, and whether qualified as const or volatile. One might argue that these cases are too prevalent to be called 'corner' cases, but that doesn't exactly help! In C++11 and C++14 there was the indisputable corner case where auto and template type deduction differed with regard to braced initializer lists, though in a rare case of backwards-compatibility-breaking, it has now been fixed [1]. Scott Meyers, for one, has given examples of particular cases in the use of braced initialization, especially in the context of templates, that can be considered corner cases in that they are probably not likely to arise very often in most of the C++ code that is being written for applications. [1] https://isocpp.org/blog/2014/03/n3922 https://isocpp.org/blog/2014/03/n3922 [2] Scott Meyers, 'Effective Modern C++', pp 52-58.
zach43 9y ago
One fairly common example of a bad C++ design edge case is the “Most Vexing Parse” problem [0]. I frequently find myself constructing objects using the () syntax will produce parse errors as the compiler is expecting a function declaration. Then replacing the () with {} just fixes it. It’s really frustrating that bad design like this is just maintained as a stumbling block for new users, instead of being fixed. [0] https://en.wikipedia.org/wiki/Most_vexing_parse https://en.wikipedia.org/wiki/Most_vexing_parse

api 9y ago

C++ is a language with a lot of features, and not all of them should be used in every code base. It's quite possible to write simple, portable, and relatively clean C++ code if you use only those features you need. It's not the prettiest language by any stretch, but it's quite capable and fast and has excellent support across just about every platform.

convolvatron 9y ago
just a contrary opinion. I read the c++ book in the very early 90s. someone told me it was the future of programming. every single c++ shop I've worked at since has said, 'well, yes the language is a mess, but if you stick to a well controlled subset, its really pretty good' and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice. i've actually seen some really* clever mixin/metaprogramming with templates. it was a total disaster, and in a different environment it could be a really great approach. i could never understand it in complete detail, but if C is a 38 that you can use to blow your foot off, C++ is a 20ga shotgun with a pound of c4 strapped to your head.
- WalterBright 9y ago
  > and all of those shops, without exception, have dragged in every last weird and contradictory feature of what is a really enormous language. so I guess the 'sane subset' argument is ok in theory, but really not in practice. To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness! I used to do that too, as a young programmer. It took about 10 years to grind that out of me. One advantage of us older programmers is we show how clever we are by writing amazingly simple and understandable code. :-)
  - dingo_bat 9y ago
    > To be fair, this happens with every language I've been associated with, even C. Just look at those people who do metaprogramming with the C preprocessor. It's madness! To be fair, C++ metaprogramming with templates makes C preprocessor look like an insignificant ant in front of a truck.

pjmlp 9y ago

Regarding D, it looks like that, but any big code base enjoys meta-programming (mixins), templates. They have a ton of warts regarding annotations, usually worked around by using templates, because on that case they are inferred. The semantics of shared are still being worked on. The way const/immuatable works, makes some devs just give up and remove them from their code. I can equally tell some Objective-C issues. Yes, in general they are better than C++, but not without their own warts.

WalterBright 9y ago
> The way const/immuatable works, makes some devs just give up and remove them from their code. That's true. The thing with D const/immutable is they are transitive, and the compiler means it. It's not a suggestion. The advantage of enforced transitive const/immutable is, of course, is it's foundational if you want to do functional style programming.

WalterBright 9y ago

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. Being a C++ compiler writer (Zortech C++, Symantec C++, Digital Mars C++) I can assure you this is not true at all. As to why C++ is so complex, my opinion is it is because it was designed a long time ago, what is considered better practice in designing languages has moved on, and C++ is unwilling to let go of the old decisions. (There's always some major and vocal user who has build their entire store around some ancient feature.) For example, why does C++ still support EBCDIC?

pjmlp 9y ago
> For example, why does C++ still support EBCDIC? Because there are companies like Unisys and IBM that want to sell C++ compilers to their mainframe customers.
- WalterBright 9y ago
  IBM can support it as an extension in their C++ compiler. No need to burden the rest of the community with it. It's not like C++ compiler vendors are shy about adding extensions :-) Despite C++ supporting EBCDIC, I seriously doubt the overwhelming majority of string processing C++ code will work with EBCDIC anyway, because the programmers probably never heard of it, let alone tested the software with it.
  - jcelerier 9y ago
    > No need to burden the rest of the community with it. yeah, the problem is when IBM goes with big checks to national standard bodies and complains "muuuuhh we won't be able to assure that the systems we sold you in 1970 will still work in 20 years if the C++ standard removes support for EBCDIC" and then these standard bodies write strongly-worded letters to the ISO commitee: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2910.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n291...
    - gpderetta 9y ago

hux_ 9y ago

Oh give me a break. Following this logic, why aren't you writing your code in English? The real world is complex. Don't confuse hiding complexity with minimizing complexity.

coldtea 9y ago
>Following this logic, why aren't you writing your code in English? Because slippery slope arguments never shone light on any situation. >The real world is complex. Which is neither here, nor there. We're talking about programming languages -- where you can be 10x as complex as another, but as long as you're both Turing Complete, you can't really do anything substantially more. So, this is not about more power to handle "the real world", but about ergonomics. Which nobody ever said were C++ strong point. >Don't confuse hiding complexity with minimizing complexity. Well, we should also not confuse adding complexity with adding expressiveness.
jejones3141 9y ago
See Brooks's "No Silver Bullet". C++'s complexity is accidental.
- mar77i 9y ago
  I thought of Brooks when I saw the title; as I mentioned in my other comment, I see a kind of amusing pendant to Conway's law here: a complex programming language will produce a complex codebase.

anfilt 9y ago

>"C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security." It's not what a compiler writer would want by any stretch. Having helped write a C++ compiler I can a test to that. I will agree that C is a nice language. It does exactly as you tell it. The complexity I would say is what you get when you "design by committee" Web standards have a similar problem they keep growing and getting more complex. Try to write a browser from the ground up these days.

mikevm 9y ago

How is Rust less complicated than C++? I don't use it, but from what I read it seems to be even more complicated, and getting even more so with the myriad of features they are adding each release.

isido 9y ago
A good, but difficult question - it's difficult to quantize complexity. Both languages have aim that their users can have much as much control as possible, even if it entails complexity in the language desing. Perhaps one answer could be, that much of Rust's complexity arises from the concepts of 'borrowing' and 'lifetimes' and how they are encoded in the language. In C++, complexity much of the complexity arises from the copy/reference semantics, and the possibility of overriding standard behaviour. You need to have wider context to understand local code. So you need to understand how the C++ works on quite a low level and you might need to know more specifics on your C++ codebase than might be the case in Rust.
masklinn 9y ago
> How is Rust less complicated than C++? In pretty much all senses of the word? > getting even more so with the myriad of features they are adding each release. It's far from adding a "myriad of features" with each release, and most of those it adds are library stuff, see for 1.23: https://github.com/rust-lang/rust/blob/master/RELEASES.md#version-1230-2018-01-04 https://github.com/rust-lang/rust/blob/master/RELEASES.md#ve... And with respect to non-library features currently in-flight, by and large they are "playing catch-up" to C/C++ for compatibility or to fulfil use cases for which the language is not currently convenient or sufficient e.g. generics-over-values, const functions, allocators. Rust has an upfront feeling of complexity in lifetimes and the borrow checker, but here's the ugly truth: pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them.
- jhasse 9y ago
  > pointer lifetime issues don't exist any less in C++, the only difference is the compiler doesn't help you with them. There's also the case though where the Rust compiler isn't helping you, but is just wrong. Must of them are going to be fixed by non-lexical lifetimes soon though.

jejones3141 9y ago

> C++, on the other hand, seems to have been designed by compiler writers for their own enjoyment and/or job security. If that were the case, the Edison Design Group (https://en.wikipedia.org/wiki/Edison_Design_Group https://en.wikipedia.org/wiki/Edison_Design_Group) wouldn't exist. It exists because compiler writers don't want to have to deal with parsing C++. (Then there's Dinkumware, which serves the same purpose for library functions.)

cageface 9y ago

C++ is a mess but it's one of the few languages that gives you low-level control of memory and fast code with zero or near zero cost abstractions. So for a certain class of application it's still the best choice. Music software, for example, is pretty much exclusively written in C++. I don't enjoy C++ the language very much but you can build some very cool things with it. Personally I'm hoping Rust displaces it from most of these remaining niches but even if it does it will probably happen slowly.

TheArcane 9y ago
Robotics is pretty much exlusively in C++ as well.
pjmlp 9y ago
Very very slowly. Only now embedded development is starting to accept C++, and C still rules there anyway. Which means it took about 20 years to reach this point. And still Rust will need to go through the same certification processes that C, C++, Ada and Java enjoy for such scenarios.
- Gibbon1 9y ago
  I feel like embedded development should just avoid c++ and go with a managed languages. I was hopeful abut go, but they kinda wrecked it for embedded. The thing with embedded is you have two cases, hard real time and just don't care.
  - pjmlp 9y ago
    They go with Java in very specific cases, but you need big bucks to pay for something like PTC Perc Ultra, JamaicaVM or WebSphere Real Time. Then there is microEJ as well, but their target is that performance critical code is anyway written in C and exposed to Java. Also depending how embedded one might consider mobile phone hardware, there is Android and Android Things. Then there are some OEMs still selling Basic, Pascal and Oberon compilers. But in what concerns embedded domains where only Assembly and C get used, currently C++ seems to be the only one that they care to adopt. Specially given that it already enjoys the same kind of safety regulations (MISRA, DOJ and similar). And not everyone mind you, C++ conferences keep having sessions on how to advocate to those devs.

osullivj 9y ago

Strongly agree on the inordinate number of features point. Which other mainstream OO language supports dynamic & static dispatch, single & multiple inheritance, interface inheritance via abstract classes, generic types and functions via templates, lambdas, type inference, and operator overloading? Roll that up with C compatibility, a 30 year history of evolution, and the complexity of commonly adopted libraries like STL & Boost, and there's simply no avoiding it. There's a lot of C++ out there, and I'm confident that will pay the bills for years to come for this 50 something 25 year C++ veteran!

nextos 9y ago
I think that's spot on. I coded quite a lot of C++ in the early 2000s. Now I'm considering to jump onboard again. C++11 and successors are almost a different language. More importantly, for my niche I don't see anything that can readily replace C++. Rust has very little support for scientific computing. Julia is great, and will replace my high level statistical inference code, but it's not designed to let me design low-level close-to-the-metal data structures. Scala has memory issues, which will be hopefully less problematic once value types are implemented in the JVM. OCaml and F# look interesting, I haven't evaluated these carefully.
- poster123 9y ago
  If you are doing scientific computing, have you considered Fortran? The gfortran (GCC Fortran) compiler supports Fortran 2003, which has object-oriented features, and since Fortran 90 the language has had array operations and syntax similar to Matlab or Python with numpy.
  - nextos 9y ago
    I'm not a big fan of Fortran for my particular domain, which includes lots of strings (biological sequences). Here Fortran is not as quick. See for example the k-nucleotide benchmark: https://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide https://benchmarksgame.alioth.debian.org/u64q/performance.ph...

oselhn 9y ago

I agree that C++ is bad but I actually find C much worse for projects bigger than a few thousands of lines. Reasons for this: * lack of namespaces - all names with long prefix look the same to me * just text based macros * no generics * error handling usually based on int constants and output function parameters - in big projects is hard to use them consistently without any type checking * no polymorphism * ton of undefined behavior (almost the same as C++)

stinos 9y ago
Never really had a problems with the lack of namespaces actually (and not due to insanely prefixed names), if everything is properly seperated there just doesn't seem to be enough chances for name clashes: headers should have only things which really are publicly needed, sources should only include headers they need, and one of the design targets should be high cohesion/low coupling. Though it probably depends on the project.
notacoward 9y ago
All your complaints about C are valid, except I'd say defined but stupid behavior buried somewhere in a gargantuan language spec is effectively the same as undefined behavior. The difference is, C lets you control how much baggage you carry along and C++ doesn't. If I want a higher-level abstraction in C, I can usually implement it pretty well using inlines and macros, void and function pointers. Will it be pretty? Hell no. Will it have all of the syntactic sugar that the C++ version does? Nope. But it will work and be usable and most importantly the complexity/risk that it carries along will be exactly what I asked for (because I know how to manage it). Using a feature in C++ means carrying along all of the baggage from its dependencies and interactions with every other feature. If programming languages were cars, it's like the dealer saying I can't add one option to the base model. No, I have to buy the top-of-the-line model with dozens of features I don't actually care about and will never use, costing far more and oh by the way that model has door handles that will cut you. That's about when I go to the Python dealership down the street, or just stick with good old C.
- AnimalMuppet 9y ago

viperscape 9y ago

Not to do the c vs c++ thing, I too prefer c. For over 20 years actually I have preferred c to c++; all the while learning and enjoying other languages like rust. c still is missing some crucial stuff in my opinion-- there are times where I wish generics existed, and when you tie that to a trait system like in rust it's really a pity to not have something like that in c. Couple that with really great package managers for libraries in other languages, and a coherent way to use the libraries, makes one long for more when working in c; it's really missing great and easy code sharing that so many other languages have at their front and center.

earenndil 9y ago
> there are times where I wish generics existed They kinda do...