D - Once again: generalized "if"-statements
- Norbert Nemec (48/48) Jan 20 2003 Hi there,
- Sean L. Palmer (14/62) Jan 20 2003 The only real problem is that the scope of everything defined inside the...
- Mike Wynn (27/98) Jan 20 2003 I like the idea that a template can contain a compile time const as a pa...
- Norbert Nemec (26/37) Jan 21 2003 OK, you've got a point there! Guess, I have to drop that "if"-idea.
Hi there,
since my suggestion of "if"-statements outside of functions was somewhat
ripped apart during the discussion and I begin to understand somewhat more
now, I'll try to split out the core part and describe that again:
At the first sight, the generalized "if" statement offers exactly what
"version" does already: Together with a "version"-expression evaluating to
a boolean at compile-time:
if(version(MYSYMBOL)) {
...
} else {
...
}
does exactly what
version(MYSYMBOL) {
...
} else {
...
}
does at the moment. Anyway, since it would handle any kind of constant
expressions, it would go far beyond that, effectively offering everything
the "#if" directive does in C.
It does so without any significant complication of the language definition.
Actually, it might even make things simpler, since a "version"-expression
seems to be somewhat less intruding than the "version" statement.
Anyway, the real power of the construction will really show up together with
the expected "integers as template parameter" extension. Just a simple
example:
-------------------
template (int N)
class Someclass {
if(N<100) {
dosomething() { simplealgorithm(); }
} else {
HashTable table;
dosomething() { complexalgorithm(table); }
};
};
-------------------
This will render most uses of partial specialization as in C++ unnecessary.
Effectively, one could define completely different class contents for
different parameters, to be determined at compile time.
One useful addition might be the guarantee, that even within functions,
branches that will never be touched because compile-time-evaluable
"if"-statements, will not be compiled at all (i.e. only syntax-check, but
no symbol resolving) since the declaration of some symbols might have been
dependant on such constants as well.
Ciao,
Nobbi
Jan 20 2003
The only real problem is that the scope of everything defined inside the if body would have to be moved outside of the if. This is a C compatibility issue. It's ok for version to do it since it has no backward compatibility to deal with. It might be ok, that everything in the taken branch gets exposed and stuff in the non-taken branches stay hidden. version can also require a compile time constant expression. With if, you're never sure if it is, or isn't, a compile time constant. Sean "Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM> wrote in message news:b0h34s$16qj$1 digitaldaemon.com...Hi there, since my suggestion of "if"-statements outside of functions was somewhat ripped apart during the discussion and I begin to understand somewhat more now, I'll try to split out the core part and describe that again: At the first sight, the generalized "if" statement offers exactly what "version" does already: Together with a "version"-expression evaluating to a boolean at compile-time: if(version(MYSYMBOL)) { ... } else { ... } does exactly what version(MYSYMBOL) { ... } else { ... } does at the moment. Anyway, since it would handle any kind of constant expressions, it would go far beyond that, effectively offering everything the "#if" directive does in C. It does so without any significant complication of the languagedefinition.Actually, it might even make things simpler, since a "version"-expression seems to be somewhat less intruding than the "version" statement. Anyway, the real power of the construction will really show up togetherwiththe expected "integers as template parameter" extension. Just a simple example: ------------------- template (int N) class Someclass { if(N<100) { dosomething() { simplealgorithm(); } } else { HashTable table; dosomething() { complexalgorithm(table); } }; }; ------------------- This will render most uses of partial specialization as in C++unnecessary.Effectively, one could define completely different class contents for different parameters, to be determined at compile time. One useful addition might be the guarantee, that even within functions, branches that will never be touched because compile-time-evaluable "if"-statements, will not be compiled at all (i.e. only syntax-check, but no symbol resolving) since the declaration of some symbols might have been dependant on such constants as well. Ciao, Nobbi
Jan 20 2003
"Mike Wynn" <mike.wynn l8night.co.uk>
I like the idea that a template can contain a compile time const as a param
but why must you insist on 'if' when version is already an 'if'
template stuff ( int N ) {
class Someclass {
version( N < 100 ) {
dosomething() { simplealgorithm(); }
} else {
HashTable table;
dosomething() { complexalgorithm(table); }
} // version
} // class
} // template
stuff(1) will be a different instance to stuff(2) (although I'm sure some
smart ast processing might determine if they can be runtime version of the
same basic template).
"Sean L. Palmer" <seanpalmer directvinternet.com> wrote in message
news:b0hf9e$1egr$1 digitaldaemon.com...
The only real problem is that the scope of everything defined inside the
if
body would have to be moved outside of the if.
This is a C compatibility issue. It's ok for version to do it since it
has
no backward compatibility to deal with. It might be ok, that everything
in
the taken branch gets exposed and stuff in the non-taken branches stay
hidden.
version can also require a compile time constant expression. With if,
you're never sure if it is, or isn't, a compile time constant.
Sean
"Norbert Nemec" <nobbi_at_theorie3.physik.uni-erlangen.de NOSPAM.COM>
wrote
in message news:b0h34s$16qj$1 digitaldaemon.com...
Hi there,
since my suggestion of "if"-statements outside of functions was somewhat
ripped apart during the discussion and I begin to understand somewhat
more
now, I'll try to split out the core part and describe that again:
At the first sight, the generalized "if" statement offers exactly what
"version" does already: Together with a "version"-expression evaluating
to
a boolean at compile-time:
if(version(MYSYMBOL)) {
...
} else {
...
}
does exactly what
version(MYSYMBOL) {
...
} else {
...
}
does at the moment. Anyway, since it would handle any kind of constant
expressions, it would go far beyond that, effectively offering
everything
the "#if" directive does in C.
It does so without any significant complication of the language
definition.
Actually, it might even make things simpler, since a
"version"-expression
seems to be somewhat less intruding than the "version" statement.
Anyway, the real power of the construction will really show up together
with
the expected "integers as template parameter" extension. Just a simple
example:
-------------------
template (int N)
class Someclass {
if(N<100) {
dosomething() { simplealgorithm(); }
} else {
HashTable table;
dosomething() { complexalgorithm(table); }
};
};
-------------------
This will render most uses of partial specialization as in C++
unnecessary.
Effectively, one could define completely different class contents for
different parameters, to be determined at compile time.
One useful addition might be the guarantee, that even within functions,
branches that will never be touched because compile-time-evaluable
"if"-statements, will not be compiled at all (i.e. only syntax-check,
but
no symbol resolving) since the declaration of some symbols might have
been
dependant on such constants as well.
Ciao,
Nobbi
Jan 20 2003
Sean L. Palmer wrote:The only real problem is that the scope of everything defined inside the if body would have to be moved outside of the if. This is a C compatibility issue. It's ok for version to do it since it has no backward compatibility to deal with. It might be ok, that everything in the taken branch gets exposed and stuff in the non-taken branches stay hidden. version can also require a compile time constant expression. With if, you're never sure if it is, or isn't, a compile time constant.OK, you've got a point there! Guess, I have to drop that "if"-idea. Maybe, the better way to go would then be to generalize the "version" statement instead? Right now, it only takes version symbols that are something completely different from normal symbols. I can't see any straightforward way to extend that syntax for compile time boolean expressions. If the version statement were to take expressions, then the version symbols would have to be encapsulated in a defined(...) expression (like in C). This would break compatibility to the current syntax, changing from version(SYMBOL) { ... } to version(defined(SYMBOL)) { ... } Not really a pleasant idea, but the end result would be the cleanest can think of. Alternatively, one could introduce a new statement: conditional(somexpression) { ... } behaving just like version, except that it accepts an expression instead. Anyway, this would mean an unnecessarily complicated language definition for reasons of backward compatibility. In any case, this effectively comes back to the same thing I proposed for "if", only that runtime-if and compiletime-if get two different keywords. Up to discussion whether compiletime-if should be called "version" or something else. Ciao, Nobbi
Jan 21 2003