Yigal Chripun wrote:
On 12/10/2009 18:45, BCS wrote:
Hello Michel,
On 2009-10-09 15:49:42 -0400, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Thanks!
I plan to add more text at the end of the chapter that discusses the
opportunities of CTFE. Walter revealed to me that CTFE, particularly
now after it's been improved by leaps and bounds by Don and by Walter
himself, could obviate a lot of the traditional metaprogramming
techniques developed for C++.
One question that bugs me is, where do you draw the line? Say there's
a metaprogramming problem at hand. How to decide on solving it with
CTFE vs. solving it with templates? It would be great to have a
simple guideline that puts in contrast the pluses and minuses of the
two approaches.
It is quite possible that templates get relegated to parameterized
functions and types, whereas all heavy lifting in metaprogramming
should be carried with CTFE.
My idea on templates is that they're good when you have type
parameters, or to create types based on constant parameters.
- - -
But an interesting thing I realized in the last few months is this:
all you can do with a template you can also do at runtime provided
sufficient runtime reflection capabilities. Even creating types!
Details follow.
I'd like to forward the thought that runtime reflection and type
creation is NOT a replacement for the same at compile time just as the
compile time version is not a replacement for the run time version.
Just to pick two differences: errors are forced to runtime and runtime
types can't be inlined.
you can have compile-time errors with (static) asserts and you can
inline runtime types by way of a smart JITer/VM and run-time profiling.
CTFE will get exceptions. Shin already put a patch in Bugzilla to do it
in a few special case; it's not included yet, since the intention is for
CTFE to support classes, and hence should support general exceptions.
OTOH, I think BCS was contrasting detecting errors during development
(at compile-time) instead of during deployment (at run-time).
