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 1 of 3  [1] 2 3  Next page →

#6449 — Integer promotions, conversions, coercions and templates :(

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.")
    return ((mask & ((T)1) << (n-((T)1))) != 0);
}

I wanted to use the appropriate integer type suffix as a template 
parameter to use on the 1's (don't know if I needed to though), but C++ 
templates won't allow that so I have the casts-to-T all over the place 
but I'm not sure if they are necessary. I made arg n a type T just to 
avoid fld and n being different unsigned integer types.

Is CheckBit correct? If not, can it be corrected? Can it be improved?

[toc] | [next] | [standalone]

#6451

On 06/ 9/11 10:09 AM, MikeP 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.")

Missing semicolon.

>      return ((mask&  ((T)1)<<  (n-((T)1))) != 0);
> }
>
> I wanted to use the appropriate integer type suffix as a template
> parameter to use on the 1's (don't know if I needed to though), but C++
> templates won't allow that so I have the casts-to-T all over the place
> but I'm not sure if they are necessary.

Why don't you just use

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

> I made arg n a type T just to
> avoid fld and n being different unsigned integer types.

fld?

> Is CheckBit correct? If not, can it be corrected? Can it be improved?

Test it!

-- 
Ian Collins

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

#6452

Ian Collins wrote:
> On 06/ 9/11 10:09 AM, MikeP 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.")
>
> Missing semicolon.

The Assert macro has it.

>
>>      return ((mask&  ((T)1)<<  (n-((T)1))) != 0);
>> }
>>
>> I wanted to use the appropriate integer type suffix as a template
>> parameter to use on the 1's (don't know if I needed to though), but
>> C++ templates won't allow that so I have the casts-to-T all over the
>> place but I'm not sure if they are necessary.
>
> Why don't you just use
>
>   const T one(1);
>   return (((mask & one) << (n-one)) != 0);

I don't know that it is better. It's a little prettier. I'll look at the 
generated assembly but why bother before determining whether both or 
either are valid or even necessary? Can I just use plain '1'? Will the 
compiler bit-shift against a 64-bit '1' without me helping it do so?

>
>> I made arg n a type T just to
>> avoid fld and n being different unsigned integer types.
>
> fld?

mask. (It was 'fld' prior to being 'mask').

>
>> Is CheckBit correct? If not, can it be corrected? Can it be improved?
>
> Test it!

Oh, I have and it does (well the code that the example herein is based on 
does, anyway), but I meant correct from an implementation standpoint, not 
from an algorithmic standpoint. There is a lot of potential stuff going 
on with integers and stuff, especially if you remove the casts. And what 
about across different compilers and platforms? 

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

#6457

Ian Collins wrote:
> On 06/ 9/11 10:09 AM, MikeP 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.")
>
> Missing semicolon.
>
>>      return ((mask&  ((T)1)<<  (n-((T)1))) != 0);
>> }
>>
>> I wanted to use the appropriate integer type suffix as a template
>> parameter to use on the 1's (don't know if I needed to though), but
>> C++ templates won't allow that so I have the casts-to-T all over the
>> place but I'm not sure if they are necessary.
>
> Why don't you just use
>
>   const T one(1);
>   return (((mask & one) << (n-one)) != 0);

Adds one move instruction to get '1' into 'one' (which is in a register) 
over the cast-to-T implementation (2 move instructions for 64-bit T), so 
I'd keep the ugly version. Using the suffix would be the way to write 
CheckBit if it wasn't a template:

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

I think it would be OK to use:

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

if I didn't want allow 64-bit masks on a 32-bit platform, but I do, so I 
need either your technique or the casts because templates don't allow 
using the integer literal suffixes. :(

I tried:

template <typename T, uint32 W, const char* S>
...

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

where 'S' s the suffix string, but though the char* parameter is allowed, 
it won't expand in the body of CheckBit (compiler thinks that 'S' is an 
identifier).

So this is a case where templates hose-up the algorithm, apparently.

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

#6471

