141–150 of 187 posts
Can a native English speaker kindly explain the title? With that many negative tenses, it's really hard to parse the motivation of the author.
It's in the vein of "even if you can't do something, you should to try anyway" Not ugly is more of a less strong "pretty" and can't not is more of a "should" (rather than "can"), so the title can be read as "you can't make c++ pretty, but you should try (to make it pretty)".
Earlier quoted context omitted.
on the contrary, std::map is a good default container with predictable performance. If you need fast O(1) look up std::unordered_map is really not fit for purpose and requires you to come up with an hash function.
> on the contrary, std::map is a good default container If you care about performance then it's not. (And if you don't care about performance then why are you using C++?) The standard requires that `insert` will not invalidate iterators, which basically forces everyone to implement `std::map` as a red-black tree, and those are pretty bad performance-wise on modern hardware mostly due to cache misses. > If you need fa…
Earlier quoted context omitted.
Making a language so big and complex that you can't expect to understand it all isn't a good idea. You might be able to get away with using 50% of the language but if some project you depend on uses a different 50% then you have a problem.
OK but if you're a competent, adult software engineer it should be fairly easy to overcome that problem.
Earlier quoted context omitted.
Small vectors break iterator guarantees, for one thing. They also really only make sense for tiny objects (ints, etc.) given you don't want a pickup truck's worth of data on your stack. They're most definitely not general-purpose. There are lots of subtleties STL containers have to worry about in designing containers, regarding everything from iterator & pointer invalidation to allocation and allocator propagation. A…
how do small vectors break iterator guarantees?
Earlier 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...
Btw, that code is using std::unordered_map which is notoriously slow compared to an ordinary std::map for a small amount of elements. And the unordered map of register names each with a pair, why? Why not use std::vector for fast lookup?
The crux of what i'm saying isn't anything new, Bjarne Stroustrup admits that C++ is mainly a high-level abstraction language. There is some new things, but really, the things that are new like << etc. are operator overloads which are just more abstractions.
Earlier quoted context omitted.
Small vectors break iterator guarantees, for one thing. They also really only make sense for tiny objects (ints, etc.) given you don't want a pickup truck's worth of data on your stack. They're most definitely not general-purpose. There are lots of subtleties STL containers have to worry about in designing containers, regarding everything from iterator & pointer invalidation to allocation and allocator propagation. A…
how do small vectors break iterator guarantees?
Earlier 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…
> Containers still do silly things when you use `c[..]` syntax with no element there. (Both when trying to insert and when trying to retrieve!) FWIW, I find std::map operator[] creating an object extremely convenient and it is very annoying having to use defaultdict to get the same behavior [edit: in python]. So ugliness really depends on what you are used to. > The general level of language size and complexity, espe…
Adding behavior to replace a NULL/None return with a default object is pretty easy.
Removing the default object that you've been inflicted upon... how would you go about that?
Earlier quoted context omitted.
You have that backwards. The STL containers are for when you have a hyper-specific niche use case. They are otherwise terrible defaults and everyone should use boost or abseil by default otherwise. std::map, for example, is only appropriate if you need a red-black tree specifically. Which almost nobody does. std::unordered_map is less awful, but abseil has a literal straight upgrade. With the same API. So... why woul…
Because C++ is a nice, mostly safe, general purpose language, being spoiled by the 1% "performance above anything else crowd". I want my OWL, VCL back, not an hash table able to do lookups in micro-seconds