W dniu 2012-05-06 22:05, Sebastian Biały pisze:
> 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.

GCC jest tu tolerancyjny, ale i tak daje warningna.

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

Takie uroki tworzenia kodu uniwersalnego. Sieczki programowania
generycznego C++ często wcale nie wyglądają lepiej :-)

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

Ale to z plikiem konfiguracji użytkownika użytkownik będzie w pierwszej
kolejności pracować. Nadawanie konfiguracji domyślnej to już bebechy...

Nie ma co sobie obrzydzać, tak wygląda język C :-)

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

Inny język, inna bajka... Świecą mi się oczy jak widzę takie rzeczy,
choć C++ daleki jest w programowaniu generycznym od tego co można sobie
wymarzyć. W wolnej chwili nie omieszkam lepiej się przyjrzeć projektowi.

I dla odmiany (też jeśli chodzi o rozwiązania generyczne i też jeśli
chodzi o zarządców pamięci): mam ostatnio do czynienia z biblioteczką
lwIP (stos TCP/IP). Mam tu w szczególności na myśli pule pamięci z tego
projektu (pliki memp.c, memp_std.h).

Wygląda to mniej więcej tak:

const u16_t memp_sizes[MEMP_MAX] = {
#define LWIP_MEMPOOL(name,num,size,desc) LWIP_MEM_ALIGN_SIZE(size),
#include "lwip/memp_std.h"
};

i na końcu pliku memp_std.h odwołujemy makro LWIP_MEMPOOL.
Plik memp_std.h tworzy ciało listy inicjalizacyjnej tablicy memp_sizes.

następnie znowu:
static const u16_t memp_num[MEMP_MAX] = {
#define LWIP_MEMPOOL(name,num,size,desc) (num),
#include "lwip/memp_std.h"
};

itd...

W ten sposób dzięki podmienianiu definicji LWIP_MEMPOOL obskoczono
wytwarzania wszystkich struktur danych niezbędnych do pracy pól pamięci
:-) Grrrrrrrrrrrrrrr... No i teraz próbuj to człowieku debugować... Aż
się prosi o szablony i trejty (ale to nie C++).

Ale w boost też tą technikę (redefiniuj makro i włącz nagłówek) się
stosuje... Paskustwo!

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

Oczywiście, że taki warunek jest związany ściśle z implementacją
hardware, więc warunek ten powinien być możliwie blisko tyłka drajwera
tego modułu.

pzdr
mk