XPost: comp.lang.c++   
   From: musiphil@bawi.org   
      
   On 2011-11-29 22:33, Daniel Krügler wrote:   
   >   
   >>         size_t iFirstPlaceholderPos = sFormat.find(g_sPlaceholder);   
   >   
   > Either use string::size_type or - more preferably auto to determine the   
   > type of iFirstPlaceholderPos. In theory there is no guarantee that   
   > size_t and string::size_type have the same type or even the same maximum   
   > value (which is relevant when using string::npos).   
      
   I agree that it's preferable to use string::size_type instead of size_t,   
   at least semantically. However, string is defined to be basic_string,   
   whose size_type is defined to be allocator::size_type, which is   
   in turn defined to be size_t. Therefore, in this particular (and common)   
   case, string::size_type is identical to size_t.   
      
   Of course, there can be other instantiations of basic_string which use   
   an allocator other than the standard one which defines its size_type   
   to be a type different from size_t. My question is: in such cases, does   
   an implementation exist where size_type is bigger than size_t, or can   
   one ever exist? On all of not-so-many implementations I have ever   
   experienced, size_t was the biggest unsigned integer type, so I have   
   a hard time imagining an unsigned integer type bigger than size_t.   
      
   --   
   Seungbeom Kim   
      
      
         [ 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)