Feedback needed: Complete symbol appoach for Bison's D backend
H. S. Teoh
hsteoh at quickfur.ath.cx
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:
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
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