171–180 of 187 posts
Earlier quoted context omitted.
But that’s true for literally everything. If you have a cpp code base and are building new stuff in rust to interop then you still have legacy cpp code even though rust has fewer problems.
Not really. Legacy stuff can be contained. For example, you could specify language version level in file and it would disable removed/deprecated stuff.
Earlier quoted context omitted.
STL by it's very name is a library, and because it ships with a compiler, doesn't mean it's part of that compiler. It's just a library, like Boost. It might have some ISO standards behind it: great! But it's still a library and not intrinsic to the language itself (see my orig question). eg. to use an 'int' you just declare one and use it. To use strings, you need to include .
The S in STL stands for Standard , something that neither boost nor Abseil are, or will ever be.
java.util.Vector is standard as well but you'd be laughed out of a code review if you tried to use it anywhere. Similarly std::auto_ptr is in the standard, and is universally agreed to be trash to avoid like the plague. So much so it was (eventually) removed. The container section of the library has just sadly not had the same deprecation & removal of bad code put into it.
The claim was "STL containers are the sane default" not that "STL containers are more available". I stand by that claim being wrong. You have so far not actually attempted to counter it on any technical grounds, just bad appeal to authority fallacies.
Earlier quoted context omitted.
> Small vectors break iterator guarantees, for one thing. It only breaks swap of the container itself during iteration. Which is a super niche condition. And that swap also invalidates some of std::vector's iterators as well - specifically the end() iterator. > 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…
> And that swap also invalidates some of std::vector's iterators as well - specifically the end() iterator. And they don't invalidate the iterators that point to actual elements, which was kind of the entire point I was making. Don't let that stop you from trying to make it look like I'm just blurting out nonsense, though.
Earlier quoted context omitted.
The S in STL stands for Standard , something that neither boost nor Abseil are, or will ever be.
Being in the standard doesn't mean they are good or should be used. java.util.Vector is standard as well but you'd be laughed out of a code review if you tried to use it anywhere. Similarly std::auto_ptr is in the standard, and is universally agreed to be trash to avoid like the plague. So much so it was (eventually) removed. The container section of the library has just sadly not had the same deprecation & removal o…
Likewise std::auto_ptr got replaced by std::unique_ptr.
As you see the standard library keeps the knowledgable developers covered, no need to look elsewhere.
You are indeed wrong.
Earlier quoted context omitted.
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…
As non exhaustive list, compilers have have intimate knowledge of: * various operator new * all the type traits * a lot of the names inherited from the C library compilers could do much more, but in general they prefer to implement generic optimizations instead of targeting a specific library name (for example removing allocation for stack allocated std::strings was not done until the generic removal of alloc/free wa…
I believe some standard-library type-traits cannot be implemented without specific compiler support.
[0] https://github.com/boostorg/type_traits/blob/059ed883/includ...
Earlier quoted context omitted.
> No it isn't and no it's not. Your assertion is so patently wrong that you either are entirely clueless or you're just trolling.
Uh, what? Here's a simple example, clang supports windows. Clang's "bundled" standard library, libc++, doesn't support windows. Clang also not only allows but is commonly used with libstd++ instead. Mixing and matching compilers and standard libraries is not only possible it's common. Especially when cross-compiling enters the picture. There is no bundling of any kind in any concept of that word, practically or techn…
You're an awful troll. Clang on Windows is distributed to use the system installation of libstdc++, not clang's experimental libc++.
https://clang.llvm.org/get_started.html
> Clang also not only allows but is commonly used with libstd++ instead.
That's because libc++ is clang's experimental implementation of the C++ standard library, developed to give the project an alternative library to GPLv3 implementations such as libstdc++.
> There is no bundling of any kind in any concept of that word, practically or technically, between C++ compilers and standard libraries.
Your personal assertion contrasts with reality. Even your cherry-picked example contradicts your claim, as clang's history as a drop-in replacement for GCC and therefore it's reliance on GCC's libstdc++ is well documented.
Earlier quoted context omitted.
> How many other languages have a Turing complete sublanguage built into them just to handle templating? On the bright side, C++ doesn't have obscure keywords like "cdr" and "car" that refer to specific hardware elements of an obsolete computer built in 1954.
Car and cdr are a shallow critique of Lisp, the equivalent of "omg, significant whitespace" critique of Python.
Significant whitespace means that we can't reliably use a traditional whitespace-insensitive diff to to compare changes in Python code that seriously change its meaning, such as change how many statements are in the scope of an if.
This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…
This decade old article describes an ancient and obsolete language (C++03 probably though some of the text suggests it might be C++98). It's not worth reading in 2020. Modern C++ is a very different language though it can still almost completely interoperate with quite old code. C++11 and C++14 already addressed most of the things brought up, and contemporary C++ (obviously most code is not in it yet) even supports g…
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…
Earlier quoted context omitted.
> And that swap also invalidates some of std::vector's iterators as well - specifically the end() iterator. And they don't invalidate the iterators that point to actual elements, which was kind of the entire point I was making. Don't let that stop you from trying to make it look like I'm just blurting out nonsense, though.
You made a broad, vague claim that iterator guarantees were broken. You misrepresented it as being a much larger issue that it actually is. Nearly all iterator guarantees are not broken. One very specific guarantee in one very specific case is, that's it. And it's a rare, not general, case at that, making the trade-off necessary to achieve it a bad default .