Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #6449 > unrolled thread

Integer promotions, conversions, coercions and templates :(

Back to article view | Back to comp.lang.c++

Contents

  Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-08 17:09 -0500
    Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-09 10:22 +1200
      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-08 17:49 -0500
      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-08 19:13 -0500
        Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-09 14:32 +1200
          Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 07:30 -0500
            Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-09 06:18 -0700
              Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 08:45 -0500
                Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-09 06:51 -0700
                  Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 13:44 -0500
            Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-10 07:37 +1200
              Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 15:11 -0500
                Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-10 09:09 +1200
                  Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 17:15 -0500
                    Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-10 10:40 +1200
                      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 05:07 -0500
                      Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-10 03:14 -0700
                        Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-10 03:19 -0700
                          Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 06:08 -0500
                            Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-10 04:32 -0700
                              Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 07:14 -0500
                                Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-10 05:27 -0700
                                  Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 07:35 -0500
                                    Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-10 06:47 -0700
                      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 06:18 -0500
                        Re: Integer promotions, conversions, coercions and templates :( Ian Collins <ian-news@hotmail.com> - 2011-06-11 08:08 +1200
                          Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 18:41 -0500
      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-10 08:11 -0500
    Re: Integer promotions, conversions, coercions and templates :( Öö Tiib <ootiib@hot.ee> - 2011-06-09 06:28 -0700
      Re: Integer promotions, conversions, coercions and templates :( "MikeP" <mp011011@some.org> - 2011-06-09 08:50 -0500
    Re: Integer promotions, conversions, coercions and templates :( (Summary so far) "MikeP" <mp011011@some.org> - 2011-06-10 08:40 -0500
      Re: Integer promotions, conversions, coercions and templates :( (Summary so far) Öö Tiib <ootiib@hot.ee> - 2011-06-10 07:14 -0700
        Re: Integer promotions, conversions, coercions and templates :( (Summary so far) "MikeP" <mp011011@some.org> - 2011-06-10 09:17 -0500
      Re: Integer promotions, conversions, coercions and templates :( (Summary so far)(Corrections and more) "MikeP" <mp011011@some.org> - 2011-06-10 09:14 -0500
        Re: Integer promotions, conversions, coercions and templates :( (Results: Generated Code) "MikeP" <mp011011@some.org> - 2011-06-10 12:43 -0500
    Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-14 18:35 -0500
      Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Ian Collins <ian-news@hotmail.com> - 2011-06-15 12:51 +1200
        Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-15 08:45 -0500
      Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Michael DOUBEZ <michael.doubez@free.fr> - 2011-06-15 03:33 -0700
        Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-15 09:17 -0500
          Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Michael DOUBEZ <michael.doubez@free.fr> - 2011-06-16 04:17 -0700
            Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-16 09:45 -0500
              Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Michael DOUBEZ <michael.doubez@free.fr> - 2011-06-17 01:56 -0700
                Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-17 07:58 -0500
                  Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Michael DOUBEZ <michael.doubez@free.fr> - 2011-06-17 06:54 -0700
                    Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-17 09:19 -0500
                Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-17 08:17 -0500
                  Re: Integer promotions, conversions, coercions and templates :( (Conclusion) Michael DOUBEZ <michael.doubez@free.fr> - 2011-06-17 07:33 -0700
                    Re: Integer promotions, conversions, coercions and templates :( (Conclusion) "MikeP" <mp011011@some.org> - 2011-06-17 09:49 -0500

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#6550

Öö Tiib wrote:
> On Jun 10, 2:08 pm, "MikeP" <mp011...@some.org> wrote:
>> Tiib wrote:
>>> On Jun 10, 1:14 pm, Tiib <oot...@hot.ee> wrote:
>>>> On Jun 10, 1:40 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>>>>> Hoops? What could be simpler than
>>
>>>>> template <typename T>
>>>>> bool CheckBit( T mask, unsigned n)
>>>>> {
>>>>> assert( n < std::numeric_limits<T>::digits );
>>
>>>>> return (mask & (T(1) << (n-1)));
>>
>>>>> }
>>
>>>>> bool result = CheckBit( 42ull, 4 );
>>
>>>>> ?
>>
>>>> Depends how simple it has to be and what is allowed by coding
>>>> policy. For example getting rid of implicit T to bool conversion
>>>> and simplifying the part with 3 nested parentheses, also adding
>>>> debug check against "n == 0 defect":
>>
>>>> template <typename T>
>>>> bool CheckBit( T mask, unsigned n)
>>>> {
>>>> assert( 1 <= n && n < std::numeric_limits<T>::digits );
>>
>>>> T bit = T(1) << (n-1);
>>>> return (mask & bit) != 0;
>>
>>>> }
>>
>>>> bool result = CheckBit( 42ull, 4 );
>>
>>> Uh, and still it wrongly asserts on the valid case "n ==
>>> std::numeric_limits<T>::digits". Hard to get used to the MikeP's
>>> unusual "counting bits from 1" habit. ;)
>>
>> And you introduced an explicit temporary: bit. Why no "inline"?
>
> Compilers optimize such simple temporaries out without problems.
> Actually i have seen how they optimize out whole instantiations of
> objects of classes and calls to member functions. Otherwise lot of the
> template magic would be inefficient.

Well, with my hesitance to use optimization switches, I'm a bit more 
conscious of the like.

>
> Not inline since "inline" keyword is only a hint to compiler.

Well why not hint it then! It serves as documentation of intent then too. 
Surely something as simple as above would be inlined? (At least if 
suffixes would work, it would be "simple"! Having to introduce C++isms to 
get around it is, well, lame and could have an effect on optimization). 
The more that this is discussed, the more the lack of being able to use 
suffixes seems like a (greater) deficiency.

> Depends
> on other options if it is reasonable to add or not. "CheckBit( 42ull,
> 4 )" is usually optimized into "true" by modern compilers.

It won't be used like that though. The arg would be a reference to a 
variable. 

[toc] | [prev] | [next] | [standalone]

#6552

On Jun 10, 3:14 pm, "MikeP" <mp011...@some.org> wrote:
> Tiib wrote:
> > On Jun 10, 2:08 pm, "MikeP" <mp011...@some.org> wrote:
> >> Tiib wrote:
> >>> On Jun 10, 1:14 pm, Tiib <oot...@hot.ee> wrote:
> >>>> On Jun 10, 1:40 am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> >>>>> Hoops? What could be simpler than
>
> >>>>> template <typename T>
> >>>>> bool CheckBit( T mask, unsigned n)
> >>>>> {
> >>>>> assert( n < std::numeric_limits<T>::digits );
>
> >>>>> return (mask & (T(1) << (n-1)));
>
> >>>>> }
>
> >>>>> bool result = CheckBit( 42ull, 4 );
>
> >>>>> ?
>
> >>>> Depends how simple it has to be and what is allowed by coding
> >>>> policy. For example getting rid of implicit T to bool conversion
> >>>> and simplifying the part with 3 nested parentheses, also adding
> >>>> debug check against "n == 0 defect":
>
> >>>> template <typename T>
> >>>> bool CheckBit( T mask, unsigned n)
> >>>> {
> >>>> assert( 1 <= n && n < std::numeric_limits<T>::digits );
>
> >>>> T bit = T(1) << (n-1);
> >>>> return (mask & bit) != 0;
>
> >>>> }
>
> >>>> bool result = CheckBit( 42ull, 4 );
>
> >>> Uh, and still it wrongly asserts on the valid case "n ==
> >>> std::numeric_limits<T>::digits". Hard to get used to the MikeP's
> >>> unusual "counting bits from 1" habit. ;)
>
> >> And you introduced an explicit temporary: bit. Why no "inline"?
>
> > Compilers optimize such simple temporaries out without problems.
> > Actually i have seen how they optimize out whole instantiations of
> > objects of classes and calls to member functions. Otherwise lot of the
> > template magic would be inefficient.
>
> Well, with my hesitance to use optimization switches, I'm a bit more
> conscious of the like.

Probably my English again. Code is simpler to read. In debug builds
you can check the value of bit. In production build it will be gone.
Win-win-win for me.

> > Not inline since "inline" keyword is only a hint to compiler.
>
> Well why not hint it then! It serves as documentation of intent then too.
> Surely something as simple as above would be inlined? (At least if
> suffixes would work, it would be "simple"! Having to introduce C++isms to
> get around it is, well, lame and could have an effect on optimization).
> The more that this is discussed, the more the lack of being able to use
> suffixes seems like a (greater) deficiency.

Because of my working process. I start hinting inlining, register
usage, switching if and else blocks (to hint branch prediction) etc.
only when i have full product profiled with real data. Before that no
hints. I have to comment inline keyword usage with real performance
issue handled.

> > Depends
> > on other options if it is reasonable to add or not. "CheckBit( 42ull,
> > 4 )" is usually optimized into "true" by modern compilers.
>
> It won't be used like that though. The arg would be a reference to a
> variable.

It was just given as example to show how compiler inlines it anyway as
it sees fit, so no keyword is needed.

[toc] | [prev] | [next] | [standalone]

#6555

Öö Tiib wrote:
> On Jun 10, 3:14 pm, "MikeP" <mp011...@some.org> wrote:
>> Tiib wrote:
>>> On Jun 10, 2:08 pm, "MikeP" <mp011...@some.org> wrote:
>>>> Tiib wrote:
>>>>> On Jun 10, 1:14 pm, Tiib <oot...@hot.ee> wrote:
>>>>>> On Jun 10, 1:40 am, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>>>>>>> Hoops? What could be simpler than
>>
>>>>>>> template <typename T>
>>>>>>> bool CheckBit( T mask, unsigned n)
>>>>>>> {
>>>>>>> assert( n < std::numeric_limits<T>::digits );
>>
>>>>>>> return (mask & (T(1) << (n-1)));
>>
>>>>>>> }
>>
>>>>>>> bool result = CheckBit( 42ull, 4 );
>>
>>>>>>> ?
>>
>>>>>> Depends how simple it has to be and what is allowed by coding
>>>>>> policy. For example getting rid of implicit T to bool conversion
>>>>>> and simplifying the part with 3 nested parentheses, also adding
>>>>>> debug check against "n == 0 defect":
>>
>>>>>> template <typename T>
>>>>>> bool CheckBit( T mask, unsigned n)
>>>>>> {
>>>>>> assert( 1 <= n && n < std::numeric_limits<T>::digits );
>>
>>>>>> T bit = T(1) << (n-1);
>>>>>> return (mask & bit) != 0;
>>
>>>>>> }
>>
>>>>>> bool result = CheckBit( 42ull, 4 );
>>
>>>>> Uh, and still it wrongly asserts on the valid case "n ==
>>>>> std::numeric_limits<T>::digits". Hard to get used to the MikeP's
>>>>> unusual "counting bits from 1" habit. ;)
>>
>>>> And you introduced an explicit temporary: bit. Why no "inline"?
>>
>>> Compilers optimize such simple temporaries out without problems.
>>> Actually i have seen how they optimize out whole instantiations of
>>> objects of classes and calls to member functions. Otherwise lot of
>>> the template magic would be inefficient.
>>
>> Well, with my hesitance to use optimization switches, I'm a bit more
>> conscious of the like.
>
> Probably my English again. Code is simpler to read. In debug builds
> you can check the value of bit. In production build it will be gone.
> Win-win-win for me.

I'd rather it just stayed the same across builds and do the premature 
optimization manually (that way, no guessing or assuming necessary) if 
possible for it's a pretty easy thing to grok.

>
>>> Not inline since "inline" keyword is only a hint to compiler.
>>
>> Well why not hint it then! It serves as documentation of intent then
>> too. Surely something as simple as above would be inlined? (At least
>> if suffixes would work, it would be "simple"! Having to introduce
>> C++isms to get around it is, well, lame and could have an effect on
>> optimization). The more that this is discussed, the more the lack of
>> being able to use suffixes seems like a (greater) deficiency.
>
> Because of my working process. I start hinting inlining, register
> usage, switching if and else blocks (to hint branch prediction) etc.
> only when i have full product profiled with real data. Before that no
> hints. I have to comment inline keyword usage with real performance
> issue handled.

OK. It's not an issue for the topic at hand anyway.

>
>>> Depends
>>> on other options if it is reasonable to add or not. "CheckBit(
>>> 42ull, 4 )" is usually optimized into "true" by modern compilers.
>>
>> It won't be used like that though. The arg would be a reference to a
>> variable.
>
> It was just given as example to show how compiler inlines it anyway as
> it sees fit, so no keyword is needed.

But if the arg is not an immediate value as you had, will it still 
optimize it away? 

[toc] | [prev] | [next] | [standalone]

#6560

On Jun 10, 3:35 pm, "MikeP" <mp011...@some.org> wrote:
> Öö Tiib wrote:
> > On Jun 10, 3:14 pm, "MikeP" <mp011...@some.org> wrote:
> >> Tiib wrote:
>
> >>> Depends
> >>> on other options if it is reasonable to add or not. "CheckBit(
> >>> 42ull, 4 )" is usually optimized into "true" by modern compilers.
>
> >> It won't be used like that though. The arg would be a reference to a
> >> variable.
>
> > It was just given as example to show how compiler inlines it anyway as
> > it sees fit, so no keyword is needed.
>
> But if the arg is not an immediate value as you had, will it still
> optimize it away?

Generally yes, but it may depend on compiler. Tried with an int got
from std::cin, MSVC 9.0 for 32 bit x86 did replace CheckBit( x, 4 )
call (where x was in edx register) with:

  shr         edx,3
  and         dl,1

Further it used the dl as returned bool value.

[toc] | [prev] | [next] | [standalone]

#6546

Ian Collins wrote:
> On 06/10/11 10:15 AM, MikeP wrote:
>> Ian Collins wrote:
>>
>>> Anyway, if you were using a
>>> macro you would have to have a parameter for the suffix.
>>
>> Yes, as I wanted with the template (for lack of any other way), but
>> templates won't allow it.
>
> Because they don't require it.  The type is known.
>
>> I thought I had it down for awhile, but I
>> hadn't yet called any of the member functions of the template class
>> so the code genrator did not generate code for those member
>> functions and everything seemed "way-kewl", until I wrote the test
>> and started calling the functions and then the compiler complained.
>> So, I can do what I wanted to do with the macro but not with the
>> template, and if I do it in "super macro" style, it may be a better
>> solution than jumping through hoops with the template "deficiency"
>> (TBD).
>
> Hoops?  What could be simpler than
>
> template <typename T>
> bool CheckBit( T mask, unsigned n)
> {
>   assert( n < std::numeric_limits<T>::digits );
>
>   return (mask & (T(1) << (n-1)));
> }
>
> bool result = CheckBit( 42ull, 4 );
>

I'm still concerned about any/all implicit transformations on the right 
side of "<<".  Any LL (Language Lawyer) care to enumerate those? A suffix 
on the literal would make things a bit easier to implement and grok, but 
again, they cannot be had in this scenario :( . The literal "starts out 
life as" a signed int? Then... 

[toc] | [prev] | [next] | [standalone]

#6580

On 06/10/11 11:18 PM, MikeP wrote:
> Ian Collins wrote:
>> On 06/10/11 10:15 AM, MikeP wrote:
>>> Ian Collins wrote:
>>>
>>>> Anyway, if you were using a
>>>> macro you would have to have a parameter for the suffix.
>>>
>>> Yes, as I wanted with the template (for lack of any other way), but
>>> templates won't allow it.
>>
>> Because they don't require it.  The type is known.
>>
>>> I thought I had it down for awhile, but I
>>> hadn't yet called any of the member functions of the template class
>>> so the code genrator did not generate code for those member
>>> functions and everything seemed "way-kewl", until I wrote the test
>>> and started calling the functions and then the compiler complained.
>>> So, I can do what I wanted to do with the macro but not with the
>>> template, and if I do it in "super macro" style, it may be a better
>>> solution than jumping through hoops with the template "deficiency"
>>> (TBD).
>>
>> Hoops?  What could be simpler than
>>
>> template<typename T>
>> bool CheckBit( T mask, unsigned n)
>> {
>>    assert( n<  std::numeric_limits<T>::digits );
>>
>>    return (mask&  (T(1)<<  (n-1)));
>> }
>>
>> bool result = CheckBit( 42ull, 4 );
>>
>
> I'm still concerned about any/all implicit transformations on the right
> side of "<<".

That's OK because there aren't any in my example!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#6597

Ian Collins wrote:
> On 06/10/11 11:18 PM, MikeP wrote:
>> Ian Collins wrote:
>>> On 06/10/11 10:15 AM, MikeP wrote:
>>>> Ian Collins wrote:
>>>>
>>>>> Anyway, if you were using a
>>>>> macro you would have to have a parameter for the suffix.
>>>>
>>>> Yes, as I wanted with the template (for lack of any other way), but
>>>> templates won't allow it.
>>>
>>> Because they don't require it.  The type is known.
>>>
>>>> I thought I had it down for awhile, but I
>>>> hadn't yet called any of the member functions of the template class
>>>> so the code genrator did not generate code for those member
>>>> functions and everything seemed "way-kewl", until I wrote the test
>>>> and started calling the functions and then the compiler complained.
>>>> So, I can do what I wanted to do with the macro but not with the
>>>> template, and if I do it in "super macro" style, it may be a better
>>>> solution than jumping through hoops with the template "deficiency"
>>>> (TBD).
>>>
>>> Hoops?  What could be simpler than
>>>
>>> template<typename T>
>>> bool CheckBit( T mask, unsigned n)
>>> {
>>>    assert( n<  std::numeric_limits<T>::digits );
>>>
>>>    return (mask&  (T(1)<<  (n-1)));
>>> }
>>>
>>> bool result = CheckBit( 42ull, 4 );
>>>
>>
>> I'm still concerned about any/all implicit transformations on the
>> right side of "<<".
>
> That's OK because there aren't any in my example!

Well I don't know that, and I categorize that info as esoteric, in a way. 
Not that it's not common knowledge and able to be known, but that it's a 
waste of mind power and human life. I'd still like to know the process. 
the '1' starts out as an int, n is unsigned.. blah, blah.. it's hardly 
clear what is happening. Of course though, my laziness on the matter is 
well-founded: why guess when a suffix would help a bit? While one cannot 
escape the inelegance of the C++ type system completely, it can be made 
incrementally, but significantly better. 

[toc] | [prev] | [next] | [standalone]

#6557

Ian Collins wrote:

> Why don't you just use
>
>   const T one(1);
>   return (((mask & one) << (n-one)) != 0);

Just realized, the above should be:

    return ((mask & (one << (n-one))) != 0);

[toc] | [prev] | [next] | [standalone]

#6491

On Jun 9, 1:09 am, "MikeP" <mp011...@some.org> wrote:
> I need help (but nevermind that!) templates and the C++ integer rules are
> confusing me! (No occifer, I have not been drinking, I am just dazed and
> confused by C++ integer rules!).
>
> // CheckBit
> // Checks the status of individual bits of any unsigned integer type.
> // Indexing of bits starts at 1, not 0.
> // mask can be any unsigned integer type.
> // W is the width of the type T.
> //
> template <typename T, unsigned int W>
> bool CheckBit(T& mask, T n)
> {   // The assertion should be an exception, I know.
>     Assert((n >= 1) && (n <= W), "Bit index out of range.")

You can use std::numeric_limits<T>::digits and drop that W entirely.

>     return ((mask & ((T)1) << (n-((T)1))) != 0);

Everybody else usually count bits starting from 0, why you count them
starting from 1?

> }

[toc] | [prev] | [next] | [standalone]

#6497

Öö Tiib wrote:
> On Jun 9, 1:09 am, "MikeP" <mp011...@some.org> wrote:
>> I need help (but nevermind that!) templates and the C++ integer
>> rules are confusing me! (No occifer, I have not been drinking, I am
>> just dazed and confused by C++ integer rules!).
>>
>> // CheckBit
>> // Checks the status of individual bits of any unsigned integer type.
>> // Indexing of bits starts at 1, not 0.
>> // mask can be any unsigned integer type.
>> // W is the width of the type T.
>> //
>> template <typename T, unsigned int W>
>> bool CheckBit(T& mask, T n)
>> { // The assertion should be an exception, I know.
>> Assert((n >= 1) && (n <= W), "Bit index out of range.")
>
> You can use std::numeric_limits<T>::digits and drop that W entirely.

Good info. I had wondered if there was something like that available or 
not.  I won't use it though, since the template is for a very finite set 
of  T: unsigned integers, i.e., 8, 16, 32, 64 bit unsigneds. No need to 
pull in a header just for that.

>
>> return ((mask & ((T)1) << (n-((T)1))) != 0);
>
> Everybody else usually count bits starting from 0, why you count them
> starting from 1?
>

Because everybody else is "wrong"! ;) 

[toc] | [prev] | [next] | [standalone]

#6558 — Re: Integer promotions, conversions, coercions and templates :( (Summary so far)

Let us assume that the outline of CheckBit is set in stone as:

template <typename T>
inline bool CheckBit(T& mask, uint32 n) // n range is 1 through the 
bit-width of T.
{
    // error handling here.
    // main part of func here.
}

For the main part of the function, the desired, but cannot be had, code 
generation from the template is something LIKE (for the case where the 
type of T is uint64):

    return ((mask & (1ui64 <<  (n-1ui32))) != 0);

which is plain-as-day, easy to grok. I added parenthesis instead of 
requiring knowledge of operator precedence rules and for clarity and 
added the truth comparison also for clarity and to avoid an implicit 
conversion to bool.

So far, we have the following possible alternatives:

A. return ((mask & ((T)1) << (n-((T)1))) != 0);

B. const T one(1);
   return ((mask & (one << (n-one)) != 0);

C. return ((mask & ((T(1) << (n-1)) != 0);

D. T bit = T(1) << (n-1);
   return ((mask & bit) != 0);

The expression on the right side of "<<" is a continual source of worry.

Are all the alternatives even correct across all platforms and compilers? 
Have the alternatives been exhausted? If A thru D are correct, I think 
each may have to be analyzed according to the implicit transformations 
that occur in order to understand (and maybe even across compilers!). All 
of this is brought about because the simple and elegant way cannot be had 
in this scenario (using suffixes with templates). Dilemma: which to 
choose? Some other?

[toc] | [prev] | [next] | [standalone]

#6562 — Re: Integer promotions, conversions, coercions and templates :( (Summary so far)

On Jun 10, 4:40 pm, "MikeP" <mp011...@some.org> wrote:
>
> The expression on the right side of "<<" is a continual source of worry.

When in doubt then practical people write tests.
If you have luxury to use constexpr and static_assert from C++0x then
you can put the tests right next to implementation.

[toc] | [prev] | [next] | [standalone]

#6565 — Re: Integer promotions, conversions, coercions and templates :( (Summary so far)

Öö Tiib wrote:
> On Jun 10, 4:40 pm, "MikeP" <mp011...@some.org> wrote:
>>
>> The expression on the right side of "<<" is a continual source of
>> worry.
>
> When in doubt then practical people write tests.

But that only gets someone information about a given platform or 
compiler. Language-level analysis is the more important first step. I 
posted some helpfull functions to test with in another post (as well as 
corrected parenthesis errors in my prior post).

> If you have luxury to use constexpr and static_assert from C++0x then
> you can put the tests right next to implementation. 

[toc] | [prev] | [next] | [standalone]

#6564 — Re: Integer promotions, conversions, coercions and templates :( (Summary so far)(Corrections and more)

Parenthesis Corrections

A. return ((mask & ((CBTYPE)1) << (n-((CBTYPE)1))) != 0);
   const CBTYPE one(1);

B. return ((mask & (one << (n-one))) != 0);

C. return ((mask & (CBTYPE(1) << (n-1))) != 0);

D. CBTYPE bit = CBTYPE(1) << (n-1);
   return ((mask & bit) != 0);

// Helpful Functions for Evaluation and Analysis

//A.
//
#define CBTYPE uint32

inline bool CheckBitA(CBTYPE mask, uint32 n)
{
   return ((mask & ((CBTYPE)1) << (n-((CBTYPE)1))) != 0);
}

//B.
//
inline bool CheckBitB(CBTYPE mask, uint32 n)
{
   const CBTYPE one(1);
   return ((mask & (one << (n-one))) != 0);
}

//C.
//
inline bool CheckBitC(CBTYPE mask, uint32 n)
{
   return ((mask & (CBTYPE(1) << (n-1))) != 0);
}

//D.
//
inline bool CheckBitD(CBTYPE mask, uint32 n)
{
   CBTYPE bit = CBTYPE(1) << (n-1);
   return ((mask & bit) != 0);
} 

[toc] | [prev] | [next] | [standalone]

#6571 — Re: Integer promotions, conversions, coercions and templates :( (Results: Generated Code)

Below are the results of compiling 5 "different" versions of a 
non-templatized free function "CheckBit" without any compiler 
optimizations turned on. Version E shows the desired implementation but 
it cannot be had because CheckBit is, in reality, a template function 
(the functions below are only to analyze and evaluate effects of various 
implementations of CheckBit) and the "impedance mismatch" between 
templates and the C++ type system will not allow version E to be 
generated by the template machinery (consider that desired is to generate 
CheckBit for all unsigned integer types, include a platform-specific 
64-bit unsigned integer). Note that A, C and E generate the same assembly 
and that B and D result in more instructions than A, C, E (but please 
note that they look longer than they are because of the embedded line 
number comments).. Full optimization had no effect on the code generated.

(It should be clear that "uint32" is an alias and the the suffixes used 
in version E are non-standard).

11 //A.
12 //
13 #define CBTYPE uint32
14 #define INLINE
15 INLINE bool CheckBitA(CBTYPE mask, uint32 n)
16 {
17    return ((mask & ((CBTYPE)1) << (n-((CBTYPE)1))) != 0);
18 }
19
20 //B.
21 //
22 INLINE bool CheckBitB(CBTYPE mask, uint32 n)
23 {
24    const CBTYPE one(1);
25    return ((mask & (one << (n-one))) != 0);
26 }
27
28 //C.
29 //
30 INLINE bool CheckBitC(CBTYPE mask, uint32 n)
31 {
32    return ((mask & (CBTYPE(1) << (n-1))) != 0);
33 }
34
35 //D.
36 //
37 INLINE bool CheckBitD(CBTYPE mask, uint32 n)
38 {
39    CBTYPE bit = CBTYPE(1) << (n-1);
40    return ((mask & bit) != 0);
41 }
42
43 //E.
44 //
45 INLINE bool CheckBitE(CBTYPE mask, uint32 n)
46 {
47    return ((mask & (1ui32 << (n-1ui32))) != 0);
48 }

Generated Assembly (Release Build, Unoptimized, CBTYPE: uint32, INLINE: )
Compiler: VC++ 2010, Intrinsics: Off, Whole Program Optimization: Off.

// A
; Line 16
push ebp
mov ebp, esp
; Line 17
mov ecx, DWORD PTR _n$[ebp]
sub ecx, 1
mov eax, 1
shl eax, cl
and eax, DWORD PTR _mask$[ebp]
neg eax
sbb eax, eax
neg eax
; Line 18
pop ebp
ret 8

// B
; Line 23
push ebp
mov ebp, esp
push ecx
; Line 24
mov DWORD PTR _one$[ebp], 1
; Line 25
mov ecx, DWORD PTR _n$[ebp]
sub ecx, 1
mov eax, 1
shl eax, cl
and eax, DWORD PTR _mask$[ebp]
neg eax
sbb eax, eax
neg eax
; Line 26
mov esp, ebp
pop ebp
ret 8

// C
; Line 31
push ebp
mov ebp, esp
; Line 32
mov ecx, DWORD PTR _n$[ebp]
sub ecx, 1
mov eax, 1
shl eax, cl
and eax, DWORD PTR _mask$[ebp]
neg eax
sbb eax, eax
neg eax
; Line 33
pop ebp
ret 8

// D
; Line 38
push ebp
mov ebp, esp
push ecx
; Line 39
mov ecx, DWORD PTR _n$[ebp]
sub ecx, 1
mov eax, 1
shl eax, cl
mov DWORD PTR _bit$[ebp], eax
; Line 40
mov eax, DWORD PTR _mask$[ebp]
and eax, DWORD PTR _bit$[ebp]
neg eax
sbb eax, eax
neg eax
; Line 41
mov esp, ebp
pop ebp
ret 8

//E.
; Line 46
push ebp
mov ebp, esp
; Line 47
mov ecx, DWORD PTR _n$[ebp]
sub ecx, 1
mov eax, 1
shl eax, cl
and eax, DWORD PTR _mask$[ebp]
neg eax
sbb eax, eax
neg eax
; Line 48
pop ebp
ret 8

[toc] | [prev] | [next] | [standalone]

#6759 — Re: Integer promotions, conversions, coercions and templates :( (Conclusion)

I opted for a preprocessor macro approach (I used the "super macro" 
technique) to implement the actual code alluded to by the example. I feel 
that aberrating the algorithm with C++-isms to make up for the 
deficiencies in the language is an inferior solution to the macro 
approach. Remember, that the example was not the actual code (the actual 
code is a class and the example is indicative of one of the methods of 
that class), and that the example suffers even more ills caused by the 
inferior/deficient/incorrect C++ type system. Note that the point was to 
generate 4 different definitions of the class (function, in the example) 
for use and not meant to be a template or macro to be used directly.

Here's a stab at a macro (non "super macro") for the example function 
which won't work because the compiler won't be able to decide on which 
overload to use:

#define DecCheckBit(T, S, W)                                        \
inline bool CheckBit(T & mask, uint32 n)                         \
{ 
\
   Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
   return ( (mask & (S << (n-1ui32)) ) != 0);                      \
}

DecCheckBit(uint8, 1ui8, 8)
DecCheckBit(uint16, 1ui16, 16)
DecCheckBit(uint32, 1ui32, 32)
DecCheckBit(uint64, 1ui64, 64)

Non-overload versions can be had (in place of the above) with 
introduction of another macro to generate unique functions instead of 
overloaded ones:

#define CheckBit(T) CheckBit_##T

#define DecCheckBit(T, S, W)                                        \
inline bool CheckBit(T)(T & mask, uint32 n)                     \
{ 
\
   Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
   return ( (mask & (S << (n-1ui32)) ) != 0);                      \
}

The above examples use assertion but that must be changed to an 
exception, and the suffixes used are not the standard suffixes. Finally, 
I didn't test the above.


Conclusions

The C++ template system cannot fully replace preprocessor techniques.
The C++ type system sucks.
The above 2 things make C++ tedious to use and difficult to learn. 

[toc] | [prev] | [next] | [standalone]

#6760 — Re: Integer promotions, conversions, coercions and templates :( (Conclusion)

On 06/15/11 11:35 AM, MikeP wrote:
> I opted for a preprocessor macro approach (I used the "super macro"
> technique) to implement the actual code alluded to by the example. I feel
> that aberrating the algorithm with C++-isms to make up for the
> deficiencies in the language is an inferior solution to the macro
> approach. Remember, that the example was not the actual code (the actual
> code is a class and the example is indicative of one of the methods of
> that class), and that the example suffers even more ills caused by the
> inferior/deficient/incorrect C++ type system. Note that the point was to
> generate 4 different definitions of the class (function, in the example)
> for use and not meant to be a template or macro to be used directly.

What your example really suffered from was your unwillingness to use the 
facilities offered by the language.

> Here's a stab at a macro (non "super macro") for the example function
> which won't work because the compiler won't be able to decide on which
> overload to use:
>
> #define DecCheckBit(T, S, W)                                        \
> inline bool CheckBit(T&  mask, uint32 n)                         \
> {
> \
>     Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
>     return ( (mask&  (S<<  (n-1ui32)) ) != 0);                      \
> }
>
> DecCheckBit(uint8, 1ui8, 8)
> DecCheckBit(uint16, 1ui16, 16)
> DecCheckBit(uint32, 1ui32, 32)
> DecCheckBit(uint64, 1ui64, 64)

So a macro using non-standard suffixes and requiring the type to be 
explicitly specified is superior a template where the type can be 
deduced by the compiler?

> Non-overload versions can be had (in place of the above) with
> introduction of another macro to generate unique functions instead of
> overloaded ones:
>
> #define CheckBit(T) CheckBit_##T
>
> #define DecCheckBit(T, S, W)                                        \
> inline bool CheckBit(T)(T&  mask, uint32 n)                     \
> {
> \
>     Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
>     return ( (mask&  (S<<  (n-1ui32)) ) != 0);                      \
> }
>
> The above examples use assertion but that must be changed to an
> exception, and the suffixes used are not the standard suffixes. Finally,
> I didn't test the above.

There's a glowing recommendation.

> Conclusions
>
> The C++ template system cannot fully replace preprocessor techniques.

No one said it does.  There are a small number of cases where a macro is 
the only solution and few if any where it is a better solution.  This 
isn't one of them.

> The C++ type system sucks.

How?

> The above 2 things make C++ tedious to use and difficult to learn.

Not at all.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#6766 — Re: Integer promotions, conversions, coercions and templates :( (Conclusion)

Ian Collins wrote:
> On 06/15/11 11:35 AM, MikeP wrote:
>> I opted for a preprocessor macro approach (I used the "super macro"
>> technique) to implement the actual code alluded to by the example. I
>> feel that aberrating the algorithm with C++-isms to make up for the
>> deficiencies in the language is an inferior solution to the macro
>> approach. Remember, that the example was not the actual code (the
>> actual code is a class and the example is indicative of one of the
>> methods of that class), and that the example suffers even more ills
>> caused by the inferior/deficient/incorrect C++ type system. Note
>> that the point was to generate 4 different definitions of the class
>> (function, in the example) for use and not meant to be a template or
>> macro to be used directly.
>
> What your example really suffered from was your unwillingness to use
> the facilities offered by the language.

At first it looked like a good idea because it was brief enough. On 
further analysis, though, I realized that compromising the algorithm was 
not prudent (for a number of reasons).

>
>> Here's a stab at a macro (non "super macro") for the example function
>> which won't work because the compiler won't be able to decide on
>> which overload to use:
>>
>> #define DecCheckBit(T, S, W)                                        \
>> inline bool CheckBit(T&  mask, uint32 n)                         \
>> {
>> \
>>     Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
>>     return ( (mask&  (S<<  (n-1ui32)) ) != 0);                      \
>> }
>>
>> DecCheckBit(uint8, 1ui8, 8)
>> DecCheckBit(uint16, 1ui16, 16)
>> DecCheckBit(uint32, 1ui32, 32)
>> DecCheckBit(uint64, 1ui64, 64)
>
> So a macro using non-standard suffixes

While I didn't/don't use the standard suffixes,  I see no reason why they 
couldn't be used.

> and requiring the type to be
> explicitly specified is superior a template where the type can be
> deduced by the compiler?

Avoid compiler "black magic" is many times beneficial. Think "explicit" 
rather than "implicit". In this case, I would say that is clearly so.

>
>> Non-overload versions can be had (in place of the above) with
>> introduction of another macro to generate unique functions instead of
>> overloaded ones:
>>
>> #define CheckBit(T) CheckBit_##T
>>
>> #define DecCheckBit(T, S, W)                                        \
>> inline bool CheckBit(T)(T&  mask, uint32 n)                     \
>> {
>> \
>>     Assert((n ge 1) and (n le W), ArgOutOfRangeError, "n")\
>>     return ( (mask&  (S<<  (n-1ui32)) ) != 0);                      \
>> }
>>
>> The above examples use assertion but that must be changed to an
>> exception, and the suffixes used are not the standard suffixes.
>> Finally, I didn't test the above.
>
> There's a glowing recommendation.

I just wanted to give anyone interested a starting point for further 
investigation if they wanted it. I no longer have the dilemma which 
prompted me to start this thread.

>
>> Conclusions
>>
>> The C++ template system cannot fully replace preprocessor techniques.
>
> No one said it does.  There are a small number of cases where a macro
> is the only solution and few if any where it is a better solution. This 
> isn't one of them.

Indeed it is one, to me, that's why I rejected any of the many template 
approaches. That there are so many, probably indicates something is 
wrong.

>
>> The C++ type system sucks.
>
> How?

Many ways, and this example shows some of them. It's a good question for 
you to answer to show that you recognize the C++ shortcomings and are 
able to objectively address them.

>
>> The above 2 things make C++ tedious to use and difficult to learn.
>
> Not at all.

Relative to a language that is cohesive in it's mechanisms, the above is 
true. Because the tediousness and difficulty is unnecessary, the above is 
true. Of course, anyone who puts C++ on a pedestal is apt to call any 
assessment of the language that is other than a glowing one, blasphemy. 

[toc] | [prev] | [next] | [standalone]

#6762 — Re: Integer promotions, conversions, coercions and templates :( (Conclusion)

On 15 juin, 01:35, "MikeP" <mp011...@some.org> wrote:
> I opted for a preprocessor macro approach (I used the "super macro"
> technique) to implement the actual code alluded to by the example. I feel
> that aberrating the algorithm with C++-isms to make up for the
> deficiencies in the language is an inferior solution to the macro
> approach.

AFAIS many solutions have been proposed. Clearly stating the desired
result would have helped.

> Remember, that the example was not the actual code (the actual
> code is a class and the example is indicative of one of the methods of
> that class), and that the example suffers even more ills caused by the
> inferior/deficient/incorrect C++ type system. Note that the point was to
> generate 4 different definitions of the class (function, in the example)
> for use and not meant to be a template or macro to be used directly.

You can use - not yet standard - static_assert() and - tr1 standard -
is_unsigned to limit the range of template parameter type:

template <typename T, unsigned int W = numeric_limit<T>::digits >
bool CheckBit(T& mask, unsigned n)
{
  static_assert( is_integral<T>::value && is_unsigned<T>::value );
  // assert n in range
  const T mask_n = T(1) << (n-1ui32);
  return mask & mask_n != 0;
}

And use your super macro for generating the
inline bool CheckBit8(uin8& mask, unsigned n)
{
  return CheckBit<uint8,8>(mask,n)
}
...

Better to put as little as possible in the macro.

> Here's a stab at a macro (non "super macro") for the example function
> which won't work because the compiler won't be able to decide on which
> overload to use:

Well, it will fail on signed type since you are using non-const
parameter by reference.
But, it shouldn't fail on unsigned type.

[snip - code]

> Conclusions
>
> The C++ template system cannot fully replace preprocessor techniques.

Well, it cannot generate new class/function name, cannot generate a
switch/case and cannot transform a parameter into its string
equivalent.

AFAIK whose are the only cases where MACRO are really needed.

> The C++ type system sucks.

It is a security. Some prefer to drive without seatbelt.

> The above 2 things make C++ tedious to use and difficult to learn.

--
Michael

[toc] | [prev] | [next] | [standalone]

#6767 — Re: Integer promotions, conversions, coercions and templates :( (Conclusion)

Michael DOUBEZ wrote:
> On 15 juin, 01:35, "MikeP" <mp011...@some.org> wrote:
>> I opted for a preprocessor macro approach (I used the "super macro"
>> technique) to implement the actual code alluded to by the example. I
>> feel that aberrating the algorithm with C++-isms to make up for the
>> deficiencies in the language is an inferior solution to the macro
>> approach.
>
> AFAIS many solutions have been proposed.

All rejected, in the end though.

> Clearly stating the desired
> result would have helped.

Surely it was clear that what desired was a "template" to generate a very 
finite set of bit field classes. Efficiency counts for such. If elegance 
of implementation surfaced as another requirement (indeed, that made the 
macro approach trump the template approaches offered, in the end), so be 
it. I think that this is a good case study.

>
>> Remember, that the example was not the actual code (the actual
>> code is a class and the example is indicative of one of the methods
>> of that class), and that the example suffers even more ills caused
>> by the inferior/deficient/incorrect C++ type system. Note that the
>> point was to generate 4 different definitions of the class
>> (function, in the example) for use and not meant to be a template or
>> macro to be used directly.
>
> You can use - not yet standard - static_assert() and - tr1 standard -
> is_unsigned to limit the range of template parameter type:
>
> template <typename T, unsigned int W = numeric_limit<T>::digits >
> bool CheckBit(T& mask, unsigned n)
> {
>  static_assert( is_integral<T>::value && is_unsigned<T>::value );
>  // assert n in range
>  const T mask_n = T(1) << (n-1ui32);
>  return mask & mask_n != 0;
> }

How is that more clear than using zero and the width of the unsigned 
integer type in the assertion?

(Aside: I have a problem with succumbing to "T(1)"  instead of "1uiXX" 
just to get type consistency, that's why I like the macro better).

>
> And use your super macro for generating the
> inline bool CheckBit8(uin8& mask, unsigned n)
> {
>  return CheckBit<uint8,8>(mask,n)
> }
> ...
>
> Better to put as little as possible in the macro.

I have used the "generate unique names with a macro for macro-based 
templates so much though, that it is a well-tested and accepted 
technique.

>
>> Here's a stab at a macro (non "super macro") for the example function
>> which won't work because the compiler won't be able to decide on
>> which overload to use:
>
> Well, it will fail on signed type since you are using non-const
> parameter by reference.

It should be const for the example.

> But, it shouldn't fail on unsigned type.

Oh? You don't think that overloading a function on only all of the 
unsigned integer types will be a problem?

>
> [snip - code]
>
>> Conclusions
>>
>> The C++ template system cannot fully replace preprocessor techniques.
>
> Well, it cannot generate new class/function name,

That is DOES do, under the covers.

> cannot generate a
> switch/case and cannot transform a parameter into its string
> equivalent.

It looks like an oversight (problem unaddressed) to design a generic type 
mechanism and not address literals within that mechanism. I think that 
pretty much characterizes the issue in the use case scenario in this 
thread.

>
> AFAIK whose are the only cases where MACRO are really needed.
>
>> The C++ type system sucks.
>
> It is a security. Some prefer to drive without seatbelt.

It's baggage from C.

>
>> The above 2 things make C++ tedious to use and difficult to learn. 

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c++

csiph-web