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

do góry

On 07.05.2012 01:25, mk wrote:

> Ale w boost też tą technikę (redefiniuj makro i włącz nagłówek) się
> stosuje... Paskustwo!
Bo nie było kiedyś m.i. variadic templates.

M.i. dlatego zacząłem programowanie magisterki od kompilacji g++ 4.7 -
mam lamby, mam variadic, mam inicjalizację przez {}, mam enum class, mam
constexpr etc.

--
Pozdrawiam
Michoo

do góry

Andrzej Ekiert wrote:
>>> Miałem po prostu nadzieję, że kogoś już to uwierało i jakieś narzędzie
>>> istnieje. No nic, napiszę sobie sam.
ecosconfig czyli konfigurator eCos'a jest takim narzedziem.

>>
>> Zerknij jeszcze na konfigurator eCos.
>>
>
> Kiedyś go nawet używałem. Faktycznie, zobaczę.
To nie bedzie bardzo skomplikowane. Trzeba tylko"
1. "Spaczkowac" projekt - wydzelic moduly, ktore maja byc opcjonalnymi
komponetami i dodac opis w jezyku CDL w katalogu cdl danej paczki
a. Jesli projekt nie bzedzi linkowany z zewnetrznym modulem, w pliku cdl
dodac opcje do budowania na wzor opcji CYGBLD_BUILD_REDBOOT_BIN z dowolnego
Hal'a.
2. Stworzyc "targety" - opis paczek skladajacych sie na konkretny modul
sprzetowy.
3. Stworzyc przynajmniej jeden "template" - dodaje wspolne paczki dla wielu
targetow - chyba opcjonalnie.
4. Powyzsze aktywnosc wykonac w jezyku CDL ->
http://ecos.sourceware.org/docs-latest/cdl-guide/cdl
-guide.html
5. Wszystko umiescic w katalogu packages zgodznie z drzewem eCos'a
6. Stworzyc plik ecos.db i dodac do niego wszystkie paczki oraz targety.
7.
$ ecosconfig new TARGET TEMPLATE
$ ecosconfig tree

i juz powinismy dostac oczekiwana konfiguracje, makefile, a
$ make
zbuduje wszystko.

do góry

Dnia 07-05-2012 o 15:52:59 Nijak <b...@b...pl> napisał(a):

>> Kiedyś go nawet używałem. Faktycznie, zobaczę.
> To nie bedzie bardzo skomplikowane. Trzeba tylko [...]

Kiedyś przenosiłem RedBoota na swoją płytkę i wtedy sobie dodałem
definicję "targetu" do plików obrabianych przez ecosconfig. Musiałbym się
tym trochę więcej pobawić, ale może faktycznie czas zaakceptować fakt, że
lepiej czegoś podobnego sam nie napiszę i przeczytać tę przydługą
dokumentację. Narzędzie wydaje się umieć spełnić moje wymagania - oraz 100
rzeczy, których nie wymagałem ;-)

Dzięki wszystkim za tę sugestię.

Pozdrowienia,
ae
--
Outsourcing usług projektowych
http://www.protronik.pl

do góry

Andrzej Ekiert wrote:

> Dnia 06-05-2012 o 15:15:04 Sebastian Biały <h...@p...onet.pl>
> napisał(a):
>
>> Zapropnuje sposób trywialny, być może akurat będzie w sam raz:
>>
>> *** i2cdriver.c ***
>>
>> #include "i2cconfiguration.h"
>> #include "../lib/i2c/i2ccore.c"
>> #include "../lib/i2c/i2chardware.c"
>>
>> *** i2cdriver.h ***
>>
>> #include "i2cconfiguration.h"
>> #include "../lib/i2c/i2cinterface.h"
>>
>> Plik i2cconfiguration.h jest częscią konkretnego projektu, podobnie jak
>> i2cdriver.c.
>>
>> I tyle. W i2cconfiguratiion stado #define per projekt. W plikach lib/i2c
>> (h i c) od groma #ifdef na każdy wariant.
>>
>
> Ale to mi w żaden sposób nie dotyka mojego problemu. Jeśli odwołam się w
> "../lib/i2c/i2ccore.c" do nowego parametru konfiguracyjnego C_I2C_SHMOO,
> to muszę go ręcznie zdefiniować w każdym i2cconfiguration.h w każdym
> projekcie. Jeśli zmienię nazwę i trochę funkcje parametru C_I2C_FOO na
> C_I2C_BAR, to znowu zmiana w każdym projekcie. Chodzi mi o sposób lub
> narzędzie do automatyzacji takich zmian: wykrywanie niedodanych definicji,
> eliminację przestarzałych definicji, itp.
>
> Samo definiowanie konfiguracji per-projekt i jej #include w plikach
> biblioteki to mam rozwiązane w miarę elegancko. Boli mnie tylko potrzeba
> ręcznego czyszczenia konfiguracji per-projekt w wypadku zmian w opcjach
> oferowanych przez bibliotekę.