On 06/ 9/11 12:13 PM, MikeP wrote:
> Ian Collins wrote:
>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>
>> Missing semicolon.
>>
>>>       return ((mask&   ((T)1)<<   (n-((T)1))) != 0);
>>> }
>>>
>>> I wanted to use the appropriate integer type suffix as a template
>>> parameter to use on the 1's (don't know if I needed to though), but
>>> C++ templates won't allow that so I have the casts-to-T all over the
>>> place but I'm not sure if they are necessary.
>>
>> Why don't you just use
>>
>>    const T one(1);
>>    return (((mask&  one)<<  (n-one)) != 0);
>
> Adds one move instruction to get '1' into 'one' (which is in a register)
> over the cast-to-T implementation (2 move instructions for 64-bit T), so
> I'd keep the ugly version. Using the suffix would be the way to write
> CheckBit if it wasn't a template:

Poor job on the compiler's part!

The function should optimise down to 0 or 1.

-- 
Ian Collins

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

#6487

Ian Collins wrote:
> On 06/ 9/11 12:13 PM, MikeP wrote:
>> Ian Collins wrote:
>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>>
>>> Missing semicolon.
>>>
>>>>       return ((mask&   ((T)1)<<   (n-((T)1))) != 0);
>>>> }
>>>>
>>>> I wanted to use the appropriate integer type suffix as a template
>>>> parameter to use on the 1's (don't know if I needed to though), but
>>>> C++ templates won't allow that so I have the casts-to-T all over
>>>> the place but I'm not sure if they are necessary.
>>>
>>> Why don't you just use
>>>
>>>    const T one(1);
>>>    return (((mask&  one)<<  (n-one)) != 0);
>>
>> Adds one move instruction to get '1' into 'one' (which is in a
>> register) over the cast-to-T implementation (2 move instructions for
>> 64-bit T), so I'd keep the ugly version. Using the suffix would be
>> the way to write CheckBit if it wasn't a template:
>
> Poor job on the compiler's part!
>
> The function should optimise down to 0 or 1.

The example is actually an inline method in a class, but even so, the 
compiler didn't inline it. Weird. (My example should have had the 
"inline" keyword on it also). My bad, I'm in debug mode with inlining 
overridden! I'll do the release version and repost later. (Still 
educational though from a learning-assembly and code generation 
perspective).

It does seem that templates are trumped by a preprocessor macro this 
time, for the macro does not require a change to the algorithm. Templates 
defficient? 

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

#6490

On Jun 9, 3:30 pm, "MikeP" <mp011...@some.org> wrote:
> Ian Collins wrote:
> > On 06/ 9/11 12:13 PM, MikeP wrote:
> >> Ian Collins wrote:
> >>> On 06/ 9/11 10:09 AM, MikeP 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.")
>
> >>> Missing semicolon.
>
> >>>>       return ((mask&   ((T)1)<<   (n-((T)1))) != 0);
> >>>> }
>
> >>>> I wanted to use the appropriate integer type suffix as a template
> >>>> parameter to use on the 1's (don't know if I needed to though), but
> >>>> C++ templates won't allow that so I have the casts-to-T all over
> >>>> the place but I'm not sure if they are necessary.
>
> >>> Why don't you just use
>
> >>>    const T one(1);
> >>>    return (((mask&  one)<<  (n-one)) != 0);
>
> >> Adds one move instruction to get '1' into 'one' (which is in a
> >> register) over the cast-to-T implementation (2 move instructions for
> >> 64-bit T), so I'd keep the ugly version. Using the suffix would be
> >> the way to write CheckBit if it wasn't a template:
>
> > Poor job on the compiler's part!
>
> > The function should optimise down to 0 or 1.
>
> The example is actually an inline method in a class, but even so, the
> compiler didn't inline it. Weird. (My example should have had the
> "inline" keyword on it also). My bad, I'm in debug mode with inlining
> overridden! I'll do the release version and repost later. (Still
> educational though from a learning-assembly and code generation
> perspective).
>
> It does seem that templates are trumped by a preprocessor macro this
> time, for the macro does not require a change to the algorithm. Templates
> defficient?

You are in debugging mode evaluating performance of compiler-generated
code? Worthless waste of time. Turn all optimizations that you plan to
use in production code on. Otherwise you get wrong impression what
compiler will really do.

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

#6496

Öö Tiib wrote:
> On Jun 9, 3:30 pm, "MikeP" <mp011...@some.org> wrote:
>> Ian Collins wrote:
>>> On 06/ 9/11 12:13 PM, MikeP wrote:
>>>> Ian Collins wrote:
>>>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>
>>>>> Missing semicolon.
>>
>>>>>> return ((mask& ((T)1)<< (n-((T)1))) != 0);
>>>>>> }
>>
>>>>>> I wanted to use the appropriate integer type suffix as a template
>>>>>> parameter to use on the 1's (don't know if I needed to though),
>>>>>> but C++ templates won't allow that so I have the casts-to-T all
>>>>>> over the place but I'm not sure if they are necessary.
>>
>>>>> Why don't you just use
>>
>>>>> const T one(1);
>>>>> return (((mask& one)<< (n-one)) != 0);
>>
>>>> Adds one move instruction to get '1' into 'one' (which is in a
>>>> register) over the cast-to-T implementation (2 move instructions
>>>> for 64-bit T), so I'd keep the ugly version. Using the suffix
>>>> would be the way to write CheckBit if it wasn't a template:
>>
>>> Poor job on the compiler's part!
>>
>>> The function should optimise down to 0 or 1.
>>
>> The example is actually an inline method in a class, but even so, the
>> compiler didn't inline it. Weird. (My example should have had the
>> "inline" keyword on it also). My bad, I'm in debug mode with inlining
>> overridden! I'll do the release version and repost later. (Still
>> educational though from a learning-assembly and code generation
>> perspective).
>>
>> It does seem that templates are trumped by a preprocessor macro this
>> time, for the macro does not require a change to the algorithm.
>> Templates defficient?
>
> You are in debugging mode evaluating performance of compiler-generated
> code?

No, read the post from the beginning. The post is about the "impedance 
mismatch" between templates and the C++ type system.

> Worthless waste of time. Turn all optimizations that you plan to
> use in production code on. Otherwise you get wrong impression what
> compiler will really do.

Reread what I wrote above! Geez, what an opportunist. 

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

#6498

On Jun 9, 4:45 pm, "MikeP" <mp011...@some.org> wrote:
> Tiib wrote:
> > On Jun 9, 3:30 pm, "MikeP" <mp011...@some.org> wrote:
> >> Ian Collins wrote:
> >>> On 06/ 9/11 12:13 PM, MikeP wrote:
> >>>> Ian Collins wrote:
> >>>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>
> >>>>> Missing semicolon.
>
> >>>>>> return ((mask& ((T)1)<< (n-((T)1))) != 0);
> >>>>>> }
>
> >>>>>> I wanted to use the appropriate integer type suffix as a template
> >>>>>> parameter to use on the 1's (don't know if I needed to though),
> >>>>>> but C++ templates won't allow that so I have the casts-to-T all
> >>>>>> over the place but I'm not sure if they are necessary.
>
> >>>>> Why don't you just use
>
> >>>>> const T one(1);
> >>>>> return (((mask& one)<< (n-one)) != 0);
>
> >>>> Adds one move instruction to get '1' into 'one' (which is in a
> >>>> register) over the cast-to-T implementation (2 move instructions
> >>>> for 64-bit T), so I'd keep the ugly version. Using the suffix
> >>>> would be the way to write CheckBit if it wasn't a template:
>
> >>> Poor job on the compiler's part!
>
> >>> The function should optimise down to 0 or 1.
>
> >> The example is actually an inline method in a class, but even so, the
> >> compiler didn't inline it. Weird. (My example should have had the
> >> "inline" keyword on it also). My bad, I'm in debug mode with inlining
> >> overridden! I'll do the release version and repost later. (Still
> >> educational though from a learning-assembly and code generation
> >> perspective).
>
> >> It does seem that templates are trumped by a preprocessor macro this
> >> time, for the macro does not require a change to the algorithm.
> >> Templates defficient?
>
> > You are in debugging mode evaluating performance of compiler-generated
> > code?
>
> No, read the post from the beginning. The post is about the "impedance
> mismatch" between templates and the C++ type system.
>
> > Worthless waste of time. Turn all optimizations that you plan to
> > use in production code on. Otherwise you get wrong impression what
> > compiler will really do.
>
> Reread what I wrote above! Geez, what an opportunist.

You better retry again. I see no differences in generated code if i
use inline template function or macro when checking a bit. So you do
something wrong. Geez what a noob.

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

#6516

Öö Tiib wrote:
> On Jun 9, 4:45 pm, "MikeP" <mp011...@some.org> wrote:
>> Tiib wrote:
>>> On Jun 9, 3:30 pm, "MikeP" <mp011...@some.org> wrote:
>>>> Ian Collins wrote:
>>>>> On 06/ 9/11 12:13 PM, MikeP wrote:
>>>>>> Ian Collins wrote:
>>>>>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>
>>>>>>> Missing semicolon.
>>
>>>>>>>> return ((mask& ((T)1)<< (n-((T)1))) != 0);
>>>>>>>> }
>>
>>>>>>>> I wanted to use the appropriate integer type suffix as a
>>>>>>>> template parameter to use on the 1's (don't know if I needed
>>>>>>>> to though), but C++ templates won't allow that so I have the
>>>>>>>> casts-to-T all over the place but I'm not sure if they are
>>>>>>>> necessary.
>>
>>>>>>> Why don't you just use
>>
>>>>>>> const T one(1);
>>>>>>> return (((mask& one)<< (n-one)) != 0);
>>
>>>>>> Adds one move instruction to get '1' into 'one' (which is in a
>>>>>> register) over the cast-to-T implementation (2 move instructions
>>>>>> for 64-bit T), so I'd keep the ugly version. Using the suffix
>>>>>> would be the way to write CheckBit if it wasn't a template:
>>
>>>>> Poor job on the compiler's part!
>>
>>>>> The function should optimise down to 0 or 1.
>>
>>>> The example is actually an inline method in a class, but even so,
>>>> the compiler didn't inline it. Weird. (My example should have had
>>>> the "inline" keyword on it also). My bad, I'm in debug mode with
>>>> inlining overridden! I'll do the release version and repost later.
>>>> (Still educational though from a learning-assembly and code
>>>> generation perspective).
>>
>>>> It does seem that templates are trumped by a preprocessor macro
>>>> this time, for the macro does not require a change to the
>>>> algorithm. Templates defficient?
>>
>>> You are in debugging mode evaluating performance of
>>> compiler-generated code?
>>
>> No, read the post from the beginning. The post is about the
>> "impedance mismatch" between templates and the C++ type system.
>>
>>> Worthless waste of time. Turn all optimizations that you plan to
>>> use in production code on. Otherwise you get wrong impression what
>>> compiler will really do.
>>
>> Reread what I wrote above! Geez, what an opportunist.
>
> You better retry again. I see no differences in generated code if i
> use inline template function or macro when checking a bit. So you do
> something wrong. Geez what a noob.

Learn to read. English not your 1st language? 

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

#6518

On 06/10/11 12:30 AM, MikeP wrote:
> Ian Collins wrote:
>> On 06/ 9/11 12:13 PM, MikeP wrote:
>>> Ian Collins wrote:
>>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>>>
>>>> Missing semicolon.
>>>>
>>>>>        return ((mask&    ((T)1)<<    (n-((T)1))) != 0);
>>>>> }
>>>>>
>>>>> I wanted to use the appropriate integer type suffix as a template
>>>>> parameter to use on the 1's (don't know if I needed to though), but
>>>>> C++ templates won't allow that so I have the casts-to-T all over
>>>>> the place but I'm not sure if they are necessary.
>>>>
>>>> Why don't you just use
>>>>
>>>>     const T one(1);
>>>>     return (((mask&   one)<<   (n-one)) != 0);
>>>
>>> Adds one move instruction to get '1' into 'one' (which is in a
>>> register) over the cast-to-T implementation (2 move instructions for
>>> 64-bit T), so I'd keep the ugly version. Using the suffix would be
>>> the way to write CheckBit if it wasn't a template:
>>
>> Poor job on the compiler's part!
>>
>> The function should optimise down to 0 or 1.
>
> The example is actually an inline method in a class, but even so, the
> compiler didn't inline it. Weird. (My example should have had the
> "inline" keyword on it also).

That's unnecessary in this case.

> My bad, I'm in debug mode with inlining overridden!

Oops...

> I'll do the release version and repost later. (Still
> educational though from a learning-assembly and code generation
> perspective).
>
> It does seem that templates are trumped by a preprocessor macro this
> time, for the macro does not require a change to the algorithm. Templates
> defficient?

What change to what algorithm?

-- 
Ian Collins

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

#6521

Ian Collins wrote:
> On 06/10/11 12:30 AM, MikeP wrote:
>> Ian Collins wrote:
>>> On 06/ 9/11 12:13 PM, MikeP wrote:
>>>> Ian Collins wrote:
>>>>> On 06/ 9/11 10:09 AM, MikeP 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.")
>>>>>
>>>>> Missing semicolon.
>>>>>
>>>>>>        return ((mask&    ((T)1)<<    (n-((T)1))) != 0);
>>>>>> }
>>>>>>
>>>>>> I wanted to use the appropriate integer type suffix as a template
>>>>>> parameter to use on the 1's (don't know if I needed to though),
>>>>>> but C++ templates won't allow that so I have the casts-to-T all
>>>>>> over the place but I'm not sure if they are necessary.
>>>>>
>>>>> Why don't you just use
>>>>>
>>>>>     const T one(1);
>>>>>     return (((mask&   one)<<   (n-one)) != 0);
>>>>
>>>> Adds one move instruction to get '1' into 'one' (which is in a
>>>> register) over the cast-to-T implementation (2 move instructions
>>>> for 64-bit T), so I'd keep the ugly version. Using the suffix
>>>> would be the way to write CheckBit if it wasn't a template:
>>>
>>> Poor job on the compiler's part!
>>>
>>> The function should optimise down to 0 or 1.
>>
>> The example is actually an inline method in a class, but even so, the
>> compiler didn't inline it. Weird. (My example should have had the
>> "inline" keyword on it also).
>
> That's unnecessary in this case.

It's necessary for a free function which the example is.

>
>> My bad, I'm in debug mode with inlining overridden!
>
> Oops...
>

Yeah. I was in a rush to see what your version looked like under the 
glass compared to the other one. I imagine they'll both expand to 
virtually nothing as you said (but I haven't looked at it yet).

>> I'll do the release version and repost later. (Still
>> educational though from a learning-assembly and code generation
>> perspective).
>>
>> It does seem that templates are trumped by a preprocessor macro this
>> time, for the macro does not require a change to the algorithm.
>> Templates defficient?
>
> What change to what algorithm?

(Please recognize the expressive liberty taken with the term "algorithm". 
I'm not afraid to let the context do most of the talking).

Templates cannot generate what the programmer would write:

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

with the appropriate suffix for the different width unsigned integers. 
But a macro can. (I know the suffixes aren't standard, but they probably 
should be (I've yet to check if VC++ accepts "ULL", cuz I always use the 
ones as shown above). Afterall, the committee standardizes common 
practice).

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

#6523

On 06/10/11 08:11 AM, MikeP wrote:
> Ian Collins wrote:
>> On 06/10/11 12:30 AM, MikeP wrote:
>>> Ian Collins wrote:
>>>>
>>>> The function should optimise down to 0 or 1.
>>>
>>> The example is actually an inline method in a class, but even so, the
>>> compiler didn't inline it. Weird. (My example should have had the
>>> "inline" keyword on it also).
>>
>> That's unnecessary in this case.
>
> It's necessary for a free function which the example is.

Not for a function template or a regular function that only appears in 
one compilation unit.

>>> It does seem that templates are trumped by a preprocessor macro this
>>> time, for the macro does not require a change to the algorithm.
>>> Templates defficient?
>>
>> What change to what algorithm?
>
> (Please recognize the expressive liberty taken with the term "algorithm".
> I'm not afraid to let the context do most of the talking).
>
> Templates cannot generate what the programmer would write:
>
> return ((mask&   1ui64<<  (n-1ui64)) != 0);
>
> with the appropriate suffix for the different width unsigned integers.
> But a macro can. (I know the suffixes aren't standard, but they probably
> should be (I've yet to check if VC++ accepts "ULL", cuz I always use the
> ones as shown above). Afterall, the committee standardizes common
> practice).

You are using prefixes, not suffixes!  Anyway, if you were using a macro 
you would have to have a parameter for the suffix.  In a template you 
have the type and as Öö Tiib pointed out else-thread, you only need one 
template parameter, which the compiler can deduce.

The standard suffixes are (from C99 6.4.4.1):

unsigned-suffix: one of u U
long-suffix: one of l L
long-long-suffix: one of ll LL

-- 
Ian Collins

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

#6524

Ian Collins wrote:
> On 06/10/11 08:11 AM, MikeP wrote:
>> Ian Collins wrote:
>>> On 06/10/11 12:30 AM, MikeP wrote:
>>>> Ian Collins wrote:
>>>>>
>>>>> The function should optimise down to 0 or 1.
>>>>
>>>> The example is actually an inline method in a class, but even so,
>>>> the compiler didn't inline it. Weird. (My example should have had
>>>> the "inline" keyword on it also).
>>>
>>> That's unnecessary in this case.
>>
>> It's necessary for a free function which the example is.
>
> Not for a function template or a regular function that only appears in
> one compilation unit.
>
>>>> It does seem that templates are trumped by a preprocessor macro
>>>> this time, for the macro does not require a change to the
>>>> algorithm. Templates defficient?
>>>
>>> What change to what algorithm?
>>
>> (Please recognize the expressive liberty taken with the term
>> "algorithm". I'm not afraid to let the context do most of the
>> talking). Templates cannot generate what the programmer would write:
>>
>> return ((mask&   1ui64<<  (n-1ui64)) != 0);
>>
>> with the appropriate suffix for the different width unsigned
>> integers. But a macro can. (I know the suffixes aren't standard, but
>> they probably should be (I've yet to check if VC++ accepts "ULL",
>> cuz I always use the ones as shown above). Afterall, the committee
>> standardizes common practice).
>
> You are using prefixes, not suffixes!

