4 ms·

Ask HN: What’s bad about C++? I kinda like it

14 points by andrewstuart 4y ago

I’m new to C++ so I’m using a very limited subset no doubt. There has been a few fiddly bits and a few surprises. But for the most part it doesn’t seem as hard as I’d expected or been led to believe. Actually it feels pretty nice. Why do people hate on C++? Presumably I’ll find out if I try to get more advanced. Having said that I’m finding I don’t really need much more than what I’m using already. Honestly it doesn’t feel too different to javascript. So why don’t people like C++?

BenT0 4y ago
As someone who likes C++, here are the main pain points I have using modern C++, those pain points are common to FORTAN or C: - compilation is a pain to setup and support along the project compared to Rust or Go, the lack of package manager is quite sensible and the experience is not warm and comforting. - Modern and (consensually enough) tooling in my opinion. (On this matter, C++ beeing widely used in the industry, you have a no-willing-to-count number of softwares to test your C++ application. The list is way to long of closed or open source framework. Got a new job ? Congratulation you probably earned new framework to get in hand with). - The compilation time. This last one is not something you do not find in C and FORTRAN project: - In the industry (does not apply to open source project), most of the C++ developpers knows the C++ of their graduation year and nothing else. You can find a lot of documentation/manuals telling you how to produce C++ before 2011 (big bang time for C++) and even now, you have poor documentation on how to produce modern C++ with C++20 features. The modern doc/manuals is a small amount of the accessible knowledge you can find on the internet about C++. Therefore, a poor amount of people are able to write modern and clean C++. The ability for educate juniors to modern C++ is quite low. Now that you are here, something to the credit of C++: - Very few languages hold the comparison with C++ regarding performance. Fewer have those performances with an object oriented structure of the code (to not say none in the embedded industry). There is a good reason to have most of the Gaming motors written in C++.
- shrimp_emoji 4y ago
  But how would this help with loneliness? ;B
  - CyberDildonics 4y ago
    Did you mean to reply somewhere else? I don't think this makes sense in this context.
    - BenT0 4y ago
      My fault, mea culpa as we say. I first sent my com in this ask HN by error <facepalm> : https://news.ycombinator.com/item?id=35832296 https://news.ycombinator.com/item?id=35832296
gregjor 4y ago
Some people don't like C++. For any programming language you can find plenty of people who don't like it or have complaints. That's true of pretty much everything. You can read informed critiques of programming languages by people who have experience, and there's no shortage of experience with C++ and books about it, because it became popular as soon as it came out and we now have over three decades of experience with C++. I don't know what you mean by "people" hating C++, or why anyone would care. You can certainly find rants and posts complaining about C++, but you can find those about anything. Study people who know better and form your own judgments.
cpach 4y ago
A guess: Many people who dislike C++ got a taste of it in the 90s/00s when the language probably was much less pleasant to use than today. That’s probably not the whole story, but I do believe it could be one of the reasons.
- warrenm 4y ago
  Irony [?] ... I learned C++ in the mid-90s (go go gadget proprietary implementations! Borland C++ 4 is where I cut my teeth!) Still LOVE the language They've added a metric frickin' buttload over the last 25 years, but I think it's still close to a "perfect" development language
  - cpach 4y ago
    Ok, cool! Not sure all devs share that love ;-) Then again, preferences for programming languages vary wildly. To each their own :)
- tjr 4y ago
  I used C++ in the 1990s and thought it felt messy and unpleasant. I've largely avoided it since then, but reading some more recent documentation, I think I would like today's updated C++ more than what I experienced decades ago.
