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,481 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: uniform initialization, auto and GCC   
   23 Sep 11 06:01:58   
   
   d0c1fb31   
   From: daniel.kruegler@googlemail.com   
      
   Am 22.09.2011 21:47, schrieb P. Areias:   
   > Is the "uniform" initialization really uniform?   
      
   Please define "really uniform".   
      
   > It is supposed to   
   > remove the "vexing" initialization syntax.   
      
   Yes.   
      
   > However we may still have   
   > to tolerate the old style initialization... whenever we use C++11   
   > auto.   
      
   What means "old style initialization"? C++11 has not removed aggregates,   
   that is for sure (but aggregates are not your problem here). It has also   
   invented a new template class initializer_list, which is useful, because   
   it allows to define a complete new constructor family that corresponds   
   to a linear sequence of uniform element types (initializer-list   
   constructors).   
      
   > auto integer={10};   
      
   I wonder why you are using braces here. What is the advantage over   
   simply writing   
      
   auto integer=10;   
      
   ?   
      
   > cout< initialization list   
   >   
   > Therefore we now have 3 styles of object initialization instead of 2   
   > with C++03. (attribution-like, function-like and C-array-like).   
   >   
   > Why?   
      
   I don't know, what "attribution-like" is supposed to mean, but I think   
   your question is misleading. First, you are using the new facility   
   "auto", which allows a type deduction based on an initializer. This   
   means, we must define a type corresponding to such an initializer. This   
   is easy, if we look at literals, because they unambiguously and uniquely   
   correspond to a given type. Now we have to ask, what is the type of   
   {10}? By the language definition, this is no expression, but it is a   
   /braced-init-list/. We could decide to say: There does not exist a   
   corresponding type, so make it ill-formed. But there are also advantages   
   to associate a type to it, if the contained element all have the same   
   type: This type decision is in general not unique, because we can   
   construct different types with such an initializer and there exists no   
   single fundamental type of a literal {10}. The decision was to associate   
   this initializer with std::initializer_list, because   
   braced-init-lists have a strong association to this type. If you don't   
   want this effect, you must provide more information to the compiler to   
   resolve the lack of information.   
      
   Now, if you are starting to compare different initialization forms, I   
   can ensure you, that either of   
      
   auto i1 = int{0};   
   auto i2 = int(0);   
      
   will result in the same type for i1 and i2. So, I don't think that the   
   different initialization forms are the root of your problem.   
      
   The problem arises, if seemingly redundant braces/parentheses are used:   
      
   auto i3 = {0};   
   auto i4 = (0);   
      
   Now (0) is indeed an expression of type int, but {0} is no expression,   
   it is a braced-init list. I understand that this is a somewhat   
   surprising result, but on the other side: *Why* should we use braces or   
   parentheses in an auto-initialization? I would simply recommend to   
   remove them and be happy with the result.   
      
   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