Greg Ercolano wrote:
> Domingo Alvarez Duarte wrote:
>> Greg Ercolano wrote:
>>> Z:\tmp>.\foo.exe
>>> 00408040 = 00408048 = 00408050
>>> ^^ ^^ ^^
>> I didn't tried it but anyway the sizeof() will be replaced at compile
>> time by it's size and no double constant string will appear.
>
> Hmm, good point.
>
> Indeed this seems to be the case in both VC and g++; this test:
>
> #include<stdio.h>
> int main() {
> printf("%d = %d = %d\n", sizeof("unique"), sizeof("unique"),
> sizeof("unique"));
> return 0;
> }
>
> What's interesting here is the string "unique" does not end up
> in the binary with either compiler.
>
> Not looking at the C/C++ spec, I suppose a smart compiler should
> not bother to allocate the string at all if it appears inside of
> sizeof().
>
> So assuming this is defined behavior of C/C++ compilers,
> I'd be +1 on your macro technique, since it prevents programmer errors.
>
> The main concern is embedded compilers that fltk supports; they
> tend to be both tight on memory but borderline on compiler features.
> But if the sizeof() behavior regarding read-only strings is actually
> in the spec (and not a compiler specific optimization), then we could
> at least say "it's a bug in the compiler" if an embedded designer
> were to notice an overuse of memory.
>
Look at http://en.wikipedia.org/wiki/Sizeof they explain it there.
An extract of it:
Implementation
It is the responsibility of the compiler's author to implement the
sizeof operator in a way specific and correct for a given implementation
of the language. The sizeof operator must take into account the
implementation of the underlying memory allocation scheme to obtain the
sizes of various datatypes. sizeof is usually a compile-time operator,
which means that during compilation, sizeof and its operand get replaced
by the result-value. This is evident in the assembly language code
produced by a C or C++ compiler. For this reason, sizeof qualifies as an
operator, even though its use sometimes looks like a function call.
Applying sizeof to dynamic arrays, introduced in C99 is an exception to
this rule.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
