13 ms·

Putting the discussion about C++ memory safety and concurrency issues aside, I am pretty astonished that C++ continues to include bugs where you have two actual

Putting the discussion about C++ memory safety and concurrency issues aside, I am pretty astonished that C++ continues to include bugs where you have two actual language features - not library functions - which on their own work perfectly fine, but combining the two makes the entire thing silently implode. I am trying very hard to imagine any other higher level language where two distinct language features, each used correctly in their own way, can not be safely combined. The only thing that comes to mind are python's default parameters and passing an empty list as one. C offers total freedom in exchange for providing ways to shooting yourself in the foot. All of its "dangerous" features can be used correctly for some benefit. With C++ it feels like to me like that benefit is often lost entirely, and whats left is just incorrect code that for some reason passes by the compiler without error.

masklinn 4y ago
> I am trying very hard to imagine any other higher level language where two distinct features, each used correctly in their own way, can not be safely combined. The only thing that comes to mind are python's default parameters and passing an empty list as one. And even then it's not a bug per-se, at best a misfeature (it can be useful as a performance hack although the performance improvements of global and builtins lookups of 3.11 might finally put that to rest).
avgcorrection 4y ago
There are two sorts of languages: languages with a coherent feature set and those that people actually use. Wait hold on, that doesn’t apply here…
0xbadcafebee 4y ago
I find it unreasonable that every language would have all of its features always compatible. Why can't we just say "don't use X and Y together" ? It might solve a ton of problems. All you have to do is have a big red warning in the manual that says DON'T COMBINE X AND Y, and a language feature that lets you turn on X and turn off Y.
- selfmodruntime 4y ago
  > Why can't we just say "don't use X and Y together"? Because that goes against the most fundamental idea of programming languages that you can build larger abstractions by combining basic building blocks.
  - travisgriggs 4y ago
    Abstractly speaking, what if we consider a "big ball of spaghetti" and "working program" to both be abstractions of just "a program". Now it fits under the larger abstraction umbrella still. :D All other things aside, C++ seems to be the language "to big to fail" and so it just keeps getting more and more features added to keep it competitive.
  - deleted 4y ago
    [deleted]
  - 0xbadcafebee 4y ago
    A half dozen languages already do this and abstractions still work
  - lionkor 4y ago
    Its okay to say "but you cant combine those two". Its also okay to point out that not every feature should be combinable with every other feature, and that needing to do so is likely an indicator of terrible (user-side) software design
    - eru 4y ago
      Then at least the compiler should complain, when you try to combine incompatible features.
- extropy 4y ago
  Sure, here is your Lego set. But do not put while bricks next to red ones or it will explode!
- CJefferson 4y ago
avidphantasm 4y ago
I have returned to using C++ over the last six-months after not using it really since university 20+ years ago. I mostly write Python these days, Java in the past, but have also recently written some moderately complex and unsafe C (e.g., making a parser using flex and bison; doing lots of void* pointer arithmetic to get around not having runtime reflection). I am astonished at the complexity of modern C++. I’ve studied Rust and used some Swift (on an iOS app for a client a couple of years back), and I struggle to “correctly” write code in C++. I feel as if C++ is collapsing under its own weight.
- TremendousJudge 4y ago
  Similar story here. I'm constantly wrestling with the tool more than the actual problem I should be solving
- curtis3389 4y ago
  I programmed in C++ all through college, and I get the same feeling watching its development. TR1 brought the language to a pretty good place with smart pointers, and at first C++11 looked awesome with its type inference features and range-based for loops. But, also in C++11 were tons of weird gotchas with new and old features. The one that comes to mind is the uniform initialization. It was supposed to fix the issues with calling regular constructors, so you could just use the new syntax and not worry. But, they also added initializer lists, and those have issues with uniform initialization, so now you not only need to know all the pre-existing issues with the old syntax, you need to know the new syntax and its issues. This all comes back to C++ refusing to break backwards compatibility, which is great and all, but at this point they've made a language that is only good for job security.
- synergy20 4y ago
  what exactly are them? I'm also back to modern c++ but I plan to only use a subset of the super set to make life easier. for example I don't need write a c++ library so many of the new (meta-template-programming) feature I don't need to pay attention to at least for now. what I really need are RAII, smart pointer, the STL library and algorithms basically, plus simple OOP use cases, those combined are not very complicated to me.
kllrnohj 4y ago
> C offers total freedom in exchange for providing ways to shooting yourself in the foot. All of its "dangerous" features can be used correctly for some benefit. C is pretty archaic in its feature set, so it's not surprising it doesn't have many language features that don't work well together since it doesn't really have any language features in the first place. That's not necessarily a good thing, either, but that's a different discussion. > With C++ it feels like to me like that benefit is often lost entirely, and whats left is just incorrect code that for some reason passes by the compiler without error. That's an odd statement to make here. Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? That said, I do wish C++ hadn't added coroutines in the first place. It feels like a weird addition to the language. Then again, I also wish Rust hadn't added them, either. They are nightmarishly complex in a non-GC'd language, and the benefits are far from clear. The "colored function" problem remains a hotly debated topic, and low-level, performance-focused languages (like C++ & Rust) feel like the very wrong place to hammer on those topics.
- selfmodruntime 4y ago
  > That's an odd statement to make here. Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? Because if you use features that may leak memory, you can still trust yourself as a programmer. If you cant even trust the language / compiler, I would consider that worse. > Then again, I also wish Rust hadn't added them, either I agree.
- dtgriscom 4y ago
  > Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? I'd rephrase "100% broken" as "always does what it says it will", and "10% broken" as "almost always does what it says it will." I'd prefer the former 99% of the time.
  - eru 4y ago
    Well, C still has plenty of undefined behaviours, that may or may not blow up on you.
hellcow 4y ago
> I am trying very hard to imagine any other higher level language where two distinct language features, each used correctly in their own way, can not be safely combined. Handling JavaScript exceptions as opposed to promise rejections in async code is a continual source of pain. They don’t work together. If you do try/catch on async code but forget to call await, catch will never be hit and your program might crash. There appears to be no linter available to detect this. Unless I’ve completely missed something, the interaction between these two features is a terrible design.
dkackman11 4y ago
Agree. Modern C++, and discussions around it, become more esoteric with every revision. As software engineers we should spend our time understanding the esoterica of the problem domain, not the toolset.
- hdjjhhvvhga 4y ago
  I'm of the same opinion. Frankly, when Go first appeared, I felt we would finally get something almost as simple as Python and almost as fast as C. Unfortunately not everything was as nice as I had expected. Still, in that respect it's better than Rust as it makes it easier to focus on the problem rather than the language.
  - _wldu 4y ago
    The complexity of C++0x is one reason Go was created. "For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson 17:45 mark here: https://www.youtube.com/watch?v=sln-gJaURzk https://www.youtube.com/watch?v=sln-gJaURzk
    - tialaramex 4y ago
      For reference of anybody too young to remember: C++0x is what you'd have called what became C++ 11 back when the committee thought it might happen in 2009 or, worst case 2010. The fact that their "2009" standard shipped only in 2011, after ripping out features everybody agreed were good yet never seemed finished, is why they moved to their current "train" model where there's a new C++ every three years, like it or not. The train will leave, if your feature wasn't ready well there's another train in three years.
  - xyzzy4747 4y ago
    I personally still don't understand the benefit of Go vs Java? They seem to accomplish similar things with similar amounts of boilerplate.
eloff 4y ago
I've always thought of C++ as the most complex programming language I know. With each revision it becomes more complex. I gave up and just moved on to Rust a year and a half ago. I have no regrets. C++ has not quite joined Perl, PHP, and Java as languages I will not work with anymore, but it's the next logical candidate.
- spoiler 4y ago
  I've not worked with PHP for over 8 years now, but I hear it's gotten much better recently. It still has issues that are commonly associated with hosting provider configuration/control over the runtime, apparently. (sources are anecdotal; two friends who've had the mental fortitude to stick with the language for so long)
  - jmt_ 4y ago
    PHP 7 & 8 introduce lots of improvements. I used PHP 5 when I got into web dev and remember moving to Python as soon as I could. At work I've had to use PHP 7 and have been very pleasantly surprised at how solid it is. Now that I have more experience than my PHP 5 days, it's become apparent that PHP is very clearly suited for web work and the built-in functions offer many conveniences for such work that simply aren't available in other languages (granted other languages weren't built for web like PHP was). I've been surprised by my speed in PHP and I chalk most of that up to many helpful standard library functions. Even though PHP has a lot of old/compat functions still present I'm always surprised by how little that actually ends up effecting my productivity. So it's not my choice for greenfield projects but I'm not nearly as adverse to it now after working with modern day PHP for a bit.
    - jamesfinlayson 4y ago
      Agreed - I've worked on a few PHP 5 era projects with hand-rolled frameworks and more recently I've worked on a few PHP 7/PHP 8 projects using proper frameworks and it's night and day.
