Re: char* to std::string
Francis Glassborow wrote:
In article <1149619909.043598.31890@u72g2000cwu.googlegroups.com>,
pepone <pepone.onrez@gmail.com> writes
can any body sayme how this code works in c++
Where did you find this code because it looks pretty bad to me and I
would not trust its author.
Well, he's asking a question about it -- he's not sure it's correct
himself (and the fact that he's asking the question indicates that he's
got doubts himself).
std::string
MyClass::doSameThing()
{
char* data = getSameData(); /*this return same data reserved
with malloc*/
Why is it doing that?
A priori, because it is written in C, and is part of a library written
in C, and used by C programs as well as C++ programs.
It makes getSomeData() a potnetial source of memory leaks. Why not
write getSomeData() so that it returns a std::string by value?
I don't know if the programmers writing the C code which uses the
function would appreciate that.
Or even better, write getSomeData(std::string &) that will write the
data directly to the string?
If the profiler says that the copying is killing you. If not, do the
natural thing.
std::string retval = data; //Whats happen here i get a new copy
of data?
Yes, it simply intialises retval with a copy of data.
delete(data); // is correct free data now?
If malloc was used to create the storage std::free() must be used to
release it. Allocation and deallocation functions must match.
Strangely enough, no one seems to have mentioned the possible use of
RAII here. I'd write a small class along the lines of
boost::scoped_array, but which used free() instead of delete[], e.g.:
class scoped_cString
{
public:
scoped_cString( char* p )
: myP( p )
{
}
~scoped_cString()
{
free( myP ) ;
}
operator std::string() const
{
return std::string( myP ) ;
}
private:
char* myP ;
} ;
std::string
MyClass::doSomething()
{
scoped_cString result( getSomeData() ) ;
return result ;
}
That way, I'm safe even if the constructor to std::string raises an
exception.
return retval;
And the upshot of all this is to ensure that the code (even when
tidied up) is so obscure that the compiler is not likely to generate
efficient code from it.
Bof. It's fairly readable -- a lot better than a lot of the code I get
to see. So if the profiler does show a performance problem, I'll be
able to understand it and tune it.
Without seeing the internals it is hard to know exactly what to do
with the code but that use of malloc is what is shooting the code.
How can you say that without knowing the context. The poster has
obviously heard of std::string, and knows enough to use it in C++, so
presumably getSomeData is either a legacy function in a C library whose
sources he cannot modify, or must also be used in C programs. If he'd
not shown any knowledge of the existance of std::string, and was trying
to hack C style strings in the posted code, I could understand your
point, but my impression is rather that he understands the problem with
C style code, and is trying to wrap what he cannot change.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]