lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Cating doubles to enums


From: Vadim Zeitlin
Subject: Re: [lmi] Cating doubles to enums
Date: Mon, 5 Nov 2018 23:42:13 +0100

On Mon, 5 Nov 2018 22:31:57 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-11-04 20:36, Vadim Zeitlin wrote:
GC> > On Sun, 4 Nov 2018 17:49:17 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Therefore, what do you think of, say,
GC> > GC>   double query    (database_key);
GC> > GC>   void   query_ref(T&, database_key);
GC> > GC>   void   query_ref(vector<T>&, database_key);
GC> > GC> which distinguishes the names without denying the similarity of
GC> > GC> the operations?
GC> > 
GC> >  I'm fine with this.
GC> > 
GC> > GC> I tried different second lexemes:
GC> > GC>   query_value  meaningless--they all retrieve values
GC> > GC>   query_into   seems obscure
GC> > 
GC> >  But my preferred version would be this one.
GC> 
GC> Then its name shall be called query_into<>(),

 Excellent, thank you.

GC> and the implementation for scalars is:
GC> 
GC> template<typename T>
GC> void product_database::query_into(T& dst, e_database_key k) const
GC> {
GC>     double d = [result of calling a more fundamental overload]
GC>     if constexpr(std::is_enum_v<T>)
GC>         {
GC>         dst = static_cast<T>(bourn_cast<std::underlying_type_t<T>>(d));
GC>         }
GC>     else
GC>         {
GC>         static_assert(std::is_integral_v<T>);
GC>         dst = bourn_cast<T>(d);
GC>         }
GC> }
GC> 
GC> which falls just short of my threshold for adding a unit test module.

 But it's so short that it definitely falls under my threshold for the code
I feel comfortable reviewing and so I did read it and have just one small
question: why do we need this static_assert<> above? It looks like it could
work without problems for float (which we'll probably never use) and for
double, which we definitely do use, and I'm not sure if there is any point
in forbidding using this version for double values, e.g. I can, in
principle, see when it might be convenient to use it just for consistency.

 I don't have anything important to say other than that however and I
really like how nice and clear this code is in C++17, especially knowing
what would have been needed to do the same thing without if-constexpr.

 Thanks again,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]