- tasubotadas 4y ago

masklinn 4y ago

> I am trying very hard to imagine any other higher level language where two distinct features, each used correctly in their own way, can not be safely combined. The only thing that comes to mind are python's default parameters and passing an empty list as one. And even then it's not a bug per-se, at best a misfeature (it can be useful as a performance hack although the performance improvements of global and builtins lookups of 3.11 might finally put that to rest).

avgcorrection 4y ago

There are two sorts of languages: languages with a coherent feature set and those that people actually use. Wait hold on, that doesn’t apply here…

0xbadcafebee 4y ago

I find it unreasonable that every language would have all of its features always compatible. Why can't we just say "don't use X and Y together" ? It might solve a ton of problems. All you have to do is have a big red warning in the manual that says DON'T COMBINE X AND Y, and a language feature that lets you turn on X and turn off Y.

selfmodruntime 4y ago
> Why can't we just say "don't use X and Y together"? Because that goes against the most fundamental idea of programming languages that you can build larger abstractions by combining basic building blocks.
- travisgriggs 4y ago
  Abstractly speaking, what if we consider a "big ball of spaghetti" and "working program" to both be abstractions of just "a program". Now it fits under the larger abstraction umbrella still. :D All other things aside, C++ seems to be the language "to big to fail" and so it just keeps getting more and more features added to keep it competitive.
- deleted 4y ago
  [deleted]
- 0xbadcafebee 4y ago
  A half dozen languages already do this and abstractions still work
- lionkor 4y ago
  Its okay to say "but you cant combine those two". Its also okay to point out that not every feature should be combinable with every other feature, and that needing to do so is likely an indicator of terrible (user-side) software design
  - eru 4y ago
    Then at least the compiler should complain, when you try to combine incompatible features.
extropy 4y ago
Sure, here is your Lego set. But do not put while bricks next to red ones or it will explode!
CJefferson 4y ago

avidphantasm 4y ago

I have returned to using C++ over the last six-months after not using it really since university 20+ years ago. I mostly write Python these days, Java in the past, but have also recently written some moderately complex and unsafe C (e.g., making a parser using flex and bison; doing lots of void* pointer arithmetic to get around not having runtime reflection). I am astonished at the complexity of modern C++. I’ve studied Rust and used some Swift (on an iOS app for a client a couple of years back), and I struggle to “correctly” write code in C++. I feel as if C++ is collapsing under its own weight.

TremendousJudge 4y ago
Similar story here. I'm constantly wrestling with the tool more than the actual problem I should be solving
curtis3389 4y ago
I programmed in C++ all through college, and I get the same feeling watching its development. TR1 brought the language to a pretty good place with smart pointers, and at first C++11 looked awesome with its type inference features and range-based for loops. But, also in C++11 were tons of weird gotchas with new and old features. The one that comes to mind is the uniform initialization. It was supposed to fix the issues with calling regular constructors, so you could just use the new syntax and not worry. But, they also added initializer lists, and those have issues with uniform initialization, so now you not only need to know all the pre-existing issues with the old syntax, you need to know the new syntax and its issues. This all comes back to C++ refusing to break backwards compatibility, which is great and all, but at this point they've made a language that is only good for job security.
synergy20 4y ago
what exactly are them? I'm also back to modern c++ but I plan to only use a subset of the super set to make life easier. for example I don't need write a c++ library so many of the new (meta-template-programming) feature I don't need to pay attention to at least for now. what I really need are RAII, smart pointer, the STL library and algorithms basically, plus simple OOP use cases, those combined are not very complicated to me.

kllrnohj 4y ago

> C offers total freedom in exchange for providing ways to shooting yourself in the foot. All of its "dangerous" features can be used correctly for some benefit. C is pretty archaic in its feature set, so it's not surprising it doesn't have many language features that don't work well together since it doesn't really have any language features in the first place. That's not necessarily a good thing, either, but that's a different discussion. > With C++ it feels like to me like that benefit is often lost entirely, and whats left is just incorrect code that for some reason passes by the compiler without error. That's an odd statement to make here. Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? That said, I do wish C++ hadn't added coroutines in the first place. It feels like a weird addition to the language. Then again, I also wish Rust hadn't added them, either. They are nightmarishly complex in a non-GC'd language, and the benefits are far from clear. The "colored function" problem remains a hotly debated topic, and low-level, performance-focused languages (like C++ & Rust) feel like the very wrong place to hammer on those topics.

