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

[H. S. Teoh]

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:
> https://github.com/akimd/bison/blob/master/examples/d/calc/calc.y#L117
> 
> An example using the Symbol struct:
> https://github.com/adelavais/bison/blob/complete-external-symbols/examples/d/calc/calc.y#L117

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
all.


T

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