Dag Henriksson wrote:
>
> "Chris Dearlove" <cmd@gmrc.gecm.com> wrote in message
> news:ak09tc$fe9$1@miranda.gmrc.gecm.com...
> > Has anyone
> > given any consideration to introducing a form of binary
> > traits, where for example binary_traits<S, T>::operator_result
> > (the name is just an example here) is the type of the
> > result of applying a standard arithmetic operator (at
> > least +, - , * or /) to the types S and T?
>
> Maybe this could be of interest:
> http://aspn.activestate.com/ASPN/Mail/Message/1154728

Thank you for the good article.
However I don't understand why the author didn't cover
every builtin arithmetic type, e.g. char and short.

I revised the code a bit and added a sample run:

#include <cstddef>

template<std::size_t N> struct selected;

template<> struct selected< 1> { typedef          char   type; };
template<> struct selected< 2> { typedef   signed char   type; };
template<> struct selected< 3> { typedef unsigned char   type; };
template<> struct selected< 4> { typedef          short  type; };
template<> struct selected< 5> { typedef unsigned short  type; };
template<> struct selected< 6> { typedef          int    type; }
template<> struct selected< 7> { typedef unsigned int    type; };
template<> struct selected< 8> { typedef          long   type; };
template<> struct selected< 9> { typedef unsigned long   type; };
template<> struct selected<10> { typedef          float  type; };
template<> struct selected<11> { typedef          double type; };
template<> struct selected<12> { typedef     long double type; };

template<std::size_t N>
struct sized { typedef char (&type)[N]; };

sized< 1>::type selector(         char);
sized< 2>::type selector(  signed char);
sized< 3>::type selector(unsigned char);
sized< 4>::type selector(         short);
sized< 5>::type selector(unsigned short);
sized< 6>::type selector(         int);
sized< 7>::type selector(unsigned int);
sized< 8>::type selector(         long);
sized< 9>::type selector(unsigned long);
sized<10>::type selector(         float);
sized<11>::type selector(         double);
sized<12>::type selector(    long double);

template<typename A, typename B>
struct arithmetic_conversion
{
        enum { id = sizeof selector(true ? A() : B()) };
        typedef typename selected<id>::type type;
};

#include <typeinfo>
#include <iostream>

int main()
{
        std::cout << std::hex;

#define ID(a, b) arithmetic_conversion< selected<a>::type,
                                        selected<b>::type >::id
#define COL(i, j, c) (std::cout << ID((i), (j)) << (c))
#define ROW(i) ( \
        COL(i, 1, ' '), \
        COL(i, 2, ' '), \
        COL(i, 3, ' '), \
        COL(i, 4, ' '), \
        COL(i, 5, ' '), \
        COL(i, 6, ' '), \
        COL(i, 7, ' '), \
        COL(i, 8, ' '), \
        COL(i, 9, ' '), \
        COL(i, 10, ' '), \
        COL(i, 11, ' '), \
        COL(i, 12, '\n') \
)

        ROW(1);
        ROW(2);
        ROW(3);
        ROW(4);
        ROW(5);
        ROW(6);
        ROW(7);
        ROW(8);
        ROW(9);
        ROW(10);
        ROW(11);
        ROW(12);

        return 0;
}

GCC 3.0.4 gives the following output:

1 6 6 6 6 6 7 8 9 a b c
6 2 6 6 6 6 7 8 9 a b c
6 6 3 6 6 6 7 8 9 a b c
6 6 6 4 6 6 7 8 9 a b c
6 6 6 6 5 6 7 8 9 a b c
6 6 6 6 6 6 7 8 9 a b c
7 7 7 7 7 7 7 9 9 a b c
8 8 8 8 8 8 9 8 9 a b c
9 9 9 9 9 9 9 9 9 a b c
a a a a a a a a a a b c
b b b b b b b b b b b c
c c c c c c c c c c c c

Interesting. :)

--
Sungbom Kim <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3D652347.12DED561@bawi.org...

> Thank you for the good article.
> However I don't understand why the author didn't cover
> every builtin arithmetic type, e.g. char and short.

