Re: [boost] Re: Small thing: yes_type and no_type made public?

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2003-01-08 14:53:19

----- Original Message -----
From: "Hartmut Kaiser" <hartmutkaiser_at_[hidden]>

> David B. Held wrote:
>
> > "Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
> > news:05ab01c2b695$2f125c70$cb6c6f50_at_pc...
> > > Sure, that would be fine. I'm not that familiar with
> > Boost.PP, though,
> > > so I think I leave it to someone else to write that
> > version. As quite a
> > > bit of code uses yes_type/no_type, now, it may be a good
> > idea to keep
> > > them, as well, anyway, for backwards compatibility and simplicity.
> >
> > Using the PP lib seems like overkill to me.
>
> I think, that using the PP library will give us the possibility to
> configure the maximum number of required sizetype typedefs. I've
> attached a version of the yes_no_type.hpp, which does so by defining a
> constant 'BOOST_MAX_SIZETYPE_COUNT' if this constant isn't already
> predefined by the user.
>
> Regards Hartmut

Just a small point, you should include
<boost/preprocessor/repetition/repeat.hpp> after your normal include guard.
While it won't change the result, it is a waste of time to include it prior
to the include guard.  One other slight problem is that BOOST_PP_REPEAT goes
from 0 to N, which will cause you to get this declaration:

typedef char (&size0_t)[0];

...which is illegal.

Separately, I don't particularly think that this is a good use of the
pp-lib.  You can achieve the effect you want easily:

template<int I> struct size_descriptor {
    typedef char (& type)[I];
};

typedef size_descriptor<1>::type yes_type;
typedef size_descriptor<2>::type no_type;

...or something similar, which solves the problem once and for all.

Paul Mensonides