When your question is answered use !solved to mark the question as resolved.
Remember to ask specific questions, provide necessary details, and reduce your question to its simplest form. For tips on how to ask a good question run !howto ask.
#Is this a bad struct for grammar for compiler?
tidal perchBOT
cloud oak
are you trying to generate parser source code from a grammar?
white scaffold
Yes
cloud oak
not sure why productions would be a double-pointer and why keywords need to be separated from terminals
keywords are really just terminals
white scaffold
For symbol table
Need to populate it with keywords at the beginning
So will need grammar for that
productions is an array of struct production
Anything else seems wrong?
cloud oak
productions is an array of struct production
it looks like an array of pointers to productions
why though
white scaffold
Keeping the productions themselves will be heavy right?
For passign around the grammar
that's why
cloud oak
but the grammar is just storing the pointer
why store a pointer to an array of pointers
and I would imagine that the grammar is passed around by pointer anyways
white scaffold
yes
cloud oak
it stores too much as that you can cheaply copy it around
so may as well put as much directly into the grammar as possible
white scaffold
unsigned int TERMINALS_BEGIN;
unsigned int TERMINALS_END;
unsigned int NON_TERMINALS_BEGIN;
unsigned int NON_TERMINALS_END;
is this bad?
cloud oak
I don't get why these are fully capitalized
white scaffold
constant
cloud oak
then why isn't it const
white scaffold
Because we have to set it later
after reading from file
The number of terminals and non terminals
what do you think?
cloud oak
typedef struct grammar {
production productions[MAX_PRODUCTIONS];
unsigned int n_terminals;
unsigned int n_productions;
unsigned int n_non_terminals;
char *terminal_to_string[MAX_TERMINALS];
char *non_terminal_to_string[MAX_NON_TERMINALS];
char *keywords[MAX_KEYWORDS];
int terminals_begin;
int terminals_end;
int non_terminals_begin;
int non_terminals_end;
hashmap string_to_terminal_map;
hashmap string_to_non_terminal_map;
hashmap first_sets_map;
hashmap follow_sets_map;
} grammar;
if you're going to pass around the grammar by pointer and you kinda have to do that, just do this
unless you want all of these arrays to be unrestricted in size
but then honestly, just don't use C for it
white scaffold
But MAX_PRODUCTIONS aint known
cloud oak
you can set a large limit on it
cloud oak
it really doesn't matter as long as you don't put it onto the stack, but dynamically allocate grammar
whether the arrays should be directly in the struct is debateable, but the hashmaps are probably just storing a pointer and a size
so there's likely no reason to point to them
white scaffold
all my hashmap functions require a pointer to the hashmap
instead of the hashmap itself
@cloud oak
cloud oak
yeah but you don't have to store a pointer
you can just create a pointer to the value you store whenever calling these functions
white scaffold
you can just create a pointer to the value you store whenever calling these func...
Create hashmap also returns pointer to hashmap
Then I will have to dereference create hashmap?
The code would be bad
cloud oak
so you can't even create a hashmap that's not heap-allocated? okay weird, maybe because it stores a FAM
in that case it would make sense to keep a pointer I suppose
tidal perchBOT
white scaffold
so you can't even create a hashmap that's not heap-allocated? okay weird, maybe ...
What's a FAM?
cloud oak
What's a FAM?
flexible array member
tidal perchBOT
tidal perchBOT