[antlr-interest] Problem with C target output on example C grammar

[Gavin Lambert]

At 07:24 3/04/2008, Jim Idle wrote:
 >On the smart pointer thing, I did not realize (as I don't use 
smart
 >pointers) that they were passed around using a reference that 
was
 >not nullable, but I was looking at supporting boost for the C++
 >stuff, so I guess it would have fallen out of the trying. I will 

 >look into that, but I am still thinking that the answer is that 
it
 >is better not to initialize the return value.

There was some discussion a while back about a similar problem 
with initialising DateTime objects in C#, since they're value 
types and can't be initialised with 'null'.

Two options discussed were either avoiding the initialisation when 
you don't recognise the type (ie. still initialise ints and 
pointers etc, but assume anything else can self-initialise), or 
adding some in-grammar syntax to let ANTLR know how to initialise 
specific types (and then throwing an error if it encounters a type 
it doesn't recognise).

Of the two, I think the first is the simplest option, and should 
be sufficient for almost all cases.  (I don't think it's a big 
hardship to require that any type used in ANTLR has a default 
constructor.)

The only drawback I see to this is disguised pointers; if someone 
has defined "typedef FOO *PFOO;" for example then there's no way 
ANTLR can be expected to figure out that "PFOO" is a simple 
pointer, so it will end up being uninitialised.  I'm not sure 
there's any way of avoiding this short of saying "user beware" 
:)  (Or using option two instead.)