5 ms·
I don't know if I agree with the premise: > People are terrified of parsers and parsing But this implementation of a reduced feature set version of .ini file
by blueblob 3y ago
I don't know if I agree with the premise:
> People are terrified of parsers and parsing
But this implementation of a reduced feature set version of .ini file parsing does not convince me that I should write my own parser instead of using one that implements a more full feature set
> No newlines in keys, values, or section names. Empty values are not allowed. Comments only on their own lines (minus whitespace). Whitespace-insensitive (whitespace at the start of line, end of line, around the “=”, is all ignored). No need for a terminating newline either.
I think it's reasonable that people want to use a parser that has better error handling and gives an idea of where the ini file may have parsing problems than just a barebones implementation such as this provides.
I also think that using a library for parsing instead of writing your own parser does not imply that you are scared of parsing.
- delusional 3y agoI don't think the author is necessarily aiming at purpose built file parsers with that statement, but rather "parser generators" like ANTLR.
- lylejantzi3rd 3y ago> But this implementation of a reduced feature set version of .ini file parsing does not convince me that I should write my own parser instead of using one that implements a more full feature set A performance comparison on a large ini file might. You may want to take the time to watch this video[0]. In it, Andreas Fredriksson walks though his reasoning for writing his own parser instead of using the standard json parser. [0]: https://vimeo.com/644068002 https://vimeo.com/644068002
- dezgeg 3y agoPerformance comparison of this code might not, however, as fgetc() based parsing is not efficient. (Each call takes a lock in the FILE object).