61–70 of 79 posts
Earlier quoted context omitted.
Distinguishing two members of a union with... 0 bytes of extra data? Sounds like magic. Not 100% sure about the terminology. Pick whatever word might fit it better. I just called it a sentinel.
Why would you need a union?
Earlier quoted context omitted.
Keep in mind that most of the details you mentioned are for the developer of the library, not the end user/consumer of the library. Ultimately most consumers of the library care if they can call std::sort(YourSpecialContainer.begin(), YourSpecialContainer.end()); in a consistent manner with some semblance that the use of templates and interfaces result in nearly zero overhead of the abstraction.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
Zero overhead cult is pretty strong. People should profile instead. Sigh.
Earlier quoted context omitted.
Since C++20, the end iterator doesn't have to be the same type. Instead it can be something like a tag with no own runtime data, and comparing with it can be implemented as asking the other iterator if it is 'out of data'.
Yeah that's definitely an improvement in some respects, but (a) generic code still has to deal with 2 iterators, (b) generic code now has to allow them to be different types (so old code will have to be rewritten), (c) it doesn't change the fact that iterators are still treated like cheap objects (generalized pointers) and hence the begin iterator is still potentially expensive to store and copy around regardless of…
Earlier quoted context omitted.
Keep in mind that most of the details you mentioned are for the developer of the library, not the end user/consumer of the library. Ultimately most consumers of the library care if they can call std::sort(YourSpecialContainer.begin(), YourSpecialContainer.end()); in a consistent manner with some semblance that the use of templates and interfaces result in nearly zero overhead of the abstraction.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
First sentence: “ An iterator is an object that points to an element inside a container” This is not the primary purpose of an iterator. Does anyone want to hazard a guess as to what an iterator’s primary purpose is? You? You? Bueller?
I think you are arguing that iterators are "primarily" for iteration. But in C++ they really are like an abstraction over C pointers. For example, you can hold a std::list::iterator, and use it to efficiently delete from a linked list, without ever iterating. Sometimes C pointers are used for iteration, but I would not say that is their primary purpose.
I really wonder why people put up with something named this way then. "That fool thinks iterators are for iteration!"
Clarity of abstraction and good naming are important, unless the practitioners are masochists.
Earlier quoted context omitted.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
Usually people say std::sort is faster than qsort
Earlier quoted context omitted.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
Usually people say std::sort is faster than qsort
At the other extreme L1C cache (typically just 32 kB) gets constantly trashed by numerous type specialized functions. Individually fast when microbenchmarked, but collectively slow.
That's why profiling is a must when high performance is required. Microbenchmarks can be very misleading.
Earlier quoted context omitted.
Keep in mind that most of the details you mentioned are for the developer of the library, not the end user/consumer of the library. Ultimately most consumers of the library care if they can call std::sort(YourSpecialContainer.begin(), YourSpecialContainer.end()); in a consistent manner with some semblance that the use of templates and interfaces result in nearly zero overhead of the abstraction.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
Earlier quoted context omitted.
"nearly zero overhead" I can't call anything "nearly zero overhead" that can generate large amounts of code. Not at least with a pure conscience. I've seen enough many cases of better performance with more "overhead" but drastically smaller code size.
Code size is not always a good performance metric
It's very easy to forget things like memory bandwidth, inter-core/CPU links, etc. are all limited resources. And that on real systems resources are shared.
Earlier quoted context omitted.
Honest question: what does it mean for something to be "deprecated" in (specifically) the c++ language spec?
The spec itself defines it as: Normative for the current edition of the Standard, but having been identified as a candidate for removal from future revisions This is a very blunt tool. In practice, a feature may be deprecated if it is: 1. Legacy inherited from C that serves no modern purpose. The register keyword. 2. Features hardly anybody implemented. Exported templates is the only example I am aware of. Like falli…