Do we prefer const char* or const char[]
Andrew Scherkus
William Chan (陈智昌)
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
Satish Sampath
Albert J. Wong (王重傑)
Wan-Teh Chang
const char * name = "Chrome";
allows the compiler to perform string pooling optimization, but
const char name[] = "Chrome";
doesn't.
Wan-Teh
Satish Sampath
That feels like it's starting to border on const happiness..
Adam Langley
On the flip side, "const char* name" involves an extra relocation record.
On Linux "const char name[]" is preferred because of this (see [1],
section 2.4.1).
[1] http://www.smilax.org/135/dsohowto.pdf
AGL
stoyan
Mark Mentovai
> I just noticed the style guide recommends const char* [1]
The only relevant thing I see in there is advice to use char* at
namespace scope in preference to std::string. That shouldn’t be read
as expressing a preference between char* and char[] in any context. At
all.
> but I had always
> assumed we preferred const char[] based on its prevalence in *_switches.cc/h
> files:
I just went through this with Erik for http://crbug.com/49544.
Summary:
const char kCharacterConstant[] is OK, and is best in most cases.
const char* const kCharacterConstant is OK. (You can also spell this
char const* const.)
const char* kCharacterConstant probably doesn’t do what you want.
Each has valid uses.
Assuming you’ve got some character data that you want to make a
constant, you want either |const char kCharacterConstant[]| or |const
char* const kCharacterConstant|. People commonly write |const char*
kCharacterConstant|, but this isn’t really const enough, and it often
doesn’t do what you think it does. |const char* kCharacterConstant|
says “kCharacterConstant is a non-const pointer to const data” and
thus still allows kCharacterConstant (the pointer value) to be
modified by assignment. |const char* const kCharacterConstant| says
“kCharacterConstant is a const pointer to const data” and doesn’t
allow the pointer OR the data to be modified.
This was significant in the bug referenced above because the pointer’s
non-constness, when used in another global variable, resulted in the
creation of a run-time static initializer instead of compile-time
const data. Bad.
Given the choice between |const kCharacterConstant[]| and |const char*
const kCharacterConstant|, I personally have no preference—the right
one depends on the context—but the former probably matches the
intention more closely in more cases. The [] form gives you a handle
to the storage used for the actual character data, which means that
you can use things like sizeof and arraysize if you’re in the same
translation unit where kCharacterConstant is defined. You can
sometimes take advantage of that and write |const size_t
kCharacterConstantLen = arraysize(kCharacterConstant) - 1;|, giving
you a compile-time constant for the length too, instead of having to
use a run-time call to strlen.
I don’t consider |const char* const| to be “going crazy” in the sense
that the style guide advises against, although I’d probably feel
differently if there were another * or & with another const on there.
Marc-Antoine Ruel
Mark Mentovai
> The main reason I'm recommending a pointer is because I've seen a few times
> people using the array notation for local const string variables. That is
> the worst case since it means stack usage.
A local const string should be |static const char
kLocalCharacterConstant[]| or |const char* const
kLocalCharacterConstant| (static or not). |const char*
kLocalCharacterConstant| can still have its pointer value accidentally
modified, which I think is pretty bad, unless you actually want it to
be mutable.
Marc-Antoine Ruel
Mark Mentovai
> local static arrays are first-execution-initialized on MSVC AFAIK.
It would surprise me if MSVC needed to initialize these at runtime if
marked “static const”—that would seem to imply that it would also
elect to use a run-time static initializer for |const char
kCharacterConstant[]| at namespace scope too, instead of just loading
it as data.
> I'd need
> to confirm on latest compiler but when in doubt, I prefer the saner choice
> to not use static locals.
That’s cool. Like I said, I don’t really have a personal preference
and there’s a place for each of these, but if it’s spelled with a *
and it’s supposed to be immutable for real and not able to point to
something else, it ought to name “const” twice.