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 31,715 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: size_type and size_t   
   02 Dec 11 22:35:00   
   
   XPost: comp.lang.c++   
   From: daniel.kruegler@googlemail.com   
      
   Am 02.12.2011 14:54, schrieb Seungbeom Kim:   
   > On 2011-11-29 22:33, Daniel Krügler wrote:   
   > 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.   
      
   You are right, I should have made clearer that my concerns do refer to   
   programming in template context or any "indirect" context, where you   
   depend on some type chains. Sometimes I forget that I'm not in such an   
   "indirect" role ;-)   
      
   > 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.   
      
   Yes.   
      
   > My question is: in such cases, does an implementation exist where size_type   
   > is bigger than size_t, or can one ever exist?   
      
   I'm interpreting your question to refer to general allocators, not to   
   std::allocator. But when I do this, the term "implementation" makes me   
   wonder a bit (which in this context can also be read as "Library   
   implementation"), nonetheless I assume you mean the implementation of   
   some user-defined allocator, I hope this is what you meant.   
      
   > 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.   
      
   There is no indication in either C or C++ that std::size_t corresponds   
   to the std::umaxint_t from , size_t typically reflects the   
   "bitness" of the underlying platfom. On my 32 bit machine gcc 4.7 gives   
   me the following program compiles successfully:   
      
   #include    
   #include    
      
   constexpr std::uintmax_t c1 = UINTMAX_MAX;   
   constexpr std::size_t c2 = SIZE_MAX;   
      
   static_assert(c1 > c2, "Error");   
   static_assert(sizeof(std::size_t) * CHAR_BIT == 32, "Error");   
   static_assert(sizeof(std::uintmax_t) * CHAR_BIT == 64, "Error");   
      
   I expect that reflects typical PCs with 32 bit architecture.   
      
   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)   

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


(c) 1994,  bbs@darkrealms.ca