pjmlp 4y ago
From my point of view, my biggest complaint is copy-paste compatibility with C. Which was a great way to gain adoption, by being born as UNIX language at Bell Labs, it quickly got adoption from C compiler vendors, making them all ship C and C++ compilers in the same box. Which is also its greatest pain point, because no matter how much we want to improve the language without fully breaking compatibility, there will always be someone that will write C++ code that could be as easily compiled by a C compiler, thus killing any attempts to safety. Those that complain about its complexity, aren't wrong, however any language with similar longenvity has similar levels of complexity. The lengthy ISO C++ standard also includes the standard library, so for similar baselines, who can master the knowledge of Python 3.11 + standard library, Java 21 + standard library, C# 12 + .NET standard library + MS frameworks, F# + .NET standard library + C# interop +..., and so on for all languages with 20+ years of evolution. Even the "basic" C, actually requires knowing compiler specific stuff, and POSIX for most deployment scenarios. My job doesn't require coding in C++ directly, it is more of a native libraries kind of thing, and the language I reach for most of my hobby coding. One day that might be Rust, but it still lacks too much stuff for the hobbies I enjoy coding for, V8/CLR/JVM/LLVM/GCC internals, GUI and GPGPU programming.
- warrenm 4y ago
  Is current C++ still upwards-compatible with current C? I know that was a major selling point 30 years ago ... but is it still?
  - pjmlp 4y ago
    Partially, there have been some slight improvements on the language level, like initializers in C++20, and adoption of several C standard library functions up to C17. That selling point isn't only integrating with existing C code, rather how many want to actually use the language, that is why there is an Orthodox C++ movement, that basically advocates to keep using C++ as if stuck in "C with Classes" CFront days.
fwsgonzo 4y ago
“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup So, if you ask me, I feel bad about Perl. Nobody seems to talk about that anymore. As someone who writes way too much C++, I will say that there is nothing wrong with the language. There is an abundance of tools to detect and fix problems, and quite a lot of libraries out there for every need. The worst stuff is the building and linking. I remember early on how angry I got when I learned that the order matters, but in reverse order too. On top of that, the language basically has no way to include other libraries on its own. https://stackoverflow.com/questions/3363398/g-linking-order-dependency-when-linking-c-code-to-c-code https://stackoverflow.com/questions/3363398/g-linking-order-... This answer highlights the poor design.
- badpun 4y ago
  > I will say that there is nothing wrong with the language. Coming from more modern languages, having to write and maintain all those superfluous header files is driving me insane.
warrenm 4y ago
>Honestly it doesn’t feel too different to javascript. ...that would be because Javascript was developed by people who wrote C/C++ :) Netscape was written mostly in C++ back in the 90s because it was the Language of Choice™ So the devs that worked on Javascript borrowed a lot from C++ in terms of syntax, structure, etc Likewise, Java looks a lot like C++ because the folks at Sun were writing in C and C++ for the SunOS/Solaris operating system, and all the Unix utilities that supported it And C++ looks a lot like C because Bjourne Stroustrop started with C, and added-on And C looks a lot like B because they started with B and made something new/better PHP looks a lot like C/C++ (and perl), too ... because they started with those as inspirations "New" languages tend to "look like" the languages the designers/developers already use :)
- pjmlp 4y ago
  Netscape was written in C, and almost died during the effort to port it to C++ on Netscape 4.0. https://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-rewrites/ https://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-r... Java semantics were inspired by the folks at Sun using Smalltalk, SELF, OpenSTEP and Objective-C. The C++ like syntax was to make it more attractive for adoption. https://cs.gmu.edu/~sean/stuff/java-objc.html https://cs.gmu.edu/~sean/stuff/java-objc.html https://www.strongtalk.org/ https://www.strongtalk.org/
  - warrenm 4y ago
    You're right ... I usually lump C & C++ for conversational purposes .. but they are different languages :)
