From: daniel.kruegler@googlemail.com   
      
   On 2012-12-14 01:16, Edmund Kapusniak wrote:   
   >    I have a question about the types in stdint.h.  Are these types   
   > guaranteed to be typedefs of one of the 'normal' integer types (e.g.   
   > short, int, long)? Or could a compiler do the following?   
   >   
   > typedef __compiler_magic_type int32_t;   
      
   I depends on what you consider as "__compiler_magic_type" ;-)   
      
   The most recent C11 draft says in 7.20 p5:   
      
   "For each type described herein that the implementation   
   provides,[footnote]  shall declare that typedef name and   
   define the associated macros."   
      
   where footnote clarifies   
      
   "Some of these types may denote implementation-defined extended integer   
   types."   
      
   The term "extended integer type" exists both in C++11 and in C99, it   
   corresponds to implementation-defined types that might exist beyond the   
   standardized ones.   
      
   > I am wondering because - I think - in modern C++ the character types   
   > wchar_t, char16_t, and char32_t are distinct types rather than typedefs   
   > of short or int?   
      
   Yes.   
      
   > This doesn't seem to be necessarily the case for   
   > int32_t and friends.   
      
   Correct. C++11 doesn't add much to the C99 standard specification for   
   , in particular it doesn't impose the requirement that all   
   these typedefs are referring to distinct types.   
      
   >  This question affects function overloading, as I would like to make a   
   > set of functions overloaded on every possible integer type.  If the   
   > types in stdint.h are guaranteed to correspond to 'normal' types then   
   > it's sufficient to use only those types.  Otherwise I potentially   
   > (depending on the platform) also need overloads for some or all of the   
   > stdint.h types.   
      
   Yes, you should not add overloads for (u)int_least*_t or (u)int_fast*_t   
   types. It should be safe to add overloads for the fixed-width types   
   unless these are not mixed with other integer types.   
      
   >    Also strict aliasing gives rise to a similar problem - to access all   
   > different integer types in a generic way I need code paths for each   
   > different type, to ensure that I am accessing each through a pointer   
   > of the same type.  That means an extra code path for each stdint.h   
   > type which has its own __compiler_magic_type.  (Leaving aside for the   
   > moment the problem of working out which 'normal' integer type to use   
   > for each stdint.h type.)   
      
   The question arises why should should need to add overloads for *all*   
   integer types of the system? Further, why don't you provide a single   
   function template that *only* accepts types that satisfy the   
   std::is_integral type trait? By definition, this trait also applies to   
   extended integer types, as specified in 3.9.1.   
      
   The effect of such a template essentially corresponds to a set of   
   overloads for any possible integral type.   
      
   HTH & 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)