[HN Gopher] C++ is an absolute blast
___________________________________________________________________
C++ is an absolute blast
Author : ok123456
Score : 110 points
Date : 2024-12-23 15:37 UTC (7 hours ago)
(HTM) web link (learncodethehardway.com)
(TXT) w3m dump (learncodethehardway.com)
| pjmlp wrote:
| While it is a great language, ir would profit from less "lets
| code C with C++ compiler" attitude.
|
| Basically it is like renaming those JavaScript files from .js to
| .ts, and keep coding as if nothing else is available as
| productivity and safety improvements.
| ablob wrote:
| Having read the article, nothing really stands out to me as "C
| with C++ compiler".
|
| It talks about ranges, shared/unique pointers, lambdas...
| Essentially a lot of things C is lacking. I don't know where
| exacly the overlap you're insinuating comes from.
| pjmlp wrote:
| Where did I mentioned the article?
| rickmode wrote:
| Pronoun confusion. The second pronoun is ambiguous.
|
| Since we are all "hackers" here, I'll be pedantic...
|
| "While it is a great language..."
|
| The "it" pronoun clearly refers to the C++ language, as I'm
| sure you intended.
|
| "...ir would profit from less 'lets code C with C++
| compiler ' attitude."
|
| The "ir" -- presumably a typo for "it" -- can refer to the
| article or C++. Given that this thread is about an article,
| the second "it" referring to the article is a natural
| assumption.
| pjmlp wrote:
| It with typo refers to C++.
| thefourthchime wrote:
| I feel like an abused spouse after C++. I now avoid:
|
| - Inheritance - Reference counting - Threading - Templates -
| Classes if possible - Hidden memory allocation - Anything that
| looks clever
|
| Anytime I use them I get flashbacks to some mangled mess of
| templated threaded classes with some memory leak that shows up
| after 3 days.
|
| I remember writing C++ and trying to figure out how the design
| would work between these classes, I would end up with something
| complicated and not entirely correct. Eventually, I thought,
| what if I did this in C? What would it look like, 90% it turns
| out with 90% less design and code (and bugs).
| pjmlp wrote:
| There is no rule that requires "programming in C++ proper"
| being equal with using 100% of the language standard.
|
| There is a middle layer, without having to keep repeating all
| the security flaws of coding in plain C.
| xorvoid wrote:
| I'm glad someone is having fun in C++. Personally, after >20
| years, I have to be done with C++. It's just a mess.
|
| If I really need the low-level control, I can wrangle C (warts
| and all), otherwise Rust, Python, etc just make me happier.
| pjmlp wrote:
| Beware of C23 and later.
|
| C is basically going into "we want C++ but without OOP and with
| templates done via _Generic".
|
| Also LLVM and GCC aren't going to be rewritten from C++ into
| Rust anytime soon.
| bilekas wrote:
| > Also LLVM and GCC aren't going to be rewritten from C++
| into Rust anytime soon.
|
| I'm afraid you underestimate the will power of rustaceans to
| find literally anything to rewrite.
| pjmlp wrote:
| I doubt Cranelift will ever match the only project that has
| beaten the contribution level of Linux kernel.
| cornstalks wrote:
| > _Beware of C23 and later._
|
| Beware of what? C23 fixed a number of issues. Sure, there are
| some oddballs (QChar and auto, mostly), but overall I think
| C23 is an improvement.
| pjmlp wrote:
| Those C89 hardliners have a different point of view.
|
| Also there is the whole point Objective-C and C++ are much
| better than those improvements will ever be.
| motorest wrote:
| > Those C89 hardliners have a different point of view.
|
| C89 was only a thing because Microsoft somehow decided to
| drag it's feet and prevented msvc from supporting
| anything beyond c89 for a long, long time. Only in 2020
| did they manage to finally do something about it.
|
| https://devblogs.microsoft.com/cppblog/c11-and-c17-standa
| rd-...
| pjmlp wrote:
| Because for Microsoft C belonged into the past, it was
| about time to move into C++.
|
| https://herbsutter.com/2012/05/03/reader-qa-what-about-
| vc-an...
|
| They only changed of point of view after Satya, and the
| whole Microsoft <3 Linux and Microsoft <3 FOSS pivot.
|
| And in any case, blaming Microsoft doesn't really work
| out, as many of those folks don't even care Windows
| exists, only UNIX/POSIX platforms.
| janice1999 wrote:
| I imagine most C programmers are still using C99 or older
| anyway, particularly in the embedded space.
| ericbarrett wrote:
| I'm not sure this is still true. I'm just a hobbyist but
| esp-idf, for example, supports C++23.
| yodsanklai wrote:
| Agree. C++ is here to stay though. Too much code written in
| that language. It's certainly a great skill to have, and there
| are super lucrative jobs too.
|
| For me, I feel the language just go in the way and is way too
| complex. Sure, I know the discourse: "modern C++" is great, you
| don't need to learn about older. versions of C++, things are
| getting simpler with each new version.
|
| The problem is that the codebase you get to work on aren't
| modern C++. They use every possible feature ever released and
| it's just hard and full of pitfalls.
|
| I suppose people who have only work on C++ in their projects
| for years can develop some level of expertise and are immune to
| the complexity. But really, not a great language...
| jandrewrogers wrote:
| One of the things that has made C++ more tolerable over time is
| that it became easy to seamlessly replace most of it with an
| implementation that works the way you think it should and with
| most behaviors being fully defined -- the core data types,
| standard library, etc. Particularly with C++20 and later,
| alternative foundations feel quite native and expressive.
|
| Most new C++ projects I see lean into this quite heavily. The
| ease with which you can build a systems-level DSL for your
| application is a strength of C++.
| motorest wrote:
| > I'm glad someone is having fun in C++. Personally, after >20
| years, I have to be done with C++. It's just a mess.
|
| I've spent a couple of decades working with C++, and the truth
| of the matter is that, as much as it pains the bandwagony
| types, C++ became great to work with once C++11 was rolled out.
| The problem is that teams need to port their projects to >C++11
| and that takes an awful lot of work (replace raw pointers with
| smart ones, rearchitect projects to shed away C-style
| constructs, etc) which some product managers are not eager to
| take.
|
| I firmly believe that the bulk of this irrational hatred
| towards C++ comes from naive developers who try to rationalize
| away their lack of experience by blaming everything on the
| tool. On top of this, cargo-cult mentality also plays a role.
|
| What makes this quite obvious is the fact that the solution
| presented to all problems always comes in the form of major
| rewrites, even with experimental and unproven features and
| technologies. Writing everything again is always the solution
| to everything. Everyone before them knows nothing whereas these
| messiah, cursed with being the only ones who see the one true
| answer, always have a quick and easy answer to everything which
| always boils down to rewriting everything from scratch with the
| flavor of the month. Always.
|
| Weird, huh?
| ModernMech wrote:
| > C++ became great to work with once C++11 was rolled out.
| The problem is that teams need to port their projects to
| >C++11
|
| The problem is the C++ that's not great to work with is still
| there, and there's nothing preventing the rest of the world
| from using it; there are always going to be naive developers
| with a lack of experience who don't know how to use the tool.
| For this reason, all the code that's possible to write in C++
| will be written, that includes the unsafe code.
|
| It's not enough to have a safe, nice, modern, subset of C++
| that everyone "should" use. If developers have the option to
| use the warty, sharp, foot-gun infested version of C++ they
| will, and they will gift that code to the rest of us in the
| form of readily exploitable software.
|
| This is why organizations like CISA are suggesting developers
| move to other languages that take a stricter posture on
| memory safety: https://www.cisa.gov/news-events/news/urgent-
| need-memory-saf...
|
| > companies should investigate memory safe programming
| languages. Most modern programming languages other than C/C++
| are already memory safe. Memory safe programming languages
| manage the computer's memory so the programmer cannot
| introduce memory safety vulnerabilities. Compared to other
| available mitigations that require constant upkeep - either
| in the form of developing new defenses, sifting through
| vulnerability scans, or human labor - no work has to be done
| once code is written in a memory safe programming language to
| keep it memory safe.
| motorest wrote:
| > The problem is the C++ that's not great to work with is
| still there, and there's nothing preventing the rest of the
| world from using it;
|
| That's precisely why all this criticism is actually thinly
| veiled naive inexperient developers blaming the tools.
| Selling full rewrites as solutions to the problems they
| created is a telltale sign. As they are lacking the
| experience and know-how to fix the mess, they succumb to
| the junior dev disease of believing deleting everything and
| starting from scratch is a solution to all of life's
| problems and inconveniences.
| markus_zhang wrote:
| I take a few features from C++ in my C++/SDL2 Ultima spinoff
| project -- never completed sadly. Class, std::function,
| std::unordered_map, std::string, std::unique_ptr<type> are the
| only ones that I could recall.
|
| I can't imagine reading other people's code though, unless it's
| in a similar style. I did find that the most difficult part is
| to get past the programming patterns (such as Visitor pattern)
| as I don't write large programs professionally.
|
| I wish C++ stopped at C++/11. The committee seems to want to
| include everything into it at the moment. Maybe C++ is sort of
| ULTRA programming language that supports every niche
| programming style.
| jandrewrogers wrote:
| FWIW, C++20 is a _much_ tidier and more usable language than
| C++11. The difference between C++11 and C++20 is almost as
| large as C++11 and legacy C++.
| mort96 wrote:
| C++ is an absolute mess.
|
| But it's a fun mess, and I like writing in it :) Sometimes,
| that's important.
|
| My relationship with, say, Rust is much colder: I respect Rust,
| I use Rust where I think it makes sense (especially in e.g
| professional contexts where I often can't defend the use of
| C++), and I think what it's doing is important. But I find it
| tedious to write, despite having a fair amount of Rust projects
| under my belt at this point. It's better in key ways, but not
| as _enjoyable_ , for me.
| NotGMan wrote:
| The problem with any language trying to replace C++ for larger
| codebases is that it's not half as powerful as C++.
|
| I've often cursed in C# because something that could be done
| trivially in C++ if impossible and causes the dev to create
| convuluted C# while it could be trivialy done in C++ due to its
| very expressive language features.
|
| Those 0.1% of the time that you need those extreme features are
| what makes or breaks the language in PRODUCTION.
| sidpatil wrote:
| What are some examples of these C++ features you've missed in
| other languages?
| pixelpoet wrote:
| Zig not having operator overloading makes it suck horribly
| for writing any kind of vector code. If everyone had to write
| int a = int_add(int_mul(3, 7), 2) etc there would rightly be
| a riot, but since they're not 3D coders they just don't give
| a shit. Too bad, Zig looks great.
| blharr wrote:
| I've had the exact same experience, but opposite. Tons of
| things that are trivial in C# take a ton of code in C++ to me.
| Maybe it's just going from being an expert in one language to a
| newer language?
| neonsunset wrote:
| This often comes from expecting C# to be _just_ like C++,
| where-as more complex use cases are often expected to be done
| in a (sometimes completely) different way there. It 's a good
| idea to try not to fight the language and work _with_ the way
| it exposes its features.
|
| My experience was just like yours - easy to move between C
| and C#, or Rust and C#. But attempting C++ implementation was
| always far more difficult. It was never worth it over just
| spending extra effort in either alternative.
|
| If GP reply author has C#-specific questions I'd be happy to
| answer or point him or her in the right direction. C# is a
| language with strong systems programming capabilities but has
| its own learning curve.
| ykonstant wrote:
| That claim certainly warrants a serious example. Perhaps you
| mean "something ... requiring maximum performance ..."?
| GlenTheMachine wrote:
| OK, so I admit I also washed my hands of C++ sometime around 2009
| and I am being forced back into for <reasons>, and I had no idea
| what these auto and lambda keywords were.
|
| Can anyone point me to a learning reference that will let me jump
| the meta programming apocalypse and just get to the good stuff?
| seanthemon wrote:
| jump into learncpp and choose where to start from, goodluck
| olvy0 wrote:
| The "Back to Basics" videos from cppcon are pretty good, IMO.
|
| For lambdas: Back to Basics: Lambdas - Nicolai Josuttis -
| CppCon 2021
|
| https://www.youtube.com/watch?v=IgNUBw3vcO4
|
| Back To Basics: Lambda Expressions - Barbara Geller & Ansel
| Sermersheim - CppCon 2020
|
| https://www.youtube.com/watch?v=ZIPNFcw6V9o
|
| For auto, this one is short and summarizes some of the gotachs:
|
| C++ Weekly - Ep 287 - Understanding `auto`
|
| https://www.youtube.com/watch?v=tn69TCMdYbQ
| vitaut wrote:
| > C++ has built-in regex now and they're pretty damn good too
|
| Sadly, `std::regex` is anything but good (poor performance, lack
| of Unicode support) and should be generally avoided.
| yodsanklai wrote:
| The linter used at my work insists on not using it....
| fooker wrote:
| Is there something wrong with the specification that causes
| poor performance?
| steveklabnik wrote:
| It's ultimately a "won't break ABI" issue:
| https://stackoverflow.com/a/70587711
| johannes1234321 wrote:
| The underlying issue is that for the matches the interface
| relies a lot on heap allocations for the individual matches,
| leading to a lot of allocations of small regions to copy from
| the original input. Many other libraries provide a lot more
| control there.
|
| In benchmarks std::regexp often is a lot slower compared to
| other implementations, independent from the standard library
| implementation of choice.
|
| The big upside compared to all others is that it's always
| available. But if there is a choice alternatives are often
| better.
| sumuyuda wrote:
| I'm not for sure auto is an improvement. I know it is required
| for lambdas and it makes it easier to type out a very verbose
| type, but it really does reduce code readability.
|
| I've even seen developers use it instead of bool, which is pretty
| laughable as the they are the same number of characters.
| wk_end wrote:
| A verbose enough type - and C++ has plenty of those - is
| indistinguishable from line noise.
|
| There are places where having an explicit type annotation can
| improve readability, places where it harms readability, places
| where it doesn't make much difference one way or another.
| Giving us the option has been a blessing. All programming calls
| for good taste, C++ programming calls for it more than most.
| SloopJon wrote:
| This is a long rant that covers a lot of ground, a lot of which
| will inevitably be ignored because the letters "C++" trigger
| people, myself included sometimes. (Skip ahead to "It's Not All
| Puppies and Butterflies" for some of the complaints.) The author
| is really impressed by C++11, as am I, after purposely ignoring
| C++ for the better part of twenty years.
|
| I appreciate the shout outs to some packages and libraries to
| play with, although I still often find it a pain to incorporate
| other libraries into my projects. (Single-file headers, anyone?)
| I'm intrigued by FTXUI.
|
| And boy, howdy, he's right: cppreference.com is amazing. Python's
| documentation is pretty good, but I've never seen anything as
| good as cppreference.com.
| DidYaWipe wrote:
| I've had some good times in C++. But for everything that's been
| thrown into it, I can't believe we're still dealing with header
| files. That was one of the greatest things about moving to Swift:
| no more of that BS.
|
| But with SwiftUI, Swift has also become "unfun." SwiftUI and
| Apple's half-assed, broken observation and "reactive" paradigm
| have made programming a joyless slog.
| badpun wrote:
| C++20 has modules, which replace header files completely
| (unless you use old libraries which aren't available as modules
| yet). Compiler support is there, but unfortunately IDEs are
| lagging. If you use modules with Visual Studio, say goodbye to
| IntelliSense. Maybe they'll iron out the bugs in a couple
| years...
| DidYaWipe wrote:
| Wow, that's ridiculous.
|
| I wonder if Xcode does any better with them. Now that would
| be something.
| ModernMech wrote:
| C++ has modules for small values of "modules":
| https://arewemodulesyet.org
|
| It's a bit tongue in cheek but: "Are we modules yet? Nope.
| ... Estimated finish by: Wed Sep 20 2541"
| badpun wrote:
| You can use modules to structure your own codebase. No more
| need to write headers and think about how to structure your
| code in terms of compilation units. But yeah, your link
| shows that practically none of the popular libraries
| (except STL) can be imported as modules today.
| sumuyuda wrote:
| I did C and C++, then moved on to Objective-C and Swift. I
| recently switched back to C++, after getting tired of Apple's
| shit treatment of developers. I also have no interest in
| learning SwiftUI.
|
| Having to define header files in C++ is pretty annoying after
| doing Swift for many years.
| motorest wrote:
| > I've had some good times in C++. But for everything that's
| been thrown into it, I can't believe we're still dealing with
| header files.
|
| There is nothing wrong with header files. In fact, there is no
| such thing as a header file specified in C++. There are only
| forward declarations and definitions, and how those can be
| managed by developers.
|
| Meaning, any talk about header files is a discussion on
| software engineering practices, and how developers create or
| avoid their own problems.
| DidYaWipe wrote:
| "There are only forward declarations and definitions, and how
| those can be managed by developers."
|
| Why do we need to manage them?
| motorest wrote:
| > Why do we need to manage them?
|
| Why do developers need to write code that makes sense and
| does what they want it to do?
| DidYaWipe wrote:
| Enjoy your echo chamber.
| motorest wrote:
| > Enjoy your echo chamber.
|
| Is that supposed to mean anything at all?
| 01100011 wrote:
| I periodically work on c++ instead of C and each time it follows
| a similar pattern where I learn about some new c++ trick, think
| it will make things better, write my code, hit a compiler error,
| then spend the rest of the day learning why I can't do what I
| want. Granted, I usually am stuck at c++14, and some of the
| issues are fixed in future versions but still...
|
| I really want to love C++. It gives me a more powerful C that
| theoretically should improve my output but in the end it carries
| so much cognitive baggage that I usually end up writing "C with
| classes" and move on.
| blastonico wrote:
| chatgpt or copilot helps a lot with that. I usually copy the
| text and let it decipher the thing for me.
| mithametacs wrote:
| they're still bad for generating any significant body of
| code.
|
| They're a little bit better about deciphering errors.
|
| They'll still bullshit* you and send you on wild goose
| chases.
|
| *hallucinate if you prefer
| matheusmoreira wrote:
| > They'll still bullshit you and send you on wild goose
| chases
|
| And confidently at that. It can't seem to find the backbone
| to say no to me either.
|
| If I say something like "wait, X doesn't seem to make
| sense, isn't it actually Y and Z?" it will agree and
| reformulate the answer as if Y and Z were correct just to
| placate me. I usually use the LLM to learn new things, I
| don't don't actually know if Y and Z apply.
| fooker wrote:
| C++, like most technology, works better if you put in the work
| to learn about it.
|
| (Admittedly there are languages like python and ruby that buck
| this trend.)
| motorest wrote:
| > C++, like most technology, works better if you put in the
| work to learn about it.
|
| There's also the impact of software entropy: if someone has
| little to no experience developing software and has to grow
| it by adding features and fixing bugs, over time their
| contribution to the project invariably results in degrading
| it beyond the point they can possibly salvage it.
|
| At that point, they blame the tools.
| gopalv wrote:
| > then spend the rest of the day learning why I can't do what I
| want
|
| There's a point when learning's fun, I think the OP is still
| there.
|
| I wrote a bunch of realtime C++ in 2003, hated it. But last
| year, I wrote most of my code in C++ and liked it finally.
|
| Lambda and auto was the tipping point where I stopped hating
| it. Some templates thrown in, but mostly to avoid writing a lot
| of branches for variants of the same function.
|
| With lambdas I could now write the way I was initially taught
| programming, mostly by Lispy teachers channeling SICP.
|
| Didn't hate the allocations either with unique_ptr.
| hashishen wrote:
| "Lispy teachers channeling SICP" made new audibly laugh
| liendolucas wrote:
| A bold statement from Ken Thompson on C++:
| https://m.youtube.com/watch?v=c-P5R0aMylM
| blastonico wrote:
| The amount of high performance, production grade, massively
| tested libraries written in C++ is unbeatable. I will be honest
| here, it's easier to improve C++ security by implementing a
| compiler that produces safer C++ (like Typescript to Javascript)
| than rewriting everything in any other language (Rust, Zig, Odin,
| whatever).
|
| I mean, could you estimate the cost ($ and time) it would take to
| rewrite the best audio framework in any other language?
| (https://juce.com/).
| devjab wrote:
| Zig is great, it's not aiming to be a replacement for C++
| though. One of the awesome things about Zig is its
| interoperability with C. In that sense it's more of a
| Typescript to C than Rust is to C++. I'm still not sure what I
| think about Rust personally. In my region of the world I
| suspect it'll continue to struggle to find any form of adoption
| as the C++ people seem to have very little interest in trading
| their decade long experience for Rust. Zig on the other hand is
| winning the hearts and minds of most C programmers I know.
|
| I hope Rust succeeds though. I say this more from a change
| management perspective than anything else. It's extremely hard
| for us to find developers who will primarily work with garbage
| collected languages but occasionally have to work with either C
| or C++ when bottle necks appear. Rust makes that much easier,
| or perhaps less dangerous would be a better term. I'm not sure
| any of the attempts at making C++ more safe to use is going to
| really succeed in this regard. Maybe, but I nothing within the
| C++ community seems to pull in that direction so I doubt it.
| I'd like to mention that I'm aware that Zig isn't helpful in
| this regard either as it's not memory safe.
| FpUser wrote:
| Agree. Sure there are problems here and there but I think that
| overall modern C++ is likely the most versatile tool in the
| "compiled to native, can do anything" family
| byyoung3 wrote:
| no, its not
| jonstewart wrote:
| Every time I try to use Rust instead of C++, I'm left asking
| "bruh, do you even functor?"
| macawfish wrote:
| Using c++ after learning rust feels like picking through moldy
| bread
| hypeatei wrote:
| Using C++ after Rust made me appreciate the latter a lot more.
| You quickly learn all the footguns that the compiler stops you
| from doing and is generally a good learning experience.
| ModernMech wrote:
| This is what I feel as well. I liken it to using an aimbot in
| Quake. Turn off the aimbot and you still win because the
| aimbot trained you how to get headshots. There are many times
| the Rust compiler told me I couldn't do something I had
| insisted would be fine, only to ponder and realize in fact
| what I was doing would cause subtle bugs in an edge case.
| Rust catches it at compile time, C++ allows you to write the
| code and sends you a segfault when the subtle edge case
| occurs in production.
| aleden wrote:
| For the love of God when will c++ compilers finally be able to
| output template errors that aren't completely expanded and are
| written in terms of the user's typedefs? Most of the time I spend
| parsing template errors with boost is just to figure out what the
| hell is being complained about.
| ModernMech wrote:
| I have found LLMs are a great tool for metaprogramming. I think
| the template error problem has been wanting for a sufficiently
| advanced compiler, and that's what I see LLMs as being. ChatGPT
| has been a great help in debugging programs I've written in C++
| templates, both in generating the template code and trying to
| decipher errors generated, leading to suggestions for the
| template code rather than the expanded syntax.
| aleden wrote:
| Yeah, totally. I find LLMs are very useful for doing stuff
| with the preprocessor, too. ChatGPT taught me how to use
| boost preprocessor (BOOST_PP_FOR_EACH_PRODUCT).
|
| Still though, I want to see MyMapType::value_type in compiler
| errors rather than... Well, you know. It's going to contain
| the type of the key, the type of the value, the type of the
| allocator, just when all you want to really know is that it's
| a pair<key, value>, which I think most people know of as My
| map type::value_type.
| wk_end wrote:
| Weren't concepts supposed to fix this? Apparently they made it
| into the 2020 standard. I haven't touched the language in many
| years - did they not help?
| ryao wrote:
| > I want you to ask yourself an honest question. When was the
| last time you actually had fun in programming?
|
| Every time I write C code.
| binary132 wrote:
| For me, C is fun until I hit a certain level of abstraction
| complexity involving fake homespun vtables and it starts
| getting harder than it should be to chase down bugs.
| 8f2ab37a-ed6c wrote:
| Come write products on top of Unreal Engine, you will have the
| opportunity to dive into 20+ MLoC of real time C++ goodness. Make
| sure it's a multiplayer experience for bonus points, eventual
| consistency makes everything extra exciting.
|
| It gives you an appreciation of just how unlikely we're to ever
| move away from the stuff, short of an LLM innovation that can
| digest codebases of that size and do an automated port, which I
| suppose is not outside of the realm of reality these days.
| IshKebab wrote:
| There's too much wrong in this rant to list...
| ModernMech wrote:
| I think we can start with "C++ is not popular enough to attract
| the weirdos".
|
| Presumes C++ is not popular and also popularity attracts
| weirdos. If anything, weirdos are attracted to languages that
| are not popular at all. I remember once I was on a small
| language project and this guy on the mailing list wouldn't stop
| going on about how our language had to support vorpal math.
| nayuki wrote:
| > C++ Is An Absolute Blast
|
| No, it's one of the worst languages I ever used. Tons of footguns
| and bad design choices everywhere. Too much cognitive load for
| less benefit than other languages.
|
| I'm surprised the article didn't mention <iostream>. The
| f.fail(), f.eof(), f.flags() are confusing and verbose. Even
| something as simple as f.read() doesn't return the number of
| elements read, so you need to make a separate call to f.gcount().
| And then there are all the opaque types like std::streamsize,
| std::mbstate_t, etc., where you have no idea how their sizes
| relate to language types like int/long/etc. or fixed-width types
| like int32_t/uint64_t/etc.
| https://en.cppreference.com/w/cpp/string/char_traits
|
| And then there are the redundancies. int x = 0; int x(0); int
| x{0}; all roughly do the same things but have subtle differences
| in more advanced use cases. This recent thread (
| https://codereview.stackexchange.com/questions/294784/c20-ro... )
| reminded me that `typedef` got replaced by `using`. A while ago,
| I came up with a long list of near-duplicate features:
| https://www.nayuki.io/page/near-duplicate-features-of-cplusp...
|
| > JavaScript still can't even figure out what a for-loop is
|
| ECMAScript 6 added the for-of loop, which is the more useful
| alternative to the for-in loop.
|
| > C++ has lambda, and it's not bullshit like Python's lambda
|
| C++ lambdas have a heavier syntax than any other lambda I know of
| (e.g. Python, Java, JavaScript, Haskell, Rust), because it needs
| to specify attributes and captures.
| https://en.cppreference.com/w/cpp/language/lambda
|
| > My thinking is C++ is now about as good as any other language
| out there
|
| Not by a longshot. Instead of C++, I reach for Java if I want
| fast design time, safe operations, and a more limited set of
| tools (e.g. not needing to decide how many layers of pointer
| indirection I want). I reach for Rust if I want the power of C++
| without its footguns.
|
| Heck, my motto for Rust has always been, "C++ done right". Every
| time I compare analogous features in C++ and Rust, I find that
| the Rust version is much better designed. As the simplest
| example, in Rust it's a compile-time error to use a variable
| whose value is moved out, whereas in C++ the variable is still
| usable but has an invalid value. Another example is that Rust has
| traits but C++ relies on instantiating templates and then "duck-
| typing" to see if the resulting code can actually compile. And
| let's not forget nullptr, the trillion-dollar mistake - C++ makes
| nullptr implicitly part of every pointer(*) type, but Rust bans
| it by default unless you opt in with Option<T>. Rust has other
| quality-of-life features such as easily declared tuple types, the
| unit type instead of void (which makes functional programming
| easier as you don't have to special-case void), pattern matching
| and unpacking, methods on primitive types (e.g. 456u32.isqrt()
| instead of sqrt(456)). I just can't look at C++ seriously when
| Rust is miles ahead, being more expressive and safer.
|
| > The Amazing Comeback of C++11
|
| I will agree with this in a limited sense When I write C++ code
| (because I'm a masochist), I will not tolerate anything less than
| C++11, because C++03 and C++98 are much, much worse. I'm talking
| about things like various types, standard library
| classes/functions, unique_ptr, and move semantics.
| motorest wrote:
| > No, it's one of the worst languages I ever used.
|
| That says more about you than the languages you've used.
|
| C++ is one of the top 5 languages used in production. This is
| true still today, with so many specialized languages to pick
| and choose. No one had to hold a gun to anyone's head to get
| them to adopt it. How do you rationalize that if your opinion
| had any substance or merit?
|
| For the sake of argument, I assert exactly the opposite: C++
| post-C++11 is the absolute best language ever devised by
| mankind, bar none. Am I wrong?
|
| > Tons of footguns and bad design choices everywhere.
|
| Please go ahead and point out the single most egregious "foot
| gun" or bad design choice you can possibly imagine. The worst.
| This will serve to show the world how well thought through your
| opinion actually is.
| whytevuhuni wrote:
| I don't think C++ is one of the worst languages; there are
| very few languages as powerful as C++, that alone makes it
| one of the best.
|
| But, much like love and hate, I also don't think that the
| opposite of good is always necessarily bad, nor vice-versa. A
| language can be both good and bad at the same time, in
| different aspects.
|
| C++ is really good (unrestrained freedom, performance,
| ecosystem), and also really bad (tooling, templates, really
| hard to debug memory issues).
|
| Rust is somewhat less good (less free, slower, puny ecosystem
| in comparison), but also a _lot_ less bad (powerful type
| system, thread safety, fearless iterators /lambdas, etc).
|
| Many of the warts C++ has to carry due to its commitment to
| compatibility, are fixed in Rust with much better
| alternatives. A lot of footguns are well encapsulated in
| Rust's affine-ish types and algebraic data types, while still
| providing unsafe hatches for when you need them. Defaults
| really matter.
| jandrewrogers wrote:
| > in Rust it's a compile-time error to use a variable whose
| value is moved out, whereas in C++ the variable is still usable
| but has an invalid value
|
| C++ does it this way because there are common cases in systems
| code where doing it the Rust way would literally be unsafe. Not
| all memory references are visible at compile-time and may exist
| outside the address space.
| aw1621107 wrote:
| Would you mind elaborating more on those common cases? I'm
| not sure I've heard of destructive moves being less safe than
| non-destructive moves and I'm not smart enough to figure out
| what you're talking about in your second sentence.
| halfcat wrote:
| I recall not being very effective with C++ for years, and then
| someone recommended the book Large Scale C++ Software Design, and
| that was a big unlock.
|
| I didn't use 80% of what's in the book, but just having a
| comprehensive way of structuring the code was a massive
| productivity boost. Looking back, I suspect it was less that it
| was "the right way", but just that it was "a way" and most of the
| benefit was it kept me from overthinking and got me to work.
|
| Later with C++11, I kept having this thought, "in Python this
| would be way less verbose", and I started writing C++ that looked
| more like Python, creating whatever helper functions Python would
| have (mostly simple stuff, string handling, etc).
|
| That was one of the most productive seasons of programming I ever
| had, and I still get tempted to write stuff in C++ that Python is
| better suited for, just because the benefit of not overthinking
| is that significant (at least for me).
| andai wrote:
| >But, C++ kept evolving, and the standards committee seemed to
| realize that if they don't do something they'll become an obscure
| language only used by a single 10 trillion dollar industry. How
| pathetic!
|
| Which industry is this referring to?
| brabel wrote:
| My guess is that it's the game industry, because it's probably
| worth that much and is almost pure C++.
| ajuc wrote:
| The stuff you use for work is not fun. The stuff you use for fun
| is fun. There, I solved the mystery for you.
|
| If you choose technology for work by what is the most fun - you
| enter a hedonist treadmill. Stop. JS framework insanity lies that
| way. No cool technology will save you from burnout.
| klysm wrote:
| I openly detest C++ and will never willingly work on another C++
| code base in a professional capacity if I can avoid it
| derriz wrote:
| I was C++ dev for 5 or 6 years, up to the late 2000s.
|
| I got another C++ job about 3 years ago but bailed after about a
| year.
|
| I could write a tome about what I dislike but to start with, any
| language that lacks a working standard built-in string type, is
| just a hard no for me at this stage in my life. Life is just too
| short.
|
| The tooling and IDE support is atrocious, no standard dependency
| management for 3rd party libraries and CMake makes maven look
| well designed.
|
| I tried to pull my knowledge up to date. Hmmm, we used to have
| lvalues and rvalues, what's this prvalue thing?
|
| Surely cppreference can explain:
|
| > _a prvalue ("pure" rvalue) is an expression whose evaluation_
|
| > _- computes the value of an operand of a built-in operator
| (such prvalue has no result object), or_
|
| > _- initializes an object (such prvalue is said to have a result
| object)._
|
| > * The result object may be a variable, an object created by
| new-expression, a temporary created by temporary materialization,
| or a member thereof. Note that non-void discarded expressions
| have a result object (the materialized temporary). Also, every
| class and array prvalue has a result object except when it is the
| operand of decltype;*
|
| > _The following expressions are prvalue expressions:_
|
| > _a literal (except for string literal), such as 42, true or
| nullptr;_
|
| > _a function call or an overloaded operator expression, whose
| return type is non-reference, such as str.substr(1, 2), str1 +
| str2, or it++;_
|
| > _a++ and a--, the built-in post-increment and post-decrement
| expressions;_
|
| > _a + b, a % b, a & b, a << b, and all other built-in arithmetic
| expressions;_
|
| > _a && b, a || b, !a, the built-in logical expressions;_
|
| > _a < b, a == b, a >= b, and all other built-in comparison
| expressions;_
|
| > _& a, the built-in address-of expression;_
|
| > _a.m, the member of object expression, where m is a member
| enumerator or a non-static member function[2];_
|
| > _p- >m, the built-in member of pointer expression, where m is a
| member enumerator or a non-static member function[2];_
|
| > _a.*mp, the pointer to member of object expression, where mp is
| a pointer to member function[2];_
|
| > _p- >*mp, the built-in pointer to member of pointer expression,
| where mp is a pointer to member function[2];_
|
| > _a, b, the built-in comma expression, where b is an prvalue;_
|
| > _a ? b : c, the ternary conditional expression for certain b
| and c (see definition for detail);_
|
| > _a cast expression to non-reference type, such as static_cast
| <double>(x), std::string{}, or (int)42;_
|
| > _the this pointer;_
|
| > _an enumerator;_
|
| > _a non-type template parameter of a scalar type;_
|
| > _a lambda expression, such as [](int x){ return x * x; };_
|
| > _(since C++11)_
|
| > _a requires-expression, such as requires (T i) { typename
| T::type; };_
|
| > _a specialization of a concept, such as
| std::equality_comparable <int>._
|
| > _(since C++20)_
|
| > _Properties:_
|
| > _Same as rvalue (below)._
|
| > _A prvalue cannot be polymorphic: the dynamic type of the
| object it denotes is always the type of the expression._
|
| > _A non-class non-array prvalue cannot be cv-qualified, unless
| it is materialized in order to be bound to a reference to a cv-
| qualified type(since C++17). (Note: a function call or cast
| expression may result in a prvalue of non-class cv-qualified
| type, but the cv-qualifier is generally immediately stripped
| out.)_
|
| > _A prvalue cannot have incomplete type (except for type void,
| see below, or when used in decltype specifier)._
|
| > _A prvalue cannot have abstract class type or an array
| thereof._
|
| Yeah, this language is loads of fun. I've worked on compilers,
| interpreters, implemented extended Hindley-Milner type systems,
| etc. so normally love reading formal language specs but this is
| just insane.
| TrianguloY wrote:
| I've had a similar situation with Kotlin. I've always been a java
| developer, and I enjoy using it, but even with the newer features
| it's just...slow.
|
| When I had to script things I chose JavaScript (native
| JavaScript) since it's way faster to iterate, but I've always
| missed the static typing (I also know python, but I honestly
| prefer JavaScript)
|
| Until I learned Kotlin. It's been a blast to use, incredible
| common libraries, streams everywhere, nulls that you can use
| without issues...I just love it (so much in fact that I'm in the
| process of switching project from java to Kotlin).
|
| When I need to do scripts, like for the advent-of-code, I choose
| Kotlin.
___________________________________________________________________
(page generated 2024-12-23 23:00 UTC)