Index a #define string

S

s

Can I do this:

#define MYSTRING "ABC"
..
..
..
char mychar = MYSTRING[0];
..
..
..



-Thanks,
s
 
L

lallous

s said:
Can I do this:

#define MYSTRING "ABC"
.
char mychar = MYSTRING[0];

-Thanks,
s
Hello

Tried it with VC and it works fine.
Also: char mychar = *MYSTRING works fine.
 
P

Petec

s said:
Can I do this:

#define MYSTRING "ABC"
.
.
.
char mychar = MYSTRING[0];
.
.
.



-Thanks,
s

I would suggest using:
const char* const MYSTRING = "ABC";

AFAIK, your #define string thing should work, though.

- Pete
 
I

Ioannis Vranos

s said:
Can I do this:

#define MYSTRING "ABC"
.
.
.
char mychar = MYSTRING[0];



Yes, but why do this anyway. Avoid macros completely.

In this case you can do:

char mychar="ABC"[0];


or


const char * const MYSTRING="ABC";

char mychar=MYSTRING[0];






Ioannis Vranos
 
T

Thomas Matthews

s said:
Can I do this:

#define MYSTRING "ABC"
.
.
.
char mychar = MYSTRING[0];
.
.
.



-Thanks,
s

This is a FAQ, but listed in the C language FAQ.
Reading the FAQs before posting is always a good
idea.
http://www.eskimo.com/~scs/c-faq/q6.11.html


--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.raos.demon.uk/acllc-c++/faq.html
Other sites:
http://www.josuttis.com -- C++ STL Library book
 
J

John Carson

s said:
Can I do this:

#define MYSTRING "ABC"
.
.
.
char mychar = MYSTRING[0];
.

The preprocessor simply does a text substitution so you end up with:

char mychar = "ABC"[0];

This is perfectly valid; it assigns 'A' to mychar. As far as the surrounding
code is concerned, a string literal is just a pointer.
 
I

Ioannis Vranos

Christopher Benson-Manica said:
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.






Ioannis Vranos
 
I

Ioannis Vranos

Christopher Benson-Manica said:
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
 
D

David Harmon

On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
Christopher Benson-Manica said:
David Harmon said:
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.
 
I

Ioannis Vranos

David Harmon said:
On Fri, 16 Apr 2004 19:07:38 +0300 in comp.lang.c++, "Ioannis Vranos"
David Harmon <[email protected]> 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
 
C

Christopher Benson-Manica

Ioannis Vranos said:
You are wrong. static variables inside a function scope are still created in
the stack.

Assuming the implementation uses a stack.
 
D

David Harmon

On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
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.
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.
 
I

Ioannis Vranos

David Harmon said:
On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"


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
 
A

Andrey Tarasevich

Christopher said:
...
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.
 
J

Jack Klein

[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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top