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,428 of 33,346   
   =?ISO-8859-1?Q?Daniel_Kr=FCgler?= to All   
   Re: Initializer lists vs. 0 or 1 items   
   28 Aug 11 11:17:51   
   
   55cd6cc1   
   From: daniel.kruegler@googlemail.com   
      
   Am 28.08.2011 03:07, schrieb Daryle Walker:   
   > On Aug 27, 8:55 am, Daniel Krügler   
   > wrote:   
   >> Am 27.08.2011 04:24, schrieb Daryle Walker:   
   >>   
   >> [..]   
   >>   
   >>> Well, it's a complex-number type, so its implementation would be like   
   >>> "T c_[2]", so the default construction code would work just fine.   
   >>   
   >> I haven't read it this way, because why in heaven should you then use an   
   >> initializer list constructor here? Why not using a normal two-argument   
   >> constructor with default arguments as in:   
   >>   
   >> template   
   >> class my_complex   
   >> {   
   >> public:   
   >>       my_complex() = default;   
   >>       my_complex(T first, T second = T());   
   >>   
   >> };   
   > [TRUNCATE]   
   >   
   > I think I overgeneralized.  The theoretical class I had in mind for   
   > this question would have a variable number of elements, controlled by   
   > a second (non-type) template parameter.  The number of components   
   > could end up being either less or greater than 2, so a constructor   
   > with a fixed number of elements, besides 0 or 1, may end up being   
   > inappropriate.  That's why I think my only choices for a generalized   
   > class would be a default constructor (0 specified elements), an   
   > (implicit) single-argument constructor (1 specified element), or an   
   > arbitrary amount of elements using these new-style initializer lists.   
      
   Your description indicates that you should better use variadic template   
   parameters instead of initializer lists, which have no good way of   
   constraining them by size. The following gives a hint how to realize that:   
      
   #include    
      
   template   
   struct all_convertible;   
      
   template   
   struct all_convertible : std::true_type {};   
      
   template   
   struct all_convertible : std::is_convertible::type   
   {   
   };   
      
   template   
   struct all_convertible : std::conditional<   
      std::is_convertible::value, all_convertible,   
      std::false_type>::type::type   
   {   
   };   
      
   template   
   class my_complex {   
      static_assert(D > 0, "Dimension out of bounds");   
      
      T data[D];   
   public:   
      my_complex() = default;   
      template 0) && (sizeof...(Args) <= D) &&   
          all_convertible::value   
        >::type   
      >   
      my_complex(Args... args);   
   };   
      
   > But the main question was could an initializer list of one element act   
   > transparently like a single-argument constructor.  The answer seems to   
   > be no, since one requires braces and the other must omit them, but we   
   > can have the single-argument constructor delegate to the initializer-   
   > list constructor to save code.  (And we can have default construction   
   > use the initializer-list constructor too.)   
      
   Yes, a single-argument constructor cannot be expressed by an   
   initializer-list constructor, because there does not exist a language   
   construction of a "default-single-argument" constructor similar to a   
   default constructor.   
      
   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