Patch: stl_vector.h and vector.tcc

Mark Mitchell mark@codesourcery.com
Mon Aug 2 04:25:00 GMT 2004


Gabriel Dos Reis wrote:

>Mark Mitchell <mark@codesourcery.com> writes:
>
>| Matt Austern wrote:
>| 
>| >>
>| >> I believe Matt's suggestion is the right long term approach, assuming
>| >> we have an implementation of #nospam.  For the mid-term, I think that
>| >> using bits/cpp_type_traits.h is the most viable option -- with proper
>| >> uglification.
>| >
>| >
>| > I wonder if this does have to be "long term"?  If we think that we
>| > have a good specification of preprocessor scoping, I bet it won't
>| > be that hard to implement.
>| >
>| > I don't attend EWG sessions, so I don't have a good sense of how it
>| > was received.  Did it look to you as if the feature is ready to
>| > implement as Bjarne proposed it?
>| 
>| I know that Nathan Sidwell had some pretty serious objections to
>| Bjarne's proposal, but I'm not sure whether they've gotten through the
>| UK committee yet, or not.
>
>I've answered (and I think Bjarne did too) Nathan's questions on the
>Evolution reflector.  Nathan did not follow up, so I assumed he had no
>further concerns.  If there still are issues, it would be rather
>helpful if he could post them as soon as possible instead of waiting
>for the "slower" path to transmit them.
>  
>
We'll have to let Nathan speak for himself; I have no further 
information.  All I know is that at some point in the past Nathan was 
not happy with the proposal; to what extent that's been resolved, I'm 
not sure.

I do think that we should be very hesitant, as a matter of policy, about 
putting any features into G++ that have not been approved by the 
committee.  I'm not sure exactly what *level* of approval to require; 
maybe Bjarne's proposal already meets a reasonable threshold, in which 
case subsequent comments do not apply. 

Implementing these features for experimental purposes and putting them 
on a branch is great; that will save us time when the final version is 
ratified.  However, putting these kinds of features on the mainline 
would be risky, in my opinion, for the same reason that we hesitate to 
implement DRs for which it is not obvious what the outcome in the 
committee will be.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com



More information about the Libstdc++ mailing list