Re: Utilising "std::string" in function declaration
On Feb 6, 9:30 am, Michael DOUBEZ <michael.dou...@free.fr> wrote:
Kei wrote:
I know this question has been asked numerous times, and I
have read previous posts, but I would like to ask anyway :/
From previous posts, I realise it's safe to return a string,
like the following class method:
std::string MyFileReader::getFileInfo(std::string path);
But when I look at other codes, people seem to have
different styles when declaring a function like above. For
example
// --(1)-- pass by reference
int MyFileReader::getFileInfo(std::string path, std::string &theInfo);
You mean pass by value.
Or is he talking about the "return value"? It's not clear.
If he's talking about the return value, the two functions do
something different: the second provides for a return code, e.g.
to indicate that the search has failed. The usual alternative
here is to use Fallible, although the classic Fallible only
supports a boolean "return code" (failed or succeeded). (I
recently needed more, and have modified my version of Fallible
to support an extended status code.)
At any rate, if you don't need the error code, you should return
the value, as in the first example. Until the profiler says you
can't---not very likely with std::string, or in general, for
that matter.
or is it a typo and you intended:
int MyFileReader::getFileInfo(std::string& path, std::string &theInfo);
I guess you meant pass by value. The pass by reference is an
output semantic.
This is fine when string use copy-on-write (COW) which is no
longer the case in the general case because of threading
issues.
Pass by value is fine until the profiler explicitly tells you it
isn't. Or until house specific coding guidelines say otherwise.
// --(2)-- const class ref
int MyFileReader::getFileInfo(const std::string &path, std::string
&theInfo);
const reference is the general input semantic for big objects,
which is likely for string (except when using the small string
optimization).
It's the general input semantic, except when it isn't:-). A
priori, you don't know the size of an object (or shouldn't have
to).
The most common coding guideline I've seen has been to pass
class types by const reference, everything else by value. Which
is simple, easy to understand, and of no help in templates. (In
the STL, iterators and predicates are passed by value; most
other things of unknown type by const reference.)
// --(3)-- use char*
int MyFileReader::getFileInfo(const char* path, std::string &theInfo);
This is what the STL does for std::fstream. It is not that bad in the
general case. :)
It forces to get the underlying array of char from a string (
c_str() ) ; depending of the implementation of string, this
may incur some costs.
Not likely, as the upcoming version of the standard will require
strings to be contiguous, as is already the case with vector.
The C++ FAQ Lite seem to endorse using "const SomeClass
&classRef" to strictly prevenet modification of the class..
(No. 2), but I don't see why I should not use constant
char*. Is char* evil? I coded in C so I'm fairly comfortable
with char*
It is just that the standard doesn't guarantee that invoking
c_str() is genuine so you may have surprises in performances
but, it it doesn't matter, it is acceptable.
Yes and no. The semantics are not at all the same, and calling
c_str() results in a loss of information---in the worst case
(the string contained '\0' characters), the actual string passed
to the function is different, but even without that, it means
that the function must work in terms of char const*, with all
that implies---from experience, most of the functions I write
that take a char const* (for reasons of compatibility with
legacy software) start by converting it to std::string, so that
I have access to all of the information immediately.
I just want to know, what is the rationale of each use, and
how do you choose which to use?
The conservative way is to use const reference.
The convervative way is to use pass by value:-). The "correct"
way is to conform to the local standards and practices.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34