Re: o.k. to use boolean expression as array index?
On 18 Mrz., 04:17, Daniel Kr?gler <daniel.krueg...@googlemail.com>
wrote:
On 17 Mrz., 17:59, Arno <ascho...@think-cell.com> wrote:
[..]
In the example the bmax = 1 and value E(2) has an
unspecified value within E. The current C++ wording
can be interpreted in a way that it could allow
an aggressive compiler to perform optimizations
based on the assumption that the values must be
within bmin and bmax. If I correctly remember,
there will be a corresponding core issue added
in the next updated issue list.
Rereading this, I notice that the text can easily
be misinterpreted. While it is true, that there
is some issue involved with the current specification
of enumeration values outside it's ranges, this
case seems not to apply in your situation. It
could happen in other situations as in:
int func2(E e) {
if (e > 1) throw e; // #
int arr[] = {3,4};
return arr[e==e1];
}
#include <iostream>
int main() {
try {
func2(E(2));
} catch(E e) {
std::cerr << "Invalid enum value: " << int(e) << std::endl;
}
}
In this situation a C++ compiler is currently
allowed to optimize the line marked with #
(including the complete try/catch frame within
main) away.
The most likely origin of your problem without
any further data available is, that you caused
an overflow on a enum with signed underlying
type (OK in C++03, not OK in C++0x given
your example enumeration type E), which has
undefined behavior. In this case the funny
bool bit patterns are easily explained as traces
of the higher bits that remain in the destination
register during conversion to bool.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]