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
>deep.
>
>
>> 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.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk