You can make C++ pretty: it's called D. https://dlang.org/comparison.html
Here's the DC++ intercompatibility project: https://wiki.dlang.org/Calypso#Current_status
You can't make C++ not ugly, but you can't not try (2010)
41–50 of 187 posts
Re: You can't make C++ not ugly, but you can't not try (2010)
#42Earlier quoted context omitted.
To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…
If everyone can forgive my ignorance... I used to call everything in the std:: namespace as just that, the standard template library (STL) (whatever it's iteration). So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? (Genuinely confused). (In old man voice) We ended up rolling out own stuff and marking std:: verboten. Why? Stl was too slow, too verbose, and…
> We ended up rolling out own stuff and marking std:: verboten.
I think that’s still pretty common, especially in game development and/or when compiling with exceptions disabled. AFAIK std::vector is fine, and probably std::string, but for things like std::[unordered_]map, Abseil and Folly have equivalents that are slightly non-standard and much faster.
Re: You can't make C++ not ugly, but you can't not try (2010)
#43Earlier quoted context omitted.
That's not "by default". The compiler doesn't provide it, the language provides for you as the developer using the language to implement your own (or use a third-party) GC and utilize it. D and Rust both offer the same amenities and are not "garbage collected" languages.
> D and Rust both offer the same amenities and are not "garbage collected" languages. Rust isn't but D is absolutely a garbage collected language. The GC is provided by default and expected to exist. https://dlang.org/overview.html#resource & https://dlang.org/spec/garbage.html There's a non-GC'd subset of D, though. That would be the BetterC subset https://dlang.org/spec/betterc.html
I think it's more accurate to say D's GC is expected to exist if you want to use the full language. That's sensible, because the option to use GC makes some things practical that otherwise wouldn't be. You can disable or simply avoid the GC, and you can add @nogc attributes to your code if you want to be certain there won't be any GC allocations. BetterC certainly does guarantee there's no GC, but that's a limited (for now at least) subset of the full language.
Re: You can't make C++ not ugly, but you can't not try (2010)
#44Earlier quoted context omitted.
From the rules: [...] Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. [...] https://news.ycombinator.com/newsguidelines.html
That's fair... but how exactly are we to call out these abuses otherwise? (Without having a trivially traceable e-mail address.) Maybe it's an idea for a new "button" other than spam/flag/etc.. FWIW, I think I backed up my accusation adequately for at least a mod review. EDIT: To be even more meta... I sense a certain pattern in your comments, sir. What gives? EDIT#2: Love your retaliation by downvoting totally unrel…
The rules I have previously posted contain the answer to your first question.
Re: You can't make C++ not ugly, but you can't not try (2010)
#45Earlier quoted context omitted.
To the contrary, modern C++ has solved very few, if any, of the problems described in the article. Being generous: * There's now `std::string_view` to address some of the problems with `std::string`, but the rest are still there. There are some attempts to specify the encoding now, at least. * Lambdas and `std::function` pretty much solve the function pointer complaints, with some added complexity. * Containers still…
If everyone can forgive my ignorance... I used to call everything in the std:: namespace as just that, the standard template library (STL) (whatever it's iteration). So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? (Genuinely confused). (In old man voice) We ended up rolling out own stuff and marking std:: verboten. Why? Stl was too slow, too verbose, and…
Every new standard incorporates language & library changes. A perfect example of this is r-value references. That was a new language feature in C++11 & was adopted by all the standard library containers & algorithms.
Not sure which part of std::string you're referring to but the compiler generally doesn't contain any knowledge of the library itself. It does goes the other way though where the standard library has to know how to implement certain functionality on a given compiler (some type traits functionality IIRC isn't possible to implement without compiler builtins that expose the AST to you). I think Rust has taken a more sustainable approach with their macro system which can modify the AST instead of relying on builtins but even in Rust I suspect they use builtins in certain places of their standard library.
Today's STL implementations are going to be better performing and more robust than anything you'd write yourself so generally a good idea to stick to it as a rule of thumb for the majority of code.
Re: You can't make C++ not ugly, but you can't not try (2010)
#46Earlier quoted context omitted.
That's fair... but how exactly are we to call out these abuses otherwise? (Without having a trivially traceable e-mail address.) Maybe it's an idea for a new "button" other than spam/flag/etc.. FWIW, I think I backed up my accusation adequately for at least a mod review. EDIT: To be even more meta... I sense a certain pattern in your comments, sir. What gives? EDIT#2: Love your retaliation by downvoting totally unrel…
The rules I have previously posted contain the answer to your first question.
EDIT: Please don't be opaque about this stuff. Post an exact link to the ToC (or whatever) I violated if you truly want to be held accountable. I'm not even on a I-want-to-an-a-hole crusade here[0], but HN has a serious lack of accountability and transparency about this. I contend that it's full of shills, but I have yet to prove that, which I acknowledge.
Anyway, I flagged it. I'd delete my post if I could. Wait, I actually still could.
That still doesn't account for the downvotes I just received on random comments unrelated to this topic. If I deleted it would that delete causally-related-downvotes?
[0] As you can hopefully tell from from my comment history.
EDIT#2: Can I "report" you... and if so, how? I'm not going to, but could I, theoretically? That's a good test for accountability.
Re: You can't make C++ not ugly, but you can't not try (2010)
#47Earlier quoted context omitted.
If everyone can forgive my ignorance... I used to call everything in the std:: namespace as just that, the standard template library (STL) (whatever it's iteration). So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? (Genuinely confused). (In old man voice) We ended up rolling out own stuff and marking std:: verboten. Why? Stl was too slow, too verbose, and…
> So is this C++03 /C++11 stuff just updates to this library, or is std::string recognised at the compiler level? std::string is in the STL. So is std::string_view. There are language changes as well that enable some of the new STL additions but some are just STL updates and you could "backport" them so to speak. Or do the same thing but yourself. Making std:: verboten these days would likely be a mistake, though. Th…
I still think the STL containers are the sane default to reach for & switch to more obscure ones when the problem domain and performance requirements say to use a different one.
Re: You can't make C++ not ugly, but you can't not try (2010)
#48Earlier quoted context omitted.
Difference is, C++ actually has more than single digit mind/marketshare outside the safety of the HN eggcup.
Market share, maybe. Mindshare - Lisp has its zealots. C++ is tolerated rather than adored, because it's more of a Katamari Damacy of stray CS than a language with a coherent focus. How many other languages have a Turing complete sublanguage built into them just to handle templating?
"...because it's more of a Katamari Damacy of stray CS than a language with a coherent focus"
This is the funniest and most accurate description of C++ that I have ever heard. +100 for the game reference.
Re: You can't make C++ not ugly, but you can't not try (2010)
#49Earlier quoted context omitted.
Internally, i mean, thats how it was originally built and it generates code much in the way that C would, if you would have manually coded it. Maybe not jump on my head without thinking first!
Not trying to jump on your head; I apologize if you got that impression. But while C++ was originally C preprocessor/transpiler, modern C++ has diverged quite a bit from from this. I mean, take a look at this and tell me how it would be possible to convert it to C in a straightforwards way: https://github.com/regular-vm/libencoding/blob/master/encodi...
For me the main issue with C++ is the idea of no overhead for features you don't use which is not bad idea, but is complete nonsense when the measure of “overhead” used by the language authors is some combination of how the hypothetical C code generated by hypothetical cfront behaves and how the resulting code would run on early 80's minicomputer...
Re: You can't make C++ not ugly, but you can't not try (2010)
#50I certainly agree that Modern C++ is vastly bett... actually this is just someone posting an old polemic and trying to stir resentment/controversy. IGNORE THIS CRITICSM OF C++ ... there are much better and more relevant ones which are worth taking seriously. This is not worth taking seriously. (I wonder how many of these posters are real or fake. Given the karma and post of this poster I'm inclined to... wait. Last c…
We detached this subthread from https://news.ycombinator.com/item?id=22428525.
Please see https://news.ycombinator.com/item?id=22429925 below.