Re: const char* vs string
On Jun 4, 1:23 pm, Craig Scott <audiofana...@gmail.com> wrote:
Actually, it can also matter for C++ code. If you are using shared
libraries, then you need to be aware that the C++ standard does not
guarantee that std::string is safe to use anywhere in a shared
library's interface (it mentions absolutely nothing about shared
libraries at all).
Strictly speaking, that's true for int as well. If all you're
counting on is what the C++ standard says, then you can't count
on int working in a dynamically linked object either.
Fair enough.
But of course, we all count on a little bit more from time to
time:-).
This is frequently a surprise to many C++
developers, but Scott Meyers and others give this topic a good
treatment in their various books (sorry, I don't have them on hand at
the moment, but one of the Effective C++/STL books I think). In short,
unless you can guarantee that your code is being compiled with exactly
the same compiler version as the library you are calling and that you
are using exactly the same compiler flags, then the only types safe to
use in the shared library's interface are POD types and pointers (but
it would be potentially unsafe to dereference these pointers).
Not even that: you can't be sure at all about any struct, since
padding may depend on compiler options. For that matter, you
can't be sure about long---I've had the byte order of a long
change from one version of the compiler to the next, and you
certainly can't be sure about pointers, whose size depends on
compiler options.
Um, I believe I said exactly the same compiler version and flags. If
you use the same settings on the same compiler for the same platform,
you should get the same byte order, padding, pointer size, etc.
If you use the same settings on the same compiler for the same
platform, you also have the same version of the standard
library.
Different compilers make different guarantees with regards to
"binary compatibility", but if binary compatability is
guaranteed between the different options, versions, etc., then
there should be no problem with the standard library either. If
it's not, on the other hand, you're likely to have problems with
POD struct's, pointers and---it happened once to me---even
longs or double. The standard library is part of the compiler,
and is covered by the sane "binary compatability" guarantees as
the rest.
In practice, there will be a set of options you can play with,
over a set of versions of the compiler.
So for the original poster's question, const char* will always be
portable and is safe to use in a library interface,
Except when the size of a pointer depends on a compiler option
(the usual case today, where all of the platforms I know support
both 32 and 64 bit pointers).
Agreed. If you change a compiler option which causes a different
pointer size, you should expect things to explode. ;) I think the
main point is to know what compiler and flags were used to build the
shared library you want to use. It is then your responsibility to use
compatible flags for your own code.
In fact, you're never really portable. The library supplier
should specify the restrictions, but in general, using
std::string entails no more risk than using any other struct.
Unless different modules have their own memory heap (we have
encountered situations where some do).
As far as I know, that never occurs under Unix, and only if you
don't take the proper precautions under Windows. (On the other
hand, I'm not sure who has to take the precautions: the user, or
the supplier of the DLL.) But that's a larger problem: you
can't free memory in one DLL that was allocated in another. Not
using components from the standard library isn't enough to avoid
problems.
Then you run the risk of having
memory allocated in one module and then when you resize the string,
vector, etc in another module the memory needs to be freed in that
module and BOOM! Even if memory is always allocated/deallocated from
the one heap, having std::string, std::vector or any other container
in the interface prevents you from doing some cool stuff like use an
alternate STL implementation in your own code (such as STLport for
improved error checking). But "cool stuff" is just that, not
necessarily "required stuff". ;)
I'm very sceptical about swapping the standard library. It's
part of the compiler, and you never know how much knowledge of
its implementation is built into the compiler.
whereas
std::string might or might not be safe depending on the compiler and
flags used. In real world code, we've found that this does matter and
we have defined our interfaces accordingly.
In the real world, we use std::string and std::vector without
problems, over a variety of compilers and systems.
More power to you. For us, we've had bad experiences doing this with
one particular third party library we have to use (customer
requirement, library is the industry standard). We make heavy use of
std::string, std::vector within modules, we just avoid making them
part of the exposed interface. It's a bit of a pain, but until the C++
standard defines an ABI all compilers must adhere to, we have little
choice. Unfortunately, my understanding is that this has been pushed
out beyond the next draft.
The C++ standard will never define an ABI, since this is, by its
very nature, platform specific.
--
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