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


Groups > comp.lang.c++ > #70318

Re: enum type in template declaration

From Paavo Helde <myfirstname@osa.pri.ee>
Newsgroups comp.lang.c++
Subject Re: enum type in template declaration
Date 2019-12-06 20:29 +0200
Organization A noiseless patient Spider
Message-ID <qse6ma$1j7$1@dont-email.me> (permalink)
References <qsbvs3$81l$1@dont-email.me> <qscii5$5an$1@dont-email.me> <qsdgou$paa$1@dont-email.me> <qsdib1$2j6$1@dont-email.me> <qsdv4a$fa2$1@dont-email.me>

Show all headers | View raw


On 6.12.2019 18:20, Soviet_Mario wrote:
> Il 06/12/19 13:42, Paavo Helde ha scritto:
>>
>> What you wrote was basically correct syntax (after commenting out "etc
>> etc"). This compiles fine:
>>
>> enum RestrictedValues { A = 1, B = 2, C = 4, D = 8 };
>>
>> template <RestrictedValues ttVal> class SizedField
>> {
>> private:
>>      unsigned char zzArray[ttVal];
>>
>>
>> public:
>>
>>      //etc etc
>>
>> };
>>
>> int main() {
>>      SizedField<B> foo;
>> }
>>
>
> yes but would such code protect me from writing
>
>
> template <5> class SizedField; ? Would the compiler check that 5 is not
> a legal value of the enum ?

Yes, it will check. Why don't you try it out by yourself?

num RestrictedValues { A = 1, B = 2, C = 4, D = 8 };

template <RestrictedValues ttVal> class SizedField
{
private:
	unsigned char zzArray[ttVal];


public:

	//etc etc

};

int main() {
	SizedField<3> foo;
}

1>main.cpp
1>d:\test\consoletestvs2017\consoletestvs2017\main.cpp(16): error C2440: 
'specialization': cannot convert from 'int' to 'RestrictedValues'
1>d:\test\consoletestvs2017\consoletestvs2017\main.cpp(16): note: 
Conversion to enumeration type requires an explicit cast (static_cast, 
C-style cast or function-style cast)
1>d:\test\consoletestvs2017\consoletestvs2017\main.cpp(16): error C2973: 
'SizedField': invalid template argument 'int'
1>d:\test\consoletestvs2017\consoletestvs2017\main.cpp(4): note: see 
declaration of 'SizedField'

However, 'SizedField<RestrictedValues(3)> foo;' compiles. I would not 
worry about that, in C++ one can always find ways to shoot himself.

>
> If so, okay ...
>
>
> Oh, but BTW, what "helper" functions about run-time INTROSPECTION are
> more or less standard ?
>
>
> I've found some is_enum<EnumType> (), is_array<typename> () and so.
>
> But a simple function like : bool is_of_type <typename> ()
>
> in other languages such operators are named like "TypeOf" (or typename,
> also a string representation could be usefull)

C++ is pretty statically typed, so you typically do not need things like 
TypeOf to find out the type at run time. For polymorphic types there is 
typeid() though which is similar, and also provides name() (which is not 
guaranteed to be useful).

>
> This question is for a concrete case.
> I'm  trying to build a 2D table container not particularly generic : it
> supports just two type of contained items, either double either a "fixed
> size string", but I'm not sure I'd be able to write really generic
> functions as the two basic types contain some equivalent operators,
> constructors and comparison op, but also some semantically different
> accessors for higher level function on a container.
>
> So I'd appreciate some way a container could look inside himself (at
> runtime) and be aware of its type and call proper specialized functions
> where the syntax are not equivalent and I cannot rely only on overload
> for automatic selection of the best fit, or even in case I have to
> choose to MIX data, thing that will end in ambiguity, as the two types
> (fixedstrings and double) are largely convertible and interchangeable,
> so a generic function with identical signatures could not know what is
> the best to be called)

You have to make up your mind if you have the type (double or string) 
fixed at compile time or at run time. If at compile time, then there is 
no need for the container to check the type at run time, as the type was 
already fixed at the compile time and cannot change. E.g. a 
std::vector<double> does not need to check at run-time if its elements 
have suddenly turned into strings.

If the item type only becomes known only at run time, then it most 
probably means you have some variant type. For this custom variant type 
there are no overloaded functions present, you have to write them 
yourself, and there you have to figure out the correct type at run-time 
and act accordingly.

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-05 23:20 +0100
  Re: enum type in template declaration James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-05 22:39 -0500
    Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-06 13:15 +0100
      Re: enum type in template declaration Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-06 14:42 +0200
        Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-06 17:20 +0100
          Re: enum type in template declaration Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-06 20:29 +0200
            Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-06 22:42 +0100
              Re: enum type in template declaration Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-07 00:51 +0200
                Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-07 18:54 +0100
      Re: enum type in template declaration Öö Tiib <ootiib@hot.ee> - 2019-12-06 06:00 -0800
      Re: enum type in template declaration James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-06 09:56 -0500
      Re: enum type in template declaration Manfred <noname@add.invalid> - 2019-12-06 15:56 +0100
  Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-06 18:43 +0100
  Re: enum type in template declaration saturnman2008@gmail.com - 2019-12-07 01:53 -0800
    Re: enum type in template declaration Soviet_Mario <SovietMario@CCCP.MIR> - 2019-12-07 18:57 +0100

csiph-web