Help debugging basic_string<char>

[Jonathan Wakely]

On Sat, Jan 21, 2006 at 11:24:19AM +0000, Jamie Kirkpatrick wrote:
> Hello one and all.

Hi Jamie,

> So far I have written my own char_traits, ctype and numpunt  
> specializations, then ive instantiated and installed the facets in  
> the default locale.  Everything works well, but as I say im still  
> seeing some issues.  I know that what i have done is not the full  
> story, but it will be enough to provide the functionality that I will  
> need.  Everything is working well, but I am having a strange memory  
> management issue that im trying to figure out.  If I return an  
> instance of my new string class from a function but I dont hold onto  
> it expclitly (perhaps I just set a pointer to the buffer that backs  
> it using .c_str() ) it is calling its destructor early.  I have run  
> tests with std::string and this does not happen... you can set a  
> pointer to the buffer and it is valid for the entire duration of the  
> calling scope.

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.

> 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)

> 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.

> 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)

> 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.

> 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.

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.

> 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>

Hope that helps,

jon

-- 
"My loathings are simple: stupidity, oppression, crime, cruelty, soft music."
	- Vladimir Nabokov