«

David Harmon wrote:
> On Fri, 16 Apr 2004 13:51:01 GMT in comp.lang.c++, "Petec" <>
> wrote,
>> I would suggest using:
>> const char* const MYSTRING = "ABC";
>
> Why the gratuitous pointer?
> const char mystring[] = "ABC";

It's just my style, and there's not much of a difference.
Besides, if I want to avoid pointers, I use a std::string.

- Pete

"Christopher Benson-Manica" <> wrote in message
news:c5p07c$5np$...
>
> Not all macros are evil.


We must try to avoid using macros completely (mainly by using templates),
with very few exceptions that this can't be done (mainly the #ifndef stuff).






Ioannis Vranos

On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
<> wrote,
>"Christopher Benson-Manica" <> wrote in message
>news:c5otbd$4jp$...
>> David Harmon <> spoke thus:
>>
>> >>const char* const MYSTRING = "ABC";
>>
>> > const char mystring[] = "ABC";
>>
>> Are there any situations where the behavior of these two constructs
>> differs?
>
>
>Behaviour no, but implementation yes. "ABC" is stored in a separate space
>reserved from the implementation, while the pointer MYSTRING and the array
>mystring with all its members are stored in the stack.

Sorry, but no. There is no "stack" at the point in namespace or file
scope where those declarations are presumably found. It could only be
on the stack if it were written local to a function, in which case I
would have written it
static const char mystring[] = "ABC";

Unfortunately, "static" means different things at function scope and at
file scope. Either way it should be merely a name referring to the same
constant area that the literal does occupy in the various other idioms.
Putting it on the stack would be very bad, calling for a copy to be made
from constant area every time you use it.

The possible extra level of indirection, and possible wasted space for
a pointer variable that was not called for in the original #define
example, is a mistake and a red herring and should never have been
introduced into the discussion. But, if it was at function scope, Pete
would presumably have declared it "static" also, and still have nothing
extra on the stack, I hope.

On Fri, 16 Apr 2004 16:05:00 +0000 (UTC) in comp.lang.c++, Christopher
Benson-Manica <> wrote,
>Ioannis Vranos <> spoke thus:
>
>> Avoid macros completely.
>
>Not all macros are evil.

Example?

"David Harmon" <> wrote in message
news:...
> On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
> <> wrote,
> >"Christopher Benson-Manica" <> wrote in
message
> >news:c5otbd$4jp$...
> >> David Harmon <> spoke thus:
> >>
> >> >>const char* const MYSTRING = "ABC";
> >>
> >> > const char mystring[] = "ABC";
> >>
> >> Are there any situations where the behavior of these two constructs
> >> differs?
> >
> >
> >Behaviour no, but implementation yes. "ABC" is stored in a separate space
> >reserved from the implementation, while the pointer MYSTRING and the
array
> >mystring with all its members are stored in the stack.
>
> Sorry, but no. There is no "stack" at the point in namespace or file
> scope where those declarations are presumably found.


At first, i assumed the definition takes place in a local scope and not in
the global or a namespace scope.

But except of that, where do you think global "non-static" variables are
created?


> It could only be
> on the stack if it were written local to a function, in which case I
> would have written it
> static const char mystring[] = "ABC";


There would be no point for this. The time cost for creating this thing is a
joke. (Even the compiler may optimise it entirely out).



> Unfortunately, "static" means different things at function scope and at
> file scope.



Yes, and instead of using static keyword in the global scope it is better to
use an anonymous namespace.


> Either way it should be merely a name referring to the same
> constant area that the literal does occupy in the various other idioms.
> Putting it on the stack would be very bad, calling for a copy to be made
> from constant area every time you use it.


I do not understand what you mean, after all copies will be created inside
the array in all case scenarios.



> The possible extra level of indirection, and possible wasted space for
> a pointer variable that was not called for in the original #define
> example, is a mistake and a red herring and should never have been
> introduced into the discussion. But, if it was at function scope, Pete
> would presumably have declared it "static" also, and still have nothing
> extra on the stack, I hope.



You are wrong. static variables inside a function scope are still created in
the stack.






Ioannis Vranos

Ioannis Vranos <> spoke thus:

> You are wrong. static variables inside a function scope are still created in
> the stack.

Assuming the implementation uses a stack.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
<> wrote,
>At first, i assumed the definition takes place in a local scope and not in
>the global or a namespace scope.

I assumed otherwise, since I have seen some huge number of such #define
constants in C code, and a somewhat lesser number of const strings in
C++ code, and the vast majority of them were near the top of the file
before any functions, if not in headers included near the top of the
file before any functions.

