cdd70681   
   From: ulrich.eckhardt@dominalaser.com   
      
   Am 01.10.2011 23:45, schrieb Ken:   
   > I have no issues telling std::vector how many I want, but I really   
   > don't want to call Foo() 100mln times (default constructor does   
   > nothing - would be fine if the objects were zero'ed out).   
      
   The vector will call the constructor for you, but I guess you are aware of   
   that already. I'm a bit unclear about what you are trying to do or, rather, to   
   avoid doing.   
      
      
   > If Foo is a POD and I know that zero-initialization is ok, I can use   
   > calloc() to allocate my array and free() it later.  Unfortunately   
   > is_pod() is a little too restrictive - Foo is rather simple, but by   
   > just having any constructor, it is no longer POD (I need some non-   
   > default constructors for convenience).   
      
   You can replace the convenience constructors with factory functions, in   
   particular for PODs that are cheap to copy.   
      
      
   > Another interesting thing I found was that I wanted to elide the   
   > default destructor because it does nothing and I don't like ~Foo()   
   > being called 100mln times.  However, that effort failed too, as I need   
   > to use Foo as a value in a std::map and having value-semantics, gcc   
   > complains about not having a ~Foo().   
      
   Huh? If you just delete the destructor from your type definition, the compiler   
   will automatically generate one. I have yet only heard complaints from the   
   compiler if the dtor was either not accessible (protected/private) or was   
   promised (declared) but    
   not supplied (implemente). The latter complaint would then come at link time,   
   not at compile time.   
      
      
   > Aside: should I create a Foo_Core that has almost nothing (no   
   > constructors, destructors, etc...) to ensure that it's a POD and then   
   > a Foo class that operates on Foo_Core to provide class-like   
   > functionality?  almost seems like a functional-programming approach   
   > would work better here.   
      
   You mean "procedural", not "functional". Anyhow, yes, an approach where   
   objects are stripped down to the point they only guarantee their own internal   
   consistency and instead using free functions to extend and manipulate them can   
   be valuable. This is an    
   alternative to an OOP/OBP approach, in particular in cases where the objects   
   in questions are mere value types or where you can't associate a main object   
   ("this" in C++) with some operations.   
      
      
   Good luck!   
      
      
   Uli   
      
      
   --   
         [ 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)