6 ms·

Good. C++ still badly needs to go through a phase of tuning, deprecation and removal before adding much more. As I have said before, there have been shockingl

Good. C++ still badly needs to go through a phase of tuning, deprecation and removal before adding much more. As I have said before, there have been shockingly poor design decisions in some of the oldest and most fundamental standard libraries. Little to no work has been done to introduce replacement APIs (or even replacement classes) that would allow the deprecation of stupid features to begin.

pjc50 11y ago
What targets did you have in mind? Boost seem to do a good job of "standard library 2.0", although perhaps a bit too keen on the templates. Killing anything in any C++ that's actually used is going to be extremely hard. Systems stick around forever. Yesterday I had to write some COM/OLE code because it was the only way to do something.
signa11 11y ago
> As I have said before, there have been shockingly poor design decisions in some of the oldest and most fundamental standard libraries. if you don't mind, may you please elucidate a few here ? or if you already have a dedicated post may you point to that ? thank you !
- clishem 11y ago
  http://i.imgur.com/mgd4hDk.jpg http://i.imgur.com/mgd4hDk.jpg
  - vmorgulis 11y ago
    Funny. https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4ec00e10a20e4a969c40/libstdc%2B%2B-v3/include/bits/stl_tempbuf.h#L92 https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4... I'm not sure of the behaviour but there is still a loop...
goalieca 11y ago
Yeah. Iostreams doesn't work with strings and is not const correct. Also a horrible idea to use oop IMHO. Somehow POSIX is a lot simpler to use with read/write and void
- gpderetta 11y ago
  iostream has its problems, but works perfectly fine with strings. Which part is not const correct? Also, iostream (buffered stream formatting), has nothing to do with posix read and write (unbuffered byte I/O). A closer match is C fprintf.
deleted 11y ago
[deleted]
PopsiclePete 11y ago
It's extremely hard to take something away once you've given it. Once it's out there, someone's using it and not everyone can afford to rewrite/re-test/re-deploy just because you changed how iostreams work. The C++ std. lib. is one of the worst abominations of over-engineered disasters that I have ever seen in my life - how people even deal with stdout/stdin without tearing their hair out is beyond me. I just go back to printf and friends. The fact that they had to have no fewer than 6 (or is it 8 now?) string types before they got Unicode right... it's truly a sad state of affairs. How can anyone look at that and not feel embarrassment to have been part of those design decisions...
- jblow 11y ago
  Actually, it is easy, if you had the foresight to put in versioning. Which they didn't.
- imglorp 11y ago
  What would legacy-free C++ look like? Abandon all the old attempts and have One Approved Method.
  - cpeterso 11y ago
    At that point, why use legacy-free C++ instead of a language like Rust?
- gpderetta 11y ago
  There is one, it is called std::string. It works fine as a container of utf8 code units. What other string type do you have in mind? Well,there is also wstring, but you should just pretend it doesn't exist.
  - PopsiclePete 11y ago
    I don't think std::string is fine. Yes, it stores bytes, and yes, UTF-8 is byte-oriented, but besides being a storage of bytes, std::string has nothing that is unicode code-point aware. You need external libraries like ICU for that.