thesuperbigfrog 4y ago
It depends on what problem you are trying to solve, your programming style, and the size of your team. I personally will avoid C++ if possible because it has too much complexity, too many "gotchas", and there are better choices available (Rust, Go, Ada, C, etc.). Some people like C++ and that is fine. They can use it. I will use something else if at all possible. https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B https://250bpm.com/blog:4/ https://250bpm.com/blog:4/ A 275-page book about how initialization works in C++: https://www.cppstories.com/2022/cpp-init-book/ https://www.cppstories.com/2022/cpp-init-book/
dagw 4y ago
I’m using a very limited subset no doubt This is one problem. I've been programming C++ on and off (mostly off) for about 15 years, and I keep running into things in code bases that I've never seen before and have no idea how to deal with. The potential difference in coding styles between two C++ developers is far larger than probably any other language I know. If I get to write C++ the way I want, using only the features I know, then it's fine. Once you start getting more developers involved you are going to need a very strong lead to keep everyone in line and consistent. C++ is also complex and interacts with other complex things in sometimes unexpected ways. It will also let you shoot yourself in the foot in very complex and unexpected. By far the hardest bugs I've ever had to deal with in my career have all been C++ bugs. Finally building and linking a non-trivial C++ project always ends up being a janky pain that eats up more time and sanity than it should. The being said, I don't mind C++ and use it quite a bit. Although these days most of the C++ code I write is libraries callable from python with pybind, rather than 'pure' C++ applications.
AnimalMuppet 4y ago
People think differently. For some people, C++ fits the way they think. For some, it very much does not. Even for those that it fits, C++ used to be a relatively simple language. They could understand all of it (if they go back that far). Now it's not, and they can't. There are tons of corners of the language, and virtually nobody knows all of them, still less how they interact with each other. This can lead to some extremely counterintuitive behaviors in your code. Many people don't like that. Personally, I like C++. It's the only mainstream language with destructors, and I consider that a very useful thing for resource management. (If the only resource you have to worry about is memory, garbage collection is probably a better answer. But if you also have to close files and release semaphores, destructors can make that less of a headache.) Still, if I'm working on my own thing, I'm not sure C++ is the first language I reach for. Depends on the problem.
- pjmlp 4y ago
  Ada, Swift, Rust, Delphi, Python also have destructors. Granted, they all have different levels of mainstream. I also don't manage to really keep up with C++ in detail, only enough to be aware of where it is going.
okaleniuk 4y ago
It's unnecessary complicated for historical reasons. And as history goes further, it only gets more complicated. E.g., due to its promotion rules stemming from the 60s PDP-7, the expression arguments are getting cast into signed type during the operation, 50000 * 50000 == -1794967296. But only on MSVC because, for compatibility reasons, MSVC still keeps its `int` type 32-bit while, for instance, clang doesn't, so on clang, the same expression will give you the correct 2500000000. Imagine writing the code, running all the tests and only discovering the issue on one of the CI build machines with no proper way to debug it. Yeah... And this is totally by the book, the size of 'int' is allowed to deviate from compiler to compiler by design. This comes from the 70s C that was suppose to become "portable assembly" and back then, apparently, portability meant compiling without errors. So C++ addresses this issue and proposes types with fixed length. You can now write your types explicitly. Like this: uint64_t(uint16_t(50000) * uint16_t(50000)) And get 18446744071914584320. Because, nevertheless the new fancy types, the promotion rules from PDP-7 still apply. Your expression is getting cast to the next signed standard type that can accommodate `uint16_t` and this is still `int`. So you get -1794967296 and only then convert it to unsigned `uint64_t` number. Fiddly bits and surprises will keep on coming. I've been writing in C++ for, what, 17 years now?, just yesterday I was rewriting a unit test with floating point data into integers. It was something like this: "1.234, 0.123, 5.678" and I wanted "1234, 123, 5678". So I just removed the decimal points and let the heading zero in 0123 hang. 0ops! In C++, heading zero marks octal notation, and 0123 actually means 83. But the thing responsible for the most rants is C++ static polymorphism. Since you don't have Rust-like type traits, the only way to ensure that one piece of code will work with another is to compile them both together. This means that for every minor change in an underlying library, you have to recompile all the dependies to see if their tests still work and this gives you enough time to write a rant or two.
- soulbadguy 4y ago
  > on arithmetic expression and type promotion/conversion rules I agree, those are complicated (not sure about the needlessly). However, one can avoid the bulk of the issue but not doing unsigned arithmetic. > C++ static polymorphism I am not clear on what's the connection between static polymorphism and ABI compatibility. In general, C++ always view ABI compatibility as a property of the platform/tools and not of the languages. We do have a pretty standard ABI (Itanium 64) where everbody seems to have converge. I am not super familiar with rust trait implementation, but it doesn't looks like the language force any particular implementation details. the current compatibility seems more a consequence of having just one rust compiler/tool chain as opposed to a conscious design decision.
