[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Use variants to support objects as semantic values.
From: |
Paolo Bonzini |
Subject: |
Re: [PATCH] Use variants to support objects as semantic values. |
Date: |
Tue, 04 Nov 2008 09:26:54 +0100 |
User-agent: |
Thunderbird 2.0.0.17 (Macintosh/20080914) |
> I used "%define variants" for lack of a more intelligent name. Joel,
> you might have an opinion about this. Maybe api.type.variants?
Maybe stype.variants? It does not need to affect the API, because you
can use a wrapper around the union if variants are not used, so that the
as<> API works in both cases:
#include <cassert>
union u {
char a;
int b;
};
template<class U>
class union_variant {
U data;
public:
template <typename T> T& as() {
return reinterpret_cast<T&>(data);
}
template <typename T> const T& as() const {
return reinterpret_cast<const T&>(data);
}
operator U&() { return data; }
operator const U&() const { return data; }
};
int main()
{
union_variant<union u> v;
union u& test = v;
test.a = 10;
assert (v.as<char>() == 10);
}
The Bison parser would use a stack of union_variant<stype>'s and export
that as parser::semantic_type, but the parser::YYSTYPE would be a union.
for backwards-compatibility. In other words:
- parser::semantic_type is always accessed with as<>
- parser::YYSTYPE is not defined at all for variants, and is a union
otherwise.
In the medium term variants could be made the default, but in the
meanwhile there would be a way to write parsers that work both for
unions and for variants. What do you think?
> I just say that the java skeleton now uses %define stype, which is
> correlated. I regret that the names were not discussed first, now we
> face a lack of structure, although Joel had been careful up to now to
> propose something consistent.
"%define stype" goes with "#define YYSTYPE" in C/C++; it was introduced
before dotted names were introduced for %defines. Note that it is in
principle possible to move from "#define YYXYZ" to "%define xyz" for
this and other preprocessor macros in the C/C++ skeletons.
Paolo