Nuh uh! "ui64" = suffix. Why would something appended to a literal be a 
prefix?

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

> In a
> template you have the type and as Öö Tiib pointed out else-thread,
> you only need one template parameter, which the compiler can deduce.

It's not worth pulling in the header for that. All I'm trying to do is 
avoid code duplication for 4 classes, but templates are fighting me. It 
can be done, of course, as shown above, it's just not elegant is all.

>
> The standard suffixes are (from C99 6.4.4.1):
>
> unsigned-suffix: one of u U
> long-suffix: one of l L
> long-long-suffix: one of ll LL

Too bad they are useless as template parameters. 

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

#6525

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 );

?
>> In a
>> template you have the type and as Öö Tiib pointed out else-thread,
>> you only need one template parameter, which the compiler can deduce.
>
> It's not worth pulling in the header for that. All I'm trying to do is
> avoid code duplication for 4 classes, but templates are fighting me. It
> can be done, of course, as shown above, it's just not elegant is all.

Pulling in a header?  isn't that what they are there for?

-- 
Ian Collins

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

#6535

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.

Well that's why I posted, to find all the alternatives. My immediate 
solution was to put the casts all over the place and avoid the integer 
issues. I find that anything less than being able to use the suffixes is 
less than elegant (but then C++ is NOT elegant, so that's neither here 
nor there), but then I'm picking nits (kind of).

>
>> 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)));
> }

I like that. I hope the T(1) will get "optimized" away even without 
advanced optimization settings turned on (as I would like to avoid 
advanced optimization settings (yes, I have many rules!)). What about the 
different operand types to operator <<? I was trying to avoid thinking 
about the C++ integer rules by making everything the same type (sometimes 
you need a Language Lawyer!).

You forgot to check for n > 0 in the assert, as I am doing 1-based bit 
indexing (note "n-1" instead of  just "n").

I already mentioned that an exception is proper rather than an assert 
(public function) which brings up another issue: something called 
"CheckBit" really needs the utmost in efficiency (you forgot the "inline" 
keyword), so are exceptions going to muck that up?

Finally, about your implementation above, it doesn't use the truth 
comparison and somewhere way back when I decided to use that (the 
function is based upon long-ago-developed macros I used in C), but it 
escapes me as to why. Probably to make the expression match the bool 
return type explicitly for clarity.

>
> bool result = CheckBit( 42ull, 4 );
>
> ?
>>> In a
>>> template you have the type and as Öö Tiib pointed out else-thread,
>>> you only need one template parameter, which the compiler can deduce.
>>
>> It's not worth pulling in the header for that. All I'm trying to do
>> is avoid code duplication for 4 classes, but templates are fighting
>> me. It can be done, of course, as shown above, it's just not elegant
>> is all.
>
> Pulling in a header?  isn't that what they are there for?

Sure, if you're into that kind of thing. ;) I have an aversion rule that 
goes something like, "If I can build it, don't pull it in via a header!". 
I am using custom startup code which does not initialize the standard 
library. (Don't even ask why about all this, as it is a separate topic 
for sure). 

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

#6536

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 );

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

#6539

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. ;)

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

#6544

Öö 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"? 

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

#6548

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.

Not inline since "inline" keyword is only a hint to compiler. Depends
on other options if it is reasonable to add or not. "CheckBit( 42ull,
4 )" is usually optimized into "true" by modern compilers.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web