Quote:Original post by Red Ant
Quote:Original post by mind in a box
Just a little side question:
_Myt& replace(size_type _Off, size_type _N0, size_type _Count, _Elem _Ch) { // replace [_Off, _Off + _N0) with _Count * _Ch if (this->_Mysize < _Off) _Xran(); // _Off off end if (this->_Mysize - _Off < _N0) _N0 = this->_Mysize - _Off; // trim _N0 to size if (npos - _Count <= this->_Mysize - _N0) _Xlen(); // result too long size_type _Nm = this->_Mysize - _N0 - _Off; if (_Count < _N0) _Traits::move(_Myptr() + _Off + _Count, _Myptr() + _Off + _N0, _Nm); // smaller hole, move tail up size_type _Num; if ((0 < _Count || 0 < _N0) && _Grow(_Num = this->_Mysize + _Count - _N0)) { // make room and rearrange if (_N0 < _Count) _Traits::move(_Myptr() + _Off + _Count, _Myptr() + _Off + _N0, _Nm); // move tail down _Chassign(_Off, _Count, _Ch); // fill hole _Eos(_Num); } return (*this); }
What notation is this? Is this Hungarian, too? I'm asking because I can't understand in less than 5 minutes looking at it what this code should do.
Btw, why are all the standard headers so f***ing ugly?! Looking at standard C++ headers, I often get the impression those guys ran their code through an obfuscator program to make everything as hard to read as possible.
If you replace the ugly identifiers with beautiful ones, it becomes nicer. If you look closely, you'll recognize that they are very consistent with their style, and after some minutes of training, it is even possible to understand their code.
That is at least the impression I got when I dissected the GNU implementation of <valarray> to learn how their expression templates implementation looks and works like and how they organized their code (that was also the time when I learned that MSVC ppl did implement <valarray> naively and sub-performant).
Quote:Original post by Hodgman
Quote:Original post by Red Ant
Btw, why are all the standard headers so f***ing ugly?! Looking at standard C++ headers, I often get the impression those guys ran their code through an obfuscator program to make everything as hard to read as possible.
Yeah it would be nice if it was a bit more readable, [...]
Short story: The problem is that users can unknowingly override meanings of the standard library, and only if the identifiers of the libraries follow the reserved naming rules, and if clients will follow the rule of not using such naming schemes, it is guaranteed that everything is fine.
How it is like when vendors don't follow that rule can be seen at microsofts min()/max() #defines vs. std::min()/std::max().
Quote:[...] like this.
That's indeed fine code. But it would already fail for
#define pred -42[...]#include <sort.h>
Quote:error: expected identifier near: void quick_sort(T* data, long low, long high, TPredicate pred) .........................................................^
even though the client did not use a reserved name / naming scheme.
But if you rename <sort.h>::... so that it is all liek
// Jump over elements that are OK (smaller than pivot)while (_Pred(_Data[_I], _Pivot)) ++_I;
instead of
// Jump over elements that are OK (smaller than pivot)while (pred(data, pivot)) ++i;
then users won't get into trouble as long as they follow the standard.
Of course <sort.h> is not part of the standard library, but imagine it would, and re-imagine how the standard library massively grows in the next revision of C++, and the more it grows, the larger the probability of conflicts.
Surely, if you avoid evil macros like the pest, you wouldn't have problems in the first place.
[Edited by - phresnel on July 19, 2010 3:10:52 AM]
