Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 1999-08-03 20:46:12

At 06:14 PM 8/3/99 -0500, Andy Glew wrote:

>> > * A template approach where the user would write code like:
>> > int_t<32>::exact // to obtain the 32-bit integer type
>I think the template approach is "better",
>and "more in the spirit of C++".
>My only concern is in template depth.
>ANSI C++ requires implementations nest templates only 17
>> The last line would read
>> numeric_limits<int_t<32>::exact>::max()
>Q: how many of our 17 levels of template nesting does this consume?
>(Apart from any levels of template nesting used in the definitions.)

My guess is that real compilers will handle any depth we are likely
to use, but I don't have any data points to back that up.

>> As Dietmar already pointed out, there could be applications
>> where specifying the width as a template parameter might be
>> natural.
>> Do we need the signed/unsigned distinction as a second "bool"
>> template parameter in the above definitions?
>{Would be a good argument for keyword parameters.}
>While you are at it, why not define
>* explicit integer ranges, not just binary bit counts
> int<upper_limit,lower_limit>
> -- you could have unchecked and checked varieties...
>* floating point types
> float<mantissa_width,exponent_width>
> -- the folks who have to deal with funny non-IEEE DSP
> floating point formats, such as 24 bit floats, would love
> to see this!

Yes you could, but do you want to do this all in the same library
and/or header? There is a complexity issue. To solve that some kind
of layered design is needed that maybe provides simple typedef like
solutions for simple problems like I have, a simple template solution
for Dietmar's generic programming problems, and your examples above
as even more powerful tools.

But I think that is two to four libraries and/or headers, not a
single library and header.

Interesting discussion. Let's keep the thread going and see if we
can refine the thinking.


Boost list run by bdawes at, gregod at, cpdaniel at, john at