Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kent.hall/tokens parser #9

Open
wants to merge 57 commits into
base: james.yang/lexer_refactor
Choose a base branch
from

Conversation

kentjhall
Copy link
Collaborator

The structure is there for setting up parsing logic.

Copy link
Owner

@JamesYang007 JamesYang007 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great design!!

General comments:

  • Inline definitions should always be placed in header file. Otherwise, compiler will only be able to inline this function whenever it gets called within current .cpp file.
  • I like to name arrays with _arr so instead of handlers_t I would write handler_arr_t. Gives less confusion to those who read your code for the first time (like how it did to me)
  • It would be better if you wrote all the using ..._t = ...; inside each of your classes. This is not code duplication. I know I didn't do this in my lexer stuff and I'm still thinking about fixing it. My issue is that I don't have a class for these routines so the "closest" place I can put these aliases are in the same scope as my functions (docgen::core).

src/core/lex_N_parse.cpp Outdated Show resolved Hide resolved
src/core/lex_N_parse.cpp Outdated Show resolved Hide resolved
src/core/parse_feeder.hpp Outdated Show resolved Hide resolved
src/core/parse_feeder.hpp Outdated Show resolved Hide resolved
src/core/parse_feeder.hpp Outdated Show resolved Hide resolved
src/core/parser.hpp Outdated Show resolved Hide resolved
src/core/parser.hpp Outdated Show resolved Hide resolved
src/core/tags_parser.hpp Outdated Show resolved Hide resolved
src/core/parse_feeder.hpp Outdated Show resolved Hide resolved
src/core/parse_feeder.hpp Outdated Show resolved Hide resolved
src/parse_file.cpp Outdated Show resolved Hide resolved
Copy link
Owner

@JamesYang007 JamesYang007 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's worth having an empty struct like

struct RoutineTraits
{
using routine_t = void (*)(const token_t&, ParseFeeder&);
};

in a separate header file, which you can include into your tags_parser.hpp, ignore_parser.hpp, comments_parser.hpp and have each of your _routines struct derive from it.

SymbolHandler should not own the actual definition for this routine_t. It can then just reference this routine_t (see comment in parser_worker.hpp).

Also, once this restructure works, try compiling with

using routine_t =std::function<void(const token_t&, ParserFeeder&)>;

inside RoutineTraits. It should theoretically work. You may have to make all of your routines non-constexpr and just const. The performance disadvantage of std::function will not be an issue because all of your lambda functions are empty structs (there's a thing called small-object optimization - your lambda function will be constructed directly inside std::function object, i.e. no heap-allocation). With this one-line fix, you provide possibility of inlining your lambdas now, so you should see a noticeable performance difference with larger files.

Copy link
Owner

@JamesYang007 JamesYang007 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coooool 💃 :D

src/core/worker_routine.hpp Outdated Show resolved Hide resolved
src/core/parser_internal/docgen_worker.hpp Outdated Show resolved Hide resolved
src/core/parser_internal/docgen_worker.hpp Outdated Show resolved Hide resolved
src/core/parser_internal/func_worker.hpp Outdated Show resolved Hide resolved
src/core/parser_internal/docgen_worker.hpp Show resolved Hide resolved
src/core/parser_internal/docgen_worker.hpp Outdated Show resolved Hide resolved
src/core/parser_internal/docgen_worker.hpp Outdated Show resolved Hide resolved
src/core/parser.hpp Show resolved Hide resolved
src/core/parse_worker.hpp Outdated Show resolved Hide resolved
src/core/parse_worker.hpp Outdated Show resolved Hide resolved
Copy link
Owner

@JamesYang007 JamesYang007 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fantastic work :')

…nherit from it, as well as global ParseFeeder
…o be passed around, Parser no longer inherits from ParseWorker but instead contains a ParseWorker and ParseFeeder, put all 'using something_t = something_else;' within classes (not in a global context), etc.
…lled <Something>Worker now, and there is now a WorkerRoutine struct with the type alias for routine_t such that <Something>Worker_routines inherits this alias from it
…_worker.hpp's parser_internal namespace); added FuncWorker() to be used
…name conflicts; moved Token<Symbol> specializations from docgen_worker.hpp to token.hpp
…() member function into const& and && overloads
…precedence is established as necessary on a per-scope basis
…, but instead is more generically fed strings
…longer recursive at all, basically just keeps a counter now; can't believe I thought that recursive thing would work lol xD)
…nce s.t. it is actually moved with std::move()
…ths to include or paths to exclude); also new options for excluding individual paths
@kentjhall kentjhall force-pushed the kent.hall/tokens_parser branch from 44f18c3 to 3c2ca7a Compare January 19, 2020 04:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants