home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c++.moderated      Moderated discussion of C++ superhackery      33,346 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 32,401 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: Type-traits may have a hole as far a   
   10 Jun 12 11:42:31   
   
   14af8d89   
   From: daniel.kruegler@googlemail.com   
      
   Am 10.06.2012 19:40, schrieb Mathias Gaunard:   
   > On 10 juin, 07:02, Daryle Walker  wrote:   
   >   
   >> The problem for us is that there is NO type-trait class template   
   >> that covers explicit conversions that only have the static_cast   
   >> operator as their only path (besides C-casts).  We should add this,   
   >> and the trivial & no-throw variants, to the TS2 (or whatever we're   
   >> calling the next minor update to C++).   
   >   
   > Or maybe the enum/integer conversion should allow C-style casts and   
   > not just static_cast.   
      
   I disagree with that suggestion. Enumeration types are not integral   
   types, they are user-defined types and it is IMO a good thing that you   
   cannot convert integral types to them without static_cast. Scoped enum   
   types more consistently also require a static_cast to convert them back   
   to integral types as well.   
      
   > This is the only conversion that's different from the rest, and it   
   > just hurts generic code for no good reason.   
      
   It depends what measure of "rest" you take. Surely you also need a   
   static_cast for void* to object pointer conversions, for derived to base   
   pointer/reference conversions and for the reversed conversions involving   
   pointer to member types. Finally a static_cast is required to cast from   
   lvalue references to rvalue references.   
      
   I can understand that you consider above cases as different from   
   enum-integral conversions because enumeration types can be considered as   
   "arithmetic values". Personally I consider them as "type-stronger"   
   values, because they are user-defined and because you can also provide   
   user-defined operators for them.   
      
   Greetings from Bremen,   
      
   Daniel Krügler   
      
      
      
      
   --   
         [ See http://www.gotw.ca/resources/clcm.htm for info about ]   
         [ comp.lang.c++.moderated.    First time posters: Do this! ]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca