Feedback needed: Complete symbol appoach for Bison's D backend

H. S. Teoh hsteoh at
Mon Nov 16 19:42:43 UTC 2020

On Sat, Nov 14, 2020 at 03:50:23PM +0000, Adela Vais via Digitalmars-d wrote:
> I need some feedback about the return value of yylex() in Bison's
> Lexer class, which must be provided by the user.
> An example of the current method, using TokenKind:
> An example using the Symbol struct:

Hi Adela,

I took a quick look the code.  I agree that returning Symbol is best
because it gives the most friendly API.

Generally, returning a struct ought to be quite cheap: for small
structs, it could even be returned in CPU registers so the cost will be
minimal.  However, I see that you allocate a new instance of YYLocation
each time: that's bound to have performance issues.  Is there any reason
to allocate YYLocation on the heap?  Is it because it's a class as
opposed to a struct?  If it's a class, what was the rationale behind it?

In my mind, it should be a struct unless there's something in it that
must persist on the heap. Based on its construction parameters, it looks
to me to be just a container to store start/end positions in the input;
if so, it does not need to be a class. A struct will do just fine, and
will avoid unnecessary GC allocations.

> The main disadvantage is the possible overhead the structure adds to
> the parser. It will be created and destroyed for each discovered
> token.

Make it a struct, and make all of its members structs or PODs. Then
there will be minimal construction overhead, and no destruction costs at


BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL

More information about the Digitalmars-d mailing list