>But except of that, where do you think global "non-static" variables are
>created?

I don't understand that. All globals have static lifetime, or they
wouldn't be global. Show me the declaration of what you are talking
about and I'll tell you where I think it's created.

>> It could only be
>> on the stack if it were written local to a function, in which case I
>> would have written it
>> static const char mystring[] = "ABC";
>
>There would be no point for this. The time cost for creating this thing is a
>joke. (Even the compiler may optimise it entirely out).

No point for what? There is certainly a point for putting "static" on
the declaration of that, at function scope, however small the cost of
omitting it on a string that happens to be very short.

>> Unfortunately, "static" means different things at function scope and at
>> file scope.
>
>Yes, and instead of using static keyword in the global scope it is better to
>use an anonymous namespace.

That's irrelevant. I was not suggesting "static" at global scope, I was
explaining why I did _not_ use "static" at global scope in the previous
example. Besides, consts at file scope are "static" in that sense by
default anyway. For purposes of this thread it matters not whether the
globals are declared "static" or in a namespace, or neither. It only
matters regarding the locals.

>You are wrong. static variables inside a function scope are still created in
>the stack.

No, not this time. Static variables wouldn't be static if they were on
the stack. If they were on the stack, where do you think their values
would be preserved from one call of the function to the next?

To illustrate, here is an compilable example:

const char* const MYSTRING = "ABC";
const char mystring[] = "ABC";
int main()
{
const char * cptr;
cptr = mystring; // line 6
cptr = MYSTRING; // line 7
static const char mystring[] = "ABC";
cptr = mystring; // line 9
static const char* const MYSTRING = "ABC";
cptr = MYSTRING; // line 11
}

I compiled that with MSVC 6.0 with default no optimization options (for
most straightforward translation) and /Fa for assembly listing output.
Here is the generated initialized data. You will notice the extra DD
storage for the two pointers, and that both of the "static" local
variables with the mangled names are in compile-time initialized
constant memory, not on the stack.

CONST SEGMENT
_MYSTRING DD FLAT:$SG265
_mystring DB 'ABC', 00H
_?mystring@?1??main@@9@4QBDB DB 'ABC', 00H
_?MYSTRING@?1??main@@9@4QBDB DD FLAT:$SG275
CONST ENDS
_DATA SEGMENT
$SG265 DB 'ABC', 00H
$SG275 DB 'ABC', 00H
_DATA ENDS

Now here is the MSVC generated code from the body of main(). Please
notice that the only variable on the stack is the non-static "cptr".
At no time does the code copy the characters "ABC\0" to the stack from
somewhere else. Also, there is the extra instruction required for
indirection in each of the pointer versions.

; Line 6
mov DWORD PTR _cptr$[ebp], OFFSET FLAT:_mystring
; Line 7
mov eax, DWORD PTR _MYSTRING
mov DWORD PTR _cptr$[ebp], eax
; Line 9
mov DWORD PTR _cptr$[ebp], OFFSET FLAT:_?mystring@?1??main@@9@4QBDB
; Line 11
mov ecx, DWORD PTR _?MYSTRING@?1??main@@9@4QBDB
mov DWORD PTR _cptr$[ebp], ecx

So you see, it is all exactly as I have told you.

"David Harmon" <> wrote in message
news:...
> On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
> <> wrote,
> >At first, i assumed the definition takes place in a local scope and not
in
> >the global or a namespace scope.
>
> I assumed otherwise, since I have seen some huge number of such #define
> constants in C code, and a somewhat lesser number of const strings in
> C++ code, and the vast majority of them were near the top of the file
> before any functions, if not in headers included near the top of the
> file before any functions.


The subject is a bit confused. In the case of macros, it doesn't count where
the macro is defined but where it is used, so since it was substituted
inside a function (turning MYSTRING[0] to "ABC"[0] before compilation takes
place), i considered it local. On the other hand he could place my
suggestions in a header file in the place of the macro definition, but it
doesn't matter anyway.



> >> static const char mystring[] = "ABC";
> >
> >There would be no point for this. The time cost for creating this thing
is a
> >joke. (Even the compiler may optimise it entirely out).
>
> No point for what? There is certainly a point for putting "static" on
> the declaration of that, at function scope, however small the cost of
> omitting it on a string that happens to be very short.


In this case, i wouldn't use an array myself but a const char * const, but
never mind. If there isn't a specific advantage for making it static, why
should one make it of static storage?