Maybe because the "usual arithmetic conversion" can never have these
types as the result. Integral promotion will bring them to at least
'int'.
for example:
arithmetic_conversion<char, short>::type
will work as expected (unless your expectations are incorrect).

--
Dag Henriksson




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dag Henriksson wrote:
>
> "Sungbom Kim" <musiphil@bawi.org> wrote in message
> news:3D652347.12DED561@bawi.org...
>
> > Thank you for the good article.
> > However I don't understand why the author didn't cover
> > every builtin arithmetic type, e.g. char and short.
>
> Maybe because the "usual arithmetic conversion" can never have these
> types as the result. Integral promotion will bring them to at least
> 'int'.
> for example:
> arithmetic_conversion<char, short>::type
> will work as expected (unless your expectations are incorrect).

However arithmetic_conversion<char, char>::type is char, isn't it?

My experiment with GCC 3.0.4 shows that, for every built-in arithmetic
type T, arithmetic_conversion<T, T>::type is equal to T.

--
Sungbom Kim <musiphil@bawi.org>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Sungbom Kim" <musiphil@bawi.org> wrote in message
news:3D6589B2.2F578F81@bawi.org...

> However arithmetic_conversion<char, char>::type is char, isn't it?

Not on my system (Comeau 4.2.44). I tried the row below with the
original implementation of arithmetic_conversion:
printf("%s\n", typeid(arithmetic_conversion<char,
char>::result()).name());
and it gave me the result 'int'.

This seems to be correct according to the standard too. The
implementation uses the conditional operator for the conversion. The
result of this operator when second and third operand are r-values of
non class type, is specified in 5.16p6: "standard conversions are
performed on the second and third operands".

--
Dag Henriksson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I know that type traits, as in Boost, are a front-runner
for the next C++ standardisation. (They were one of seven
candidates in one of Matt Austern's articles.) Has anyone
given any consideration to introducing a form of binary
traits, where for example binary_traits<S, T>::operator_result
(the name is just an example here) is the type of the
result of applying a standard arithmetic operator (at
least +, - , * or /) to the types S and T? This would
take on board the usual promotions and conversions,
and to be useful in the context where one of my colleagues
has wanted something like this, should be specialised
in <complex> for complex types. Of course this example
presumes it is sensible to use the same type for all
four operators, but could be generalised if this was
not taken to be the case. There may be other binary
traits as well (although none occur obviously to me).

(I've had an example pointed out to me, by the same
collegue, of an example by Todd Veldhuizen who
credits Jean-Louis Leroy, but I'm not sure the
idea of ranking types will properly cope with
double + complex<float> which ought to give
complex<double>, although I have to admit I haven't
verified that.)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Chris Dearlove" <cmd@gmrc.gecm.com> wrote in message
news:ak09tc$fe9$1@miranda.gmrc.gecm.com...
> Has anyone
> given any consideration to introducing a form of binary
> traits, where for example binary_traits<S, T>::operator_result
> (the name is just an example here) is the type of the
> result of applying a standard arithmetic operator (at
> least +, - , * or /) to the types S and T?

Maybe this could be of interest:
http://aspn.activestate.com/ASPN/Mail/Message/1154728

--
Dag Henriksson


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

cmd@gmrc.gecm.com (Chris Dearlove) wrote in message news:<ak09tc$fe9$1@miranda.gmrc.gecm.com>...
> I know that type traits, as in Boost, are a front-runner
> for the next C++ standardisation. (They were one of seven
> candidates in one of Matt Austern's articles.) Has anyone
> given any consideration to introducing a form of binary
> traits, where for example binary_traits<S, T>::operator_result
> (the name is just an example here) is the type of the
> result of applying a standard arithmetic operator (at
> least +, - , * or /) to the types S and T?

I would be very surprised if the next Standard did not include a
"typeof()" operator, which would cover everything your binary_traits
class would and more.

        -Steve

Stephen Cleary
http://my.voyager.net/~shammah/

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dag Henriksson (dag.henriksson@quidsoft.se) wrote:
: Maybe this could be of interest:
: http://aspn.activestate.com/ASPN/Mail/Message/1154728

This is essentially equivalent to the approach I noted,
with the limitation of only working if you can rank
the types in a strict hierarchy.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]