Jeffrey Schwab wrote, On 13/11/2006 11:45 AM:
Dave Rudolf wrote:
Hey all,
I noticed with MSVC.net 2003 that if I do something like
cout << sizeof( std::string* ) << endl;
it prints 4, whereas if I do the same thing with a reference, like so
cout << sizeof( std::string& ) << endl;
I get 16. This is the same whether I am doing a Debug or Release
configuration. So, why would it need 16 bytes to represent a
reference, and only 4 for a pointer? On other platforms (including
cygwin on the same machine), I get only 4 bytes for references. My
machine is using a 64-bit processor, so that might explain if it were
using 8 bytes. I tend to use a lot of references in my code, but
because of the storage requirements, would consider changing many if
them to pointers.
So can someone shed some light on this issue? Is there perhaps a
compiler option to reduce this memory footprint?
28 is the size of std::string. The reference is not an object in its
own right, and may not require any run-time storage at all. The
compiler may or may not use a pointer to implement the reference
semantics.
Ah, I see now. When I do sizeof( std::string ) in unix, it coincidently
gives 4 as the size. Which begs the question, why do std::string objects
need more memory in Windows land than in other systems? I know that
there can be platform differences and such, but if a string is just an
array of bytes (or whatever underlying character type is given to the
basic_string template), then why would the class take more room in VC
than in, say g++? I know this is a rather fuzzy and esoteric question,
so don't take the question too seriously :)
Anyway, thanks.
Dave
I think Dinkumware std::string uses "small string optimization". Strings
invoking the heap.