On 02/28/2014 06:03 PM, Michael Hennebry wrote: > On Sat, 1 Mar 2014, Markus Hitter wrote: > >> Am 28.02.2014 20:33, schrieb Michael Hennebry: >>> On Thu, 27 Feb 2014, Onno Kortmann wrote: >>> >>>> But IMHO the general approach of having a text-based configuration >>>> file >>>> for AVR topologies, even if those files are kept up to date >>>> manually, is >>>> still a good idea. I think it is better than having C++ files filled >>>> with what is essentially just declarative configuration data. But I >>>> guess that's arguing about taste :-) >>> >>> No. It is not. >>> Where to put data, in how many places and amongst >>> how much clutter is not just a matter of taste. >> >> To defend Onno a bit, such a file is already in use. It's the one used >> for tracing signals into VCD files. It's a single file in an arbitrary >> position, you pass a path to it as parameter. See -c and -o parameters >> for simulavr. > > I'd thought this was already clear: > I was not attacking Onno's suggested code and data organization. > I was attacking the notion that the decision to be made is just about > taste. > The notion had it coming. I guess I should have been more explicit: The pros/cons are technical, but weighting them is taste. What do you mean by 'how many places' and 'how much clutter'?
These are the pros I see for configuration data as C++: - Simulavr is more self-contained, does not need configuration files - no parser needed for text files, so less generic code vs. a standalone config file: - easier to fix and change, no recompilation necessary - less boiler plate code, as needed for C++ vs. a part-config mini-language - part configuration and to an extent how much certain I/O features are supported can be figured out from the configuration file. For example when installing just a binary from a .deb. Are there any other issues? What do people think? Cheers, Onno _______________________________________________ Simulavr-devel mailing list Simulavr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/simulavr-devel