-2

I am writing drivers for different devices to work with my embedded system. Currently I write any new driver manually but for the future I would like to automate this using a settings file. I figure I have 2 options:

  1. write a single universal driver that reads the setting file and behaves accordingly;

  2. write a code generator that reads the setting file and generates code from that with appropriate behavior.

Which one of these is the better option and why? Are there any better options still?

Improve this question
5
  • 1
    Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see How to Ask Commented Jan 8, 2019 at 6:40
  • @gnat both of them helps me to resolve my problem. but I didn't know the Consequences of each choices in further develop. Commented Jan 8, 2019 at 6:43
  • 1
    @nader but I didn't know the Consequences of each choices There's no shortcuts to the heaven. Why don't make a proof of concept? Experiencing the pros and cons yourself is way more useful and valuable for you than just believing strangers on the internet. Commented Jan 8, 2019 at 8:17
  • @Laiv I want to use the experience of others. There is no shortcuts to the heaven but there is guide for finding the right path path to heaven. Commented Jan 8, 2019 at 9:35
  • 1
    Yes. Walking the way not seeing others walking it for you :-) Commented Jan 8, 2019 at 9:47

1 Answer 1

Reset to default
1

It depends...

Will you need to:

  • Produce many similar instances either across languages?
  • Slight variations within the same language?
  • Handle a complex grammar (such as a scripting language)?

Code-Generation will look good because its write-once, declarative, reproducible, and the tooling can assist in generating correct grammars.

Unfortunately most generators do not provide the semantic mappings, and even when they do, two applications may have different internal models and hence different mappings. If you do go down this route most of the heavy lifting is done for you in terms of syntax and assembly. You will however need to encode the compositional semantics for whatever model the configuration is assembling.

The other downsides are that generators produce unintelligible code, require an extra tool in the build chain, and have uncanny traps for the unfamiliar such as infinite regress.

Will you need to:

  • Handle Key:Value style configuration?
  • provide some semblance of human readability?
  • potential need internationalisation?

Prefer to use a stock off the shelf configuration file language. These languages often come with easy to use and reliable object serial, and dom style parsers native to your language. These handle pesky details of multi-language encodings, escapes, and other parsing woes. The only drawback is that you still need to comprehend that object structure and translate it into your own domain objects. Don't be tempted to just use the parsed objects directly, that way leads to high coupling.

Alternately

  • The parser-generator tooling is inappropriate or imposes too many restrictions.
  • The off the shelf config languages are inappropriate
  • The language being parsed is a murky mess without obvious rules, yet...

Roll your own parser, its not terribly difficult.

Rules of thumb:

  • keep lexing, parsing, and assembling separated by clean interfaces.
  • do not throw to communicate failure to parse, this is an expected outcome.
  • on an error always report in the output/on return diagnostics: current parse tree and assembled data, line, column, what was not found, what was found instead, and perhaps advice on how to fix it.
  • always report diagnostics reported by a sub-parse, even if successful, this allows warnings to be communicated.
  • always have a "test" assembly implementation that returns a collection of the values it was given to assemble, with the context. This allows you to easily test lexing and parsing, and to produce a validator program with useful diagnostics.
Improve this answer
2
  • thanks for your answer. what about performance and speed? and is there any other choices? Commented Jan 8, 2019 at 8:09
  • 1
    @nader Are you parsing 30TB of data per second? If you are you will need to be careful in what language you use, and what tooling you pick. If you are working on a limited computing device, prefer to use a precompiled binary representation. Provide a tool for composing that on a less restricted system. Otherwise don't worry overly much. React when you have definitive data that it is Slow, or Burdensome, or Greedy in someway and specifically address that. The most important aspect is clarity because you need to be able to fix problems in this code. Commented Jan 8, 2019 at 8:13

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.