This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [Patch] Qualify standard functions with std:: in stl_algo.h
On Sun, Jun 29, 2003 at 11:38:45PM +0200, Paolo Carlini wrote:
> Nathan Myers wrote:
> >>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>).
> 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?
Sorry, I had not read the patch carefully enough. (I thought you had
added declarations to another file.) It would be a little better to
shuffle than to add the declarations, but not better enough to hold
up the patch.
> >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.
This was just about how to be certain you hadn't missed any uses.
It wouldn't work anyway, because of the __name cases Gaby identified.
> >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.
When there's that much detail, though, applying diff -p to the
checked-in versions is more helpful, and less work anyway.
Nathan Myers
ncm-nospam@cantrip.org