czasami w przypadku koniecznosci zachowania wstecznej kompatybilnosci
biblioteki stosuje sie w c++ namespace-inlining (a w c wersjonowanie
symboli na poziomie skryptu gnu/linkera).

na zalaczonym przykladzie masz w bibliotece obslugujacej costam
wersje v1, ktora byla na poczatku wszechswiata :) potem programista
wpadl na pomysl by rozwiazanie ulepszyc i dodal wersje v2,
ale, ze lubil uzytkownikow, to nie chial ich zmuszac do poprawiania
w starych projekatach wszystkich wywolan api i za pomoca prostego
#define USE_LEGACY w aktualnej wersji biblioteki udostepnia stary
interfejs/implementacje. autor biblioteki wewnetrznie (w lib.cpp)
juz sobie rozwizuje problem jak stare api przempowac na aktualna
implementacje, a uzytkownicy sa szczesliwi.

do góry

Hello Paweł,

Monday, May 7, 2012, 9:42:46 PM, you wrote:

[...]

> na zalaczonym przykladzie masz w bibliotece obslugujacej costam

Z jakiej choinki się urwałeś, że na grupie dyskusyjnej załączniki
wpychasz?

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

RoMan Mandziejewicz wrote:

> Hello Paweł,
>
> Monday, May 7, 2012, 9:42:46 PM, you wrote:
>
> [...]
>
>> na zalaczonym przykladzie masz w bibliotece obslugujacej costam
>
> Z jakiej choinki się urwałeś, że na grupie dyskusyjnej załączniki
> wpychasz?

zalacznik tekstowy jest gorszy od wklejenia przykladu do tresci wiadomosci?
przeciez to nie megabajtowe pliki, zeby je slac na bin.*, a tak wszystko
widac od reki i mozna latwo sobie zapisac przyklad na dysku.

do góry

Hello Paweł,

Tuesday, May 8, 2012, 7:56:24 AM, you wrote:

>>> na zalaczonym przykladzie masz w bibliotece obslugujacej costam
>> Z jakiej choinki się urwałeś, że na grupie dyskusyjnej załączniki
>> wpychasz?
> zalacznik tekstowy jest gorszy od wklejenia przykladu do tresci wiadomosci?

Tak, bo go część serwerów wytnie. A inna część serwerów wytnie razem
z wiadomością.

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Dnia 08-05-2012 o 08:50:07 RoMan Mandziejewicz <r...@p...pl.invalid>
napisał(a):

> Hello Paweł,
>
> Tuesday, May 8, 2012, 7:56:24 AM, you wrote:
>
>>>> na zalaczonym przykladzie masz w bibliotece obslugujacej costam
>>> Z jakiej choinki się urwałeś, że na grupie dyskusyjnej załączniki
>>> wpychasz?
>> zalacznik tekstowy jest gorszy od wklejenia przykladu do tresci
>> wiadomosci?
>
> Tak, bo go część serwerów wytnie. A inna część serwerów wytnie razem
> z wiadomością.
Eee tam marudzisz, gazeta niczego nie wycieła i widać wszystkie załączniki,
a ważą raptem mniej niż kilo.


--
Pozdr
JanuszK

do góry

In the darkest hour on Tue, 08 May 2012 15:13:27 +0200,
janusz_kk1 <j...@o...pl> screamed:
>>>>> na zalaczonym przykladzie masz w bibliotece obslugujacej costam
>>>> Z jakiej choinki się urwałeś, że na grupie dyskusyjnej załączniki
>>>> wpychasz?
>>> zalacznik tekstowy jest gorszy od wklejenia przykladu do tresci
>>> wiadomosci?
>>
>> Tak, bo go część serwerów wytnie. A inna część serwerów wytnie razem
>> z wiadomością.
> Eee tam marudzisz, gazeta niczego nie wycieła i widać wszystkie załączniki,
> a ważą raptem mniej niż kilo.
>

Gazeta nie, ale inne tak. Przyjmij do wiadomości, że załączników się
nie wysyła.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:227B ]
[ 09:06:45 user up 13163 days, 21:01, 1 user, load average: 0.97, 0.81, 0.15 ]

The world is coming to an end... SAVE YOUR BUFFERS!!

do góry