Topic: || and && with void argument (was: Proposal fix: [i,j] => [i;j])
Author: Alexandre Oliva <oliva@dcc.unicamp.br>
Date: 1996/12/23 Raw View
James Kanze writes:
> bradds@concentric.net (Bradd W. Szonye) writes:
> |> David Sachs <b91926@fsui02.fnal.gov> wrote in article
> [...]
> |> > open(FILE, file) || die(); // C++ is not Pascal
> [...]
> |> And I do consider this a "superior" notation, in that it emphasizes the
> |> "normal" course of events. In the same way that exception handling is
> |> superior notation in that it segregates the exceptional code after the
> |> normal course of events.
> More generally, in C++, in cases where failure would not be considered
> normal (say, createTempFile), I would just write the function, and let
> exceptions do their job. (Unless special actions are taken, exceptions
> cause an abnormal program termination. Which is, IMHO, an excellent
> default, and probably what die() does.)
Then I'd prefer to write:
FILE = open(file) || throw "Cannot open file";
By the way, what is the type of a throw expression? Is it void?
The Nov'96 DWP says [except.throw]:
2 [...] The type of
the throw-expression shall not be an incomplete type, or a pointer or
reference to an incomplete type, other than void*, const void*,
volatile void*, or const volatile void*.
But I guess it's actually referring to the expression just after the
keyword "throw", not to the type of the evaluated throw expression
(which is never available anyway).
If it were defined to be the same type as the throw argument, there
would be a "portable" way to check the order arguments are evaluated:
void foo(int, bool);
void bar() {
foo(throw 1, throw false);
}
But then what would the type of a throw expression without any
argument be?
--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]
Author: James Kanze <james-albert.kanze@vx.cit.alcatel.fr>
Date: 1996/12/26 Raw View
Alexandre Oliva <oliva@dcc.unicamp.br> writes:
|> By the way, what is the type of a throw expression? Is it void?
Presumably, the same type as a delete expression:-).
Actually, there is a hint that a throw expression should be of type
void, in 5.16: "[Concerning conditional operator...] Both the second and
the third operands have type void; the result is of type void and is an
rvalue. [Note: this includes the case where both operands are
throw-expressions.]" (I'm not sure if the note is normative, but it
certainly would be indicative of the intent of the standards committee.)
Logically, I think that both throw and delete should have void type.
Practically, it would be nice if this were explicit in the standard. (I
think that adding words to this effect would qualify as a simple
clarification, and should not delay the standardization process.)
|> The Nov'96 DWP says [except.throw]:
|>
|> 2 [...] The type of
|> the throw-expression shall not be an incomplete type, or a pointer or
|> reference to an incomplete type, other than void*, const void*,
|> volatile void*, or const volatile void*.
|>
|> But I guess it's actually referring to the expression just after the
|> keyword "throw", not to the type of the evaluated throw expression
|> (which is never available anyway).
I'm almost certain of this, but it is sloppy wording. The term
throw-expression is part of the grammar, where it very definitly does
mean the entire expression, including the "throw" keyword.
--
James Kanze home: kanze@gabi-soft.fr +33 (0)3 88 14 49 00
office: kanze@vx.cit.alcatel.fr +33 (0)1 69 63 14 54
GABI Software, Sarl., 8 rue des Francs Bourgeois, F-67000 Strasbourg, France
-- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated. To submit articles: Try just posting with your
newsreader. If that fails, use mailto:std-c++@ncar.ucar.edu
comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
Comments? mailto:std-c++-request@ncar.ucar.edu
]