4 ms·

I read that book around 1998 and was an instant convert. C++ has a steep learning curve, and does not stop you from getting yourself into a lot of trouble, but

by ttul 8y ago

I read that book around 1998 and was an instant convert. C++ has a steep learning curve, and does not stop you from getting yourself into a lot of trouble, but it does stand up to Bjarne’s original promise about performance. IMHO the STL is one of mankind’s greatest accomplishments.

jzwinck 8y ago
The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."
- jstimpfle 8y ago
  > Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...
  - jstimpfle 8y ago
    > string-to-hash map string-to-int hash map
- dralley 8y ago
  Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.
  - jstimpfle 8y ago
    The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.
- lbrandy 8y ago
  "zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message. As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).
beagle3 8y ago
C++ the language, maybe. STL really is a cruel joke. is it ok to mutate a data structure while an iterator to it is live? It depends, which makes it much less abstract and generic than it could be (and that people believe it is) Error messages are useless. Compilers can and do (recently) help with that, but the main issue is the convoluted STL design in which every instantiation’s type name actually takes a full 80x25 screen to spell out. STLs primary objects are individual iterated elements, which does abstract over pointers (as was stepanov’s intention) but are at such a low level of abstraction as to be onerous. Modern C++ is slightly better.
- amelius 8y ago
  Could be true, but a modern language such as Rust has its own problems: https://news.ycombinator.com/item?id=16442743 https://news.ycombinator.com/item?id=16442743
  - bluejekyll 8y ago
    What you’ve just linked to is a solution to the issue mentioned above. Rust makes a lot of guarantees, but sometimes those guarantees run afoul of certain required operations in different contexts. For this reason the language has an escape valve, unsafe, and the unsafe blocks are blindingly obvious in the code. To say it’s a problem is misleading at best.
fpoling 8y ago
STL tried hard to abstract pointer manipulation semantic of low-level C and apply it everywhere whether it fit or not. This pointer heritage inevitably lead to misfeatures like invalidation of iterators under container mutations or the need to have access both to the iterator and its container to implement things like vector::erase(). Other languages and runtimes use the notion of an iterator or cursor that is alone enough to perform all looping-like operations on the container including efficient erase() and can cheaply (so it is ok to have that in production) or even with good optimizing compiler at zero cost provide protection against container mutations.
abhishekjha 8y ago
I have recently got upto speed with c++17 features and I want to explore more C++. So far I have used Java and Python to build webapps. Are there libraries/framework that can replicate the MVC in C++ as well? I think I can extend functionalities from there.
- AstralStorm 8y ago
  Not quite MVC but RxCpp exists and can help with designing MVP style code. (also known as event driven programming)

by ttul 8y ago

jzwinck 8y ago

The STL doesn't always live up to the standard of "zero overhead abstractions." The list is not high performance, many implementations of hash tables never shrink (and used to have O(n) erase!), and deque is a bad joke (no chunk size control, plus laughable fixed chunk size on some common platforms). Many high performance projects use vector but few other containers. If the STL had a lesson to teach us it should have been "iterators everywhere, including for your own algorithms and container types." Instead most people learned "C++ has all the containers you need built in, throw away your performance tricks and let it call malloc a million times."

jstimpfle 8y ago
> Most high performance projects use vector and little else. Right. And then it is actually a lot simpler to simply use pointer + size pairs [1] instead of std::vector. Changing to explicit allocation was the best decision I've made. I now find myself not longing for any C++ features anymore at all. I haven't needed anything besides a little allocation wrapper [2] and maybe a string-to-hash map since. [1] Or n pointers + 1 size for parallel arrays, indicating that it's a bad idea to glue pointer + size in the first place. [2] https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5be8cdb https://gist.github.com/jstimpfle/562b2c3e9fe537e378351bb9d5...
- jstimpfle 8y ago
  > string-to-hash map string-to-int hash map
dralley 8y ago
Endeavors that really need high performance tend to use other standard library implementations. I think EA has their own, for example.
- jstimpfle 8y ago
  The motivation for creating of EASTL was mostly to get rid of allocations. std::vector does not have an allocation problem. Other STL containers do.
lbrandy 8y ago
"zero overhead abstractions" is a principle of the language, not the library. The STL containers are clearly designed to be on the "safer" side than the performant side. You are right that, perhaps, we've extracted the wrong lesson from the STL but your version ("iterators everywhere, including for your own algorithms and container types") is still definitely the right message. As an example, STL unordered-maps have fairly strict requirements around iterator invalidation and that results in indirection that do affect performance. It's pretty easy to make a "faster" unordered_map that tosses that requirement (as many do).

beagle3 8y ago

C++ the language, maybe. STL really is a cruel joke. is it ok to mutate a data structure while an iterator to it is live? It depends, which makes it much less abstract and generic than it could be (and that people believe it is) Error messages are useless. Compilers can and do (recently) help with that, but the main issue is the convoluted STL design in which every instantiation’s type name actually takes a full 80x25 screen to spell out. STLs primary objects are individual iterated elements, which does abstract over pointers (as was stepanov’s intention) but are at such a low level of abstraction as to be onerous. Modern C++ is slightly better.

amelius 8y ago
Could be true, but a modern language such as Rust has its own problems: https://news.ycombinator.com/item?id=16442743 https://news.ycombinator.com/item?id=16442743
- bluejekyll 8y ago
  What you’ve just linked to is a solution to the issue mentioned above. Rust makes a lot of guarantees, but sometimes those guarantees run afoul of certain required operations in different contexts. For this reason the language has an escape valve, unsafe, and the unsafe blocks are blindingly obvious in the code. To say it’s a problem is misleading at best.

fpoling 8y ago

STL tried hard to abstract pointer manipulation semantic of low-level C and apply it everywhere whether it fit or not. This pointer heritage inevitably lead to misfeatures like invalidation of iterators under container mutations or the need to have access both to the iterator and its container to implement things like vector::erase(). Other languages and runtimes use the notion of an iterator or cursor that is alone enough to perform all looping-like operations on the container including efficient erase() and can cheaply (so it is ok to have that in production) or even with good optimizing compiler at zero cost provide protection against container mutations.

abhishekjha 8y ago

I have recently got upto speed with c++17 features and I want to explore more C++. So far I have used Java and Python to build webapps. Are there libraries/framework that can replicate the MVC in C++ as well? I think I can extend functionalities from there.

AstralStorm 8y ago
Not quite MVC but RxCpp exists and can help with designing MVP style code. (also known as event driven programming)