On 2012-05-06 17:21, mk wrote:
>>> #include "../lib/i2c/defaultconfiguration.h"
>>> #include "i2cconfiguration.h"
> Chyba miało być odwrotnie...

Nie. plik lokalny dla projektu nadpisuje parametry domyślne.

do góry

On 06.05.2012 14:19, Zbych wrote:
> Ja raczej unikami używania tej samej kopii biblioteki do różnych
> projektów. Dasz sobie głowę uciąć, że zmiana w bibliotece pod bieżący
> projekt x nie spowoduje jakiś anomalii w projekcie x-10, który pisała inna
> osoba?
> Wolę zrobić kopię biblioteki z projektu x-1 i nanieść poprawki.

Kopię? Od tego są systemy kontroli wersji. Robimy brancha nowego i
dostosowujemy. Jak coś się zmieni w głównej gałęzi (np straszny bug
wykryty) to mergujemy samą zmianę. W gicie robi się to pięknie...

Takie problemy występują podczas rozwoju każdego oprogramowania, warto
poczytać o schematach/rozwiązaniach przetestowanych w takim środowisku.

http://nvie.com/posts/a-successful-git-branching-mod
el/

Marek

do góry

Dnia 06-05-2012 o 17:21:11 mk <reverse_lp.pw@myzskm> napisał(a):

> Ciągle nie rozumiem na czym polega Twój problem...
> Skoro pojawia się nowy parametr modułu bibliotecznego, to mamy dwie
> opcje: albo musi on być obligatoryjne określony przez użytkownika
> biblioteki (wtedy zdajemy się na kompilator i błąd klasy undefined),
> albo nowy parametr ma jakąś wartość domyślną (stałą lub jakoś
> ewaluowaną) i użytkownik ewentualnie może przedefiniować ten parametr.

Skłaniam się ku pierwszej opcji: obligatoryjne określenie, nawet jeśli
zwykle będzie to przypisanie wartości domyślnej. Chcę jakoś sobie to
określanie usprawnić semi-automatyzując zadanie. Na razie mam tylko
autowykrywanie przez próbę kompilacji gdzie parametr nie jest
zdefiniowany. Chciałbym ułatwić sobie dodawanie tego parametru do plików
konfiguracyjnych, oraz mieć wykrywanie ustawienia parametrów, które stały
się "obsolete".

ae

do góry

W dniu 2012-05-06 17:35, Sebastian Biały pisze:
> On 2012-05-06 17:21, mk wrote:
>>>> #include "../lib/i2c/defaultconfiguration.h"
>>>> #include "i2cconfiguration.h"
>> Chyba miało być odwrotnie...
>
> Nie. plik lokalny dla projektu nadpisuje parametry domyślne.

Używając #undef???

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

pzdr
mk

do góry

W dniu 06.05.2012 16:55, Michoo pisze:
> On 06.05.2012 16:28, Zbych wrote:
>> W dniu 06.05.2012 15:54, Michoo pisze:
>>> HW::uart<0>::send_char(buf[i]);
>>> zamienia na pojedynczy mov do rejestru.
>>
>> A jakie będą tego zalety w stosunku do wersji z define?
> Że nie muszę kopiować kodu dla uart 1. No i środowisko mi ładniej
> koloruje funkcje wpisane jako funkcje a nie jako połamane define.

Póki rejestry UART są rozmieszczone identycznie względem bazowego, to w
zwykłym C napiszesz jedną obsługę do wszystkich UARTów bez żadnych
define'ów.

> Btw - jak będę miał dość czasu, żeby posprzątać kod to wrzucę go na
> jakieś sourceforge i każdy będzie mógł ocenić.

Chętnie zobaczę.

do góry

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

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

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

IMO to nie konfiguracja powinna szukać bledów w #define i wyliczać
pośrednie parametry tylko implementacja. Więc detekcje źle ustawionych
parametrów robię w pliku c. To dlatego że to w pliku c wiadomo jaka
konfiguracja jest nielegalna, np. uart avr ie obsługuje 2 bitów stopu.
Gdyby te zależności miał wyliczać globalny plik default-config.h to
wiedza o uart avr wyciekła by z implementacji specyficznej dla hardware
do globalnej przestrzeni gdzie ją ciężko utrzymać.

W moim rozwiązaniu zależności są detektowane i obliczane w c drivera bo
nie ma innej możliwości. I dzieki temu plik default-config jest czysty o
specyficznej wiedzy o hardware. Nie zawsze, ale zazwyczaj. Innymi słowy
wszystko co dotyczy avr znajduje się w katalogu /avr/ i nie przecieka do
inych plików.

