[Patch] Qualify standard functions with std:: in stl_algo.h

[Paolo Carlini]

Nathan Myers wrote:

>On Sun, Jun 29, 2003 at 10:57:25PM +0200, Paolo Carlini wrote:
>  
>
>>this is another bit of the work you envisaged a while ago
>>(about 6 months)...
>>    
>>
>Wow, thanks Paolo!  This had long vexed me.  I wonder, though
>if they shouldn't say "::std::" instead.  Anyway this is better
>than before, and switching to "::std::" later would not break 
>binary compatibility -- at least not with any correct program!
>
Well, if we all agree that '::std::' is better, it's very easy for me to 
do the change: it's just a single search/replace.

>>Very boring but for one thing: ordering becomes important and
>>I had to declare 'merge' (both versions) and 'partial sort'
>>in advance. Is this ok/expected? I'm not sure that reshuffling
>>is even possible and adding a full set of declarations seems
>>overkilling...
>>    
>>
>Duplication is the problem.  Usually we prefer to add another header 
>under bits/ and include it wherever the names are needed, assuming
>that you can't just sub-include the whole header where the names are
>rightfully declared.  (An example where this would be impossible is
>when it introduces a circular dependency; see HEADER_POLICY.)  Also,
>if a header is to be sub-included, it's always worth checking if it
>suffices to include it in the .tcc file only.  Finally, (also re:
>HEADER_POLICY) sub-includes should never name the "official" header
>(e.g. <algorithm>) they should name the internal name (e.g.
><std/std_algorithm.h>).
>
>I suppose we could verify coverage by sub-including it in another 
>namespace, something like
>
>  #include <algorithm>
>  namespace dummy {
>  #  include <iterator>
>  }
>
>but then you would have to instantiate them all, too.
>
Hummm. So, sorry for appearing even more simple minded than I am (late 
at night ;) : for the case at hand what are you really suggesting?

>By the way, when you touch all or most of the objects in a header, 
>you don't have to name them all in the change log.  Just say "lots".
>The point of mentioning the file and object is so somebody reading
>has an answer to the question, "what changed?".  To know what to put 
>there, imagine yourself reading the changelog, looking for a hint of
>which change broke your program.
>
Hummm(2). In this case (guessing) I touched more or less 2/3 of the 
functions and I believed we always had to document which specific 
functions underwent change: seems more useful if you have to reconstruct 
exactly  when something went wrong.

Paolo.