Re: Help debugging basic_string<char>

[Jamie Kirkpatrick <jkp at kirkconsulting dot co dot uk>]

<snip>

> Do you mean this works:
>
> std::string getString();
>
> void f()
> {
>     const char* p = getString().c_str();
>     // use p
> }
>
> ?
> It shouldn't work ... or rather, you are not allowed to rely on it
> working because the destructor for the string will be run
> immediately after the assignment to p, which means p is invalidated.
> This sounds like the behaviour you're seeing, and is correct.

Ok - this is what I meant.  So what im seeing is correct OK, thats  
good I guess!  Is there something in the c++ spec i can point people  
too to indicate that this is the case?  An out of interest - how come  
the destructor on string is not getting called so soon?  Also, is it  
ok to assume that the following is valid?

int test( char * buffer );

main()
{
	int result = test( someFunctionReturningString().c_str() );			//  
buffer valid for duration of subsequent call?
}

> > I set my debugger to break on free() and watched what was going on
> > and in doing so I noticed that std::string uses its own deconstructor
>
> (I'm assuming you mean the destructor, not some other function that  
> does
> de-construction)

oops :)  bad terminology :)

> > that was different to the one my specialization was using.  This
> > leads me to believe that there are some differences implemented in
> > std::string that I have not applied to my own specialization.
>
> Have you written an explicit specialisation of basic_string<uint16_t>
> or implicitly specialised it by instantiating it?  You shouldn't  
> need to
> write an explicit specialisation of basic_string, only the char_traits
> and other parts you mentioned already.

The latter.

> > So, the next thing I wanted to do was to find this code, but after
> > looking hard at everything i have I couldn't locate any extra code.
> > So next I tried enabling debug mode in libstdc++ to see If i could
> > step into the std::string stuff and see for myself what was going
>
> Libstdc++ debug mode is not for stepping through the code in a  
> debugger.
> The debug mode adds extra checks and bookkeeping that catch errors and
> misuses.  The intent is to help debug your program, but not  
> necessarily
> by using a debugger (in many cases using the debug mode makes it clear
> what the error is without ever having to start a debugger - which is
> nice)

Yeah, I was aware of the difference - there is a lot of stuff out  
there about debug mode, which as far as I can tell adds more runtime  
checks etc.

> > on.  No go.  So lastly I used darwinsource to build a debug version
>
> What does that mean?
> Did you use the --enable-libstdcxx-debug configuration option when
> building GCC?  That is the recommended way to get a debug version  
> of the
> library (i.e. one built with debugging symbols) but I don't know if  
> it's
> the right way for Mac OS X.

Yeah, I think darwinbuild (which is an automated build system for  
parts of the darwin source code tree) automatically builds a release  
and a debug version.  I've checked the symbols table with nm on the  
lib im linking to and it definately hasnt been stripped.

> > of libstdc++ and forced DYLD to link it in at runtime.  When i debug
> > my app, as before I can step into the constructor etc for my own
> > specialization but not for std::string!
>
> Sounds like you didn't link to the debug version then.  std::string is
> instantiated in the library, so if the library has debugging  
> symbols you
> *should* be able to step through in the debugger.

I'm definitely linking to that version - I have got the linker to  
print what it linked in at runtime and it is linking that version of  
the lib.

> You can cause std::string to be instantiated in your application by
> compiling with -D_GLIBCXX_EXTERN_TEMPLATE=0 which will prevent the
> std::string instantiation from being suppressed in your app.  That  
> might
> work in letting you step through the std::string code in a debugger
> without having to recompile the library.

Hmmm - tried this, but it doesnt seem to be doing anything.  Googled  
it on the web as well but it turns up nothing - is this an  
undocumented feature?  To summarise, I still cant step into anything  
internally compiled in libstdc++ when it comes to wstring and string.

That leads me to ask another question as well.  The whole locale /  
facet thing seems a little kludgy to me as someone who wants  to  
instantiate 3 new facets and add them to the default locale before  
the app starts, simply because I can only add one facet at a time,  
which means creating 3 dummy locales and adding a new facet to each  
one on top of the last and finally installing the last as the default  
locale.  Is there some way I can do this more elegantly?  At the  
moment that will have to be the first thing that happens in my  
framework but it seems very messy - at the least is there a way I can  
add multiple facets to a locale at once?

> > What I want to know is a: is there extra code for the std::string
> > speciazation that I am missing? (if so where might i find it) and b:
> > how can i get a version of libstdc++ that lets me step into this
> > stuff?  Surely this is possible or else, how do you guys actually
> > develop the stuff in the first place!?
>
> I hope I've answered b: above, the answer to a is no, there is no
> explicit specialisation of basic_string<char> - the explicitly
> specialised parts are char_traits etc. and a couple of overloads for
> operator>> and getline() for basic_string<char>

Yeah - your answers have been extremely helpful - thanks very much  
for getting back to me.  I would like to ask one more thing - I have  
seached the code for things such as the numpunct specializations for  
wchar_t and char but I cant find them.  Is there any way you can tell  
me or point me to the places where these things (I mean those and the  
other templates I needed to implement) are defined?  For me the  
existing code is very useful since Im not a c++ coder really and  
having a prior example to work from is the easiest way for me to get  
this right.

Cheers!

Jamie