Przy czym żeby było jasno - oba podejścia są tak samo mizerne.

do góry

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

do góry

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.

do góry

W dniu 2012-05-06 17:41, Andrzej Ekiert pisze:
> Dnia 06-05-2012 o 17:21:11 mk <reverse_lp.pw@myzskm> napisał(a):
>
>> Ciągle nie rozumiem na czym polega Twój problem...
>> Skoro pojawia się nowy parametr modułu bibliotecznego, to mamy dwie
>> opcje: albo musi on być obligatoryjne określony przez użytkownika
>> biblioteki (wtedy zdajemy się na kompilator i błąd klasy undefined),
>> albo nowy parametr ma jakąś wartość domyślną (stałą lub jakoś
>> ewaluowaną) i użytkownik ewentualnie może przedefiniować ten parametr.
>
> Skłaniam się ku pierwszej opcji: obligatoryjne określenie, nawet jeśli
> zwykle będzie to przypisanie wartości domyślnej. Chcę jakoś sobie to
> określanie usprawnić semi-automatyzując zadanie. Na razie mam tylko
> autowykrywanie przez próbę kompilacji gdzie parametr nie jest
> zdefiniowany. Chciałbym ułatwić sobie dodawanie tego parametru do plików
> konfiguracyjnych,

Nie rozumiem nadal dlaczego nie posługiwać się wartością domyślną
konfiguracji zdefiniowaną gdzieś w module bibliotecznym...

#ifndef ALPHA
#error ALPHA parameter must be defined in your configuration file.
#endif

lub

#ifndef ALPHA
#warning Using defalut value X of ALPHA parameter. Specify an explict
definition of ALPHA parameter in your configuration file to suppress
this warning.
#define ALPHA X
#endif

lub po cichu

#ifndef ALPHA
#define ALPHA X
#endif

> oraz mieć wykrywanie ustawienia parametrów, które
> stały się "obsolete".

#ifdef ALPHA
#warning ALPHA parameter is obsolete configuration value. Use BRAVO instead.
#endif

Jeśli wzbraniasz się przed konceptem konfiguracji domyślnej wtedy po
prostu pozostaje jakaś automatyczna modyfikacja plików wielu projektów
-- zwykle z wykorzystaniem języków skryptowych, albo zaawansowanego edytora.

W sumie można sobie wyobrazić jakiś system zarządzania konfiguracjami
np. w postaci jakiejś bazy danych czy coś... Nie nie spotkałem się z
czymś takim.

pzdr
mk

do góry

Dnia 06-05-2012 o 22:25:15 mk <reverse_lp.pw@myzskm> napisał(a):

> Nie rozumiem nadal dlaczego nie posługiwać się wartością domyślną
> konfiguracji zdefiniowaną gdzieś w module bibliotecznym...
>
> #ifndef ALPHA
> #error ALPHA parameter must be defined in your configuration file.
> #endif

To w zasadzie mam teraz, tyle że warning lub błąd wynikający z
niezdefiniowania ALPHA generuje się samoczynnie w miejscu jego użycia
(bezwzględnie tego pilnuję). Nie trzeba więc nawet takiego #ifndefa pisać.

> #ifndef ALPHA
> #warning Using defalut value X of ALPHA parameter. Specify an explict
> definition of ALPHA parameter in your configuration file to suppress
> this warning.
> #define ALPHA X
> #endif

Można. Ale wciąż wymaga ręcznego dopisania #define ALPHA wszędzie, jeśli
się nie chce tych warningów. A to mnie właśnie boli, ze względu na
bezproduktywną pracochłonność.

> lub po cichu
>
> #ifndef ALPHA
> #define ALPHA X
> #endif

Ryzykowne - otrzymujący mój kod mogą nie zauważyć nowych opcji, które np.
mogą okrajać dotychczasową funkcjonalność. Sam mogę zapomnieć ustawić w
jednym z projektów.

> #ifdef ALPHA
> #warning ALPHA parameter is obsolete configuration value. Use BRAVO
> instead.
> #endif

Można, ale wymaga trzymania całej historii. Średnio mi się podoba taki
śmietniczek.

> W sumie można sobie wyobrazić jakiś system zarządzania konfiguracjami
> np. w postaci jakiejś bazy danych czy coś... Nie nie spotkałem się z
> czymś takim.

No właśnie sobie to wyobraziłem. Chyba będę pisał, bo niczego sensownego
nie znalazłem. Jeśli mi się uda skończyć, to opublikuję pod GPL.

ae

do góry