maldev 4y ago
Nothing wrong with it. The only downside is having to either use RAII(C++) or SESE. RAII removes pretty much all pointers and wraps allocations in a class. SESE is using goto's and only returning in one location and all the variables at the top so you don't bypass control flow. Otherwise you have a coding style that can cause issues with memory leaks. Languages like Go are designed so that someone who's not familiar or wants to use these patterns can write safe and good code. And ALOT of people are complete idiots at c and c++ in a good fashion. You can see the most obvious and horrible programmers making critical things like routers who just have the most blatant bugs or bad practices. And what you don't know, you don't know. So these people exist in bliss pushing shitty horrible, bug ridden code. ANd using these coding styles which prevent that are extra tedious and annoying. For libraries, try to use VCPKG to find and build new ones to statically link. You also need to learn about compiler definitions, like declspec. And need to worry about alignment on some things as well.
speedgoose 4y ago
I do write some C++ once in a while and I don’t hate the language but since you asked for the bad things, here is my personal top list: - the headers files are a pain and feel unnecessary. - the build systems are annoying. So many of them, none is great. - no common package manager. - the language has too many paradigms and is a mess unless you restrict yourself, but usually the C++ code base you work on is not yours. - memory management is hard. - the segfaults. - the compilation error messages. - the templates hell from the standard library or boost.
- kurisufag 4y ago
  >the headers files are a pain and feel unnecessary. >no common package manager. I actually really love these. The best thing about C(++) is that, more than being simple a la Python, things are /obvious/. When writing Python code, for example, I often find myself opening a REPL window and testing small language features ("...can you __import__ a module twice if you bind both copes to different variables? do they have unique module-scoped state?"). "take this text file and insert it into this other text file" requires ZERO new considerations. ditto with having specific memory structures for objects, etc. etc. oh, and package managers are evil. you end up getting locked into some bullshit ecosystem or workflow that you never wanted to sign up for, not to mention the obvious security issues (it seems like a large npm or pip package gets compromised once a month).
  - boring_twenties 4y ago
    Oh, things are obvious in C++, huh? Is the result of this function copied when it returns? auto f1() { if (check_something()) { std::optional<foo> result(std::in_place, arg1, arg2...); if (result->check_something_else()) { /\* do something unrelated */ } return result; } else { return std::optional<foo>(std::nullopt); } } How about this one? auto f2() { std::optional<foo> result(std::nullopt); if (check_something()) { result.emplace(arg1, arg2...); if (result->check_something_else()) { /\* do something unrelated \*/ } } return result; }
Am4TIfIsER0ppos 4y ago
cout << this << fucking << garbage;
shrimp_emoji 4y ago
Look up the Rule of Three (now Five). You don't see that type of complexity in any other language, and it's because of a tragic marriage of low levelness and object orientedness, and the language tries to hide some of the complexity behind implicit behavior which actually generates more complexity. It's also very old and has accumulated a lot of lessons learned without changing the old behaviors due to backward compatibility handcuffs, resulting in the characteristic "the most obvious thing is the wrong thing" syndrome. I like it too though.
randomopining 4y ago
If you need fast performance you use C++ or C. There are less guardrails so more unintended or bad results can happen. But you have full control of things. Sounds like things have gotten so good with Java that you don't need C for many use cases anymore.
VirusNewbie 4y ago
Because::it::is_too->goddamn(*verbose);

