   C++ bloat?
  I'm writing a small app for Unix.  I have a templated circular buffer class (see here for the header code) that I want to use.General .cpp file looks like this:#include <stdio.h>#include <stdlib.h>#include "ringbuff.h"int main(int argc, char** argv) {   RingBuffer<unsigned char, 8> PreBuffer; // ***   // do C-style stuff here}If I comment out the line marked with *** my executable size on Solaris 8 is roughly 7 kb.  If I uncomment the line (i.e. instantiate the ring buffer) my executable size is 447 kb.In both cases my object file is only about 2 kb.My g++ arguments are:-fexpensive-optimizations -O3As can be verified, the templated RingBuffer classes uses zero outside libraries.  All it is is a glorified array.  I thought maybe that the templates were doing something funny but I quickly made a non-templatized version of the buffer with the exact same executable size.I did some more experimentation and discovered that new/delete are the culprits.  It seems that the C++ memory/heap manager is taking up 440 kb of my executable size.  Any idea why?  Shouldn't this be dynamically linked to the C++ libraries?  I then took out the new/delete and used malloc/free and guess what my executable size is?  7 kb...Thanks,Jeff   
  It is only 7k on my system (x86, Gentoo, gcc 3.3.3), with the line uncommented. 3k after stripping. What version of gcc are you using?   ;  gcc 3.1.1I guess I need to install & build a more recent gcc if I want any better?   ;  *shrug* Try and see. I've got libstdc++.2.9.0 too, if that's any help.   ;  Oddly, even if I make a C-style allocator with malloc and free, I still need to call placement new and explicitly call the destructor, which brings the bloat back up to where it was with the C++ style allocation.  Any way of getting around this?Evil...guess I just need to update the GCC version.Regards,Jeff   ;Quote:Original post by rypyrOddly, even if I make a C-style allocator with malloc and free, I still need to call placement new and explicitly call the destructor, which brings the bloat back up to where it was with the C++ style allocation.  Any way of getting around this?Evil...guess I just need to update the GCC version.Regards,Jeffmalloc & free deal with uninitialized memory, free does not invoke deconstructors and mixing free with new is asking for trouble. If you wont to deal with uninitialized memory you would be better using typesafe memory functions & iterators in memory header, uninitialized_copy, uninitialized_fill, uninitialized_fill_n, raw_storage_iterator.   ;Quote:Original post by rypyrI'm writing a small app for Unix.  I have a templated circular buffer class (see here for the header code) that I want to use.General .cpp file looks like this:*** Source Snippet Removed ***If I comment out the line marked with *** my executable size on Solaris 8 is roughly 7 kb.  If I uncomment the line (i.e. instantiate the ring buffer) my executable size is 447 kb.In both cases my object file is only about 2 kb.My g++ arguments are:-fexpensive-optimizations -O3As can be verified, the templated RingBuffer classes uses zero outside libraries.  All it is is a glorified array.  I thought maybe that the templates were doing something funny but I quickly made a non-templatized version of the buffer with the exact same executable size.I did some more experimentation and discovered that new/delete are the culprits.  It seems that the C++ memory/heap manager is taking up 440 kb of my executable size.  Any idea why?  Shouldn't this be dynamically linked to the C++ libraries?  I then took out the new/delete and used malloc/free and guess what my executable size is?  7 kb...Thanks,JeffI use MinGW on Windows and I get similar executable sizes. Other than using highest level optimizition avaliable I strip the executable which usually takes several kB off the size.Sorry if that's not much help.   ;Quote:Original post by snk_kidmalloc & free deal with uninitialized memory, free does not invoke deconstructors and mixing free with new is asking for trouble. I did say I was using _placement new_.  If I malloc the memory and then run placement new on that memory, then I explicitly call the destructor and run free on that memory, how will that cause trouble?   ;  rypyr: I had a problem when doing that that placement new used part of the allocated memory for a buffer itself and it didn't return the same pointer I gave it, which meant not enough memory was left for the object.You should use the functions listed by snk_kid to initialize uninitialized memory because that is what they are meant for and they are more likely to do it than placement new.   