This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Moving apart SGI extensions


Hi all and sorry for contributing to the discussion a bit late... you know, here
in Italy we were all sleeping...

Benjamin Kosnik wrote:

> >     http://gcc.gnu.org/ml/libstdc++/2001-09/msg00158.html
>
> 2) extensions. My preference is to not have a macro at all, and just move
> individual bits to include/ext/some_name.h. Furthermore, it would be
> great if the include/ext stuff was not in namespace std::, as it is presently
> (gag!). I think this is a better idea then macros... besides, stuff in
> /include/ext wouldn't have to be mangled, right? Since it's only brought
> in by request and not part of the standard library proper?
>
> It would be nice if /include/ext was
> 1) in namespace __gnu_cxx
> 2) not mangled
>
> That seems best to me, but I'm curious as to others suggestions.

Are you favouring this approach for the new or for old (i.e., SGI) extensions?

Honestly, for stuff like those bits in stl_algo.h I find it somewhat unnatural:
conceptually they are part of <algorithm> and depends on all the headers
specified in std_algorithm.h. So, if the user is supposed to include the
ext-header and use it we should duplicate most of the structure of
<algorithm>-std_algorithm.h only for those extra bits.

... on the other hand, the important advantage is that the names would be not
mangled, so the user would simply add at the beginning of the legacy code an
additional include and an using namespace __gnu_cxx ... What do you think Gaby?

Ok, I will try to prepare an include/ext/algorithm_ext.h and see what comes
out...

Cheers,
Paolo.

PS. I have a couple of partially-reviewed/unapproved patches...
1- Some more missing typename keywords in preparation for the new parser (quite
harmless, IMHO):

        http://gcc.gnu.org/ml/libstdc++/2001-12/msg00332.html

(as soon as Nathan Sidwell refines his deprecated implicit typename warning I
will separately simplify a typedef in stl_rope.h)

2- The next round of the improvements we are preparing together with Nathan
Myers to improve as much as possible the performance of the string class while
keeping its correctness vs overlapping ranges. This one is for insert members.
Nathan already reviewed the final code:

        http://gcc.gnu.org/ml/libstdc++/2001-12/msg00299.html
        http://gcc.gnu.org/ml/libstdc++/2001-12/msg00335.html

(I volunteer to work next on the benchmarking framework but I will need some
help for this... Phil?)






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]