14 points by andrewstuart 4y ago

BenT0 4y ago

As someone who likes C++, here are the main pain points I have using modern C++, those pain points are common to FORTAN or C: - compilation is a pain to setup and support along the project compared to Rust or Go, the lack of package manager is quite sensible and the experience is not warm and comforting. - Modern and (consensually enough) tooling in my opinion. (On this matter, C++ beeing widely used in the industry, you have a no-willing-to-count number of softwares to test your C++ application. The list is way to long of closed or open source framework. Got a new job ? Congratulation you probably earned new framework to get in hand with). - The compilation time. This last one is not something you do not find in C and FORTRAN project: - In the industry (does not apply to open source project), most of the C++ developpers knows the C++ of their graduation year and nothing else. You can find a lot of documentation/manuals telling you how to produce C++ before 2011 (big bang time for C++) and even now, you have poor documentation on how to produce modern C++ with C++20 features. The modern doc/manuals is a small amount of the accessible knowledge you can find on the internet about C++. Therefore, a poor amount of people are able to write modern and clean C++. The ability for educate juniors to modern C++ is quite low. Now that you are here, something to the credit of C++: - Very few languages hold the comparison with C++ regarding performance. Fewer have those performances with an object oriented structure of the code (to not say none in the embedded industry). There is a good reason to have most of the Gaming motors written in C++.

shrimp_emoji 4y ago
But how would this help with loneliness? ;B
- CyberDildonics 4y ago
  Did you mean to reply somewhere else? I don't think this makes sense in this context.
  - BenT0 4y ago
    My fault, mea culpa as we say. I first sent my com in this ask HN by error <facepalm> : https://news.ycombinator.com/item?id=35832296 https://news.ycombinator.com/item?id=35832296

gregjor 4y ago

Some people don't like C++. For any programming language you can find plenty of people who don't like it or have complaints. That's true of pretty much everything. You can read informed critiques of programming languages by people who have experience, and there's no shortage of experience with C++ and books about it, because it became popular as soon as it came out and we now have over three decades of experience with C++. I don't know what you mean by "people" hating C++, or why anyone would care. You can certainly find rants and posts complaining about C++, but you can find those about anything. Study people who know better and form your own judgments.

cpach 4y ago

A guess: Many people who dislike C++ got a taste of it in the 90s/00s when the language probably was much less pleasant to use than today. That’s probably not the whole story, but I do believe it could be one of the reasons.

warrenm 4y ago
Irony [?] ... I learned C++ in the mid-90s (go go gadget proprietary implementations! Borland C++ 4 is where I cut my teeth!) Still LOVE the language They've added a metric frickin' buttload over the last 25 years, but I think it's still close to a "perfect" development language
- cpach 4y ago
  Ok, cool! Not sure all devs share that love ;-) Then again, preferences for programming languages vary wildly. To each their own :)
tjr 4y ago
I used C++ in the 1990s and thought it felt messy and unpleasant. I've largely avoided it since then, but reading some more recent documentation, I think I would like today's updated C++ more than what I experienced decades ago.

pjmlp 4y ago

From my point of view, my biggest complaint is copy-paste compatibility with C. Which was a great way to gain adoption, by being born as UNIX language at Bell Labs, it quickly got adoption from C compiler vendors, making them all ship C and C++ compilers in the same box. Which is also its greatest pain point, because no matter how much we want to improve the language without fully breaking compatibility, there will always be someone that will write C++ code that could be as easily compiled by a C compiler, thus killing any attempts to safety. Those that complain about its complexity, aren't wrong, however any language with similar longenvity has similar levels of complexity. The lengthy ISO C++ standard also includes the standard library, so for similar baselines, who can master the knowledge of Python 3.11 + standard library, Java 21 + standard library, C# 12 + .NET standard library + MS frameworks, F# + .NET standard library + C# interop +..., and so on for all languages with 20+ years of evolution. Even the "basic" C, actually requires knowing compiler specific stuff, and POSIX for most deployment scenarios. My job doesn't require coding in C++ directly, it is more of a native libraries kind of thing, and the language I reach for most of my hobby coding. One day that might be Rust, but it still lacks too much stuff for the hobbies I enjoy coding for, V8/CLR/JVM/LLVM/GCC internals, GUI and GPGPU programming.

