What about cross compilers? I develop on a desktop but my code runs on
an embedded device with different CPU and instruction set. Does my
compiler now need to be an emulator? Or be bundled with one.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

jsanga@cox.net wrote:
> What about cross compilers? I develop on a desktop but my code runs on
> an embedded device with different CPU and instruction set. Does my
> compiler now need to be an emulator? Or be bundled with one.

I'd see the primary purpose of "hermetic" rather as something which
gives code readers/reviewers a clear guarantee that a function has no
side effects.  As a side effect (pun intended), it facilitates a
potential optimization on common compiler/target combinations.

However, this optimization is by no means mandatory, so nothing keeps
cross compilers from continuing to work exactly as they do now.

-Gerhard
--
                   o o
Gerhard Wesp        |       http://www.cosy.sbg.ac.at/~gwesp/
                   \_/       See homepage for email address!

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle <nagle@animats.com> wrote:
> and it will be evaluated during program startup.  You don't
> get a compile-time constant, but do you really need one?

Well, it would be kind of nice.  We might deal with another function
which takes much longer to evaluate.

A really sophisticated compiler could detect that sqrt(2) will always
return the same value and do the computation at compile time.

Now the compiler might have a hard time to figure that out, so in order
to help it we could invent a function tag guaranteeing that its return
value only depends on its input parameters and nothing else, and that it
doesn't have any other side effects.  Let's call a function with these
properties a "hermetic" function.

hermetic double f( double const& x ) {

  // Forbidden because rand() isn't hermetic.
  int y = rand() ;

  // Allowed because sqrt() is hermetic.
  double s2 = sqrt( 2 ) ;

  // Allowed because operator+() is hermetic.
  return x + s2 ;

}

It appears that a function can be hermetic if it calls only hermetic
functions.  The question is, can one come up with a concise definition
of "hermetic" that fits well into the C++ class and function model?
I.e., how to define it for member functions, if objects are passed
around as function parameters, etc.

Hermetic functions with compile-time constant arguments can safely be
evaluated at compile time.

Do other languages implement a comparable notion?

-Gerhard
--
                   o o
Gerhard Wesp        |       http://www.cosy.sbg.ac.at/~gwesp/
                   \_/       See homepage for email address!

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Gerhard Wesp wrote:
> invent a function tag guaranteeing that its return
> value only depends on its input parameters and nothing else, and that it
> doesn't have any other side effects.  Let's call a function with these
> properties a "hermetic" function.
>
> hermetic double f( double const& x ) {
>   // Allowed because sqrt() is hermetic.
>   double s2 = sqrt( 2 ) ;

sqrt() has side effects.  It may set errno.  On many implementations
the result is dependent on something other than the argument, for
instance a run-time floating-point rounding mode.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

wade@stoner.com wrote:
> sqrt() has side effects.  It may set errno.  On many implementations
> the result is dependent on something other than the argument, for
> instance a run-time floating-point rounding mode.

D*mn.  I knew I'd miss something.  :)

OK, for the sake of the example let's use sin() instead and assume no
choice of FP rounding mode.

-Gerhard
--
                   o o
Gerhard Wesp        |       http://www.cosy.sbg.ac.at/~gwesp/
                   \_/       See homepage for email address!

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I would suggest that if a function has only the side effect of setting
errno, that it would be appropriate to allow it to be hermetic and
abort compilation in the event that the compile time evaluation DOES
set errno.

I like the idea of hermetic functions in general.  I'm not sure if they
fit into the design goals of c++, but I think I would enjoy working in
a language whose design goals included such things.

An interesting thought if we are to consider this seriously, IMHO,
would be whether there could be generalized 'symbolic algebra'
involved.  For example:

int foo(int in) {
  return in+rand()*(2+strlen("string")+sqrt(4));
}

This could be evaluated at compile time down to { return in+rand()*10;
}.

Basicly, the compiler would have to be able to interpret an inline
function, or compile it, or both depending on how it was actually used.
 This would relieve the syntactic annoyance of writing (e.g.)
tmp_sqrt<2>()  for compile time evaluation or sqrt(i) for run time
evaluation, and allow one to request compile time evaluation by (e.g.)
adding a const to a variable:

inline int sum(int lhs, int rhs) {
  return lhs+rhs;
}
int main() {
  const int clhs = 2;
  const int crhs = 2;
  int vlhs = 2;
  int vrhs = 2;

  cout << sum(clhs,crhs) << endl; // evaluates to cout << 4 << endl;
  cout << sum(clhs,vrhs) << endl; // evaluates to cout << sum(2,vrhs)
<< endl;
  cout << sum(vlhs,crhs) << endl; // evaluates to cout << sum(vlhs,2)
<< endl;
}

obviously not useful in this trivial example, but it could be.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> sqrt() has side effects.  It may set errno.  On many implementations
> the result is dependent on something other than the argument, for
> instance a run-time floating-point rounding mode.

I think the idea would be that the compiler would then return an error
when std::sqrt set errno.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Gerhard Wesp" <gwesp@cosy.sbg.ac.at> wrote in message
news:df8puc$77l$1@esel.cosy.sbg.ac.at...

> wade@stoner.com wrote:
>> sqrt() has side effects.  It may set errno.  On many implementations
>> the result is dependent on something other than the argument, for
>> instance a run-time floating-point rounding mode.
>
> D*mn.  I knew I'd miss something.  :)
>
> OK, for the sake of the example let's use sin() instead and assume no
> choice of FP rounding mode.

Fine, what is sin(1e30)? It's well defined, and it *can* be computed,
but whether it *should* be computed has been debated for decades.
As a result, you currently get about as many answers as implementations.
Should the compiler be guaranteed to get the same (semi-random)
answer as the runtime?

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

I think we've diverged into 'should sin or sqrt be considered hermetic
functions' which is probably best discussed at some point after 'should
there be such a thing as a hermetic function'

I'm crazy about the concept, but not the name.  SQL uses deterministic,
which is too long.  But again, probably best hashed out after one
determines if the little critters would be useful / implementable / a
source of weeping, wailing, and gnashing of teeth.

Note that my counter proposal above would only work for inline
functions, so one could assume by the one definition rule that the
behavior would be the same at compile time and at runtime (modulo
things that can be changed at runtime, for example the aformentioned
floating point settings).

Of course one would also have to consider whether we want to be able to
generate a compile time warning by declaring that 'write' is hermetic,
and including write(2,"oops",4) in a hermetic function.  My vote would
be that write should probably not be a hermetic function.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

(NOTE: I originally posted this on comp.lang.c++.modertated before I
knew of this group.  I believe this is actually the more appropriate
group since this is where it is recommended to discuss standard
proposals.  I hope I'm not breaking the group rules.)

I know that with template meta-programming, one can create functions
that will be evaluated at compile-time.  However, TMP has its
disadvantages:

(1) Templates do not support floating point numbers

(2) Many compilers will only recurse a certain number of levels (10 to
50).  Many useful calculations require possibly hundreds of levels of
recursion (especially for floating point calculations)

(3) Some experimental work has been done to support floating point
calculations using templates
(http://mi.eng.cam.ac.uk/~er258 /code/fp_template.html), but the speed
is terrible -- FLOPS measuring in the single digits.

Personally, I'd really love to see something provided by the language
that would allow evaluation of all the functions in <math> at compile
time.  For example:

    double root_2 =     // user defined variable
        meta_sqrt(2.0); // compile-time function

What do you guys think?

Many thanks!

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

kevin.hall@motioneng.com wrote:
> (NOTE: I originally posted this on comp.lang.c++.modertated before I
> knew of this group.  I believe this is actually the more appropriate
> group since this is where it is recommended to discuss standard
> proposals.  I hope I'm not breaking the group rules.)
>
> I know that with template meta-programming, one can create functions
> that will be evaluated at compile-time.  However, TMP has its
> disadvantages:

TMP was never an intended capability of templates. The template
features that make it possible were created for other reasons, and then
some clever people figured that they made TMP possible. However, the
syntax is extremely clumsy; it requires too much cleverness to figure
out how to use it.

> (1) Templates do not support floating point numbers
>
> (2) Many compilers will only recurse a certain number of levels (10 to
> 50).  Many useful calculations require possibly hundreds of levels of
> recursion (especially for floating point calculations)

The C++ standard, Annex B, recommends that an implementation support at
least 17 levels of recursion; however, it's only a recommendation.
There's no mandatory minimum value for that limit, so a compiler that
allows 0 levels of recursion would still be conforming.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]