From: daniel.kruegler@googlemail.com   
      
   Am 03.10.2011 20:56, schrieb Dave Harris:   
   > musiphil@bawi.org (Seungbeom Kim) wrote (abridged):   
   >> Then is new[]/delete[] your preferred choice?   
   >> What benefits does it bring, and why would you prefer it to   
   >> std::vector?   
   >   
   > As a petty example, you can't write:   
   >   
   >     #include   
   >     class MyData;   
   >     std::vector  vec;   
   >   
   > because it's undefined behaviour to instantiate a std::vector on a   
   > partial type. Where-as with my home-grown vector, I can.   
      
   With a grain of salt, yes. It would still be undefined behaviour, if MyData   
   has a non-trivial destructor or a deallocation function.   
      
   > The standard   
   > reserves for itself lots of freedoms and those translate into   
   > restrictions for users.   
      
   This is correct, even though I believe that this constraint *could* be relaxed   
   for std::vector (and some other library types). In this case, the problem is   
   mainly the cost to define the specification. It surely won't be without costs.   
   You have to make    
   this valid for all the declaration dependencies of std::vector (std::allocator   
   and std::initializer_list come immediately into my mind) and you have to be   
   sure that you have considered every member function. Plus it increases the   
   complexity for each    
   newly added member (because it has to be fine-checked in regard to type   
   completeness). This is a lot of work. As an example, just search for the terms   
   "shall be well formed" and "shall have well-defined behavior" in sub-clause   
   [unique.ptr.single]. Now    
   try to apply this std::vector.   
      
   > The consequence is that I can't use std::vector in a header, without also   
   > including the definition of MyData, which pollutes the namespace and   
   > causes more and longer recompiles. I can't forward-declare std::vector<>   
   > itself, either.   
      
   Also agreed. Again, this would need a good-quality specification. You probably   
   need to specify basically the same number of  headers for each current   
    header, with all the content description.   
      
   I'm sure that the committee would appreciate a proposal like that, but the   
   risk could me that the proposal would have the effect of increasing the   
   library part of the standard by estimated one-fourth. I'm not sure, whether   
   the resources exist to manage    
   this (But I don't want to discourage anyone, I'm only pointing out the risks).   
      
   The alternative is to just complain to your compiler vendor, AFAIK there do   
   exist implementations that allow this. Once this has been done, it is much   
   easier to standardize this. De factor, the C++ standardization is mainly   
   driven by "existing    
   implementation experience" in the wild.   
      
   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)