At 17:50 +0100 2005/03/26, Laurence Finston wrote:
> With unions, one wants to avoid dynamic allocations. Each dynamic
allocation takes several tens, sometimes, hundreds of cycles.
If pointers are used, then memory needs to be allocated for the objects they
point to, whether the pointers are in a
> With unions, one wants to avoid dynamic allocations. Each dynamic
> allocation takes several tens, sometimes, hundreds of cycles.
If pointers are used, then memory needs to be allocated for the objects they
point to, whether the pointers are in a `struct' or a `union'. It needn't be
allocated
At 14:56 +0100 2005/03/25, Laurence Finston wrote:
> This discussion is very confusing, because it mixes two topics:
Extending C++, and what is appropriate for Bison.
This is just my opinion, but I don't think adding type information to
`union'
would be in the spirit of C. If this feature were
From: Hans Aberg
--
--
> This discussion is very confusing, because it mixes two topics:
> Extending C++, and what is appropriate for Bison.
This is just my opinion, but I don't think adding type information to `union'
At 11:10 +0100 2005/03/24, Laurence Finston wrote:
> It would not be the old union, but a new union with new required
semantics, that is clear.
My point was that `union' is an element of the C and C++ languages,
whereas your new `Union' class would not be. I think this is important,
others may n
At 19:34 +0100 2005/03/23, Laurence Finston wrote:
> One would need to
be aware that the C++ unions
The rest of this sentence was missing.
If one adds such semantics to the C++ union, one needs to be aware of
that it differs from that of the C union. I think this should be
without problem, as o
On Thu, 24 Mar 2005, Hans Aberg wrote:
> It would not be the old union, but a new union with new required
> semantics, that is clear.
My point was that `union' is an element of the C and C++ languages,
whereas your new `Union' class would not be. I think this is important,
others may not.
> >Th
At 19:34 +0100 2005/03/23, Laurence Finston wrote:
On Wed, 23 Mar 2005, Hans Aberg wrote:
At 14:16 +0100 2005/03/23, Laurence Finston wrote:
>Add it where?
Just add a field, invisible to the user, with the type information.
I meant "in C++ or in Bison?"
In the context, I though you meant exten
On Wed, 23 Mar 2005, Hans Aberg wrote:
> At 14:16 +0100 2005/03/23, Laurence Finston wrote:
> >Add it where?
> Just add a field, invisible to the user, with the type information.
I meant "in C++ or in Bison?"
> Dynamic allocations must have such a field with the size, so that it
> can be prope
At 14:16 +0100 2005/03/23, Laurence Finston wrote:
> The union does not
contain any type information which field is selected. If one adds that,
unions with non-trivial con-/de-Structors would be possible.
Add it where?
Just add a field, invisible to the user, with the type information.
Dynamic
Hans Aberg wrote:
> With unions, the problem is, if con-/de-structors are non-trivial, that it
> is impossible to know which ones to apply and when.
Stroustrup, _The C++ Programming Language_, Special Edition, 2000,
p. 257, Section 10.4.12:
"Consequently, a union may not have members with constr
At 10:39 +0100 2005/03/22, Laurence Finston wrote:
On Mon, 21 Mar 2005, Hans Aberg wrote:
They should be OK in C++, as pointers do not have non-trival
con-/de-structors. The compiler needs to see a declaration of the
name as a type, though, before it sees the pointer.
If I remember correctly, it
On Tue, 22 Mar 2005, Laurence Finston wrote:
> @=%type path_primary@>@/
> [...] in the rule
> `path_primary: SUBPATH numeric_list OF path_primary',
> `$4' can only be a `Path*', cast to `void*'.
This isn't true. The semantic value of a symbol of type
`pointer_value' can be 0, which I've found
On Sun, 20 Mar 2005, DYP wrote:
> My %union is declared in the following way [...]
>
> %union{
> float fconst;
> int type;
> astNode* node;
> string* name;
> nodeList* list;
>}
>
If you don't mind an unsolicited suggestion,
On Mon, 21 Mar 2005, Hans Aberg wrote:
> They should be OK in C++, as pointers do not have non-trival
> con-/de-structors. The compiler needs to see a declaration of the
> name as a type, though, before it sees the pointer.
If I remember correctly, it has to do with the size of the objects not
be
Sent: Monday, March 21, 2005 1:17 PM
>To: [EMAIL PROTECTED]
>Cc: help-bison@gnu.org
>Subject: Re: %union errors that shouldn't be there
>
>It looks as though the C++ compiler does not see the declaration of
>the types astNode, string (is it std::string?), nodeList, before it
>sees
on@gnu.org
Subject: Re: %union errors that shouldn't be there
It looks as though the C++ compiler does not see the declaration of
the types astNode, string (is it std::string?), nodeList, before it
sees the union that the parser implements. So, you have to make sure
that info is included somewh
It looks as though the C++ compiler does not see the declaration of
the types astNode, string (is it std::string?), nodeList, before it
sees the union that the parser implements. So, you have to make sure
that info is included somewhere, perhaps in the %{ ... %} segment
before the %union in the
At 11:55 +0100 2005/03/21, Laurence Finston wrote:
On Sun, 20 Mar 2005, DYP wrote:
In file included from misery.ll:30:
gram.yy:26: error: ISO C++ forbids declaration of `astNode' with no type
gram.yy:26: error: expected `;' before '*' token
gram.yy:27: error: ISO C++ forbids declaration of `str
On Sun, 20 Mar 2005, DYP wrote:
> In file included from misery.ll:30:
> gram.yy:26: error: ISO C++ forbids declaration of `astNode' with no type
> gram.yy:26: error: expected `;' before '*' token
> gram.yy:27: error: ISO C++ forbids declaration of `string' with no type
> gram.yy:27: error: expecte
Hello,
My %union is declared in the following way and does have the proper
header file included but I still get errors that should not be there.
%union{
float fconst;
int type;
astNode* node;
string* name;
nodeList* list;
}
21 matches
Mail list logo
