Topic: functions in constant expressions
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/18 Raw View
In article <m33ec1vhgy.fsf@fred.muc.de>,
ak@muc.de wrote:
> jkanze@otelo.ibmmail.com writes:
>
> > For the moment, we don't see too much of this in C++, because it is
> > all the implementors can do to keep up with the language. Now that
> > we (almost) have a standard, however, I would say that in 3-5 years
> > time, it would be a very poor compiler which doesn't recognize the
> > special cases of vector, where it can determine that the size is given
> > at initialization, and never changes, and generate basically the same
> > code as if you had used a C style array.
>
> This is a really frightening thought - because it'll make C++ as a language
for
> compilers much more complex than it already is.
Better them than us. I'd rather have the compiler do extra work, than
have to do it myself. And without this optimization (or similar such
things), I'm sure that there will be times when I'll have to forego
the convenience of vector because of performance reasons.
(The optimization is probably not as difficult as it seems; it can basically
be done by rewriting the source to use a built-in array, thus, with no
impact on the parser, code generator, etc. The tricky part is detecting
when you can do it, but even if you miss a few, it would probably be
worth it.)
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ak@muc.de
Date: 1998/07/14 Raw View
"Martijn Lievaart" <Invalid@against.spam.nl> writes:
> Care to explain this one? I never saw a C++ compiler where it wasn't a
> function in the runtime library (a heavily optimized handcrafted assembler
> function, but still a function). The compiler knows nothing (and shouldn't
> know) about this function AFAIK.
gcc knows about this function (or rather about __builtin_strlen()) and
expands it inline without any headers. It also optimizes constant strlen()s
away ( x = strlen("a"); turns into x = 1; )
g++ does not seem to, although the executable contains "strlen" and
"__builtin_strlen" (?)
I'm pretty sure that other compilers support this too, I remember seeing
it often in compiler documentation.
Of course the runtime library still needs to contain strlen in case the user
wants to take strlen's address [alternatively the compiler could generate
a private copy then like for inline functions, but putting only one copy
into the runtime library is clearly better]
-Andi
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran)
Date: 1998/07/15 Raw View
>gcc knows about this function (or rather about __builtin_strlen()) and
>expands it inline without any headers. It also optimizes constant strlen()s
>away ( x = strlen("a"); turns into x = 1; )
>
>g++ does not seem to, although the executable contains "strlen" and
>"__builtin_strlen" (?)
When you compile without optimization or with debugging, the program
always calls strlen. When you compile with O1 or O2 or O3, and the
argument of strlen(...) is a constant, the compiler evaluates it at
compile time. No run-time call to strlen(...).
Also, if you use "-O --pedantic" and say
int array[strlen("name")];
the program gives an error message, saying that variable size arrays are
not allowed in C++. On the other hand, if you use "-O --pedantic" and
say
const int N=strlen("name");
it simply replaces N with 4 at compile time. So it only does the
optimization when the context of the program does not require an
integral constant.
>I'm pretty sure that other compilers support this too, I remember seeing
>it often in compiler documentation.
Other candidates for compile time evaluation are sin, cos, complex<double>.
Basically, all the commonly used mathematical functions.
Inline functions are also candidates for compile time evaluation, it seems
to me. In "The C++ Language" Bjarne Stroustrup says that a smart compiler
may replace fact(5) where fact(int) is something like
inline int fact(int x) { return x>1 ? x*fact(x-1) : 1 }
with 120. If the function weren't inline, I'm not sure if the subtitution
would be legal.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/15 Raw View
Martijn Lievaart wrote:
>
> J. Kanze wrote in message ...
> >sbnaran@localhost.localdomain (Siemel Naran) writes:
> >
> >|> >Not exactly. According to the language definition, the array
> >|> >size must be an integral constant-expression. Among other
> >|> >restrictions, an integral constant-expression cannot
> >|> >include a function call, and strlen is a function.
> >|>
> >|> This makes sense to me now. My original idea is that the compiler
> >|> could evaluate strlen(...) at compile time. But this function, no
> >|> matter how universal it is, it is not builtin to the C++ compiler.
> >
> >Yes it is. (Or more correctly, it is built into the C++ translation
> >system.) One could consider the stricture banning it as arbitrary,
> >but:
> >
>
> Care to explain this one? I never saw a C++ compiler where it wasn't a
> function in the runtime library (a heavily optimized handcrafted assembler
> function, but still a function). The compiler knows nothing (and shouldn't
> know) about this function AFAIK.
An implementation is allowed to handle reserved functions differently
than other functions, just as it's allowed to handle standard library
headers differently than other ones. That is why providing your own
definition for any reserved function has undefined results. In
particular, I've seen implementations that provided the option of
in-lining the definitions of many of the smaller standard library
functions, including most of the mem* and str* families, and most of the
math library.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/07/15 Raw View
sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
>Other candidates for compile time evaluation are sin, cos, complex<double>.
>Basically, all the commonly used mathematical functions.
Essentially all the components of the standard library are reserved
to the implementation and so are candidates for compile-time
evaluation. For example, a compiler could simplify
printf("%s", "a");
to
putc('a');
but I don't think a compiler would bother to perform that analysis.
>Inline functions are also candidates for compile time evaluation, it seems
>to me.
Of course. One of the major advantages of inline functions is
the combining of the code in the function body with the
code surrounding the call, eliminating copies of things,
folding constants, and performing other improvements.
Example:
inline int f(int a, int b) { return a + b; }
int g() { return f(1,2); }
I'd be surprised if a compiler generated anything but "return 3;"
for function g. Even if 'f' is not declared inline, compilers
can and do perform inlining and thus code simplication.
>In "The C++ Language" Bjarne Stroustrup says that a smart compiler
>may replace fact(5) where fact(int) is something like
> inline int fact(int x) { return x>1 ? x*fact(x-1) : 1 }
>with 120. If the function weren't inline, I'm not sure if the subtitution
>would be legal.
The language definition requires only that "observable behavior"
be preserved. Function "fact" has no observable behavior, since
it has no effect on anything outside itself.
With the example as presented, no valid program could detect
whether a closed subroutine was called for "fact(5)", or whether
the code was expanded inline, or whether the compiler evaluated
the function at compile time.
--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ak@muc.de
Date: 1998/07/15 Raw View
sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
[really getting off-topic for comp.std.c++ now]
> >gcc knows about this function (or rather about __builtin_strlen()) and
> >expands it inline without any headers. It also optimizes constant strlen()s
> >away ( x = strlen("a"); turns into x = 1; )
> >
> >g++ does not seem to, although the executable contains "strlen" and
> >"__builtin_strlen" (?)
>
> When you compile without optimization or with debugging, the program
> always calls strlen. When you compile with O1 or O2 or O3, and the
> argument of strlen(...) is a constant, the compiler evaluates it at
> compile time. No run-time call to strlen(...).
>
> Also, if you use "-O --pedantic" and say
> int array[strlen("name")];
> the program gives an error message, saying that variable size arrays are
> not allowed in C++. On the other hand, if you use "-O --pedantic" and
> say
> const int N=strlen("name");
> it simply replaces N with 4 at compile time. So it only does the
> optimization when the context of the program does not require an
> integral constant.
No, neither g++ 2.7.2 nor egcs g++ do this. Try it out yourself.
I would consider it a bug.
> >I'm pretty sure that other compilers support this too, I remember seeing
> >it often in compiler documentation.
>
> Other candidates for compile time evaluation are sin, cos, complex<double>.
> Basically, all the commonly used mathematical functions.
>
> Inline functions are also candidates for compile time evaluation, it seems
> to me. In "The C++ Language" Bjarne Stroustrup says that a smart compiler
> may replace fact(5) where fact(int) is something like
> inline int fact(int x) { return x>1 ? x*fact(x-1) : 1 }
> with 120. If the function weren't inline, I'm not sure if the subtitution
> would be legal.
You can force the compiler to do such computations during compile time too -
using templates. Templates are turing complete so you can do any computation.
See http://seurat.uwaterloo.ca/blitz/ for more information. For example it is
used there to unroll FFTs to the optimal size.
-Andi
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/15 Raw View
In article <slrn6qnsl0.48u.sbnaran@bardeen.ceg.uiuc.edu>,
sbnaran@KILL.uiuc.edu wrote:
> Inline functions are also candidates for compile time evaluation, it se=
ems
> to me. In "The C++ Language" Bjarne Stroustrup says that a smart compi=
ler
> may replace fact(5) where fact(int) is something like
> inline int fact(int x) { return x>1 ? x*fact(x-1) : 1 }
> with 120. If the function weren't inline, I'm not sure if the subtitut=
ion
> would be legal.
Inline is just a hint to the compiler -- a comment that the compiler
understands, if you prefer. Its only effect is to allow multiple
definitions of the function. It has no effect on the semantic of the
program using it. Thus, if an optimization is legal with inline, it
is legal without.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient=E9e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----=3D=3D Posted via Deja News, The Leader in Internet Discussion =3D=3D=
-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/15 Raw View
In article <6ofqlu$6h9@news3.euro.net>,
"Martijn Lievaart" <Invalid@against.spam.nl> wrote:
> J. Kanze wrote in message ...
> >sbnaran@localhost.localdomain (Siemel Naran) writes:
> >
> >|> >Not exactly. According to the language definition, the array
> >|> >size must be an integral constant-expression. Among other
> >|> >restrictions, an integral constant-expression cannot
> >|> >include a function call, and strlen is a function.
> >|>
> >|> This makes sense to me now. My original idea is that the compiler
> >|> could evaluate strlen(...) at compile time. But this function, no
> >|> matter how universal it is, it is not builtin to the C++ compiler.
> >
> >Yes it is. (Or more correctly, it is built into the C++ translation
> >system.) One could consider the stricture banning it as arbitrary,
> >but:
> >
>
> Care to explain this one? I never saw a C++ compiler where it wasn't a
> function in the runtime library (a heavily optimized handcrafted assembler
> function, but still a function).
I've seen several C compilers where most of the functions in string.h
were built into the compiler, and caused in line code to be generated.
It's generally not worth it on a risc machine, but on an Intel (at least
the pre-Pentium Intels) or the late NSC machines, it was a definite win.
Even on a risc machine, one could imagine that the library contained a
number of versions of, say, memcpy -- which one got called would depend
on the arguments (address alignment, number of bytes multiple of 2,4,8, etc.),
with a generic version used if none of the arguments were known at
compile time.
> The compiler knows nothing (and shouldn't
> know) about this function AFAIK.
Why not? The semantics of the function are defined by the standard, and the
user is not allowed to replace the version delivered by the implementation.
The library functions ARE part of the language; they are not something
separate.
For the moment, we don't see too much of this in C++, because it is
all the implementors can do to keep up with the language. Now that
we (almost) have a standard, however, I would say that in 3-5 years
time, it would be a very poor compiler which doesn't recognize the
special cases of vector, where it can determine that the size is given
at initialization, and never changes, and generate basically the same
code as if you had used a C style array.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: ak@muc.de
Date: 1998/07/16 Raw View
jkanze@otelo.ibmmail.com writes:
> For the moment, we don't see too much of this in C++, because it is
> all the implementors can do to keep up with the language. Now that
> we (almost) have a standard, however, I would say that in 3-5 years
> time, it would be a very poor compiler which doesn't recognize the
> special cases of vector, where it can determine that the size is given
> at initialization, and never changes, and generate basically the same
> code as if you had used a C style array.
This is a really frightening thought - because it'll make C++ as a language for
compilers much more complex than it already is.
-Andi
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: AllanW@my-dejanews.com
Date: 1998/07/14 Raw View
In article <slrn6qf64j.2bt.sbnaran@localhost.localdomain>,
sbnaran@uiuc.edu wrote:
> >Not exactly. According to the language definition, the array
> >size must be an integral constant-expression. Among other
> >restrictions, an integral constant-expression cannot
> >include a function call, and strlen is a function.
>
> This makes sense to me now. My original idea is that the compiler
> could evaluate strlen(...) at compile time. But this function, no
> matter how universal it is, it is not builtin to the C++ compiler.
> So then, it has to be evaluated at run time. But compilers may
> evaluate strlen(...), sin(...), cos(...), complex<double>(...),
> and so on at compile time when it is safe to do so -- i.e. the
> function is not used in a way that requires a compile time
> constant. If we wanted to evaluate functions at compile time, I
> guess we could use template meta-programming.
I have very often found this useful:
static const name[] = "My name";
// ...
char buf[30+sizeof(name)-1];
The symbol name now can be used wherever "My name" would have been
used, with the added bonus that it will only exist once in memory (some
compilers do this optimization automatically, but it never hurts to be
explicit). Further, you can use sizeof(name)-1 as a compile-time
(and therefore faster) equivalent to strlen(name).
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: "Martijn Lievaart" <Invalid@against.spam.nl>
Date: 1998/07/14 Raw View
J. Kanze wrote in message ...
>sbnaran@localhost.localdomain (Siemel Naran) writes:
>
>|> >Not exactly. According to the language definition, the array
>|> >size must be an integral constant-expression. Among other
>|> >restrictions, an integral constant-expression cannot
>|> >include a function call, and strlen is a function.
>|>
>|> This makes sense to me now. My original idea is that the compiler
>|> could evaluate strlen(...) at compile time. But this function, no
>|> matter how universal it is, it is not builtin to the C++ compiler.
>
>Yes it is. (Or more correctly, it is built into the C++ translation
>system.) One could consider the stricture banning it as arbitrary,
>but:
>
Care to explain this one? I never saw a C++ compiler where it wasn't a
function in the runtime library (a heavily optimized handcrafted assembler
function, but still a function). The compiler knows nothing (and shouldn't
know) about this function AFAIK.
Greetz,
Martijn (see sig for email address)
--
#include <stddisclaimer.h>
My email address is intentionally invalid agains spam.
Please reply to mlievaar at orion in nl
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/07/14 Raw View
"Martijn Lievaart" <Invalid@against.spam.nl> writes:
>J. Kanze wrote in message ...
>>
>>|> This makes sense to me now. My original idea is that the compiler
>>|> could evaluate strlen(...) at compile time. But this function, no
>>|> matter how universal it is, it is not builtin to the C++ compiler.
>>
>>Yes it is. (Or more correctly, it is built into the C++ translation
>>system.) One could consider the stricture banning it as arbitrary,
>>but:
>>
>Care to explain this one? I never saw a C++ compiler where it wasn't a
>function in the runtime library (a heavily optimized handcrafted assembler
>function, but still a function). The compiler knows nothing (and shouldn't
>know) about this function AFAIK.
The C (and also the C++) standard makes several requirements
about "strlen":
1. The name "::strlen" is reserved to the implementation if <string.h> (or
std::strlen if <cstring>) is included.
2. "strlen" is always reserved to the implementation for use as an
external identifier (unless it is in a namespace other than std).
3. The "strlen" function in the standard library has a defined
interface and semantics.
A program that does not respect these requirements has undefined
behavior.
Put them all together, and the compiler is allowed to assume
that any use of "strlen" when it is an external identifier
(and not qualified by a namespace other than std) is the one
from the standard library. The compiler is then free to
generate inline code for the function, or to evaluate its
result at compile time when its argument is known. This is
in fact a common optimization.
Finally, any program is allowed to take the address of the
library function and call it via a pointer. Since the compiler
cannot in general tell when that function will be called
in such a way, it must also provide an ordinary closed
function called "strlen" in the runtime library.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@localhost.localdomain (Siemel Naran)
Date: 1998/07/12 Raw View
>Not exactly. According to the language definition, the array
>size must be an integral constant-expression. Among other
>restrictions, an integral constant-expression cannot
>include a function call, and strlen is a function.
This makes sense to me now. My original idea is that the compiler
could evaluate strlen(...) at compile time. But this function, no
matter how universal it is, it is not builtin to the C++ compiler.
So then, it has to be evaluated at run time. But compilers may
evaluate strlen(...), sin(...), cos(...), complex<double>(...),
and so on at compile time when it is safe to do so -- i.e. the
function is not used in a way that requires a compile time
constant. If we wanted to evaluate functions at compile time, I
guess we could use template meta-programming.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: kanze@gabi-soft.fr (J. Kanze)
Date: 1998/07/13 Raw View
sbnaran@localhost.localdomain (Siemel Naran) writes:
|> >Not exactly. According to the language definition, the array
|> >size must be an integral constant-expression. Among other
|> >restrictions, an integral constant-expression cannot
|> >include a function call, and strlen is a function.
|>
|> This makes sense to me now. My original idea is that the compiler
|> could evaluate strlen(...) at compile time. But this function, no
|> matter how universal it is, it is not builtin to the C++ compiler.
Yes it is. (Or more correctly, it is built into the C++ translation
system.) One could consider the stricture banning it as arbitrary,
but:
1. Allowing it (but not arbitrary user functions) in constant
expressions would compilate the definition of a constant expression
enormously, and
2. Not allowing it does allow one of the more common implementations, in
which it is treated exactly like a user function.
|> So then, it has to be evaluated at run time. But compilers may
|> evaluate strlen(...), sin(...), cos(...), complex<double>(...),
|> and so on at compile time when it is safe to do so -- i.e. the
|> function is not used in a way that requires a compile time
|> constant.
It's slightly more complex. The reason the compiler cannot use it in a
constant expression is basically because the standard says so, period.
A program which tries to use it in a constant expression is illegal, and
the error is one that the compiler is required to diagnose.
In legal uses, of course, all the standard requires is that the
observable behavior conforms. Since replacing a function call which
always returns the same thing (strlen( "abcd" ), sin( 0.0 ) etc.) with
the returned value has no effect on the observable behavior, it is
always allowed.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jsa@edg.com (J. Stephen Adamczyk)
Date: 1998/07/07 Raw View
In article <35a23c07.0@news.primary.net> peter.garner@toward.com (Crazy Pete) writes:
> I was using KAI C++ to compile some code I downloaded and I got the error :
>
>error: expression must have a constant value
> char buf[30+strlen(name)];
>
>[...] Is the above construct allowed under FDIS?
No. An array bound expression must be a constant expression, and strlen(name)
is a function call.
C9X will likely have variable-length arrays, but the C++ FDIS does not.
Steve Adamczyk
Edison Design Group
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran)
Date: 1998/07/07 Raw View
>error: expression must have a constant value
> char buf[30+strlen(name)];
The size of a builtin array and also the argument of a template
list must be constants known at compile time. This way, the
compiler knows exactly how much space to reserve for these
objects.
If "name" is a constant known at compile time and the strlen
function applied to any variable X always returns the same
result -- i.e. strlen(...) is not a random number generator
or a status function -- then it follows that strlen(name) is
a constant known at compile time. Hence 30+strlen(name) is
also a constant known at compile time. So the above should
work. But all this depends depends on how smart your compiler
is.
In other words, this should be ok:
int main()
{
const char * name = "filename"; // note const!
char buf[30+strlen(name)]; // ok: same as [30+8]
}
And this is not ok:
int main()
{
char name[40]; // note non-const!
cin >> name;
char buf[30+strlen(name)]; // bad: [30+s], where s is a runtime constant
}
This is also not ok:
void action(const char * name)
{
char buf[30+strlen(name)];
// bad: name can be different in each call to this function
// even though it is declared with a "const"
// so [...] is not known at compile time
}
int main()
{
char tmp[40];
cout << "Enter a filename: " << flush;
cin.getline(tmp,sizeof(tmp));
action(tmp);
}
Bobby Schmidt's column in last month's C++ User's Journal says
that the C9X standard is thinking about adding arrays of
variable size, meaning that the above would be legal.
--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: David R Tribble <david.tribble@noSPAM.central.beasys.com>
Date: 1998/07/07 Raw View
Crazy Pete wrote:
>
> I was using KAI C++ to compile some code I downloaded and I got the
> error :
>
> error: expression must have a constant value
> char buf[30+strlen(name)];
>
> While I do not like such constructs myself, (I prefer to store results
> in a variable, and then use the variable) I am more concerned with
> the standard than my personal opinion. Is the above construct allowed
> under FDIS?
This is known as a Variable Length Array (VLA), which is not supported
in C++. Essentially, you can't define a variable (or type) unless
its length is known at compile time. Your example above doesn't
have a length until run time.
The only way to create such a variable-sized object is with a 'new'
expression:
bufp = new char[30+strlen(name)];
The new C draft (C9X), however, does allow VLAs (with a few caveats).
So your example would work as new C code.
-- David R. Tribble, dtribble@technologist.com --
-- C++, the PL/1 of the 90s.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: stephen.clamage@sun.com (Steve Clamage)
Date: 1998/07/07 Raw View
sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
>>error: expression must have a constant value
>> char buf[30+strlen(name)];
>The size of a builtin array and also the argument of a template
>list must be constants known at compile time. This way, the
>compiler knows exactly how much space to reserve for these
>objects.
>If "name" is a constant known at compile time and the strlen
>function applied to any variable X always returns the same
>result -- i.e. strlen(...) is not a random number generator
>or a status function -- then it follows that strlen(name) is
>a constant known at compile time. Hence 30+strlen(name) is
>also a constant known at compile time. So the above should
>work. But all this depends depends on how smart your compiler
>is.
Not exactly. According to the language definition, the array
size must be an integral constant-expression. Among other
restrictions, an integral constant-expression cannot
include a function call, and strlen is a function.
A compiler might allow the code as a language extension, but
to conform to the standard it must at minimum issue a
diagnostic message.
--
Steve Clamage, stephen.clamage@sun.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/08 Raw View
In article <6ntuh8$dc6@engnews1.Eng.Sun.COM>,
stephen.clamage@sun.com (Steve Clamage) wrote:
> sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
> Not exactly. According to the language definition, the array
> size must be an integral constant-expression. Among other
> restrictions, an integral constant-expression cannot
> include a function call, and strlen is a function.
One question: would something like sizeof( f() ) be legal, where the
expression is not evaluated?
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/08 Raw View
jkanze@otelo.ibmmail.com wrote:
>
> In article <6ntuh8$dc6@engnews1.Eng.Sun.COM>,
> stephen.clamage@sun.com (Steve Clamage) wrote:
> > sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
>
> > Not exactly. According to the language definition, the array
> > size must be an integral constant-expression. Among other
> > restrictions, an integral constant-expression cannot
> > include a function call, and strlen is a function.
>
> One question: would something like sizeof( f() ) be legal, where the
> expression is not evaluated?
Yes, since f() does not indicate a function call in that context.
Section 6.4 permits all sizeof() expression that do not involve VLA's or
parenthesized names of VLA's.
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jsa@edg.com (J. Stephen Adamczyk)
Date: 1998/07/08 Raw View
In article <6nvrp1$phb$1@nnrp1.dejanews.com> jkanze@otelo.ibmmail.com writes:
>[In a constant expression...]
>One question: would something like sizeof( f() ) be legal, where the
>expression is not evaluated?
Yes. And something like sizeof("abcd") is also valid (it gives 5, rather
than the 4 given by strlen, because it includes the final null character).
Steve Adamczyk
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: jkanze@otelo.ibmmail.com
Date: 1998/07/08 Raw View
In article <slrn6q4q0t.1d4.sbnaran@bardeen.ceg.uiuc.edu>,
sbnaran@uiuc.edu wrote:
> >error: expression must have a constant value
> > char buf[30+strlen(name)];
>
> The size of a builtin array and also the argument of a template
> list must be constants known at compile time. This way, the
> compiler knows exactly how much space to reserve for these
> objects.
This is true for C++, and formally still for C, but the upcoming
revision to the C standard allows variable length arrays in certain
contexts.
> If "name" is a constant known at compile time and the strlen
> function applied to any variable X always returns the same
> result -- i.e. strlen(...) is not a random number generator
> or a status function -- then it follows that strlen(name) is
> a constant known at compile time. Hence 30+strlen(name) is
> also a constant known at compile time. So the above should
> work. But all this depends depends on how smart your compiler
> is.
It has nothing to do with the compiler; the standard (C or C++) defines
what is and what isn't a compile time constant (an "integral constant
expression", in standardise). An executable function call is not a
compile time constant, regardless of what the compiler can or should
know. (This does not mean that the compiler cannot substitute the
constant into code, as an optimizing measure.) A compiler *must*
issue a diagnostic if a function call occurs in a context that requires
an integral constant expression.
> In other words, this should be ok:
> int main()
> {
> const char * name = "filename"; // note const!
> char buf[30+strlen(name)]; // ok: same as [30+8]
> }
>
> And this is not ok:
> int main()
> {
> char name[40]; // note non-const!
> cin >> name;
> char buf[30+strlen(name)]; // bad: [30+s], where s is a runtime constant
> }
Both are illegal in C++ and the current C standard. Both will be legal
in the next version of the C standard.
> This is also not ok:
> void action(const char * name)
> {
> char buf[30+strlen(name)];
> // bad: name can be different in each call to this function
> // even though it is declared with a "const"
> // so [...] is not known at compile time
> }
Again, legal in the next version of the C standard.
> int main()
> {
> char tmp[40];
> cout << "Enter a filename: " << flush;
> cin.getline(tmp,sizeof(tmp));
> action(tmp);
> }
>
> Bobby Schmidt's column in last month's C++ User's Journal says
> that the C9X standard is thinking about adding arrays of
> variable size, meaning that the above would be legal.
I think it has passed the stage of "thinking about it". They are
part of the CD; it would take a committee vote now to remove it.
--
James Kanze +33 (0)1 39 23 84 71 mailto: kanze@gabi-soft.fr
+49 (0)69 66 45 33 10 mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient e objet --
-- Beratung in objektorientierter Datenverarbeitung
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: James Kuyper <kuyper@wizard.net>
Date: 1998/07/09 Raw View
James Kuyper wrote:
>
> jkanze@otelo.ibmmail.com wrote:
> >
> > In article <6ntuh8$dc6@engnews1.Eng.Sun.COM>,
> > stephen.clamage@sun.com (Steve Clamage) wrote:
> > > sbnaran@bardeen.ceg.uiuc.edu (Siemel Naran) writes:
> >
> > > Not exactly. According to the language definition, the array
> > > size must be an integral constant-expression. Among other
> > > restrictions, an integral constant-expression cannot
> > > include a function call, and strlen is a function.
> >
> > One question: would something like sizeof( f() ) be legal, where the
> > expression is not evaluated?
>
> Yes, since f() does not indicate a function call in that context.
> Section 6.4 permits all sizeof() expression that do not involve VLA's or
> parenthesized names of VLA's.
Sorry; wrong language. The corresponding section for C++ is 5.19, and of
course does not need an exception for VLA's.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Author: peter.garner@toward.com (Crazy Pete)
Date: 1998/07/07 Raw View
Hi All! :-)
I was using KAI C++ to compile some code I downloaded and I got the error :
error: expression must have a constant value
char buf[30+strlen(name)];
While I do not like such constructs myself, (I prefer to store results in a variable, and then use the variable) I am more concerned with the standard than my personal opinion. Is the above construct allowed under FDIS?
Thank you kindly
Peter
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]