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 3 of 3 — ← Prev page 1 2 [3]

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

On 15 juin, 16:17, "MikeP" <mp011...@some.org> wrote:
> 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.

From experience, I find the super macro approach less elegant; reading
inside a macro definition is quite a pain. And the functions are not
caught by code analyzers.

>
> >> 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?

The static assert ensures the range of template type parameters is
limited to unsigned integral type.

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

Funny how c++ literal constants where designed for avoiding writing
the type and that they would be now required.

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

And one I use extensively together with code generation of the super
macro. And even after two years of using it, I find it unclear, hard
to debug and a pain to read.

> >> 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?

Not if you forbid the overload on the signed types (my making them
private by example).
Note that static_assert() makes the compilation fails on signed types.

Do you see any other 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.

What syntax would you propose ?


--
Michael

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

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

Michael DOUBEZ wrote:
> On 15 juin, 16:17, "MikeP" <mp011...@some.org> wrote:
>> 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.
>
> From experience, I find the super macro approach less elegant; reading
> inside a macro definition is quite a pain. And the functions are not
> caught by code analyzers.

It's for precise usage, not general usage in place of templates.

>
>>
>>>> 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?
>
> The static assert ensures the range of template type parameters is
> limited to unsigned integral type.

Too much machinery for such a simple need. Too obfuscating also.

>
>> (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).
>
> Funny how c++ literal constants where designed for avoiding writing
> the type and that they would be now required.

The underlying type system does not play nice with the things sitting on 
top of it.

>
>>> 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.
>
> And one I use extensively together with code generation of the super
> macro. And even after two years of using it, I find it unclear, hard
> to debug and a pain to read.

Don't know what to tell ya. It works great for me. Nary a problem. Super 
macros allow stepping into and debugging whereas a traditional macro (all 
on one line with line continuation chars) are hard to debug. I probably 
have a more evolved way of handling the issues.

>>> 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?
>
> Not if you forbid the overload on the signed types (my making them
> private by example).
> Note that static_assert() makes the compilation fails on signed types.

Signed types are not an issue in this case, per se. Implicit 
conversions/coercions/promotions are the issue in regards to overloaded 
functions.

>> 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.
>
> What syntax would you propose ?

I have a short-term solution (macros). While the issue should probably be 
addressed, it can't really be fixed, only band-aided over. Perhaps 
something that allows templates to have some text-substitution 
capabilities is in order. Consider:

template <typename T>
class MyClass
{
    T x;

    public:
    T To##T(){ return x; }
};

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

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

On 16 juin, 16:45, "MikeP" <mp011...@some.org> wrote:
> Michael DOUBEZ wrote:
> > On 15 juin, 16:17, "MikeP" <mp011...@some.org> wrote:
> >> 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.
>
> > From experience, I find the super macro approach less elegant; reading
> > inside a macro definition is quite a pain. And the functions are not
> > caught by code analyzers.
>
> It's for precise usage, not general usage in place of templates.

For now.

> >>>> 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?
>
> > The static assert ensures the range of template type parameters is
> > limited to unsigned integral type.
>
> Too much machinery for such a simple need. Too obfuscating also.

True. I would have prefered concepts but AFAIS we won't get them for
another decade now.

> >> (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).
>
> > Funny how c++ literal constants where designed for avoiding writing
> > the type and that they would be now required.
>
> The underlying type system does not play nice with the things sitting on
> top of it.
>
> >>> 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.
>
> > And one I use extensively together with code generation of the super
> > macro. And even after two years of using it, I find it unclear, hard
> > to debug and a pain to read.
>
> Don't know what to tell ya. It works great for me. Nary a problem.

We don't have the same problem space.

> Super
> macros allow stepping into and debugging whereas a traditional macro (all
> on one line with line continuation chars) are hard to debug. I probably
> have a more evolved way of handling the issues.

The tools available are a bit dated but I didn't expect a debugger
could step into a macro definition.

> >>> 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?
>
> > Not if you forbid the overload on the signed types (my making them
> > private by example).
> > Note that static_assert() makes the compilation fails on signed types.
>
> Signed types are not an issue in this case, per se. Implicit
> conversions/coercions/promotions are the issue in regards to overloaded
> functions.

Could you give me a failing case/scenario ?

> >> 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.
>
> > What syntax would you propose ?
>
> I have a short-term solution (macros). While the issue should probably be
> addressed, it can't really be fixed, only band-aided over. Perhaps
> something that allows templates to have some text-substitution
> capabilities is in order.

Yes. That and iterating over the members, getting a meaningful name
identifier. In brief, compile time reflexion/introspection.

--
Michael

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

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

Michael DOUBEZ wrote:

>>> From experience, I find the super macro approach less elegant;
>>> reading inside a macro definition is quite a pain. And the
>>> functions are not caught by code analyzers.
>>
>> It's for precise usage, not general usage in place of templates.
>
> For now.

Until when?

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

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

On 17 juin, 14:58, "MikeP" <mp011...@some.org> wrote:
> Michael DOUBEZ wrote:
> >>> From experience, I find the super macro approach less elegant;
> >>> reading inside a macro definition is quite a pain. And the
> >>> functions are not caught by code analyzers.
>
> >> It's for precise usage, not general usage in place of templates.
>
> > For now.
>
> Until when?

What I mean is once a tool is in use, there is the temptation for
others to (mis)use it.
Once, it becomes common practice, in the team culture, there is no way
to stop it.


--
Michael

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

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

Michael DOUBEZ wrote:
> On 17 juin, 14:58, "MikeP" <mp011...@some.org> wrote:
>> Michael DOUBEZ wrote:
>>>>> From experience, I find the super macro approach less elegant;
>>>>> reading inside a macro definition is quite a pain. And the
>>>>> functions are not caught by code analyzers.
>>
>>>> It's for precise usage, not general usage in place of templates.
>>
>>> For now.
>>
>> Until when?
>
> What I mean is once a tool is in use, there is the temptation for
> others to (mis)use it.
> Once, it becomes common practice, in the team culture, there is no way
> to stop it.

Kids should not play with knives. If the "team" lacks discipline, or the 
management lacks capability or effectiveness, isn't the project doomed at 
the onset? All programming constructs can be abused. Banning constructs 
or techniques is not the solution, in general. The key is judicious use 
(but that is not to say that banning isn't ever desireable). I try to 
program defensively in cognizance of the future which surely will be one 
without C++ in it (for me), so I don't want a "damn constructor in every 
freekin' line of code". "Software maintenance and evolution and 
lifetime", to me, has cross-language concerns. 

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

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

Michael DOUBEZ wrote:

>>>>> 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?
>>
>>> The static assert ensures the range of template type parameters is
>>> limited to unsigned integral type.
>>
>> Too much machinery for such a simple need. Too obfuscating also.
>
> True. I would have prefered concepts but AFAIS we won't get them for
> another decade now.

IOW, never! (Because that is beyond C++'s lifespan potential).


>>>>> 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.
>>
>>> And one I use extensively together with code generation of the super
>>> macro. And even after two years of using it, I find it unclear, hard
>>> to debug and a pain to read.
>>
>> Don't know what to tell ya. It works great for me. Nary a problem.
>
> We don't have the same problem space.

I don't see that as an issue, but I'm assuming you mean that proverbial 
"large scale project". The issue is appropriate application of the 
technique. Sure, if you over-use it instead of just using it when 
necessary, problems may ensue (especially with no ancillary management of 
the development process that recognizes various techniques instead of The 
Big One). No need to continue this assumptive dialog though. Just a few 
thoughts that immediately came to mind.

>
>> Super
>> macros allow stepping into and debugging whereas a traditional macro
>> (all on one line with line continuation chars) are hard to debug. I
>> probably have a more evolved way of handling the issues.
>
> The tools available are a bit dated but I didn't expect a debugger
> could step into a macro definition.

That is what "super macros" afford you. It's their biggest selling point. 
Perhaps you don't know what I meant with "super macro"? A web search will 
probably find it for you. But in short, the technique is such that the 
parameterized code is put in a separate include file and the inclusion of 
that file is wrapped with desired parameter values. For example:

#define T uint32
#include <myclasstemplate.h>
#undef T // Undefines can be put in the include file at the bottom.

The above will define whatever is in the include file but with the Ts as 
uint32s. There are no line continuation characters in the supermacro in 
myclasstemplate.h and that allows the compiler to step through instances 
of objects of the supermacro.


>
>>>>> 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?
>>
>>> Not if you forbid the overload on the signed types (my making them
>>> private by example).
>>> Note that static_assert() makes the compilation fails on signed
>>> types.
>>
>> Signed types are not an issue in this case, per se. Implicit
>> conversions/coercions/promotions are the issue in regards to
>> overloaded functions.
>
> Could you give me a failing case/scenario ?

Try the example and you are bound to run into problems. Overloading on 
integer types is perilous with C++.

>
>>>> 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.
>>
>>> What syntax would you propose ?
>>
>> I have a short-term solution (macros). While the issue should
>> probably be addressed, it can't really be fixed, only band-aided
>> over. Perhaps something that allows templates to have some
>> text-substitution capabilities is in order.
>
> Yes. That and iterating over the members, getting a meaningful name
> identifier. In brief, compile time reflexion/introspection.

Perhaps. I haven't thought much about that kind of thing other than 
recognizing, as in this example, that something is missing. 

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

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

On 17 juin, 15:17, "MikeP" <mp011...@some.org> wrote:
> Michael DOUBEZ wrote:
> >>>>> 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?
>
> >>> The static assert ensures the range of template type parameters is
> >>> limited to unsigned integral type.
>
> >> Too much machinery for such a simple need. Too obfuscating also.
>
> > True. I would have prefered concepts but AFAIS we won't get them for
> > another decade now.
>
> IOW, never! (Because that is beyond C++'s lifespan potential).

I disagree. We will need 2 years to get c++11 compliant compilers, 7
more years to get them main stream in production. Yet another 5 years
to get people trained using it and transfer it into the culture.

> >>>>> 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.
>
> >>> And one I use extensively together with code generation of the super
> >>> macro. And even after two years of using it, I find it unclear, hard
> >>> to debug and a pain to read.
>
> >> Don't know what to tell ya. It works great for me. Nary a problem.
>
> > We don't have the same problem space.
>
> I don't see that as an issue, but I'm assuming you mean that proverbial
> "large scale project".

I said problem space not problem scale.

In fact, IMHO the right solution would have been code generation but
that raised other problems such as variabilities specifications.

[snip]

>
> >> Super
> >> macros allow stepping into and debugging whereas a traditional macro
> >> (all on one line with line continuation chars) are hard to debug. I
> >> probably have a more evolved way of handling the issues.
>
> > The tools available are a bit dated but I didn't expect a debugger
> > could step into a macro definition.
>
> That is what "super macros" afford you. It's their biggest selling point.
> Perhaps you don't know what I meant with "super macro"? A web search will
> probably find it for you.

Actually, it did not but I have two of three techniques that may
correspond: a big macro with another macro name in parameter or
playing with includes files.

> But in short, the technique is such that the
> parameterized code is put in a separate include file and the inclusion of
> that file is wrapped with desired parameter values. For example:
>
> #define T uint32
> #include <myclasstemplate.h>
> #undef T // Undefines can be put in the include file at the bottom.

In my case, the parameters is the variable part. Different problem
space.

> The above will define whatever is in the include file but with the Ts as
> uint32s. There are no line continuation characters in the supermacro in
> myclasstemplate.h and that allows the compiler to step through instances
> of objects of the supermacro.

Nice to know. Thanks.

> >>>>> 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?
>
> >>> Not if you forbid the overload on the signed types (my making them
> >>> private by example).
> >>> Note that static_assert() makes the compilation fails on signed
> >>> types.
>
> >> Signed types are not an issue in this case, per se. Implicit
> >> conversions/coercions/promotions are the issue in regards to
> >> overloaded functions.
>
> > Could you give me a failing case/scenario ?
>
> Try the example and you are bound to run into problems. Overloading on
> integer types is perilous with C++.

True.

[snip]

--
Michael

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

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

Michael DOUBEZ wrote:
> On 17 juin, 15:17, "MikeP" <mp011...@some.org> wrote:
>> Michael DOUBEZ wrote:
>>>>>>> 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?
>>
>>>>> The static assert ensures the range of template type parameters is
>>>>> limited to unsigned integral type.
>>
>>>> Too much machinery for such a simple need. Too obfuscating also.
>>
>>> True. I would have prefered concepts but AFAIS we won't get them for
>>> another decade now.
>>
>> IOW, never! (Because that is beyond C++'s lifespan potential).
>
> I disagree.

That there will never be concepts in C++ or that C++'s life has less than 
10 years left?

> We will need 2 years to get c++11 compliant compilers, 7
> more years to get them main stream in production. Yet another 5 years
> to get people trained using it and transfer it into the culture.
>

>>>>>>> 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.
>>
>>>>> And one I use extensively together with code generation of the
>>>>> super macro. And even after two years of using it, I find it
>>>>> unclear, hard to debug and a pain to read.
>>
>>>> Don't know what to tell ya. It works great for me. Nary a problem.
>>
>>> We don't have the same problem space.
>>
>> I don't see that as an issue, but I'm assuming you mean that
>> proverbial "large scale project".
>
> I said problem space not problem scale.

"large scale projects" can be viewed as "a space".

>
> In fact, IMHO the right solution would have been code generation but
> that raised other problems such as variabilities specifications.
>
> [snip]
>
>>
>>>> Super
>>>> macros allow stepping into and debugging whereas a traditional
>>>> macro (all on one line with line continuation chars) are hard to
>>>> debug. I probably have a more evolved way of handling the issues.
>>
>>> The tools available are a bit dated but I didn't expect a debugger
>>> could step into a macro definition.
>>
>> That is what "super macros" afford you. It's their biggest selling
>> point. Perhaps you don't know what I meant with "super macro"? A web
>> search will probably find it for you.
>
> Actually, it did not

Here ya go: http://s11n.net/papers/supermacros_cpp.html

[toc] | [prev] | [standalone]

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

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

csiph-web