C++Talk.NET

kaufmann@cs.uni-potsdam.d · Guest

Hello,

I have a non-local constant fooName defined like this:

const char* const fooName = "foo";

fooName is used in a function f that is called in the course of the
dynamic-initialization of a non-local object (f and the non-local
object live in different TUs)

My question: Is it guaranteed that on entering f fooName is already
initialized and therefore different to 0?

As far as I understand the C++ Standard it is because fooName is a
non-local object of POD-type which is initialized using a constant
expression and 3.6.2/1 states:

"[...]Objects of POD Types with static storage duration initialized
with constant expressions shall be initialized before any dynamic
initialization takes place"

I'm asking because at least on one compiler I tried fooName is
sometimes a null pointer when f is entered.

Is this a bug in the compiler? Or am I misinterpreting the C++
Standard?

Regards,
- Ben

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

kanze@gabi-soft.fr · Guest

[email]kaufmann (AT) cs (DOT) uni-potsdam.de[/email] wrote:

tony_in_da_uk@yahoo.co.uk · Guest

Why create two variables when you only need one? Try:

const char fooName[] = "foo";

Cheers, Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gerhard Menzl · Guest

[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:

wkaras@yahoo.com · Guest

[email]kaufmann (AT) cs (DOT) uni-potsdam.de[/email] wrote:

Gerhard Menzl · Guest

[email]wkaras (AT) yahoo (DOT) com[/email] wrote:

Francis Glassborow · Guest

In article <1120758734.270911.14180 (AT) g43g2000cwa (DOT) googlegroups.com>,
"wkaras (AT) yahoo (DOT) com" <wkaras (AT) yahoo (DOT) com> writes

tony_in_da_uk@yahoo.co.uk · Guest

const char* const fooName creates an ASCII-NUL terminated buffer with
'f', 'o', 'o', '', then the second variable is a constant pointer to
const char, intialised to address the former. Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gerhard Menzl · Guest

[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:

tony_in_da_uk@yahoo.co.uk · Guest

Hi Gerhard,

You're thinking from the C++ perspective of "variable", while I'm
thinking at the assembly level - in terms of reserved space in the
executable.

Anyway, you appear to have missed my point, which is that there is no
need for a pointer-to-character variable to keep track of a string
literal when we can directly allocate and access the string literal,
and have no intention of moving the pointer. It removes the OP's
problem if he allocates const char foo[] = "foo"; ... there is simply
no race condition involving a pointer's assignment.

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Allan W · Guest

[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:

Gerhard Menzl · Guest

[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:

tony_in_da_uk@yahoo.co.uk · Guest

Hi Gerhard,

I hope Allan's spot-on post is explicit enough to convey the difference
between 'const char* p = "abc";' and "const char p[] = "abc";'. Still,
I see you don't see the relevance to the original poster's queries,
so...

Firstly, the question is about linkage, and is not specific to C++.
You've got to be able to think a level lower - in terms of the implicit
as well as explicit variables your C++ code is generating, as well as
objects, symbols, linkage and static initialisation - to understand
these issues.

Secondly, Ben was asking whether the pointer version was guaranteed to
be initialised before it was accessed, even if the accessing code was
part of a separate translation unit. Thus, he is asking whether
there's a race condition: not necessarily in the multi-threaded sense,
but definitely in the "which-initialisation code will the linker select
to run first" sense. It _could_ also be a race condition in the
multithreaded sense if code planning to use the pointer was running in
a distinct thread from that planning to initialise it.

Ultimately, my point is simply to follow the "keep it simple, [stupid]"
rule, and remove the unnecessary pointer from the situation. Allan
says this is premature optimisation, but that's not true. It's not an
optimisation, or a compromise, it's simply the purest expression of
what's wanted, and should be used by default. To access string
literals through pointers implies that you may want to point these
pointers elsewhere, but when they're const pointers that's not even
possible so it's a needless obfuscation and waste of CPU time,
executable and memory space.

Cheers,

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Gerhard Menzl · Guest

[email]tony_in_da_uk (AT) yahoo (DOT) co.uk[/email] wrote:

tony_in_da_uk@yahoo.co.uk · Guest

Gerhard,

I agree that the Standard _should_ allow people to understand that
const char* const p = "abc" is asking for two data elements (though the
pointer may well be optimised out), and should specify the required
programmatically observable behaviour of the
compiler/linker/loader/executable in performing initialisation. I
maintain that this thread is evidence of the failure of interested
parties to either consult the Standard or interpret it in such a way
that they provide the best advice to the original poster.

What I've suggested as a complement to the Standard is an understanding
of the constraints placed on the C++ compiler by the layout and
handling of generated objects in typical deployment environments. It
is these constraints that have shaped the C++ Standard, and how the C++
compiler works can sometimes be deduced by an understanding of these
factors.

These aspects obviously aren't clear to you, as you say `you cannot
rely on it to cause const char p[] = "abc" to execute in time either'.
In this case, the only data element (p) will be placed in a section of
the executable storing preinitialised data, and loaded by the Operating
System loader without the aid of any executable-provided code. If
necessary on a particular deployment environment, any pointers to the
data will be "patched" into the executable image by the loader before
starting the executable running. The original poster's concern was
that on some systems `const char* p = "abc"' could require code in the
executable to initialise the pointer, and I'm showing that since he
doesn't actually have any use for the pointer, he can discard it and
have one less problem to worry about.

Summarily, basic knowledge of Operating Systems, object layout,
linkage, and loaders makes this obvious.

You're correct in saying that the original poster didn't mention
threads, but he didn't specifically say he had a single-threaded
program either. Surely you're not maintaining that multi-threading is
so arcane in the context of initialisation order I shouldn't have
bothered to complicate the situation by mentioning it? Anyway way, as
threading may be relevant to the situation, I believe it's useful to
discuss whether a prospective solution is thread safe or not.

And as a stylistic issue, it's simply poor practice to write const
char* const p = "abc", as you've no use for the pointer, and it
suggests a lack of understanding of the layout of data that you do
actually intend to use. It's not a case of "[only] (typically) four
bytes" as you suggest - it's a matter of concision and clarity of
intent. You're not buying anything except obfuscation with your extra
four bytes.

In conclusion, your belief that `const char p[] = "abc" is just a
possible workaround for a particular version of a non-conforming
compiler' is complete nonsense. It is the proper programming practice
that removes even the question of initialisation order.

Tony

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]