selfmodruntime 4y ago
> That's an odd statement to make here. Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? Because if you use features that may leak memory, you can still trust yourself as a programmer. If you cant even trust the language / compiler, I would consider that worse. > Then again, I also wish Rust hadn't added them, either I agree.
dtgriscom 4y ago
> Yes this is an unfortunate combination that results in memory leaks, but how is C's "everything is a memory leak" any better? 100% broken is better than 10% broken? I'd rephrase "100% broken" as "always does what it says it will", and "10% broken" as "almost always does what it says it will." I'd prefer the former 99% of the time.
- eru 4y ago
  Well, C still has plenty of undefined behaviours, that may or may not blow up on you.

hellcow 4y ago

> I am trying very hard to imagine any other higher level language where two distinct language features, each used correctly in their own way, can not be safely combined. Handling JavaScript exceptions as opposed to promise rejections in async code is a continual source of pain. They don’t work together. If you do try/catch on async code but forget to call await, catch will never be hit and your program might crash. There appears to be no linter available to detect this. Unless I’ve completely missed something, the interaction between these two features is a terrible design.

dkackman11 4y ago

Agree. Modern C++, and discussions around it, become more esoteric with every revision. As software engineers we should spend our time understanding the esoterica of the problem domain, not the toolset.

hdjjhhvvhga 4y ago
I'm of the same opinion. Frankly, when Go first appeared, I felt we would finally get something almost as simple as Python and almost as fast as C. Unfortunately not everything was as nice as I had expected. Still, in that respect it's better than Rust as it makes it easier to focus on the problem rather than the language.
- _wldu 4y ago
  The complexity of C++0x is one reason Go was created. "For me, the reason I was enthusiastic about Go was just about the same time we were starting on Go, I read (or tried to read) the C++0x proposed standard. And that was the convincer for me." - Ken Thompson 17:45 mark here: https://www.youtube.com/watch?v=sln-gJaURzk https://www.youtube.com/watch?v=sln-gJaURzk
  - tialaramex 4y ago
    For reference of anybody too young to remember: C++0x is what you'd have called what became C++ 11 back when the committee thought it might happen in 2009 or, worst case 2010. The fact that their "2009" standard shipped only in 2011, after ripping out features everybody agreed were good yet never seemed finished, is why they moved to their current "train" model where there's a new C++ every three years, like it or not. The train will leave, if your feature wasn't ready well there's another train in three years.
- xyzzy4747 4y ago
  I personally still don't understand the benefit of Go vs Java? They seem to accomplish similar things with similar amounts of boilerplate.

eloff 4y ago

I've always thought of C++ as the most complex programming language I know. With each revision it becomes more complex. I gave up and just moved on to Rust a year and a half ago. I have no regrets. C++ has not quite joined Perl, PHP, and Java as languages I will not work with anymore, but it's the next logical candidate.

spoiler 4y ago
I've not worked with PHP for over 8 years now, but I hear it's gotten much better recently. It still has issues that are commonly associated with hosting provider configuration/control over the runtime, apparently. (sources are anecdotal; two friends who've had the mental fortitude to stick with the language for so long)
- jmt_ 4y ago
  PHP 7 & 8 introduce lots of improvements. I used PHP 5 when I got into web dev and remember moving to Python as soon as I could. At work I've had to use PHP 7 and have been very pleasantly surprised at how solid it is. Now that I have more experience than my PHP 5 days, it's become apparent that PHP is very clearly suited for web work and the built-in functions offer many conveniences for such work that simply aren't available in other languages (granted other languages weren't built for web like PHP was). I've been surprised by my speed in PHP and I chalk most of that up to many helpful standard library functions. Even though PHP has a lot of old/compat functions still present I'm always surprised by how little that actually ends up effecting my productivity. So it's not my choice for greenfield projects but I'm not nearly as adverse to it now after working with modern day PHP for a bit.
  - jamesfinlayson 4y ago
    Agreed - I've worked on a few PHP 5 era projects with hand-rolled frameworks and more recently I've worked on a few PHP 7/PHP 8 projects using proper frameworks and it's night and day.
tasubotadas 4y ago