> > > The following translation unit appears to be well-formed.
> > > int x[true?throw 4:5];
> > > According to 5.19, this appears to be an integral constant
> > > expression: it is a conditional expression, involves only literals,
> > > and no assignment, increment, decrement, function-call, or comma
> > > operators. However, if this is well-formed, the standard gives no
> > > meaning to this declaration, since the array bound (8.3.4/1) cannot
> > > be computed.
> > > I believe the defect is that throw expressions should also be banned
> > > from constant expressions.
> > Although it threw me for a loop at first, I have to agree that the
> > declaration does appear to be well-formed as per 5.19. It also seems
> > that it ought to work as expected, i.e., either the exception is
> > thrown and x is not initialized, in which case the array bound is not
> > required, or x is initialized to a size of 5. In other words, I do
> > not agree that this is a defect.
> The problem is that the decision must occur at compile time. In the
> given expression, of course, the exception will always be thrown. But
> the expression is a compile time constant; how do you throw an exception
> at compile time?
> --
> Conseils en informatique oriente objet/
> Beratung in objektorientierter Datenverarbeitung
Of course our code cannot throw an exception at compile time, but
arrays are initialized at run time, when we certainly can do so.
Conceptually this is similar to the case of a file-scope static object
with a constructor. That constructor is invoked at run time, prior to
the start of main, and may well throw an exception at that time.
I do agree that the construct is confusing, and perhaps that alone is
sufficient reason to ban it, but its behavior does seem to me to be
well defined, at least in terms of whether and how the array is
initialized.
Of course, there is the related issue of how do you catch an exception
that occurs prior to entry to main. Will a function try block around
main catch such an exception? And what would you do with it if you
caught it? Seems to me that things could get pretty hairy if a user
initialization threw an exception prior to the start of main, perhaps
even before some parts of the stdlib, like std::cout say, were
initialized.
However, banning this particular construct because it might cause
unusual behavior in the gray area prior to the start of main could
logically be followed by a ban on all exceptions prior to entry to
main. That might very well be a good thing, but how would it affect
the rules governing construction of static objects?
This is a really interesting question and it's not at all clear to me
where we go with answers to it.
Randy.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]