makapuf 11y ago
Of course, deprecating libraries that are in use is hard. What could be done however, is finding a coherent best subset of current available options which are defined as "the current", blessed C++. Smaller than C++ as a whole, simpler to fit in your head (hopefully), and setting the rest as deprecated. but still complete and coherent. Maybe it's already done, in that case it just lacks a name a website and more publicity !
- _kst_ 11y ago
  Some might argue that that coherent subset is called "C". (I wouldn't, but some might.)
  - gpderetta 11y ago
    Some others would say that the intersection between the sane subset and "C" is empty.
- vmorgulis 11y ago
  Yes, we need that subset. We could call that RC++ (or rC++, like RPython is a reduced Python). What I would put in that subset: - constructors/destructors (RAII) - auto (type inference) - class with template arguments (no nesting) - variadic templates for function parameters What I would remove: - virtual - rtti - complex templates (nesting) - no STL (or something new and/or based on POSIX) - no private/protected in classes (public by default) - or remove class (only structures) - operator overloading - namespaces - name mangling (a.b gives a_b) I imagine a good subset as something that Thorvalds could approve and ideally allow in the kernel.
makecheck 11y ago
I’ve been asked for examples so here is a shot, although I am sure the list could become even longer if I spent more time to think about it (and I’m sure many people have thought about this): - Localized text doesn’t work with "iostream" sequences because one language says "A foo B" and another "B bar A". The entire concept of a sequencer like "<<" was wrong from the beginning but they kept it. All I really expect is a formatting method that accepts tuples. Apple made object formats work in Objective-C simply by adding "%@", and they have a solution for internationalization by embedding numeric order. - Not only are stream operators awkward to use but they are awkward and vague when customized. For years, until compilers basically hacked in ways to inline "friend" functions, you had to put the entire implementations for these operators in inconvenient places outside of classes. And what does it even mean to "operator <<" an object? For many classes, there are at least two useful streamed-out interpretations: a literal version of the object’s primary value(s) from the user’s viewpoint, and a full state representation for developers. The C++ standard library manages to create a very complex way to do something that is not even sufficient!! Many languages and environments have ways to generate multiple object representations. C++ should deprecate "operator <<" and create more grep-able functions that can produce variations (e.g. std::print_obj<T>(std::ostream&, T&) and std::print_debug<T>(std::ostream&, T&), where a default template implements the 2nd using the 1st). - The "iostream" classes are full of poorly named/located things. Often there are duplicate values with similar names so you have to remember which goes where and hope mistakes don’t compile (e.g. "f << std::hex" and "f << std::ios::hex" are completely different but the compiler allows both). And heck, "good()" does not have the exact opposite meaning of "bad()"! To this day, I see people screwing up and not handling edge-case stream failures correctly; that is an insane problem to have in a widespread standard class that every programmer should be able to learn correctly (and hasn’t, because the class has so many quirks). - As others have said, std::string lacks practical international support for sources like UTF-8 (which is ironic considering how the class template tried so hard to be adaptable for whatever they thought strings might need). And std::string does not have any really useful methods, especially after considering internationalization. I would say the least useful feature of std::string is size variance; I would hope for a new UTF-8-only class that just expects to be bytes, using good ideas from modern environments to present views of those bytes to programmers. - STL algorithms probably should not have been implemented in terms of iterators. For instance, if someone writes a template on "container", "container.find(x)" will not work for both sets and vectors; since "find(container.begin(), container.end(), x)" technically compiles with both, a naive programmer may choose to force that approach in every case and incur unnecessary O(n) complexities. Systems are typically so layered with generics that you cannot possibly know if this type of mistaken slowdown has been forced into your code. Assuming you want anything generic at all here, what you really need in the standard is something of the form "find(container, x)" so there is at least a chance for optimal behavior within the magic. - Ultimately, I wish that more of standard C++ would simply build on or improve standard C. The core C functions should be first-class, with object-oriented peanut-buttering added later where useful instead of baking functionality only into awkward classes that are found later to have design flaws. Even if the C++ version wants to take advantage of C++ "inline" or std::function<>, etc. it should still start as a function and work toward a class. Functions would also create more opportunities to get away from this insane syntax prediction problem that templates have, where you don’t really know if "x.f()" or "f(x)" is required (or if both are available, or worse if they do different things).

pjc50 11y ago

What targets did you have in mind? Boost seem to do a good job of "standard library 2.0", although perhaps a bit too keen on the templates. Killing anything in any C++ that's actually used is going to be extremely hard. Systems stick around forever. Yesterday I had to write some COM/OLE code because it was the only way to do something.

signa11 11y ago

> As I have said before, there have been shockingly poor design decisions in some of the oldest and most fundamental standard libraries. if you don't mind, may you please elucidate a few here ? or if you already have a dedicated post may you point to that ? thank you !

clishem 11y ago
http://i.imgur.com/mgd4hDk.jpg http://i.imgur.com/mgd4hDk.jpg
- vmorgulis 11y ago
  Funny. https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4ec00e10a20e4a969c40/libstdc%2B%2B-v3/include/bits/stl_tempbuf.h#L92 https://github.com/gcc-mirror/gcc/blob/bd3f0a53c07086e978ea4... I'm not sure of the behaviour but there is still a loop...

goalieca 11y ago

Yeah. Iostreams doesn't work with strings and is not const correct. Also a horrible idea to use oop IMHO. Somehow POSIX is a lot simpler to use with read/write and void

gpderetta 11y ago
iostream has its problems, but works perfectly fine with strings. Which part is not const correct? Also, iostream (buffered stream formatting), has nothing to do with posix read and write (unbuffered byte I/O). A closer match is C fprintf.

deleted 11y ago

[deleted]

PopsiclePete 11y ago

It's extremely hard to take something away once you've given it. Once it's out there, someone's using it and not everyone can afford to rewrite/re-test/re-deploy just because you changed how iostreams work. The C++ std. lib. is one of the worst abominations of over-engineered disasters that I have ever seen in my life - how people even deal with stdout/stdin without tearing their hair out is beyond me. I just go back to printf and friends. The fact that they had to have no fewer than 6 (or is it 8 now?) string types before they got Unicode right... it's truly a sad state of affairs. How can anyone look at that and not feel embarrassment to have been part of those design decisions...

jblow 11y ago
Actually, it is easy, if you had the foresight to put in versioning. Which they didn't.
imglorp 11y ago
What would legacy-free C++ look like? Abandon all the old attempts and have One Approved Method.
- cpeterso 11y ago
  At that point, why use legacy-free C++ instead of a language like Rust?
gpderetta 11y ago
There is one, it is called std::string. It works fine as a container of utf8 code units. What other string type do you have in mind? Well,there is also wstring, but you should just pretend it doesn't exist.
- PopsiclePete 11y ago
  I don't think std::string is fine. Yes, it stores bytes, and yes, UTF-8 is byte-oriented, but besides being a storage of bytes, std::string has nothing that is unicode code-point aware. You need external libraries like ICU for that.

makapuf 11y ago

Of course, deprecating libraries that are in use is hard. What could be done however, is finding a coherent best subset of current available options which are defined as "the current", blessed C++. Smaller than C++ as a whole, simpler to fit in your head (hopefully), and setting the rest as deprecated. but still complete and coherent. Maybe it's already done, in that case it just lacks a name a website and more publicity !

_kst_ 11y ago
Some might argue that that coherent subset is called "C". (I wouldn't, but some might.)
- gpderetta 11y ago
  Some others would say that the intersection between the sane subset and "C" is empty.
vmorgulis 11y ago
Yes, we need that subset. We could call that RC++ (or rC++, like RPython is a reduced Python). What I would put in that subset: - constructors/destructors (RAII) - auto (type inference) - class with template arguments (no nesting) - variadic templates for function parameters What I would remove: - virtual - rtti - complex templates (nesting) - no STL (or something new and/or based on POSIX) - no private/protected in classes (public by default) - or remove class (only structures) - operator overloading - namespaces - name mangling (a.b gives a_b) I imagine a good subset as something that Thorvalds could approve and ideally allow in the kernel.

makecheck 11y ago

I’ve been asked for examples so here is a shot, although I am sure the list could become even longer if I spent more time to think about it (and I’m sure many people have thought about this): - Localized text doesn’t work with "iostream" sequences because one language says "A foo B" and another "B bar A". The entire concept of a sequencer like "<<" was wrong from the beginning but they kept it. All I really expect is a formatting method that accepts tuples. Apple made object formats work in Objective-C simply by adding "%@", and they have a solution for internationalization by embedding numeric order. - Not only are stream operators awkward to use but they are awkward and vague when customized. For years, until compilers basically hacked in ways to inline "friend" functions, you had to put the entire implementations for these operators in inconvenient places outside of classes. And what does it even mean to "operator <<" an object? For many classes, there are at least two useful streamed-out interpretations: a literal version of the object’s primary value(s) from the user’s viewpoint, and a full state representation for developers. The C++ standard library manages to create a very complex way to do something that is not even sufficient!! Many languages and environments have ways to generate multiple object representations. C++ should deprecate "operator <<" and create more grep-able functions that can produce variations (e.g. std::print_obj<T>(std::ostream&, T&) and std::print_debug<T>(std::ostream&, T&), where a default template implements the 2nd using the 1st). - The "iostream" classes are full of poorly named/located things. Often there are duplicate values with similar names so you have to remember which goes where and hope mistakes don’t compile (e.g. "f << std::hex" and "f << std::ios::hex" are completely different but the compiler allows both). And heck, "good()" does not have the exact opposite meaning of "bad()"! To this day, I see people screwing up and not handling edge-case stream failures correctly; that is an insane problem to have in a widespread standard class that every programmer should be able to learn correctly (and hasn’t, because the class has so many quirks). - As others have said, std::string lacks practical international support for sources like UTF-8 (which is ironic considering how the class template tried so hard to be adaptable for whatever they thought strings might need). And std::string does not have any really useful methods, especially after considering internationalization. I would say the least useful feature of std::string is size variance; I would hope for a new UTF-8-only class that just expects to be bytes, using good ideas from modern environments to present views of those bytes to programmers. - STL algorithms probably should not have been implemented in terms of iterators. For instance, if someone writes a template on "container", "container.find(x)" will not work for both sets and vectors; since "find(container.begin(), container.end(), x)" technically compiles with both, a naive programmer may choose to force that approach in every case and incur unnecessary O(n) complexities. Systems are typically so layered with generics that you cannot possibly know if this type of mistaken slowdown has been forced into your code. Assuming you want anything generic at all here, what you really need in the standard is something of the form "find(container, x)" so there is at least a chance for optimal behavior within the magic. - Ultimately, I wish that more of standard C++ would simply build on or improve standard C. The core C functions should be first-class, with object-oriented peanut-buttering added later where useful instead of baking functionality only into awkward classes that are found later to have design flaws. Even if the C++ version wants to take advantage of C++ "inline" or std::function<>, etc. it should still start as a function and work toward a class. Functions would also create more opportunities to get away from this insane syntax prediction problem that templates have, where you don’t really know if "x.f()" or "f(x)" is required (or if both are available, or worse if they do different things).