Re: Index a #define string

From: Ioannis Vranos (ivr_at_guesswh.at.emails.ru)
Date: 04/16/04 

Date: Fri, 16 Apr 2004 23:46:01 +0300

"David Harmon" <source@netcom.com> wrote in message
news:4094284f.54313113@news.west.earthlink.net...
> On Fri, 16 Apr 2004 20:46:22 +0300 in comp.lang.c++, "Ioannis Vranos"
> <ivr@guesswh.at.emails.ru> 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

Relevant Pages

  • Re: Do buffers always start with the lowest memory address being the first element?
    ... > The C standard does not assume a downward-growing stack, ... > an upward-growing stack. ... C allows but does not require that the array produced ... > machine depends on both the C compiler and the machine. ...
    (comp.lang.c)
  • Re: Writing single bits to a file
    ... The 'const' keyword provides the same kind of benefit that prototypes ... enabling the compiler to warn you if it detects the fact that you ... I had not gone and more correctly fixed up the precedence heirarchy (unary ... I like to implement scripting languages for breakfast ...
    (comp.lang.c)
  • Re: switch statement, was compiler, status...
    ... Primary Register, Secondary Register, ... Stack, and abit of storage does it. ... This version of Small-C is copyrighted as a revision to Ron Cain's ... Croatia) is "Calculator Compiler" by Senko Rasik. ...
    (alt.lang.asm)
  • Re: const
    ... > const modifiers, ... willing to remove the const'ness with a cast, ... I don't know how good a cross-file compiler could be - it would have to be ... it's a guarantee by the programmer. ...
    (comp.programming)
  • Re: back online again...
    ... really "acceptable") convention. ... stack machine, but the design ... target with my compiler (may need a different name for this though, ... most of this code is not likely to ever go to object files anyways... ...
    (alt.lang.asm)