This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ defect reports: how to behave
Phil Edwards <phil@jaj.com> wrote:
> (BTW, are you sure you mean 295? I can't find such commented code.)
It's not eactly commented. It's just worked around. cp/tree.c,
cp_build_qualified_type_real.
> See docs/html/ext/howto.html#5 for more.
>
> The existing practice is to only implement changes with DR or TC status,
> as we find them and have time, and to mark the change as noted in that
> howto.
Yes, I'm against implementing defects which are still in open status.
>> If not, I suggest we implement all the defect reports with TC1 status
>
> Sounds great, go for it.
Well, *let's* go for it ;)
> We used to mark the change via #ifdef, but once we moved to the point
where
> the library would not build without that symbol, we started just using it
> in a comment. (Grep for examples.) Either way is fine now.
> [...]
> Library code can't detect command line arguments. We (well, cpplib)
> would have to automatically define preprocessor symbols. Also, some
> changes would have to be reverted, to implement the "pure" c++98 code.
>
> I don't necessarily have a problem with all that; just letting you know
> what would have to happen before you/we could start.
Yes, I see what you mean. I don't know how many defects with WP status have
been implemented into the whole GCC, either core or library I mean. But yes,
probably we want to move some of them to a new dialect since they will be
officially part of C++0x. Instead, TC1 defects are really just "bugs" of the
standard, so I don't think we should care about keeping them separate from
C++98.
As for the new macro, we might as well bump __cplusplus (since that's its
meaning). Comments?
Giovanni Bajo