🚀 go-pugleaf

>>>>> "IB" == Igor Boukanov <boukanov@afrodite.fi.uib.no> writes:
IB>    My proposal is to change definition of the "integral
IB> constant-expression"[5.19] to something like this:

IB> An integral constant-expression is an expression that can be
IB> calculated at the compilation phase.

IB> And according to this one would be able to use inline functions in
IB> constant-expressions and instead of writing:
[...]

This would imply that `inline' is no longer mere ``hint'', but in certain
cases a requirement. Note that your proposed definition may either be
hard to implement or imprecise.

E.g.,

	inline int fac(int k) {
	    int r = 1;
	    while (k) r *= k--;
            return r;
	}

	double d[fac(10)];	// ??

It's certainly feasible to compute this at compile-time... but this sort
of requirement would make a compiler much more complex. (And it is not
feasible, in general, to determine whether it is feasible :).

	Daveed


[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <4h775a$m4s@ugress.uib.no> boukanov@afrodite.fi.uib.no (Igor
Boukanov) writes:

|>    My proposal is to change definition of the 
|> "integral constant-expression"[5.19] to something like this:

|> An    integral   constant-expression is an expression that can be calculated
|> at the compilation phase. 

|> And according to this one would be able to use inline
|> functions in constant-expressions and instead of writing:

|> #define ALIGN(number, base) ((number + base - 1) / base * base)
|> #define MAX(x, y) ((x > y) ? (x) : (y))
|> #define GRAD_TO_RADIAN(x) (x * 3.1415926 / 180)

|>    char buf[ALIGN(50, sizeof(float))];
|>    char buf2[MAX(sizeof(long), sizeof(double))];
|>    const double angle = GRAD_TO_RADIAN(30);

|> one can write:

|> inline unsigned T align(unsigned number, unsigned base) {
|>    return ((number + base - 1) / base * base);
|> } 

|> template<class T> inline T max(T x, T y){ 
|>    return (x > y) ? x : y;

|> inline double grad_to_radian(double x){
|>    return x * 3.1415926 / 180;
|> }

|>    char buf[align(50, sizeof(float))];
|>    char buf2[max(sizeof(long), sizeof(double))];
|>    const double angle = grad_to_radian(30);

|> So what do you think about this?

That it would be nice, but that there are two very big problems:

1. It would basically require a complete C++ interpreter in the
compiler, and

2. It would make the notion of constant expression somewhat
implementation dependant.  Suppose my compiler implements the function
sin as an inline invocation of a compiler built-in.  Can I then use sin
in a constant expression?
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
              -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

Igor Boukanov (boukanov@afrodite.fi.uib.no) wrote:
:    My proposal is to change definition of the 
: "integral constant-expression"[5.19] to something like this:
: 
: An    integral   constant-expression is an expression that can be calculated
: at the compilation phase. 
[...]
: So what do you think about this?

With appropriate restrictions on which in-line functions are allowed
in these expressions, it could be very convenient.  Note, however,
that compile-time calculability, like calculability in general, is
recursively undecidable, when you allow functions with recursion or
unbounded loops.

Tom Payne (thp@cs.ucr.edu)
---
[ To submit articles: try just posting with your news-reader.
                      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu.
]

J. Kanze (kanze@gabi-soft.fr) wrote:
> That it would be nice, but that there are two very big problems:

> 1. It would basically require a complete C++ interpreter in the
> compiler, and

But in almost all cases such interpreter is already present in C++ 
compilers! Because of cause all such const look expressions are correct 
C++ expressions so every C++ compiler has to generate a code that will 
evaluate them at run time and if forget about the crosscompilation case 
I think instead of putting the code to object file compiler can just execute 
it...

> 2. It would make the notion of constant expression somewhat
> implementation dependant.  Suppose my compiler implements the function
> sin as an inline invocation of a compiler built-in.  Can I then use sin
> in a constant expression?

Consider, for example, next:
const double x = 1.0 / (very small number); 
And of cause, the result will depend on exact representation of double... 

--
Regards, Igor Boukanov 
// igor.boukanov@fi.uib.no  http://www.fi.uib.no/~boukanov/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]

In article <4hh34b$21r@ugress.uib.no> boukanov@kvark.fi.uib.no (Igor
Boukanov) writes:

|> J. Kanze (kanze@gabi-soft.fr) wrote:
|> > That it would be nice, but that there are two very big problems:

|> > 1. It would basically require a complete C++ interpreter in the
|> > compiler, and

|> But in almost all cases such interpreter is already present in C++ 
|> compilers! Because of cause all such const look expressions are correct 
|> C++ expressions so every C++ compiler has to generate a code that will 
|> evaluate them at run time and if forget about the crosscompilation case 
|> I think instead of putting the code to object file compiler can just execute 
|> it...

Generating code and interpreting it are two different things.  For
example, the code generator only knows about the current scope (stack
frame); the compiler typically has no mechanism for maintaining the
image of multiple stack frames (needed is it is to evaluate a
function) internall.

|> > 2. It would make the notion of constant expression somewhat
|> > implementation dependant.  Suppose my compiler implements the function
|> > sin as an inline invocation of a compiler built-in.  Can I then use sin
|> > in a constant expression?

|> Consider, for example, next:
|> const double x = 1.0 / (very small number); 
|> And of cause, the result will depend on exact representation of double... 

Agreed.  That is why the above is not a constant expression, according
to the draft standard.  Think about the case of a cross-compiler: it
would be very unintuitive if `1.0 / (very small number)' gave
different results than assigning 1.0 to a double variable, then
dividing the double variable by `(a very small number)'.  A
(cross-)compiler is not required to emulate the floating point
arithmetic of the target machine.

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]