W dniu 2012-05-06 19:00, Sebastian Biały pisze:
> On 2012-05-06 18:18, mk wrote:
>>> Nie. plik lokalny dla projektu nadpisuje parametry domyślne.
>> Używając #undef???
>
> Uzywając def.
>
> Np. tak:
>
> default-config: #define UART_STOP_BITS 1
>
> project-config: #include "default.h", #define UART_STOP_BITS 2

Redefiniowanie makra nową wartością jest nielegalne!!!

>
>> IMO zdecydowanie lepsze jest jednak włączenie najpierw pliku z
>> konfiguracją użytkownika, a potem nagłówek z konfiguracją domyślną -- to
>> zresztą powszechna praktyka.
>
> Zdecydowana lepszośc tutaj dyskusyjna. Oba rozwiązania działają.

Jak gdzie (patrz wyżej).
Można by odwołać jak wspomniałem z użyciem #undef, ale użycie #undef
jest niezgodne np. z MISRA-C i w ogóle niepotrzebnie zaciemnia plik
konfiguracji użytkownika.

>
>> Plik nagłówkowy "defaultconfiguration.h" nie definiuje parametrów już
>> zdefiniowanych (#ifndef), a jedynie te które jeszcze nie zostały
>> zdefiniowane nadając im wartości domyślne (+ ewentualnie jakiś komunikat
>> przy pomocy #warning), obliczając je (np. na podstawie parametrów
>> podanych przez użytkownika) lub walnąć błędem (#error) jeśli parametr ma
>> być obligatoryjne określony przez użytkownika.
>
> W drugą stronę działa to tak samo (nie)skutecznie bez #ifndef, kwestia
> implementacji.

Niezgodne ze standardem.

> IMO to nie konfiguracja powinna szukać bledów w #define i wyliczać
> pośrednie parametry tylko implementacja.

To zależy i to już trochę inny temat... część rzeczy można i należy
sygnalizować już na wczesnym etapie rozpoznania konfiguracji użytkownika
np. zgodność wersji modułu bibliotecznego i jej użytkownika, czy wiele
innych parametrów o globalnym charakterze.
Rozmowa na temat czy "default.h" należy czy nie należy do implementacji
jest również czysto akademicka, tak jak i gdzie najlepiej określać
parametry default.

pzdr
mk