> No, not this time. Static variables wouldn't be static if they were on
> the stack. If they were on the stack, where do you think their values
> would be preserved from one call of the function to the next?


And where they get stored? As far as i know it is implementation-dependent
but i think the usual is stack.



>
> To illustrate, here is an compilable example:
>
> const char* const MYSTRING = "ABC";
> const char mystring[] = "ABC";
> int main()
> {
> const char * cptr;
> cptr = mystring; // line 6
> cptr = MYSTRING; // line 7
> static const char mystring[] = "ABC";
> cptr = mystring; // line 9
> static const char* const MYSTRING = "ABC";
> cptr = MYSTRING; // line 11
> }
>
> I compiled that with MSVC 6.0 with default no optimization options (for
> most straightforward translation) and /Fa for assembly listing output.
> Here is the generated initialized data. You will notice the extra DD
> storage for the two pointers, and that both of the "static" local
> variables with the mangled names are in compile-time initialized
> constant memory, not on the stack.
>
> CONST SEGMENT
> _MYSTRING DD FLAT:$SG265
> _mystring DB 'ABC', 00H
> _?mystring@?1??main@@9@4QBDB DB 'ABC', 00H
> _?MYSTRING@?1??main@@9@4QBDB DD FLAT:$SG275
> CONST ENDS
> _DATA SEGMENT
> $SG265 DB 'ABC', 00H
> $SG275 DB 'ABC', 00H
> _DATA ENDS


I see a DD and a DB. But i do not know much of assembly, only very basic
theoretic, that we fetch data from memory to registers and vice versa,
e.t.c..

So you mean that it is in a memory area reserved by the implementation. I
can agree with that. The static storage space is implementation defined but
i thought that the usual is stack (at the beginning of it).


>
> Now here is the MSVC generated code from the body of main(). Please
> notice that the only variable on the stack is the non-static "cptr".
> At no time does the code copy the characters "ABC\0" to the stack from
> somewhere else.


You mean that the compiler optimises it out. I can agree with that, but
there is no guarantee that it will happen with all compilers, even with
different versions of the same compiler. The overall implementation details
we are discussing here are implementation-dependent. What i said is that if
we define a built in array like this as auto, there is no real performance
gain in most platforms. I think we should define a built in array to have
static storage only when we see actual benefit from it. In the
squeeze-every-cycle attitute (that i also had few years ago), you can gain 1
cycle or two after subsequent function calls with that char array, but in my
1,000,000 Hz CPU (and i bet you have a faster one) it will not be noticed,
especially when the system idle process of windows takes 95% of the CPU time
in the usual workload.

I consider the use of static only for some object whose creation/destruction
introduces significant time cost. Now if someone likes to optimise the
run-time of creation/destruction of some chars, it is fine with me.






Ioannis Vranos

Christopher Benson-Manica wrote:
> ...
>>>const char* const MYSTRING = "ABC";
>
>> const char mystring[] = "ABC";
>
> Are there any situations where the behavior of these two constructs
> differs?

Technically, yes. Remember that, firstly, string literal is an object
with static storage duration in C++. It has no name but it has its own
address in storage. And secondly, the implementation is allowed to merge
identical literals. The consequence of this is that in the following code

const char* const MYSTRING1 = "ABC";
const char* const MYSTRING2 = "ABC";

it is quite possible that both pointers will hold the same value
(depends on implementation).

However, if you do it this way

const char MYSTRING1[] = "ABC";
const char MYSTRING2[] = "ABC";

you can be sure that 'MYSTRING1' and 'MYSTRING2' are two different
objects and values of '&MYSTRING1' and '&MYSTRING2' are guaranteed to be
different.

In most cases this behavior makes no difference in the actual program.
But in some cases it could.

--
Best regards,
Andrey Tarasevich

On Fri, 16 Apr 2004 23:46:01 +0300, "Ioannis Vranos"
<> wrote in comp.lang.c++:

> "David Harmon" <> wrote in message
> news:...

[snip]

> In this case, i wouldn't use an array myself but a const char * const, but
> never mind. If there isn't a specific advantage for making it static, why
> should one make it of static storage?
>
>
>
> > No, not this time. Static variables wouldn't be static if they were on
> > the stack. If they were on the stack, where do you think their values
> > would be preserved from one call of the function to the next?
>
>
> And where they get stored? As far as i know it is implementation-dependent
> but i think the usual is stack.

Since you have no idea at all how hardware stacks are used in typical
processors under typical C++ implementations, perhaps you shouldn't
try to answer questions here by discussing them incorrectly.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html