4 ms·

To anyone that considers this approach for learning C++, I would advise strongly against it. Standard library code has to deal with too many cases and tries to

by dxuh 5y ago

To anyone that considers this approach for learning C++, I would advise strongly against it. Standard library code has to deal with too many cases and tries to be optimal for as many of them as possible. Also the formatting is highly unusual, compared to other C++ code found in the wild.

dataflow 5y ago
Yeah... for C++ it's more like s/To learn/To really learn/
aetherspawn 5y ago
Uh yeah if you try and read the Haskell standard library, you're screwed. It's list fusion and fancy algorithms to hack asymptotics all the way down.
- cprecioso 5y ago
  What does it mean to “hack asymptotics”?
  - zamadatix 5y ago
    Algorithm runtime analysis is usually measured with asymptotic estimates (Big O, Little O, Big Theta, etc). In something as commonly and generically used as the standard library of any performance focused language you're liable to find a focus on optimizing these algorithmic performance guarantees for corner cases over optimizing for simple and straightforward code.
    - cprecioso 5y ago
      Got it, thanks!
eepp 5y ago
thank you
jimbob45 5y ago
That’s actually what I do whenever I’m lacking humility as a coder. One F12 on std::iterator (which is now deprecated lol [0]) is enough for me to remember that I don’t know anything. [0] https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated/ https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated...
- cyber_kinetist 5y ago
  My gripe with C++ is that you need to know so many things to build even the most basic abstractions. When writing a custom data structure you always end up with having headaches about the specifics of std::iterators and rvalue references and all that jazz rather than focusing on the actual algorithm. There’s a reason why people want to go back to Orthodox C++ (using C++ as C with a few extra features)
  - catlifeonmars 5y ago
    This. Want to define a class? Remember the rule of 3 (or is it 5?).
guerrilla 5y ago
Yeah, the first thing that popped into my head was some poor n00b spending the next six years of their life deciphering glibc. There have got to be easier ways :)
- yjftsjthsd-h 5y ago
  musl, I would expect? (granted, that's C, but vs glibc...)
  - guerrilla 5y ago
    Yeah, musl is simpler and cleaner than glibc. I was referring to C, by the way. libstdc++ is actually part of gcc, not glibc.
gefhfff 5y ago
I would have commented that if you didn't
thayne 5y ago
That's probably true of quite a few languages actually. I mean if there is any library you want to be as fast as possible, it's the standard library. Take python for example, a big chunk of the standard library is actually written in c (although there is often an equivalent implementation in python). In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code, because you will be calling something in core or std that does it for you, and has been rigorously checked to be safe. The java standard library has parts that are written in c++. Etc. Etc.
- dataflow 5y ago
  > I mean if there is any library you want to be as fast as possible, it's the standard library. To a decent extent yeah, though I would emphasize the issue isn't quite being as fast as possible (although in some cases it is, but also see I/O streams...), but rather having near-absolute correctness, and achieving high performance as a secondary goal. You can usually find a faster third-party implementation of anything in the C++ standard library. The problem is third-party implementations always cut corners somewhere, whether it's strong exception-safety, proper trait/concept handling, thorough testing of rare edge cases, extensibility/customizability, or other stuff. Even the syntactic complexity rises as a result, let alone the complexity of the actual semantics. (Even minor stuff like using difference_type/size_type instead of ptrdiff_t/size_t makes things more verbose and harder to read in the standard library; third-party implementations would often opt for the latter.)
- leshow 5y ago
  > In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code I have found the Rust std lib to be a great resource. Much of the unsafe is necessary because there is literally no other way to build up abstractions like Box or certain data structures without it. Obviously once those are written though, you want to build on top of them where possible and not use unsafe. It's probably important to delineate between a good example of application code vs library code also. The std lib is not going to help much with application code.
FpUser 5y ago
I was about to post the same but here you are. The only time I would study std:: namespace would be is I needed to write some generic library. Trying to learn C++ by reading std:: can make one's head explode.
deleted 5y ago
[deleted]
cyber_kinetist 5y ago
And the C++ standard library has too many fundamental design issues that are just bad advice for writing actual maintainable and performant code. For example, the standard specifies all map containers to have pointer stability, which is often not needed in reality. Because of this all <unordered_map> implementations are hilariously slow. Or what about std::vector<bool>, <iostream>, std::string, you name it. The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…
devin 5y ago
The same is true of clojure. Don’t read clojure.core as idiomatic.
- filoeleven 5y ago
  One thing I have wondered about is the number of multi-arity functions that individually specify 1, 2, 3, 4, 5 argument cases in 3rd-party library code. Is it a result of people thinking that’s idiomatic, or is ([a b c d]) performant enough to matter in library code instead of using ([a b & more]) ? I hope it’s the former.
phillipcarter 5y ago
This is also true for .NET, especially modern .NET where performance is critical nearly everywhere. It's representative of perf-sensitive code, but not general purpose C#.

by dxuh 5y ago

dataflow 5y ago

Yeah... for C++ it's more like s/To learn/To really learn/

aetherspawn 5y ago

Uh yeah if you try and read the Haskell standard library, you're screwed. It's list fusion and fancy algorithms to hack asymptotics all the way down.

cprecioso 5y ago
What does it mean to “hack asymptotics”?
- zamadatix 5y ago
  Algorithm runtime analysis is usually measured with asymptotic estimates (Big O, Little O, Big Theta, etc). In something as commonly and generically used as the standard library of any performance focused language you're liable to find a focus on optimizing these algorithmic performance guarantees for corner cases over optimizing for simple and straightforward code.
  - cprecioso 5y ago
    Got it, thanks!

eepp 5y ago

thank you

jimbob45 5y ago

That’s actually what I do whenever I’m lacking humility as a coder. One F12 on std::iterator (which is now deprecated lol [0]) is enough for me to remember that I don’t know anything. [0] https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated/ https://www.fluentcpp.com/2018/05/08/std-iterator-deprecated...

cyber_kinetist 5y ago
My gripe with C++ is that you need to know so many things to build even the most basic abstractions. When writing a custom data structure you always end up with having headaches about the specifics of std::iterators and rvalue references and all that jazz rather than focusing on the actual algorithm. There’s a reason why people want to go back to Orthodox C++ (using C++ as C with a few extra features)
- catlifeonmars 5y ago
  This. Want to define a class? Remember the rule of 3 (or is it 5?).

guerrilla 5y ago

Yeah, the first thing that popped into my head was some poor n00b spending the next six years of their life deciphering glibc. There have got to be easier ways :)

