simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] fab feature deprecated


From: Onno Kortmann
Subject: Re: [Simulavr-devel] fab feature deprecated
Date: Fri, 28 Feb 2014 19:52:01 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]