help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: stl constructs inside the union block


From: lfinsto1
Subject: Re: stl constructs inside the union block
Date: Fri, 5 Oct 2007 10:51:00 +0200 (CEST)
User-agent: SquirrelMail/1.4.9a

> On 2 Oct 2007, at 23:48, Randy Smith wrote:
>
>> I'm trying to incorporate c++ stl constructs into the %union { }
>> block of yacc.  Specifically, I'm trying to do something similar to
>> this:
>>
>> %union {
>> ...
>>    std::list<unsigned int>* int_list;
>> ...
>> }
>>
>> This yields the error:
>>
>> eidd.y:100: error: using-declaration for non-member at class scope
>> eidd.y:100: error: expected `;' before '<' token
>>
>>

I'm having trouble interpreting these error messages.  Just to be sure, is
this line at line 100 of `eidd.y'?

std::list<unsigned int>* int_list;

There might be a reason for this, but I don't know why the compiler would
call `std::' a "using-declaration".  I would expect it to call it a
"namespace specifier" or something similar.  Nor do you have a semi-colon
before the '<' token.  On the other hand, cryptic error messages from GCC
are hardly unknown, and there's always some reason for them.

Perhaps it would help to put the global declaration `using std;' in a
place which will cause Bison to put it in the right place in the file of C
code it generates.  I'm a little rusty in this area --- perhaps in the
declarations area?  I don't know where it puts the `%union' declaration. 
It would be easy to test, though.  One could modify the skeleton file, but
that's the point at which I would decide not to bother.

On any "normal" system, all pointers will be the same size, so I don't see
any reason in principle why this shouldn't work.  However, I did have a
problem myself trying to use `vector<some_type>*' as the return value of
functions.  I now use a "wrapper" class which I've defined myself.  For
some reason, this works, although it is also a template class.  Go figure.
 My wrapper class has other advantages, so I'm not that concerned about
finding out the reason why what I tried before didn't work.  Of course,
I'd like to know, but trying to find out is way down on my priority list.

I'm pretty sure that Hans Aberg is correct and that the reason for your
problem involves `list<unsigned int>' not being instantiated at this point
during compilation.  I suppose you're including the correct header file? 
Based on my experience, compilation might not actually fail if it's not
included, although I think it ought to.  If it were me, I would
double-check, just to be sure.

Although there's always a reason for everything with GCC, computers being
deterministic, I find that there can be a point of diminishing returns
when trying to find out the reason for something.  It's more satisfying to
find the ultimate answer, of course, but sometimes one has to be satisfied
with getting it to work.  Sometimes, the answer then just falls into one's
lap when one least expects it.

In my opinion, the main sticking point is that C++ (together with the
STL), much as I like it, is just too complicated and demands too much of a
compiler and linker.  Just my two cents.

Laurence Finston








reply via email to

[Prev in Thread] Current Thread [Next in Thread]