yjftsjthsd-h 5y ago
musl, I would expect? (granted, that's C, but vs glibc...)
- guerrilla 5y ago
  Yeah, musl is simpler and cleaner than glibc. I was referring to C, by the way. libstdc++ is actually part of gcc, not glibc.

gefhfff 5y ago

I would have commented that if you didn't

thayne 5y ago

That's probably true of quite a few languages actually. I mean if there is any library you want to be as fast as possible, it's the standard library. Take python for example, a big chunk of the standard library is actually written in c (although there is often an equivalent implementation in python). In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code, because you will be calling something in core or std that does it for you, and has been rigorously checked to be safe. The java standard library has parts that are written in c++. Etc. Etc.

dataflow 5y ago
> I mean if there is any library you want to be as fast as possible, it's the standard library. To a decent extent yeah, though I would emphasize the issue isn't quite being as fast as possible (although in some cases it is, but also see I/O streams...), but rather having near-absolute correctness, and achieving high performance as a secondary goal. You can usually find a faster third-party implementation of anything in the C++ standard library. The problem is third-party implementations always cut corners somewhere, whether it's strong exception-safety, proper trait/concept handling, thorough testing of rare edge cases, extensibility/customizability, or other stuff. Even the syntactic complexity rises as a result, let alone the complexity of the actual semantics. (Even minor stuff like using difference_type/size_type instead of ptrdiff_t/size_t makes things more verbose and harder to read in the standard library; third-party implementations would often opt for the latter.)
leshow 5y ago
> In rust the standard library uses quite a bit of unsafe code, and even nightly only features and standard-library-only features that you don't usually need in real code I have found the Rust std lib to be a great resource. Much of the unsafe is necessary because there is literally no other way to build up abstractions like Box or certain data structures without it. Obviously once those are written though, you want to build on top of them where possible and not use unsafe. It's probably important to delineate between a good example of application code vs library code also. The std lib is not going to help much with application code.

FpUser 5y ago

I was about to post the same but here you are. The only time I would study std:: namespace would be is I needed to write some generic library. Trying to learn C++ by reading std:: can make one's head explode.

deleted 5y ago

[deleted]

cyber_kinetist 5y ago

And the C++ standard library has too many fundamental design issues that are just bad advice for writing actual maintainable and performant code. For example, the standard specifies all map containers to have pointer stability, which is often not needed in reality. Because of this all <unordered_map> implementations are hilariously slow. Or what about std::vector<bool>, <iostream>, std::string, you name it. The frustrations people have with it are sometimes up to the point where they begin writing everything from scratch…

devin 5y ago

The same is true of clojure. Don’t read clojure.core as idiomatic.

filoeleven 5y ago
One thing I have wondered about is the number of multi-arity functions that individually specify 1, 2, 3, 4, 5 argument cases in 3rd-party library code. Is it a result of people thinking that’s idiomatic, or is ([a b c d]) performant enough to matter in library code instead of using ([a b & more]) ? I hope it’s the former.

phillipcarter 5y ago

This is also true for .NET, especially modern .NET where performance is critical nearly everywhere. It's representative of perf-sensitive code, but not general purpose C#.