warrenm 4y ago
Is current C++ still upwards-compatible with current C? I know that was a major selling point 30 years ago ... but is it still?
- pjmlp 4y ago
  Partially, there have been some slight improvements on the language level, like initializers in C++20, and adoption of several C standard library functions up to C17. That selling point isn't only integrating with existing C code, rather how many want to actually use the language, that is why there is an Orthodox C++ movement, that basically advocates to keep using C++ as if stuck in "C with Classes" CFront days.

fwsgonzo 4y ago

“There are only two kinds of languages: the ones people complain about and the ones nobody uses.” ― Bjarne Stroustrup So, if you ask me, I feel bad about Perl. Nobody seems to talk about that anymore. As someone who writes way too much C++, I will say that there is nothing wrong with the language. There is an abundance of tools to detect and fix problems, and quite a lot of libraries out there for every need. The worst stuff is the building and linking. I remember early on how angry I got when I learned that the order matters, but in reverse order too. On top of that, the language basically has no way to include other libraries on its own. https://stackoverflow.com/questions/3363398/g-linking-order-dependency-when-linking-c-code-to-c-code https://stackoverflow.com/questions/3363398/g-linking-order-... This answer highlights the poor design.

badpun 4y ago
> I will say that there is nothing wrong with the language. Coming from more modern languages, having to write and maintain all those superfluous header files is driving me insane.

warrenm 4y ago

>Honestly it doesn’t feel too different to javascript. ...that would be because Javascript was developed by people who wrote C/C++ :) Netscape was written mostly in C++ back in the 90s because it was the Language of Choice™ So the devs that worked on Javascript borrowed a lot from C++ in terms of syntax, structure, etc Likewise, Java looks a lot like C++ because the folks at Sun were writing in C and C++ for the SunOS/Solaris operating system, and all the Unix utilities that supported it And C++ looks a lot like C because Bjourne Stroustrop started with C, and added-on And C looks a lot like B because they started with B and made something new/better PHP looks a lot like C/C++ (and perl), too ... because they started with those as inspirations "New" languages tend to "look like" the languages the designers/developers already use :)

pjmlp 4y ago
Netscape was written in C, and almost died during the effort to port it to C++ on Netscape 4.0. https://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-rewrites/ https://gigamonkeys.wordpress.com/2009/09/28/a-tale-of-two-r... Java semantics were inspired by the folks at Sun using Smalltalk, SELF, OpenSTEP and Objective-C. The C++ like syntax was to make it more attractive for adoption. https://cs.gmu.edu/~sean/stuff/java-objc.html https://cs.gmu.edu/~sean/stuff/java-objc.html https://www.strongtalk.org/ https://www.strongtalk.org/
- warrenm 4y ago
  You're right ... I usually lump C & C++ for conversational purposes .. but they are different languages :)

thesuperbigfrog 4y ago

It depends on what problem you are trying to solve, your programming style, and the size of your team. I personally will avoid C++ if possible because it has too much complexity, too many "gotchas", and there are better choices available (Rust, Go, Ada, C, etc.). Some people like C++ and that is fine. They can use it. I will use something else if at all possible. https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B https://250bpm.com/blog:4/ https://250bpm.com/blog:4/ A 275-page book about how initialization works in C++: https://www.cppstories.com/2022/cpp-init-book/ https://www.cppstories.com/2022/cpp-init-book/

