Re: [boost] Re: Possible defect macros for BCB for config.hpp

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-05-13 00:16:46

From: "David B. Held"

> "Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
> news:007b01c1f9b6$19927fc0$60fb5dd5_at_pc...
> > [...]
> > Case 2 - Non-type parameter problem
> > -----------------------------------------------------
> > [...]
> > I don't really know what to call this, as it may well be BCB specific,
so
> > one could have a parallel to the
> > "BOOST_MSVC6_MEMBER_TEMPLATES", something like:
> >
> > BOOST_BCB6_NONTYPE_PARAMETERS
> > [...]
>
> In keeping with the MSVC macro, I've called this "feature"
> BOOST_BCC_NONTYPE_TEMPLATE_PARAMETERS,
> which implies that non-type template parameters are supported by bcc,
> but in an incomplete or incorrect way (just as VC6 has member templates,
> but they don't work in every situation).  Calling it bcc instead of BCB is
> slightly more accurate, as it applies to the compiler, and not the
> development environment (some people just use the command line
> compiler alone).

Yes, it's a good name.

However, for MSVC, they also have BOOST_NO_MEMBER_TEMPLATES in addition. I
guess you can have the above name for BCC, without also having to set
something like BOOST_NO_NONTYPE_TEMPLATE_PARAMETERS (which doesn't exist,
either), though. After all, with BOOST_BCC_NONTYPE_PARAMETERS, I could
#ifdef that in the code.

> I think it should be added to
> boost/config/compilers/borland.hpp, but I don't know what the procedure
> is for suggesting such additions.

I think the BCC partial specialization problem also could need a name,
whatever it's called, as it shows up a lot in the Loki code, and I imagine
if other libraries using more advanced PS were to be ported to BCC, they
could well run into the same.

According to the docs for config.hpp, there's the following steps for
suggesting additions:

--- Start quote ---

Adding New Defect Macros

When you need to add a new defect macro - either to fix a problem with an
existing library, or when adding a new library - distil the issue down to a
simple test case, often at this point other (possibly better) workarounds
may become apparent. Secondly always post the test case code to the boost
mailing list and invite comments; remember that C++ is complex and that
sometimes what may appear a defect, may in fact turn out to be a problem
with the authors understanding of the standard.

When you name the macro, follow the BOOST_NO_SOMETHING naming convention, so
that it's obvious that this is a macro reporting a defect.

--- End quote ---

If it goes through, it's some more stuff to do, like adding a test case to
the regression tests.

The test is given as this:

namespace boost_no_foo{

int test()
{
   // test code goes here:
   //
   return 0;
}

}

I guess this means that if a feature is present, then it returns zero,
otherwise it gives an error, or whatever.

However, what about the partial specialization problem, where the problem is
that it doesn't compile in the first place, how do you fit such a test into
this?

Regards,

Terje