Thoughts about the newer STL linked C++ language features
-
I appreciate the newer C++ standards like C++20 even though I haven't really done more than scratch the surface of it yet. But one thing I have mixed feelings about is promoting STL things as part of the first class language features, like (an older but good example)
for(:). I have qualms about The STL, primarily around the way it uses memory, almost guaranteeing you need custom allocators and a custom heap for anything without gobs of RAM. Otherwise, fragmentation will nail you. I *think* most of it works like C# where it's not explicitly tied to the library - as long as a separate library exposes the same features it will bind to it likeforeachin C#. I'm good with that. I just fear how far they are going to take it. How many features will a container eventually have to expose to take advantage of all the available language features that act on them for example? Also, it feels like less of a mid level language now. I'm not sure how I feel about that.To err is human. Fortune favors the monsters.
-
I appreciate the newer C++ standards like C++20 even though I haven't really done more than scratch the surface of it yet. But one thing I have mixed feelings about is promoting STL things as part of the first class language features, like (an older but good example)
for(:). I have qualms about The STL, primarily around the way it uses memory, almost guaranteeing you need custom allocators and a custom heap for anything without gobs of RAM. Otherwise, fragmentation will nail you. I *think* most of it works like C# where it's not explicitly tied to the library - as long as a separate library exposes the same features it will bind to it likeforeachin C#. I'm good with that. I just fear how far they are going to take it. How many features will a container eventually have to expose to take advantage of all the available language features that act on them for example? Also, it feels like less of a mid level language now. I'm not sure how I feel about that.To err is human. Fortune favors the monsters.
I just noticed this post. IMO the objections against the coupling between language/lib are somewhat academic. They make sense from a strict purist point of view. But I would argue that the practical view wins the race by miles. I have seen no further "coupling-creep" since the C++11. Or have I? I wanted to see how those initial discussions went during the standardisation process, and instead I stumbled into this, a novelty for me, no idea if it went into the standard: Generalizing the Range-Based For Loop[^]
[...] which requires a range’s begin and end to have the same type. This paper proposes to lift that restriction for C++17
As for C++ being a mid-level language... with
template, I never regarded it as such. :cool:"If we don't change direction, we'll end up where we're going"
-
I just noticed this post. IMO the objections against the coupling between language/lib are somewhat academic. They make sense from a strict purist point of view. But I would argue that the practical view wins the race by miles. I have seen no further "coupling-creep" since the C++11. Or have I? I wanted to see how those initial discussions went during the standardisation process, and instead I stumbled into this, a novelty for me, no idea if it went into the standard: Generalizing the Range-Based For Loop[^]
[...] which requires a range’s begin and end to have the same type. This paper proposes to lift that restriction for C++17
As for C++ being a mid-level language... with
template, I never regarded it as such. :cool:"If we don't change direction, we'll end up where we're going"
I just look at templates as fancy text preprocessing with a bit of typing and deduction mixed in. Never really considered it to elevate the language to a high level language, but to each their own.
To err is human. Fortune favors the monsters.