dagw 4y ago

I’m using a very limited subset no doubt This is one problem. I've been programming C++ on and off (mostly off) for about 15 years, and I keep running into things in code bases that I've never seen before and have no idea how to deal with. The potential difference in coding styles between two C++ developers is far larger than probably any other language I know. If I get to write C++ the way I want, using only the features I know, then it's fine. Once you start getting more developers involved you are going to need a very strong lead to keep everyone in line and consistent. C++ is also complex and interacts with other complex things in sometimes unexpected ways. It will also let you shoot yourself in the foot in very complex and unexpected. By far the hardest bugs I've ever had to deal with in my career have all been C++ bugs. Finally building and linking a non-trivial C++ project always ends up being a janky pain that eats up more time and sanity than it should. The being said, I don't mind C++ and use it quite a bit. Although these days most of the C++ code I write is libraries callable from python with pybind, rather than 'pure' C++ applications.

AnimalMuppet 4y ago

People think differently. For some people, C++ fits the way they think. For some, it very much does not. Even for those that it fits, C++ used to be a relatively simple language. They could understand all of it (if they go back that far). Now it's not, and they can't. There are tons of corners of the language, and virtually nobody knows all of them, still less how they interact with each other. This can lead to some extremely counterintuitive behaviors in your code. Many people don't like that. Personally, I like C++. It's the only mainstream language with destructors, and I consider that a very useful thing for resource management. (If the only resource you have to worry about is memory, garbage collection is probably a better answer. But if you also have to close files and release semaphores, destructors can make that less of a headache.) Still, if I'm working on my own thing, I'm not sure C++ is the first language I reach for. Depends on the problem.

pjmlp 4y ago
Ada, Swift, Rust, Delphi, Python also have destructors. Granted, they all have different levels of mainstream. I also don't manage to really keep up with C++ in detail, only enough to be aware of where it is going.

okaleniuk 4y ago

It's unnecessary complicated for historical reasons. And as history goes further, it only gets more complicated. E.g., due to its promotion rules stemming from the 60s PDP-7, the expression arguments are getting cast into signed type during the operation, 50000 * 50000 == -1794967296. But only on MSVC because, for compatibility reasons, MSVC still keeps its `int` type 32-bit while, for instance, clang doesn't, so on clang, the same expression will give you the correct 2500000000. Imagine writing the code, running all the tests and only discovering the issue on one of the CI build machines with no proper way to debug it. Yeah... And this is totally by the book, the size of 'int' is allowed to deviate from compiler to compiler by design. This comes from the 70s C that was suppose to become "portable assembly" and back then, apparently, portability meant compiling without errors. So C++ addresses this issue and proposes types with fixed length. You can now write your types explicitly. Like this: uint64_t(uint16_t(50000) * uint16_t(50000)) And get 18446744071914584320. Because, nevertheless the new fancy types, the promotion rules from PDP-7 still apply. Your expression is getting cast to the next signed standard type that can accommodate `uint16_t` and this is still `int`. So you get -1794967296 and only then convert it to unsigned `uint64_t` number. Fiddly bits and surprises will keep on coming. I've been writing in C++ for, what, 17 years now?, just yesterday I was rewriting a unit test with floating point data into integers. It was something like this: "1.234, 0.123, 5.678" and I wanted "1234, 123, 5678". So I just removed the decimal points and let the heading zero in 0123 hang. 0ops! In C++, heading zero marks octal notation, and 0123 actually means 83. But the thing responsible for the most rants is C++ static polymorphism. Since you don't have Rust-like type traits, the only way to ensure that one piece of code will work with another is to compile them both together. This means that for every minor change in an underlying library, you have to recompile all the dependies to see if their tests still work and this gives you enough time to write a rant or two.

soulbadguy 4y ago
> on arithmetic expression and type promotion/conversion rules I agree, those are complicated (not sure about the needlessly). However, one can avoid the bulk of the issue but not doing unsigned arithmetic. > C++ static polymorphism I am not clear on what's the connection between static polymorphism and ABI compatibility. In general, C++ always view ABI compatibility as a property of the platform/tools and not of the languages. We do have a pretty standard ABI (Itanium 64) where everbody seems to have converge. I am not super familiar with rust trait implementation, but it doesn't looks like the language force any particular implementation details. the current compatibility seems more a consequence of having just one rust compiler/tool chain as opposed to a conscious design decision.

maldev 4y ago

Nothing wrong with it. The only downside is having to either use RAII(C++) or SESE. RAII removes pretty much all pointers and wraps allocations in a class. SESE is using goto's and only returning in one location and all the variables at the top so you don't bypass control flow. Otherwise you have a coding style that can cause issues with memory leaks. Languages like Go are designed so that someone who's not familiar or wants to use these patterns can write safe and good code. And ALOT of people are complete idiots at c and c++ in a good fashion. You can see the most obvious and horrible programmers making critical things like routers who just have the most blatant bugs or bad practices. And what you don't know, you don't know. So these people exist in bliss pushing shitty horrible, bug ridden code. ANd using these coding styles which prevent that are extra tedious and annoying. For libraries, try to use VCPKG to find and build new ones to statically link. You also need to learn about compiler definitions, like declspec. And need to worry about alignment on some things as well.

speedgoose 4y ago

I do write some C++ once in a while and I don’t hate the language but since you asked for the bad things, here is my personal top list: - the headers files are a pain and feel unnecessary. - the build systems are annoying. So many of them, none is great. - no common package manager. - the language has too many paradigms and is a mess unless you restrict yourself, but usually the C++ code base you work on is not yours. - memory management is hard. - the segfaults. - the compilation error messages. - the templates hell from the standard library or boost.

kurisufag 4y ago
>the headers files are a pain and feel unnecessary. >no common package manager. I actually really love these. The best thing about C(++) is that, more than being simple a la Python, things are /obvious/. When writing Python code, for example, I often find myself opening a REPL window and testing small language features ("...can you __import__ a module twice if you bind both copes to different variables? do they have unique module-scoped state?"). "take this text file and insert it into this other text file" requires ZERO new considerations. ditto with having specific memory structures for objects, etc. etc. oh, and package managers are evil. you end up getting locked into some bullshit ecosystem or workflow that you never wanted to sign up for, not to mention the obvious security issues (it seems like a large npm or pip package gets compromised once a month).
- boring_twenties 4y ago
  Oh, things are obvious in C++, huh? Is the result of this function copied when it returns? auto f1() { if (check_something()) { std::optional<foo> result(std::in_place, arg1, arg2...); if (result->check_something_else()) { /\* do something unrelated */ } return result; } else { return std::optional<foo>(std::nullopt); } } How about this one? auto f2() { std::optional<foo> result(std::nullopt); if (check_something()) { result.emplace(arg1, arg2...); if (result->check_something_else()) { /\* do something unrelated \*/ } } return result; }

Am4TIfIsER0ppos 4y ago

cout << this << fucking << garbage;

shrimp_emoji 4y ago

Look up the Rule of Three (now Five). You don't see that type of complexity in any other language, and it's because of a tragic marriage of low levelness and object orientedness, and the language tries to hide some of the complexity behind implicit behavior which actually generates more complexity. It's also very old and has accumulated a lot of lessons learned without changing the old behaviors due to backward compatibility handcuffs, resulting in the characteristic "the most obvious thing is the wrong thing" syndrome. I like it too though.

randomopining 4y ago

If you need fast performance you use C++ or C. There are less guardrails so more unintended or bad results can happen. But you have full control of things. Sounds like things have gotten so good with Java that you don't need C for many use cases anymore.

VirusNewbie 4y ago

Because::it::is_too->goddamn(*verbose);