On 2012-05-06 21:32, mk wrote:
>> 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!!!

Masz rację, jak zwykle pisze skrótami i nie wszystko podaje. Oczywiscie
że jest #undef ale tylko dlatego że nie da się zrobić wprost #define
ponownie (w gcc da się). Samo undef jest wyłacznie wytrychem a nie
sednem metody. Sendem metody jest ponowne zdefiniowanie symbolu
nadpisując default.

Jak napisałem - dla mnie nie ma znaczenia którą metodą inkludowania
wybierzesz - obydwie sa mizerne i sprwadzają się do tej samej sieczki w
define.

> jest niezgodne np. z MISRA-C i w ogóle niepotrzebnie zaciemnia plik
> konfiguracji użytkownika.

Nie mam targetu na misra-c. Więc ich zalecenia nie są dla mnie kluczowe.
Czy zaciemnia - to już inna sprawa. W odwrotnej konfiguracji zaciemnia
#ifdef. Tak czy inaczej - to nie wygląda dobrze.

Prawde mowiąc korzystam znacznie częściej ze statycznego polimorfizmu.
#define to odprysk w kilku miejscach.

Mam taki nieskończony projekcik (który strasznie zaniedbałem, ale
obiecuje poprawę) na SF, możesz sobie zerknąć co mam na myśli:

http://sourceforge.net/projects/microheap/

> 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.

W moim przypadku nie sposób w momencie inkludowania default wykryć czy
dopuszczalne jest mieć uart o 2 bitach stopu. Przy czym "nie sposób" w
sensie, że jakikolwiek sposób powoduje wyciek wiedzy o hardware do
miejsca o innym poziomie abstrakcji. Im niej zależności tym lepiej dla
projektu.

> 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.

Z tej akademickiej dyskusji wynikają dobre praktyki. Dla mnie on nie
jest akademicka, bo dzieki takiemu podejsciu nie mam burdelu w kodzie.