Re: (Forward) declarations of enums
On 5 Dez., 19:58, Greg Herlihy <gre...@mac.com> wrote:
I think that the more straightforward approach would be to limit the
number of source files that include the enum definition (or references
to it, including function prototypes). Only those source files that
need the enum definition (say, to pass as an argument in a function
call) should include the necessary header.
This approach is fine and good, but I suppose that Alberto
describes a system, where the usual techniques have
been applied and that they can choose one of the following
routes:
- Switch to an indifferent (opaque), but unfortunately not
typesafe integral type in the interface, that can hold the
enum.
- Stay typesafe using the enum but to the risk that you
unnecessarily have to provide the enumerators all over
the code.
I think that Alberto's use-case happens much more often
than one might expect. Usually there exist many functions,
which only transfer the enum without the need to be aware
of the enumerators it can hold. This would also apply to
classes, like these:
struct Something {
enum State : unit64_t; // Would be fine
State s; // Even this should work
};
A forward-declaration of the enum E would be pointless - because
either a) a source file calls Func() (and therefore has to include the
complete definition of E anyway) or b) a source file does not call
Func() - in which case there is no reason to include either the Func()
function prototype or the forward declaration of E - in the first
place.
I cannot agree here. Please note that there exists special rules,
which allow a similar approach for classes. This is valid C++:
struct S;
void foo(S);
This is for essentially the described need that often exists:
A function declaration as a diffuse transfer capsule, which
does not have to be aware of the struct definition.
The rationale has nothing to do with the underlying type of the enum -
and everything to do with the fact that source files fall into either
one of the two categories mentioned above: those that require the
complete enum definition and those that do not need the enum
definition at all. Because, unlike a class object, which can be passed
by reference or pointer (and thus may be an incomplete type) - an enum
is always referenced by value. So the practice of forwardly declaring
a class - simply has no equivalent purpose when it comes to enums.
As shown above classes can also be provided as by-value
arguments and do not need to be complete types at the
point of function declaration.
Actually I totally agree with Alberto, the new typed enums
would be ideal candidates to support forward-declarable enum's.
As far as I recall from earlier discussions on this theme, the
current reason for *not* supporting forward-declarable enums
is based on the conclusion that this would have the effect that
pointers to enum's would need to be of the same size. This
reason is lapsed given the current proposal to support enum's
with specified underlying types. In contrast to classes, it
would definitivly make sense to allow
enum E : int;
because the actual "members" (aka enumerators) of the
enum are not relevant for the physical "representation" of
the enum. The more I think about it, the more I like this
idea!
Has this issue been discussed before? Could it be considered? Is there
something that I'm missing?
You are describing "strong" or "opaque" typedefs. See:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1891.pdf
This comes somewhat near, but after a short reading I don't see how
you can simply forward declare such an opaque type without providing
a definition for it. But viewing from a different angle I would say
that
"inheriting enums" are more or less a realization of these types -
only restricted on integral representations, but that is already ok
for Alberto.
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2141.html
This is not very much related, it more or less corresponds to the
predecessor of as "inheriting constructors" described in the most
recent proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2438.htm
It's obvious that I always need the *definition* of a base class to
realize this issue.
I am not sure whether strong typedefs will make it into C++ or not.
I don't know either. It seems the proposal has at least been
split into inheriting constructors and other parts. I don't know
which the other parts are. I will read your first provided link
completely to understand which meaning the word "opaque"
is meant here - it does not seem to mean an opaque type
that is usually meant with an incomplete type used as
a handle or similar, but I might err here.
Greetings from Bremen,
Daniel KrLgler
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]