Re: strings
On Oct 25, 1:53 pm, Maxim Yegorushkin <maxim.yegorush...@gmail.com>
wrote:
On 25/10/09 10:42, James Kanze wrote:
On Oct 24, 7:23 pm, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
On 24/10/09 18:59, Juha Nieminen wrote:
thomas wrote:
On Oct 24, 8:09 pm, Maxim Yegorushkin<maxim.yegorush...@gmail.com>
wrote:
On 24/10/09 10:58, thomas wrote:
char a[] = "abc";
char a[] = {'a','b','c','\0'};
Is there ANY difference between these two strings?
"abc" has the same binary layout as {'a','b','c','\0'}
does, hence no difference.
Why do you ask?
I thought the first may mean that the string cannot be
modified. But actually it can. So I cannot figure out
any difference between these two which I hope exists.
In the first case you are not actually modifying the
literal "abc" but the values inside the 'a' array. That's
different from:
const char* a = "abc";
In this case you don't have an array. You have a pointer
pointing to a literal. An modification attempt would
modify the literal (and thus is UB). In the case of the
array you are modifying the contents of the array, not the
contents of the literal you used to initialize the array.
A bit off topic, from unix linker point of view, char
const[] is better than char const* for global and namespace
scope strings.
Every linker I've seen (Unix or otherwise) is capable of
handling both without any distinction.
Not true.
Here is an example:
[max@truth test]$ cat test.cc
char const a[] = "abc";
char const* b = "def";
char const* foo() { return a; }
char const* bar() { return b; }
Which proves what I said. The linker handles both cases without
any problems; if it doesn't, it's not compiling C++ correctly.
Have you actually tried compiling and linking this? Does one of
the cases fail when you do?
Let's look at the assembly code of foo() and bar() when they
are compiled as position independent code (intended to be a
part of a shared library):
If I were worried about the assembler code, I'd write in
assember.
[...]
In summary, when building a shared library global and namespace scope
char const[] requires no run-time linker processing, where as char
const* does.
So? I wouldn't say that that's really an argument one way or
another.
Making b char const* const instead, effectively making it
static, allows the compiler optimize out accessing b and
access the string referred by b directly.
Let's worry about the semantics before worrying about typically
insignificant optimization issues. My point, as I expanded it,
is that there are significant differences in the semantics
(visibility from other translation units, etc.), and that the
choice should depend on the desired semantics. If the public
interface requires that b be a char const* visible from other
translation units (e.g. so that they can change it), then you
don't have any choice. If the public interface says that b
shouldn't be visible outside the translation unit, then you
can't use just "char const*", except in a local namespace. If
the code requires the value to be used as an argument to a
template, then you can't use just "char const* const", either.
The point I was making that using char const* for representing
global and namespace scope read-only stings is the worst
possible choice from the linker standpoint of view. Better
choices are char const[] or char const* const.
The best choice is always to say what you mean, until the
profiler says you can't. If what you want is an array, then
char const[] is indicated. If what you (conceptually) want is a
pointer, then char const* is indicated. And as I pointed out,
about the only time I'd use char const* const is in a table.
--
James Kanze