Boost logo

Boost :

From: Fernando Cacciola (fcacciola_at_[hidden])
Date: 2001-10-26 13:05:48

----- Original Message -----
From: Darin Adler <darin_at_[hidden]>
To: Boost <boost_at_[hidden]>
Sent: Friday, October 26, 2001 1:57 PM
Subject: Re: [boost] ANN: Optimized numeric_cast<> implementation

> Fernando,
> I am excited about the possibility of a more-efficient numeric_cast.
> Recently, when discussing the smart_ptr library, we established that boost
> libraries are primarily aiming for clarity and correctness, and less for
> optimization. But in this case I think some extra complexity is probably
> warranted because efficiency and correctness are related.
> I have some thoughts about the cast macros in general that apply to
> numeric_cast, but I decided to mention those in a separate message to
> confusion.
> Here's a first cut of nitpicky editorial comments about the proposal:
> I'd call the traits class "numeric_conversion_traits". While the traits
> being used for numeric_cast, they can also be used for other kinds of
> numeric conversions. The name numeric_cast is used to emphasize that we
> the same interface as the other kinds of casts, but cast is not a general
> name for all conversions, I don't think.
Agreed. I borrowed the name but I like 'conversion' better.

> > // static const int numeric_cast_traits<T,S>::mixture
> > // static const int numeric_cast_traits<T,S>::sign_mixture
> Is there a reason that these are of type int rather than an enum type?
Not really. I overlooked that. Those should be enum types.

> > // type numeric_cast_traits<T,S>::super_type
> > // type numeric_cast_traits<T,S>::sub_type
> Since the words are "supertype" and "subtype", not "super type" and "sub
> type", I think the identifiers should be "supertype" and "subtype", not
> "super_type" and "sub_type".
Yes, you're right.

> > // type numeric_cast_traits<T,S>::arg_type
> > // type numeric_cast_traits<T,S>::ret_type
> I'd suggest skipping the abbreviation, and using "argument_type" and
> "result_type".
This is fine with me. If no one complains about the longer name I can change

> > // static int out_of_range ( arg_type s ) ;
> Same int/enum question.
Yes. An enum is better.

> > // static void assert_in_range ( arg_type s ) ;
> The word assert has a specific meaning in C++ libraries as defined in
> <cassert>. I think you should find another word to use in the name of this
> function. I'd suggest throw_if_out_of_range, if you can't think of
> nicer.
I see.
If the funcionality is fixed to throw an exception, I think that
"throw_if_out_of_range" is OK; otherwise, I'd name it "verify_in_range".

> > // static ret_type cvt ( arg_type s ) ;
> How about "convert" instead of "cvt"?

Thanks for these comments!

I apply those changes after this first cut of feedback .

Fernando Cacciola
Sierra s.r.l.

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