[HN Gopher] C++ Should Be C++
___________________________________________________________________
C++ Should Be C++
Author : steveklabnik
Score : 73 points
Date : 2023-12-19 18:11 UTC (4 hours ago)
(HTM) web link (www.open-std.org)
(TXT) w3m dump (www.open-std.org)
| gavinray wrote:
| Honestly, the changes in C++ 20 and 23, plus the upcoming changes
| for 26 (looking at you, Concurrency TS v2) have so drastically
| improved the language it's almost like the ES5 -> ES6 evolution
| of JavaScript.
|
| I might be in the minority here, but I genuinely enjoy writing
| modern C++.
|
| My complaints are about it's dependency management story and lack
| of integrated, standardized tools for things like dependencies,
| testing, logging, etc.
| JohnFen wrote:
| I don't know if you're in the minority or I am, but I find
| modern C++ to be borderline intolerable (and I've been
| programming mostly in C++ from before there were C++
| compilers).
|
| I used to love C++ (and still do if we're talking about older
| standards), but the new stuff is just a baroque torture.
| eps wrote:
| Aye, same here.
|
| I don't mond C++ evolving into some thing of its own beyond
| all recognition, but there is a distinct lack of modern "C
| with Classes" language. Basically, C on steroids. There are
| attempts at that, but none is perfect and/or has enough
| traction to be viable.
| WanderPanda wrote:
| I just want a C with templates (and function overloading)?
| eps wrote:
| "this" and virtual functions are pretty damn useful too.
| jacoblambda wrote:
| You can still have "C with Classes" in modern C++ if you
| really want that. Just set a style guide that limits your
| code to that.
|
| There's more viable coding styles in C++ than I can
| honestly even bother to count. There's absolutely no reason
| to limit the language to one specific coding style when
| doing so would alienate large groups of users and you can
| set those limits yourself on your project.
| JohnFen wrote:
| This is what I do for my own projects, but it's not a
| viable thing to do with my work projects since I don't
| set the style.
| eps wrote:
| Yeah, I know and that's how I've been using it for the
| past decade, but it's not that simple. The language keeps
| changing and this forces adding cruft to the code if one
| wants to use newer compilers.
|
| For example, there are cases where the existence of move
| semantics necessitates adding some boilerplate when
| working with STL containers. There's no functional reason
| for it, just something to please the compiler.
| josephg wrote:
| I'm excited for Zig for this reason. I've been writing a
| lot of rust lately and - well, it's fine. Good at what it's
| trying to do. But Zig seems a lot more fun. Much more in
| the spirit of C.
| eps wrote:
| To each their own, but I find zig syntax to be on the
| ugly side and the resulting code unelegant.
| Night_Thastus wrote:
| Anything C++11 forward is alright with me, though 17 introduces
| some very nice conveniences like <execution>, <filesystem> and
| most critically <optional>. Honorable mention to std::clamp
| too.
| ska wrote:
| > Honorable mention to std::clamp too.
|
| One shudders to think how many times variations of that
| template have been written in house.
| Night_Thastus wrote:
| Heck, I find so many cases where std::min and std::max
| could be used as well.
| frfl wrote:
| 23 introduced <expected> (result/either) as well
| spacechild1 wrote:
| I would like to add:
|
| - structured bindings
|
| - auto parameters in lambdas
|
| - init statements in if and switch clauses
|
| - template argument deduction for constructors
| TillE wrote:
| You're absolutely not in the minority, old C++ was awful and
| there have been so many improvements to the language and
| standard library to help write simpler, clearer code.
|
| I was just recently appreciating the if statement with an
| initializer in C++17, which helps me express exactly what I
| want for variable scope in one line instead of multiple awkward
| ones.
| oldpersonintx wrote:
| this feels defeatist
|
| c++ is with us for the near future, it needs an evolutionary path
| that provides a sane path forward
|
| why not break with the past? anyone needing to compile c++11 can
| find the tools and still use them, they can live in the past as
| long as they like
|
| just getting dependency/build management and integrated testing
| would be huge and really a small ask given what is happening in
| other tools
|
| its crazy that you still can't make sane use of things like
| modules, even if you fully commit to "modern" c++
| pphysch wrote:
| Lack of modules support is the biggest thing keeping me from
| doing more c++ greenfield. So much friction in managing a
| _pointless_ interface <->implementation layer.
| frfl wrote:
| I'm not well versed in C++ best practices, but unless it's a
| non-option for your situation, have you considered single
| file headers or perhaps even a unity build[1] approach? Of
| course, both are just workarounds for proper module support
| and have their drawbacks and limitations.
|
| [1]: https://en.wikipedia.org/wiki/Unity_build
| u_name wrote:
| Yes! Proper modules support would give c++ a well needed
| boost (no pun intended!). msvc is kinda there, but it breaks
| here and there with intellisense.
| Night_Thastus wrote:
| This is the never-ending problem with programming languages.
|
| If you make big breaking changes, the community suffers - even
| if the changes are very well intentioned. Look at the long tail
| of Python 2 vs 3 issues. If it happens once it's not so bad,
| but the older the community and the greater the size of its
| existing ecosystem - the more that pain becomes. Rust, from
| what I've seen, understands this issue.
| EdSchouten wrote:
| > What is much less prevalent is a demand from average C++ users
| for memory safety features; they're much more concerned about
| compilation speed. When most C++ developers haven't adopted tools
| like Coverity and C++ core guidelines checkers, it is hard to
| claim that memory safety features substantially improve their
| lives at least from their point of view.
|
| I don't really agree with this. There's also a group of
| developers that want more safety, but don't feel like setting up
| (or in the case of Coverity purchasing) additional tooling. Some
| people just want a decent out of the box experience.
| moffkalast wrote:
| I think it's less about not wanting memory safety and more that
| compilation speeds are so time-wastingly abysmal that it's a
| few orders of magnitude more important to address.
|
| The whole deal with interpreted languages was to avoid sitting
| there for a few minutes every time you make a god damn one
| letter change, with the unfortunate but usually acceptable
| trade-off of some execution speed.
| mxmlnkn wrote:
| And the additional trade-off that some bugs are only noticed
| at runtime when that particular line is executed while it
| could have been noticed by the compiler of a strongly typed
| language. Pytype helps but at this point you have a static
| analyzer that potentially runs as slow as a compiler without
| the additional performance benefit.
| moffkalast wrote:
| Idk as long as you can develop at speed I don't see why a
| static analyser that's a few times slower than compiling
| couldn't run on the latest commit overnight? More as a
| sonarqube type thing I suppose.
| josephg wrote:
| There's no good reason for type checking to be super slow.
| I'm no fan of Go, but the language compiles insanely fast
| while being fully statically typed.
|
| As I understand it, C++'s slow compilation comes from the
| fact that it usually parses all of your header files n
| times instead of once. This isn't a problem with static
| typing. It's a problem with C++, and to a lesser extent C.
| aw1621107 wrote:
| > As I understand it, C++'s slow compilation comes from
| the fact that it usually parses all of your header files
| n times instead of once.
|
| That's one of the things that can slow compilation down
| but it's definitely not the only one. It helps that
| precompiled headers (and maybe modules?) can go a long
| way towards reducing and possibly eliminating these costs
| as well.
|
| I think some (most?) of the larger remaining costs
| revolve around template instantiation, especially it
| impacts link times as well due to the fact that the
| linker needs to do extra work to eliminate redundant
| instantiations.
| josephg wrote:
| > due to the fact that the linker needs to do extra work
| to eliminate redundant instantiations.
|
| Yeah, I see this as another consequence of C++'s poor
| compilation model:
|
| - Compilation is slow because a template class in your
| header file gets compiled N times (maybe with precompiled
| headers). The compiler produces N object files filled
| with redundant code.
|
| - Then the linker is slow because it needs to parse all
| those object files, and filter out all the redundant code
| that you just wasted time generating.
|
| Its a bad design.
| JohnFen wrote:
| I know I'm weird, but as long as I can compile individual
| units and link them to other already-compiled units then
| compilation speed is something I don't care about much at
| all.
| sakjur wrote:
| That sentence stood out to me as well. I don't think C++
| developers is necessarily the best people to ask when
| discussing whether memory safety is important and urgent to
| work on or not. A lot of developers are relatively shielded
| from the consequences of bugs and security vulnerabilities,
| either by their programs not being exposed to the wild in any
| major sense or by bureaucracy being in between them and any
| consequences.
|
| At some point, the deficiencies of a language becomes a concern
| for its end-users rather than its developers.
| JohnFen wrote:
| > the deficiencies of a language becomes a concern for its
| end-users rather than its developers.
|
| I think that this level of professional malpractice is
| something that can't be solved by language choice.
| worik wrote:
| Yes
|
| It is not about what we want. It is what we need
|
| Not real.y "we". I have lost any interest in C++ now. I loved
| it, in the day. Time has moved on
| MaulingMonkey wrote:
| I'll make a similar, but fundamentally different, claim to what
| you're quoting: There isn't much demand for _half assed_ memory
| safety features. And C++ memory safety features are - nearly by
| definition - half assed. They 're opt-in (meaning all the
| third-party and system code you link against doesn't have
| coverage), slow (meaning you can't use it in production), and
| tend to catch the trivial bugs rather than the hard-to-find
| ones that keep you up at night.
| andrewmcwatters wrote:
| Reminds me of "type-safety" features in duck type languages.
| BeetleB wrote:
| C++ Developers aren't complaining for two reasons:
|
| 1. Most of those who care about memory safety have already left
| the building.
|
| 2. Those who are still in the building and care don't speak up
| because their colleagues don't value it, and many of their
| colleagues will view them as having lower competence.
| diath wrote:
| Nevermind the language itself, we need a way to pull compilers
| and project dependencies, pinned to their specific versions, with
| a single, ergonomic tool. vcpkg seemed really promising but the
| fact that they didn't start with library versioning from the get
| go was a very stupid decision, and nowadays versions are pinned
| to specific commit hashes rather than actual dependency versions,
| and libraries that weren't previously versioned cannot be fetched
| if your project relies on an older pre-vcpkg version of a library
| and cannot be upgraded for one reason or another. These days I
| find myself struggling more and more with proper dev setup where
| I have an up-to-date compiler on any machine I want to build the
| code along with its libraries without running into a rabbit hole
| of compiler and library issues.
| bqmjjx0kac wrote:
| Have you looked into Bazel? https://bazel.build/start/cpp
|
| It's not always easy to use, but the focus on reproducible
| builds and caching is really nice.
|
| Edit: I guess it doesn't fetch a specific compiler for you by
| default, but you could probably ship your toolchain somewhere
| and pin it in your WORKSPACE file.
| steveklabnik wrote:
| Don't forget buck2 as well.
| andrewmcwatters wrote:
| vcpkg was dead in the water because they altered source
| packages. Completely unacceptable in many situations.
| kimixa wrote:
| I also find vcpkg extremely fragile.
|
| Not in that pinning versions or the APIs or the actual
| contents of the packages we rely on, so much that every time
| we update a (rather small) set of dependencies there's nearly
| always some weirdness around vcpkg itself or the builds.
|
| Just the last week we updated to a newer tag and building
| openssl failed setting up the nasm build dependency, claiming
| it already existed.
|
| Which it did - there was a "nasm" folder in the tools
| directory it was trying to install it in, from the last time
| it was installed presumably and somehow got it's internal
| state messed up. But this caused a fatal error. I eventually
| worked around it by deleting the nasm directory from every
| build machine and letting it reinstall exactly the same
| package again.
|
| But the time before there was also a "random" build error,
| claiming that xz wasn't installed, despite the log showing it
| was just installed as a dependency in the line above. I guess
| this was fixed upstream, as the "workaround" was to use a tag
| from a month or so previous, but now seems to be fixed.
|
| Perhaps I'm using it wrong, perhaps you should "always"
| completely blast away the global vcpkg folder (and any vcpkg
| stuff cached in build directories from it's cmake
| integration) every time you touch it. But it's still time and
| effort for something that probably should be seamless.
| throwaway81523 wrote:
| In critical embedded development they snapshot the entire VM
| containing the OS, compilers, entire tool chain, and everything
| else.
| JohnFen wrote:
| In the olden days, we always checked the compiler, libraries,
| and essential build tools being used into version control along
| with the code. That way you could always be sure that you could
| compile the code.
|
| This stopped working so well with Windows, where you usually
| can't just copy executables out of version control and run them
| (you have to run an installer instead), but it still works
| pretty well for the Unices.
| lisper wrote:
| > It is easy to see that C++ is fit as a general-purpose
| programming language-adoption by millions is a testament to that.
|
| No, that is false. It is akin to arguing that Christianity must
| be true because 2.4 billion Christians can't be wrong. The
| fallacy is easy to see because the argument can be applied
| equally to the world's 1.9 billion Muslims and 1.2 billion Hindus
| and 500 million Buddhists, etc. And yet these groups hold
| mutually-exclusive positions and so at least N-1 of them _must_
| be wrong.
|
| Humans are social animals. With only a few exceptions, we tend to
| conform to the group. That tends to make us get stuck in very
| deep ruts. "Everyone is doing it" is absolutely no indication
| that "it" is a good idea.
|
| [UPDATE] A lot of people seem to be missing the point here, so I
| feel the need to clarify: I'm not saying C++ is analogous to a
| relgion. I'm using the exclusivity of religious belief just as a
| short-cut to show that it is possible for large groups of people
| to hold false beliefs without getting into the weeds of which of
| those beliefs are actually false. The point is not that C++ is
| analogous to a religion, just that "adoption by millions" is not
| a valid argument for its merits.
|
| [UPDATE2] I am also not saying that religion has no value beyond
| the truth of its objective claims. I am only saying that (some
| of) the world's major religions do make objective claims, some of
| those claims are mutually exclusive, and so some of them must be
| objectively false, and therefore it is manifestly true that large
| groups of people can hold objectively false beliefs, and
| therefore the fact that large groups of people hold a position is
| not evidence that that position is objectively true. Being "fit
| as a general purpose programming language" is an objective claim.
| paulddraper wrote:
| Awful analogy.
|
| C++'s fitness as a general-purpose programming language is not
| an exclusive assertion.
| rcthompson wrote:
| That's not the point. The point is that "N people can't be
| wrong" is not a valid argument for any value of N.
| lisper wrote:
| I'm not saying it is. I'm using the exclusivity of religious
| belief just as a short-cut to show that it is possible for
| large groups of people to hold false beliefs without getting
| into the weeds of which of those beliefs are actually false.
| The point is not that C++ is analogous to a religion, just
| that "adoption by millions" is not a valid argument for its
| merits.
| paulddraper wrote:
| No, your analogy falls over.
|
| The equivalent assertion is "Christianity is a good/useful
| belief system" (and "Islam is a good/useful belief system")
|
| Now, you could endeavor to disprove that equivalent
| assertion, but your earlier argument doesn't.
| lisper wrote:
| My argument applies equally well to that: the mere fact
| that a religion has large numbers of adherents does not
| in and of itself show that it is either good or useful.
| But that's a harder case to make because it turns on what
| is meant by "good" and "useful", and those are things
| about which reasonable people can disagree.
|
| To be clear, "fitness as a general purpose programming
| language" is also something about which reasonable people
| can (and manifestly do) disagree. All I'm saying is that
| having large numbers of adherents is not a valid argument
| in favor of fitness any more than it is an argument in
| favor of goodness or usefulness. It's possible that all
| it shows is that a lot of people drank the kool-aid.
|
| [UPDATE] It's also possible that most of the people using
| C++ think that it sucks, and they are all just using it
| because everyone else is using it.
| paulddraper wrote:
| Your argument is "large numbers of people can be wrong,
| as shown by the fact that either Christians or Muslims
| are wrong."
|
| But metaphysics/religion is different than programming
| language utility.
|
| We can expect a higher degree of accurate judgment in the
| latter.
| lisper wrote:
| > metaphysics/religion is different than programming
| language utility.
|
| Of course it is. But religions make mutually exclusive
| _objective_ claims. Metaphysics has nothing to do with
| it.
| AnimalMuppet wrote:
| "Christianity is true" and "Islam is true" are mutually-
| contradictory positions. "C++ is fit as a general-purpose
| programming language" does not contradict "X other language is
| fit as a general-purpose programming language". So your logic
| in your first non-quote paragraph doesn't work.
|
| [Edit: To respond to the actual point: For every claim that X
| is fit as a tool to do Y, the evidence that millions of people
| use X to do Y is in fact proof of the claim. If the claim had
| been "C++ is _the best_ language for general purpose
| programming ", then your argument would have merit. But that
| wasn't the claim.]
| Georgelemental wrote:
| A religion does not have to be true to serve a positive social
| function. Arguably, the persistence of the most ancient and
| widespread faiths suggests that they do serve such a function.
| epolanski wrote:
| I mean the statement you quote is undeniable.
|
| If something is used by millions as a general-purpose
| programming language it is fit to the task, regardless of the
| alternatives or how ideal it is.
| lisper wrote:
| That depends on your criteria for fitness. There are millions
| of people using homeopathic remedies. That doesn't mean that
| homeopathy is actually fit for any of the tasks that people
| employ it for.
| epolanski wrote:
| You know that people actually write complex software in C++
| right whereas homeopathy does not achieve anything.
| lisper wrote:
| I know that _some_ people write complex software in C++.
| I suspect that number is actually very small.
| jocaal wrote:
| IMO the reason C++ isn't a general purpose programming language
| is due to memory management. Many many many applications can be
| built without having to worry about the garbage collector and
| the productivity gains of using a GC language is so so worth
| it. And I know you can force C++ into acting like a GC
| language, but why go through the effort? C++ is a precision
| tool for building complex and performant systems and that is
| nothing to be ashamed of, but it is not something you would use
| for web api's, or a quick script, or UI's or any quick and
| dirty project. I also feel like the rust community is forcing
| the language into places where it shouldn't really be. But yeah
| - people can argue about what general purpose means to them,
| just my 2c.
| zozbot234 wrote:
| GC is not required for memory safety. The proper use of GC
| nowadays is for dealing with problems that inherently involve
| spaghetti-like reference graphs for which no other memory
| management strategy is suitable. Using it as mere convenience
| might be okay for quick prototyping, but it ultimately leads
| to half-baked, hard-to-refactor code requiring a lot of CPU
| and memory overhead at runtime.
| discreteevent wrote:
| > GC is not required for memory safety.
|
| >memory overhead at runtime.
|
| These statements are true. The rest is grandstanding.
| wheels wrote:
| Yeah, probably should have left the religion analogy out. It
| wasn't essential to the point you were making and was based on
| a false model of religion.
|
| There's actually a pretty complex matrix in religious
| disagreement with or without exclusivity. And not all religions
| are exclusive at all. Islam's views of other Abrahamic
| religions is complicated, but it is exclusive about non-
| Abrahamic religions. Christianity sees Judaism as having been
| correct, but incomplete. Hinduism isn't essentially
| exclusionary (particularly to other religions which evolved
| from old Vedic practices), but is often confused with modern
| Hindu nationalism, which is. And even within single "religions"
| there are complicated lines where e.g. some Christians consider
| themselves to be in "communion" with some Christians, but not
| others.
|
| So, yeah, bad example. It's a terrible thing to have pulled out
| to try to show clear mutually exclusive groups.
| lisper wrote:
| What would have been a better example?
|
| The problem with trying to come up with examples of large
| numbers of people holding objectively false beliefs is that
| you have to look outside the realm of science. The whole
| point of science is that it provides a mechanism for
| resolving disagreements about objective truth objectively
| (i.e. experiment) and so you just don't get a lot of people
| holding objectively false beliefs, at least not for any
| length of time. Religion is all that's left.
| wheels wrote:
| Most of what humans talk about isn't science or religion,
| and to reduce the world to just that is pretty weird to say
| the least. Most things can't be resolved by appeals to
| objective truth. It sounds like you're working on a model
| where that's how one resolves conflicts, but literally most
| of the history of knowledge, humanity, whatever label you
| want to put on it -- isn't that. Even science isn't by any
| means that binary. Disagreements can last centuries. And
| we're even at a spot in science where a lot of the
| interesting stuff fumbles around for decades before we can
| even come up with experiments that could possibly test it;
| and some of it we won't ever be able to test. (A lot of
| cosmology isn't testable.)
|
| But the point me and a few others were making is that you
| don't seem to know much about religion, so it's probably
| not a good thing to use in analogies. Religion is
| definitely not a set of neatly divided mutually exclusive
| beliefs. Almost all of the world's adherents come from two
| families of religions -- Abrahamic or Vedic -- and within
| those groups there's a whole lot of similarity and varying
| levels of theological exclusivity.
|
| I feel like gambling or the stock market may be better
| examples. If one person takes a long position on a stock
| and another short, they have mutually exclusive beliefs
| about it, and one of them will be wrong.
| vcg3rd wrote:
| It's easy to see that driving on the RIGHT side of the road is
| a fit as a general mode of transportation. Adoption by millions
| is a testament to that.
|
| It's easy to see that driving on the LEFT side of the road is a
| fit as a general mode of transportation. Adoption by millions
| is a testament to that.
|
| Both statements are true. The author didn't say only C++ is
| fit. Nor did he say a program written in BOTH C++ AND python
| (i.e. a system of driving on both left and right sides of the
| road) is fit.
|
| The counter-argument (C++ is NOT fit as a general purpose
| programming language) is invalidated by millions of programmers
| who use it as such in the same way that thumbs are not fit for
| grasping is invalidated by, well, grasping with your hands.
|
| It doesn't mean pliers are not fit for grasping just because
| thumbs are fit for grasping.
|
| You're conflating types of evidence and types of arguments.
| lisper wrote:
| No. I'm not saying that C++ is not fit as a general purpose
| programming language. It very well may be. All I'm saying is
| that "adoption by millions is a testament to [the fitness of
| C++]" is not a valid argument. If it were, "adoption by
| millions is a testament to truth of [objective religious
| claim X]" would be a valid argument, and it manifestly isn't
| because different religions make mutually exclusive objective
| claims.
| jacoblambda wrote:
| "adoption of X is a testament that it is fit for purpose"
| and "adoption of X is a testament of truth" are two
| incredibly different things.
|
| The equivalent statement would be that "adoption by
| millions is a testament to the viability of X as a cohesive
| religion".
| lisper wrote:
| "Fitness as a general purpose programming language" is
| (at least in part) an objective claim. If a million
| people professed to believe that, say, brainfuck was fit
| as a general purpose programming language that in and of
| itself would not make it so. This is not the case for
| being a cohesive religion. If a million people profess to
| believe some religious belief, that in and of itself is
| sufficient for that belief to be a cohesive religion.
| trealira wrote:
| > If a million people professed to believe that, say,
| brainfuck was fit as a general purpose programming
| language that in and of itself would not make it so.
|
| No, but if millions of people actually did manage to use
| Brainfuck for general purpose programming, then that
| would be evidence that it really is fit as a general
| purpose programming language, even if it's not ideal.
|
| Brainfuck isn't in that position, hence no one thinks
| it's fit, but C++ is. People do use it for general
| purpose programming, even if their program could be
| rewritten in a garbage-collected language.
| galkk wrote:
| I like that this doc at least says that C++ is unergonomic. I'm
| always saying that good way to learn language patterns and idioms
| is to look into standard libraries implementations.
|
| And when you look into C++ libraries/stdlib, they often look like
| they're written in another language entirely. This is not normal.
| professoretc wrote:
| > I'm always saying that good way to learn language patterns
| and idioms is to look into standard libraries implementations.
|
| Why would that be true? When you write a library, you are
| writing code to cover _all possible_ uses; everything within
| the scope of your library should at least be considered, even
| if you personally have no need of that particular bit of
| functionality. But when you write a _program_ it only has to do
| one thing, so of course it 's going to be simpler. To me, it
| seems obvious that (good) library code will be very different
| from (good) application code.
|
| (I've used libraries that were written like applications, but
| they were bad libraries; I was constantly fighting the fact
| that the library author wrote only for their own use-case, and
| didn't consider any other.)
| josephg wrote:
| I hear you. But I've also learned a lot about how to write
| idiomatic rust from scrolling through rust's standard
| library. You're right - because it's written to support lots
| of programs, it sure is packed with a lot of functions I'll
| probably never use. But it's still quite beautiful and
| readable. Much more so than C++.
|
| Here's std::vec: https://doc.rust-
| lang.org/src/alloc/vec/mod.rs.html
|
| I tried to read C++'s vec class when I was learning C++ and I
| was confused and lost. I agree with the GP post - it feels
| like another language.
| blt wrote:
| I feel the C++ committee saw the major quality-of-life
| improvements from C++11 and convinced themselves that Python's
| ergonomics with templated C++'s speed was possible. I won't say
| it's impossible, but the backwards compatibility sure seems like
| too much weight.
| KerrAvon wrote:
| Is this a response to some specific set of proposals? I know
| there's been a lot of general angst / misunderstanding over C++
| memory safety.
| tempodox wrote:
| What's to misunderstand? There is no memory safety in C++.
| IshKebab wrote:
| It's a response to Rust. Rust is significantly better than C++,
| and most importantly it's the first language that could
| actually replace C++ for the things C++ is generally used for.
|
| I guess the C++ community is coming to terms with not being the
| top dog of "zero-cost abstraction" languages anymore.
|
| Really I think it's too late for C++. They had literal decades
| to fix very basic flaws, and they just haven't done it.
|
| Accidental octal literals. Case fall-through. Missing
| `return`s. Accidental string literal addition. The whole module
| system mess.
|
| They focused way too much on adding complex features and not at
| all on fixing footguns. As a result C++ is painful and
| dangerous. Too late to fix IMO.
| CoolGuySteve wrote:
| > It is easy to see that C++ is fit as a general-purpose
| programming language-adoption by millions is a testament to that.
|
| I really wish the std would drop this pretense and focus on C++'s
| strong point: Continue being the fastest systems language
| possible.
|
| Everywhere in the std lib you can see compromises that require
| rewriting substantial portions for any real time application.
|
| Things like: shared_ptr eagerly using atomics whenever possible;
| std::string allocating; the lack of built-in faster
| std::allocator replacements like bump allocators, memory pools,
| etc; no lockless and wait free concurrency primitives; no
| architecture-aware thread pools or even architecture
| descriptions; no IPC primitives; etc.
|
| Considering how many C++ developers are working on things like
| games, high performance server applications, databases, and
| operating systems, it's just bizarre how inappropriate the
| standard headers are for these tasks.
|
| Even something trivial like casting bytes off the wire to a
| packed struct is an exercise in frustration due to aliasing rules
| that should have been encoded in the type system and invisible to
| the user.
| zozbot234 wrote:
| Why does this have to be part of the standard library? Isn't
| that the whole point of Boost, that one is not limited to
| what's in std?
| CoolGuySteve wrote:
| It depends on the contributors, but boost also almost always
| fails to consider performance implications.
|
| For me it mostly looks like a reject pile for a stdlib that I
| must also reject most of the time.
|
| The alignment of incentives between these library authors and
| people that use C++ for high performance applications is just
| off.
| andrewmcwatters wrote:
| I have never once seen Boost seriously considered in
| performance environments.
| Kranar wrote:
| Boost has its uses and in many cases it's an improvement over
| the standard library, but performance isn't one of its key
| properties. Some parts of boost are about as fast as they can
| be, but that's the exception.
| shortrounddev2 wrote:
| It was my understanding that one can easily add their own
| allocator to any STL container, though as you point out you
| have to write that allocator yourself
| worik wrote:
| > one can easily add their own allocator to any STL
| container,
|
| You and I must have a different definition of "easily "
| CoolGuySteve wrote:
| You can but it's definitely not easy to do correctly.
|
| There's also a lack of traits that can describe what's
| required of a specialized allocator. For example, std::map
| only needs to allocate 1 object at a time in practice while
| std::vector needs to allocate a contiguous count of objects.
| gavinray wrote:
| > Continue being the fastest systems language possible.
|
| If you want to be pedantic -- in _theory_ C++ can never be the
| fastest systems language possible because of the language 's
| rules about aliasing.
|
| You'd need to smatter "_restrict" everywhere to skirt this.
| Kranar wrote:
| This is not pedantic at all. Aliasing issues are really
| subtle and hinder so many optimizations. It's not clear that
| there is a way to even fix this without substantially
| breaking backwards compatibility.
| dataangel wrote:
| > If you want to be pedantic -- in theory C++ can never be
| the fastest systems language possible because of the
| language's rules about aliasing.
|
| True but the only practical competitor is Rust, and they gain
| some alias information (mut) and lose other aliasing
| information (type punning is fully allowed in unsafe code all
| the time).
| zozbot234 wrote:
| Not so, unsafe code still has restrictions in Rust due to
| pointer provenance. You can override these restrictions but
| it's very much an explicit operation, the default is that
| pointers with incompatible provenance will not alias. This
| is how Rust models its equivalent to TBAA, and the concept
| is spreading to C/C++ as well.
| MaxBarraclough wrote:
| Your specific gripes seem reasonable (I suspect design-by-
| committee plays a big part), but:
|
| > I really wish the std would drop this pretense and focus on
| C++'s strong point: Continue being the fastest systems language
| possible.
|
| You've essentially described C, not C++. C++ has a different
| philosophy and makes different trade-offs.
|
| C++ is at least still pretty committed to the _you only pay for
| what you use_ principle. As far as I know RTTI is the only real
| exception (corrections welcome), but even RTTI can be disabled
| in many compilers.
|
| Some of your gripes with the standard library can be addressed
| with libraries, perhaps from the Boost project.
| gafferongames wrote:
| > C++ is at least still pretty committed to the you only pay
| for what you use principle. As far as I know RTTI is the only
| real exception (corrections welcome), but even RTTI can be
| disabled in many compilers.
|
| Compile time would also be an exception.
| throwaway81523 wrote:
| I had a program that had to parse a lot of integers like
| "12345". The std way to do it was an order of magnitude
| slower than writing my own simple parsing code. I have no
| idea what the std version was doing, but it was crazy to
| see my program's execution time (measured in hours)
| dominated by int parsing. The handwritten version
| eliminated that.
| IAmLiterallyAB wrote:
| > You've essentially described C
|
| I'd disagree pretty strongly with that. C is more focused on
| being relatively simple to implement and backwards
| compatibility with the past 50 years. (I read a blog post by
| a C committee member talking about that recently, wish I
| could find the link)
|
| Just look at the garbage fire which is the standard library.
| qsort. strtok. rand.
|
| C++ should (in theory at least) be able to match or surpass C
| for _any_ performance benchmark, because it simply gives you
| more tools in your toolbox. For example, C is never going to
| be able to beat std::sort because it can't monomorphize in
| the compare function.
|
| I'm not saying C++ is perfect either (looking at you
| unordered_map and regex). But I am saying people look at C
| with rose colored glasses.
| CoolGuySteve wrote:
| No, C is not the same as it is less expressive.
|
| C++ templates allow for declarative nested inlining into a
| single compilation unit that is extremely difficult to
| achieve with C macros.
|
| See elsewhere in this thread for discussion of boost, it's
| not applicable.
| weinzierl wrote:
| _" upcoming anti-C++ safety regulations"_
|
| Is this a thing really or just FUD?
| omoikane wrote:
| Probably related to things like these:
|
| https://news.ycombinator.com/item?id=33560227 - NSA urges orgs
| to use memory-safe programming languages
| steveklabnik wrote:
| What is a real thing: various government organizations arguing
| that projects should move towards memory safe languages.
|
| What is not a real thing: regulations requiring such.
|
| Some think regulations may come, others don't.
| unstruktured wrote:
| Not familiar with said regulations, but Ada was a good example
| of not using C++ for these very reasons in a military context.
| barryrandall wrote:
| It's both and neither. Some countries are considering
| legislation to require "memory-safe" tooling for "critical"
| workloads, and C++ has never been placed on the "memory-safe
| tooling" list.
| steveklabnik wrote:
| Which countries? Can you share the reporting on this
| legislation? I'd be very interested.
| cbsmith wrote:
| "Consider the hoops one needs to jump through to make std::print
| work with a custom type when compared to the old stream
| operators."
|
| As an old timer, this kind of made me laugh. I remember when
| people found the old stream operators burdensome.
| 29athrowaway wrote:
| If C++ wants to continue evolving, it needs breaking changes. It
| needs to impose a migration duty to the user, but that is not
| going to happen.
|
| So it will die a death by entropy where noone can know the
| language.
| tempodox wrote:
| > it needs breaking changes.
|
| Then nobody will use the new compiler because nobody wants to
| rewrite millions of LOC and introduce new bugs.
| 29athrowaway wrote:
| AI will do it one day.
| eej71 wrote:
| I think the great challenge with breaking changes is
| demonstrating how other systems have done breaking changes with
| great success. They are quite rare. And no, the
| python2->python3 migration is not one of them. Neither is
| ip4->ip6.
| clibraries wrote:
| weird to throw in 3 pet libraries he is advocating for at the end
| artagnon wrote:
| Honestly, everyone working with C++ sticks to a select subset of
| the language that they've chosen for their project, or the
| project they're contributing to. Nobody knows all of C++.
| Personally, I don't mind C++ forking out in different directions
| and accepting diverse proposals; while I wouldn't bother to use
| them myself, I realize that it may be useful to other people.
|
| C++ is an engineer's language, and it's ridiculous to imagine
| that we'd ever need a C++2.0 that cleans it up. Subjectively, you
| could say that some features are "ugly", but this is an
| evolutionary process, and there are bound to be vestigial
| features.
|
| Yes, there are memory safety issues, but in practice, these are
| isolated in very few places. Take a compiler like LLVM for
| instance: most developers are working on transforms or analyses,
| and they're exposed to zero manual memory management. Sure, the
| Pass Manager needs to build passes, and the IR needs to be
| allocated, but that's about all the manual memory management
| there is.
|
| Personally, I couldn't care less about standardized argv-parsing,
| as each project has its own set of complex requirements. There
| are JSON parsing libraries available for C++, and I don't see why
| it should be standardized. Faster hashing in std could be a low-
| priority feature, but projects like LLVM have their own optimized
| version of std data structures and algorithms.
|
| I suppose a module system could be useful; most C++ projects are
| built with CMake which is already very good at finding and
| linking dependencies. Personally, my biggest pain point is
| compile-times, but that's really an LLVM/Clang problem.
|
| Overall, the article doesn't seem to be written by someone who
| has a lot of experience with large C++ codebases.
| wavemode wrote:
| I agree with everything written here - C++ is never going to be
| Rust, or any other language, but it can at least become better
| than it is now, in some common-sense ways.
|
| In my view, C++'s biggest problem is its design-by-committee
| structure, leading to a lack of pragmatism - in other words,
| perfect is the enemy of good. Pragmatism is what you see when you
| look at the standard libraries of languages like Python and Java:
| are they perfect? Far from it. But they prioritize being at least
| good enough for a good amount of situations, over being perfect.
| Which ends up being far more useful for regular people. And being
| useful for regular people is what makes a programming language
| successful.
|
| But design by committee means if your proposal isn't perfect, it
| will get shot down. So the language remains bad for everyone's
| use cases, rather than at least becoming somewhat good for some
| people's use cases.
| chris_wot wrote:
| I have seen that the biggest issue with C++ is that legacy C++ is
| quite hard to refactor to the new patterns. For example, I have
| been working on font substitution in LibreOffice, and I'd like to
| use a more functional style of programming, but I'm getting stuck
| because of an overuse of classes.
|
| I've been reading Functional Programming in C++ by Ivan Cukic and
| I'd like to adopt this - it does require a lot of refactoring of
| this massive codebase.
|
| Perhaps this is a massive, ancient codebase issue more than a C++
| issue, though.
| andrewmcwatters wrote:
| I think this is one place where you're totally working against
| the language.
|
| Edit: I don't know how you can arrive at this conclusion given
| the history of the language. The STL isn't the C++ standard
| library.
|
| I would love to discuss this more, but dang has limited and
| nerfed my account.
| chris_wot wrote:
| Not really. Look at the standard template library. It's not
| really using classes with inheritance. It's using non-member
| functions, often with iterators.
|
| Ironically I've just learned, however, that lambdas are
| actually anonymous classes! I'm currently up to the bit in
| yhe book I referred to before that explains how to do
| currying in C++.
|
| The more I read, the more I think I'm working against the
| code base than I am against C++. I'm actually very curious
| how ranges work, something the book talks about later.
| samsquire wrote:
| I hope people don't throw out the effective and well-thought out
| parts with the problematic parts.
|
| It happened with Macromedia Flash and it happened with
| Microsoft's Visual Basic. The JVM and industry attitudes to Java.
| PHP.
|
| We have lost some good technology over time, please don't let us
| lose the good parts of C++.
| andrewmcwatters wrote:
| For whatever reason, the software industry never learns this
| lesson. Maybe because people would rather move on to something
| new entirely and new entrants are not aware of what they're
| losing at all.
| fl0ki wrote:
| > However, I don't want to give the impression we should say no
| to all proposals. There are plenty of opportunities to improve
| our user's lives through proposals. Here are a few concrete
| examples: [all 3 are just library additions that exist outside
| the standard already]
|
| This may not have been the intent, but the way I read it, it's
| saying that language evolution is now pointless and only library
| additions can be considered. That would be a pretty dire
| situation for C++ overall.
|
| Never mind that this means many language issues will never be
| fixed, it would also mean that implementations face the burden of
| yet more standard library additions which quickly fall behind
| external libraries because of the added burden of ABI lockin, and
| now multiplied by several vendors vs just one third party
| library.
| fancyfredbot wrote:
| What is the proposed legislation referred to in this article?
___________________________________________________________________
(page generated 2023-12-19 23:01 UTC)