On 21/07/2022 20:12, Dawid Rutkowski wrote:
> PCIowy realtek z kolei ma przerwy w transmisji.
> Więc używam USB-ethernet.
> Chyba że to jego sterowniki psują kernel.

Spawdzaleś z jakimś starszym Live Linuxem? Zazwyczaj odpalam wtedy
SystemRescueCD i puszczam jakiś prosty test sieciowy do wewnętrznego
serwera. Miałem już ze 3 razy, kiedy update kernela psuł ethernet,
głównie pod kątem wydajności. Czy to był Realtek, nie pamiętam, ale
jeden to na pewno był Marvell. Zazwyczaj dotyczyło to nowych chipów,
których sterowniki cągle miały problemy i co chwile w aktualizacji coś
zmieniali.

> Echh, nowy komputer to gorzej niż nowe spodnie - tym bardziej, że żona nie kupi...

Ta sieciówka naprawdę działa na PCI? Nie na PCIe? Ogólnie karty sieciowe
PCIe tanie są... to z usb to padlina, ma spore opóźnienia ;)

do góry

W dniu 2022-07-21 o 16:41, heby pisze:
> On 21/07/2022 16:25, Piotr Gałka wrote:
>> Chciałem móc przekazać GUID jako parametr konstruktora - chyba mi się
>> nie udało.
>
> Czy GUIDy są zmienne? Pisałeś o statycznych.
>
> To miejsce na tempaltes, jesli są statyczne.
>
>> Tak na prawdę to nie wiem co chciałem i na czym poległem (za dawno było).
>> Pamiętam jedynie, że wniosek był - tylko tak to mi działa.

Znalazłem to co sobie wtedy napisałem jako podsumowanie. Jak się coś
takiego po latach czyta to też się nie jest pewnym co się miało na
myśli, choć było to pisane 'ku pamięci'.

--------------------------------
Próbowałem umieścić GUID w DevTab i dostarczać go w konstruktorze
tabeli. Wyszło mi, że oprócz statycznej DevTab w klasach typu U485 muszę
też dać statyczny GUID (bo nie udawało mi się wygenerować go w biegu
jako parametru wywołania konstruktora).
W sumie aby w funkcji FindDevs móc zawołać FindDevs tabeli bez podawania
w tym miejscu GUIDa zapisy w każdej klasie docelowego urządzenia USB
robiły się większe niż po prostu wpisanie GUID w funkcji FindDevs() więc
zrezygnowałem z GUID w DevTab.
---------------------------------

Moja struktura klas do obsługi urządzeń WinUsb:

class WUsbDev
Urządzenie WinUsb (uchwyt i wywołania funkcji) - głównie zasłania różne
nic mi nie mówiące funkcje Windows.

class WUsbDevTab
zawiera WUsbDev Tab[WUsbDevTabSize];
tabelka znalezionych urządzeń według GUID
dlatego chciałem aby GUID był w tej klasie i wtedy jej FindDevs() byłaby
bez parametrów.

Mam tabelkę, bo zakładam możliwość podpięcia więcej niż jednego takiego
samego urządzenia. Na przykład jak wylosowany klikaniem na ekranie klucz
chcę wpisać do dwu urządzeń, które potem służą do szyfrowania
komunikacji, to chcę je oba na raz widzieć.

class WUsbBulkD
bazowa klasa urządzeń WinUsb z dwoma endpointami bulk (we i wy)
ona zawiera WUsbDev *Dev; - wskaźnik na aktualne wybrane z tabelki

class MmWUsbBulkD : public WUsbBulkD
nasze urządzenia - obsługują komunikację zgodnie z naszymi standardami
(ramka, rozkazy rozpoznawcze, rozkazy ugrade'u)

class Usb485 : public MmWUsbBulkD
przejściówka USB-RS485
i tu pojawia się konkretny UID

nie widzę w tej chwili jak to się łączy z tabelką a nie mam w tej chwili
czasu.
wrócę do tego później.
P.G.

do góry

W dniu 2022-07-21 o 16:41, heby pisze:

> Zaznaczam, że to nie jest optymalne. Tracisz 4 bajty na pole m_guid.

Ja kombinowałem z obiektem GUID w klasie (a nie referencją) i żeby go
inicjalizować w konstruktorze.

> Hmmm... całośc tego wydaje mi się niejasna, co w zasadzie było problemem.

Stopniowo przypominam sobie o co mi chodziło i co było problemem.
Problemem było wpisanie wartości GUID bezpośrednio w wywołaniu
konstruktora obiektu static. Wydawało mi się, że kompilator wtedy
powinien wpisać dane z treści kodu źródłowego prosto do zmiennej typu GUID.
Szczerze mówiąc to jakbym w obiekcie miał referencję a wartość GUID
podawał jako parametr konstruktora (jak w Twoich przykładach) to nie
wiedziałbym czy to jest dobrze. Dla mnie (intuicyjnie) parametry wpisane
w wywołanie jakiejkolwiek funkcji (również konstruktora) znikają po
wykonaniu funkcji. Nie lubię stosować konstrukcji co do których nie
jestem pewny - dlatego przypisanie referencji do czegoś znikającego to
nie moja bajka.
Choć wiem, że łańcuch znaków mogę tak przekazać i przypisać wskaźnik na
ten łańcuch, ale wydawało mi się, że łańcuchy czasami są traktowane
inaczej od innych danych.
Zapewne kompilator radzi sobie z tym doskonale tworząc jakiś obiekt
gdzieś tam i przypisując do niego referencję, ale ja mam wtedy wrażenie
że to nie ja panuję nad wszystkimi danymi. Parametry z wywołania
konstruktora tak normalnie uważam, że powinienem w całości skopiować do
danych w klasie a nie przypisać sobie referencję do nich.

Mam zamiar powtórzyć tamte moje próby i dam znać.

Ale uciekam z pracy (pracuję na poddaszu po zachodniej stronie) - po
południu straszny upał się tu robi. Może w poniedziałek, chyba, że coś
wyskoczy.

> To metasłowa. Może być GORZAŁKA i ZAGRYCHA.

To mi wieloletni zgryz wyjaśniłeś :)

> Raczej nie dam wiary, że jest tak źle. Prosty kod usb UARTa na STM32
> zajmował jakies kilobajty. Ba, w małym AVR potrafili to zmieścić, z
> softwareową emulacją.

Bardzo prawdopodobne, że się gruntowanie mylę. Dotychczas jak
rozmawialiśmy nie usiłowałem dopytywać o szczegóły więc wiem tylko tyle
co mi się tam po głowie kołacze.
P.G.

do góry

On 22/07/2022 18:19, Piotr Gałka wrote:
> Szczerze mówiąc to jakbym w obiekcie miał referencję a wartość GUID
> podawał jako parametr konstruktora (jak w Twoich przykładach) to nie
> wiedziałbym czy to jest dobrze. Dla mnie (intuicyjnie) parametry wpisane
> w wywołanie jakiejkolwiek funkcji (również konstruktora) znikają po
> wykonaniu funkcji.

Skoro konstruktor przyjmuje referencję, to umawiasz się z wołającym, że
to jego sprawa trzymać ten obiekt. Taka umowa, w przypadku używania
referencji, jest dość powszechna i bardzo podobna do trzymania pointera.

Dla skomplikowanych przypadków współdzielenia własności wymyślono
smart_ptr<>, ale tutaj jest to zbędne.

W kodzie ten obiekt jest w ogóle trzymany w zmiennej globalnej.

> Nie lubię stosować konstrukcji co do których nie
> jestem pewny - dlatego przypisanie referencji do czegoś znikającego to
> nie moja bajka.

GUIDy w przykłądzie nie zniką. Są trzymane w przestrzenie globalnej,
inicjowane przed main() i usuwane po wyjści z programu.

> Choć wiem, że łańcuch znaków mogę tak przekazać i przypisać wskaźnik na
> ten łańcuch, ale wydawało mi się, że łańcuchy czasami są traktowane
> inaczej od innych danych.

Tutaj ten problem jest zupełnie inny gdzięki temu, że GUID jest tworzony
i trzymany w zmiennej globalnej. Nigdzie nie zniknie.

Niewykluczone, że na dziwacznych architekturach w ogóle powinien być
trzymany we flashu, więc to nie jest optymalne.

> Zapewne kompilator radzi sobie z tym doskonale tworząc jakiś obiekt
> gdzieś tam i przypisując do niego referencję, ale ja mam wtedy wrażenie
> że to nie ja panuję nad wszystkimi danymi. Parametry z wywołania
> konstruktora tak normalnie uważam, że powinienem w całości skopiować do
> danych w klasie a nie przypisać sobie referencję do nich.

Piszesz o przypadakch "przedłużania zycia zmiennych". Tutaj to nie
zachodzi. Specjalnie przykład jest napisany tak, aby nie było
niejasności. Referencje są bezpieczne w tym przypadku.

Aczkolwiek, jak powiedziałem, szablony+mixiny pozwoliły by zaoszczędzić
4 bajty klasy bazowej w RAM kosztem kilkudziesięciu bajtów flasha...

do góry

W dniu 2022-07-22 o 18:51, heby pisze:

Znajduję tylko czas aby się odezwać, a nie aby poeksperymentować -
zawsze mówię sobie - to zaraz i ... nic nie robię.

> Skoro konstruktor przyjmuje referencję, to umawiasz się z wołającym, że
> to jego sprawa trzymać ten obiekt. Taka umowa, w przypadku używania
> referencji, jest dość powszechna i bardzo podobna do trzymania pointera.

To jest standardowe podejście.
Ale moim celem było, aby tego GUID wpisać tylko i wyłącznie jako
parametr wywołania funkcji - pominąć potrzebę robienia przeze mnie
zmiennej tego typu.

Twój przykład nawet stosując referencje nie realizuje tego co ja wtedy
chciałem osiągnąć.

W tym Twoim przykładzie?:
---------------
static GUI konkretnyGUID = { };

class KlasaKonkretna : public KlasaBazowa {
public:
KlasaKonkretna() : KlasaBazowa( konkretnyGUID ) { [...] };

[...]
};
---------------

Mi chodziło o to aby: nie tworzyć statycznej zmiennej konkretnyGUID
tylko zapis jego wartości ująć jakoś od razu w miejscu gdzie go
wstawiłeś jako parametr konstruktora KlasyBazowej w konstruktorze Klasy
konkretnej.

Konstruktor KlasyKonkretnej najchętniej zostawiłbym w pliku h, a takie
static konkretny GUID to dla mnie musi być w pliku cpp więc i
konstruktor trzeba tam przenieść.

Ja chciałem zrobić coś podobnego jak mam definiowane mikrokontrolery.

Mam:

class ATProg : public ATProc
{
....
public:
ATProg(dword fs,dword fp,dword es,dword ep,qeord fm,dword
sg):ATProc(...){}
};

I potem już konkretne są definiowane tak:

class ATmega162Prog : public ATProg
{
public:
ATmega162Prog():ATProg(0x4000,128,512,1,0x1EFFFF,0x1
E9404){}
};

To jest cała definicja (w pliku h). Nic w niej tu nie skróciłem.
Bez śladu w pliku cpp.

Tak samo następnie mam definiowane klasy:
ATmega8Prog
ATmega48Prog
ATmega88Prog
ATmega644Prog

I tak samo chciałem zrobić z różnymi pochodnymi pewnej klasy, które to
pochodne różnią się między sobą tylko tym GUID.
Czyli konstruktor klasy bazowej miał mieć jeden parametr typu GUID a
konstruktory kolejnych klas miały go wołać wpisując tam wartość tego GUIDa.

Klasy pochodne występowały by tylko w pliku h.

Wiem, że mi się to nie udało. Ogólnie wiem, że nie udawało mi się wpisać
GUIDA jako parametru wywołania konstruktora (bezpośrednio w wywołaniu).
P.G.

do góry

On 25/07/2022 15:33, Piotr Gałka wrote:
> Ale moim celem było, aby tego GUID wpisać tylko i wyłącznie jako
> parametr wywołania funkcji - pominąć potrzebę robienia przeze mnie
> zmiennej tego typu.
> Twój przykład nawet stosując referencje nie realizuje tego co ja wtedy
> chciałem osiągnąć.
> W tym Twoim przykładzie?:
> ---------------
> static GUI konkretnyGUID = { };
>
> class KlasaKonkretna : public KlasaBazowa {
> public:
>     KlasaKonkretna() : KlasaBazowa( konkretnyGUID ) { [...] };
>
>     [...]
> };
> ---------------
>
> Mi chodziło o to aby: nie tworzyć statycznej zmiennej konkretnyGUID
> tylko zapis jego wartości ująć jakoś od razu w miejscu gdzie go
> wstawiłeś jako parametr konstruktora KlasyBazowej w konstruktorze Klasy
> konkretnej.

Nie rozumiem jaki by to miało mieć zysk.

Gdzieś to musisz trzymać.

Możesz zrobić tak:

class KlasaBasowa {
[...]
virtual GUI& getGUID() = 0;
};

class KlasaKonkretna : public KasaBazowa {
[...]
GUID& getGUID() override {
static GUID guid = { };
return guid;
}
}

Ale zysk taki, że masz metodę wirtualną ale nie masz pola w klasie bazowej.

> Konstruktor KlasyKonkretnej najchętniej zostawiłbym w pliku h, a takie
> static konkretny GUID to dla mnie musi być w pliku cpp więc i
> konstruktor trzeba tam przenieść.

Dlaczeo konstruktor chcesz mieć w h? Zwyczajowo nie ma powodów tego.

> Ja chciałem zrobić coś podobnego jak mam definiowane mikrokontrolery.
> Mam:
> class ATProg : public ATProc
> {
> ....
> public:
>   ATProg(dword fs,dword fp,dword es,dword ep,qeord fm,dword
> sg):ATProc(...){}
> };
> I potem już konkretne są definiowane tak:
> class ATmega162Prog : public ATProg
> {
> public:
>   ATmega162Prog():ATProg(0x4000,128,512,1,0x1EFFFF,0x1
E9404){}
> };

No wiec w czym problem?

class KlasaBazowa {
public:
KlasaBasowa( int a1, int a2, int a3m int a4 );
[...]
};

class KlasaKonkretna : publci KlasaBazowa {
public:
KlasaKonkretna() : KlasaBazowa( 1,2,3,4 ) { };
};


> Czyli konstruktor klasy bazowej miał mieć jeden parametr typu GUID a
> konstruktory kolejnych klas miały go wołać wpisując tam wartość tego GUIDa.

No to dokładnie tak to opisałem.

Być może widzisz to jako problem, że ten GUID jest widoczny przez cały
czas trwania programu w zmiennej globanej, do której przekazujesz
referencje. To jest szybkie - nie trzeba go w miejscu inicjować za
każdym razem.

> Wiem, że mi się to nie udało. Ogólnie wiem, że nie udawało mi się wpisać
> GUIDA jako parametru wywołania konstruktora (bezpośrednio w wywołaniu).

Jesli mówisz o inicjacji w miejscu, to powinno dać radę tak:

struct GUID {
int a1;
int a2;
};

class KlasaBazowa {
public:
KlasaBazowa( GUID const& _gui ) { /*tu mam GUID*/ };
};

class KlasaKonkretna : public KlasaBazowa {
public:
KlasaKonkretna() : KlasaBazowa( {1,2} ) { }
};

Zmienna istnieje tylko na czas wołania konstruktora KlasaBazowa. Musi
być wykorzystana w nim i nie wolno przetrzymać referencji na dłużej
(choć można zrobić kopię). Zapis {1,2} inicjuje GUIDa w miejscu i jest z
nowego C++, w starym to pewnie będzie "GUID(1,2)", zalezy jaki konstruktor.

do góry

W dniu 2022-07-25 o 16:31, heby pisze:
>> Mi chodziło o to aby: nie tworzyć statycznej zmiennej konkretnyGUID
>> tylko zapis jego wartości ująć jakoś od razu w miejscu gdzie go
>> wstawiłeś jako parametr konstruktora KlasyBazowej w konstruktorze
>> Klasy konkretnej.
>
> Nie rozumiem jaki by to miało mieć zysk.

Bo to być może nie da się zrozumieć - jakieś chore moje koncepcje :)

Dla Ciebie 'zysk' to jakieś oszczędności pamięci lub czasu realizacji.

A dla mnie zysk z takiego podejścia polega na tym, że dopisanie kolejnej
klasy to byłoby kilka linijek w jednym pliku, a nie po kilka w dwu plikach.
Jak nowa klasa nie wymaga nic w pliku cpp to dopisuję ją tylko do
jednego wspólnego dla wszystkich tych klas pliku h.
Jak wymaga też czegoś w pliku cpp to w moim pojęciu wypada już całą ją
przenieść do plików h i cpp opisujących urządzenie (inna klasa) które
korzysta z tej bazowej tabelki w której to jest mi potrzebny GUID.

Ale nie jestem do tego aż tak przywiązany.

> Możesz zrobić tak:
>
> class KlasaBasowa {
>     [...]
>     virtual GUI& getGUID() = 0;
> };
>
> class KlasaKonkretna : public KasaBazowa {
>     [...]
>     GUID& getGUID() override {
>         static GUID guid = { };
>         return guid;
>     }
> }

Jak mi się nie udało to zrobiłem podobnie jak napisałeś w powyższym
przykładzie tylko nie w tej klasie a w klasie wołającej jej funkcję
wyszukania wszystkich urządzeń - tam robię lokalnego GUID i go używam.

> Ale zysk taki, że masz metodę wirtualną ale nie masz pola w klasie bazowej.

Patrzysz cały czas na kod wynikowy, a mi chodziło o krótkość zapisu.
Wszystkie używane guidy mam zebrane razem w jednym miejscu - to jest dla
mnie zaleta.

> Dlaczeo konstruktor chcesz mieć w h? Zwyczajowo nie ma powodów tego.

Jak konstruktor tylko woła kontruktor klasy bazowej wstawiając tam
konkretne liczby to jak go napiszę w h to chyba on nawet zrobi się sam
inline.


>> Ja chciałem zrobić coś podobnego jak mam definiowane mikrokontrolery.
>> Mam:
>> class ATProg : public ATProc
>> {
>> ....
>> public:
>>    ATProg(dword fs,dword fp,dword es,dword ep,qeord fm,dword
>> sg):ATProc(...){}
>> };
>> I potem już konkretne są definiowane tak:
>> class ATmega162Prog : public ATProg
>> {
>> public:
>>    ATmega162Prog():ATProg(0x4000,128,512,1,0x1EFFFF,0x1
E9404){}
>> };
>
> No wiec w czym problem?

Problem, że jak chciałem tak zrobić to mi nie wyszło. Nie potrafiłem
wpisać wartości konkretnego guid jako parametr w wywołaniu konstruktora
klasy bazowej. O tym, że nie potrafiłem go wpisać w miejsce parametru
już chyba trzeci raz piszę.

>
> class KlasaBazowa {
> public:
>     KlasaBasowa( int a1, int a2, int a3m int a4 );
>     [...]
> };
>
> class KlasaKonkretna : publci KlasaBazowa {
> public:
>     KlasaKonkretna() : KlasaBazowa( 1,2,3,4 ) { };
> };
>
>
>> Czyli konstruktor klasy bazowej miał mieć jeden parametr typu GUID a
>> konstruktory kolejnych klas miały go wołać wpisując tam wartość tego
>> GUIDa.
>
> No to dokładnie tak to opisałem.

Tak, ale z liczbami int.
Wiem tyle, że jak chciałem tak zrobić z guid to mi nie wyszło.

> Być może widzisz to jako problem, że ten GUID jest widoczny przez cały
> czas trwania programu w zmiennej globanej, do której przekazujesz
> referencje. To jest szybkie - nie trzeba go w miejscu inicjować za
> każdym razem.
>
>> Wiem, że mi się to nie udało. Ogólnie wiem, że nie udawało mi się
>> wpisać GUIDA jako parametru wywołania konstruktora (bezpośrednio w
>> wywołaniu).
>
> Jesli mówisz o inicjacji w miejscu, to powinno dać radę tak:
>
> struct GUID {
>     int a1;
>     int a2;
> };
>
> class KlasaBazowa {
> public:
>     KlasaBazowa( GUID const& _gui ) { /*tu mam GUID*/ };
> };
>
> class KlasaKonkretna : public KlasaBazowa {
> public:
>     KlasaKonkretna() : KlasaBazowa( {1,2} ) { }
> };
>
> Zmienna istnieje tylko na czas wołania konstruktora KlasaBazowa. Musi
> być wykorzystana w nim i nie wolno przetrzymać referencji na dłużej
> (choć można zrobić kopię). Zapis {1,2} inicjuje GUIDa w miejscu i jest z
> nowego C++, w starym to pewnie będzie "GUID(1,2)", zalezy jaki konstruktor.

Zaczyna to być jakby w tym kierunku co ja kombinuję.
Tylko wiem, że nie udało mi się wtedy tego zapisać tak, aby kompilator
przyjął. Nie udało mi się też konwertować bufora bajtów w guid, czy
jakiegoś innego zapisu np kilku wordów w guid.

Ale to było ileś lat temu. Teraz powinienem ponownie popróbować, aby
wskazać co konkretnie mi nie wychodzi, ale mam zero czasu.
Poprzedni post przerwałem bo coś miałem zrobić. Jak tylko to skończyłem
to piszę ten, a w międzyczasie ustaliliśmy tu, że muszę się pilnie czymś
kolejnym zająć (potrzebne na środę) no i znów nie dojdę do powtarzania
eksperymentów.
Po prostu okazja, aby o tym pogadać trafiła się gdy inne zadania
zabierają totalnie czas. Niektóre plany i tak już nieco zawaliłem.
P.G.

do góry

On 25/07/2022 18:00, Piotr Gałka wrote:
> Dla Ciebie 'zysk' to jakieś oszczędności pamięci lub czasu realizacji.

Tak, to w końcu embedded, każdy bajt sie liczy.

> A dla mnie zysk z takiego podejścia polega na tym, że dopisanie kolejnej
> klasy to byłoby kilka linijek w jednym pliku, a nie po kilka w dwu plikach.

To troche stoi w poprzek koncepcji hermetyzacji. Skogo GUID jest
specyficzny dla konkretnej implemetacji klasy, składanie ich w jednym
plików jest nierozsądne, nie powinny wiedzieć o swoim istnieniu.

W ogóle twój przykład wygląda jak próba emualacji Fabryki/Buildera na
konstruktorach. W większych kawałkach kodu było by to zapewne wytknięte
na review ;)

>> Dlaczeo konstruktor chcesz mieć w h? Zwyczajowo nie ma powodów tego.
> Jak konstruktor tylko woła kontruktor klasy bazowej wstawiając tam
> konkretne liczby to jak go napiszę w h to chyba on nawet zrobi się sam
> inline.

inline może zrobić się również, kiedy jesteś w pliku cpp. Zainteresu się
"lto" - w embedded to może być krytycznie ważny bajer, a mało kto
piszący kod na uC wie że w ogóle istnieje.

> Zaczyna to być jakby w tym kierunku co ja kombinuję.
> Tylko wiem, że nie udało mi się wtedy tego zapisać tak, aby kompilator
> przyjął. Nie udało mi się też konwertować bufora bajtów w guid, czy
> jakiegoś innego zapisu np kilku wordów w guid.

Nowe C++ mają interesujace metody inicjacji struktur, może warto
zainteresować się własnie dlatego standardami C++xx. Jedna już Ci
pokazałem: { 10, 20 } konstruje strukturę z dwoma intami, jesli
występuje w kontekscie, gdzie takie coś jest sensowne.

do góry

W dniu 2022-07-25 o 18:12, heby pisze:
> On 25/07/2022 18:00, Piotr Gałka wrote:
>> Dla Ciebie 'zysk' to jakieś oszczędności pamięci lub czasu realizacji.
>
> Tak, to w końcu embedded, każdy bajt sie liczy.

Już co najmniej kilka razy przewinęła się informacja, że ja pod
Builderem, a nie embedded.
Piszę sobie programiki które się komunikują z embedded, ale same nie są
embedded i kilka bajtów w tę czy tamtą mnie nie rusza.

> To troche stoi w poprzek koncepcji hermetyzacji. Skogo GUID jest
> specyficzny dla konkretnej implemetacji klasy, składanie ich w jednym
> plików jest nierozsądne, nie powinny wiedzieć o swoim istnieniu.

Od strony embedded - oczywiście masz rację. To są osobne urządzenia i
nic jednemu do drugiego.

Ale ja piszę o moim programie komunikującym się z nimi.
Potrzebuję zdefiniować N pochodnych klasy Tabelka z których każda z nich
robi dokładnie to samo ale posługuje się innym GUID.
Jak definicje klas pochodnych byłyby kilkulinijkowe w pliku h to jak dla
mnie bardzo rozsądne jest mieć je wszystkie razem. Jak piszę program,
który komunikuje się z jakimś z naszych urządzeń to wkładam ten plik i
mogę działać.

Mój program często komunikuje się z wieloma z tych urządzeń.
Na przykład program produkcyjny.

Najpierw wrzuca do mikrokontrolera urządzenia program testowy.
W tym celu używa naszego programatora PDI (GUID nr 1).
Następnie przeprowadza test urządzenia.
W tym celu używa testera (GUID nr 2). W czasie testu z urządzeniem łączy
się przez jego normalne kanały komunikacyjne. Jeśli jest to urządzenie
USB to jego program testowy to GUID nr 3.

Jak wszystko dobrze to pobiera odpowiedni HEX, wkłada do niego numer
urządzenia i zestaw kluczy dla niego.
Klucze pobiera z kolejnego urządzenia - GUID nr 4.

Programuje urządzenie. Po zaprogramowaniu jeszcze ostatnia kontrola -,
czy urządzenie prawidłowo się odzywa. Jeśli jest to urządzenie USB to
będzie to GUID nr 5.

To w przypadku produkcji jednego urządzenia.
Ale ten program, służy do produkcji wszystkich naszych produktów. Dla
drugiego urządzenia USB dojdą kolejne dwa GUIDy bo program testowy dla
innego hardware'u będzie miał swój GUID i docelowy program znów swój.

Mi pasuje jak tabelki umiące wyszukiwać urządzenia o poszczególnych
GUIDach są zdefiniowane w jednym pliku.
Być może template miałoby tu faktycznie sens żeby do programu weszły
tylko te wersje faktycznie użyte, ale jak poszczególne klasy to tylko
inny konstruktor i być może (zapisany w h) robiony z automatu jako inline.

> inline może zrobić się również, kiedy jesteś w pliku cpp. Zainteresu się
> "lto" - w embedded to może być krytycznie ważny bajer, a mało kto
> piszący kod na uC wie że w ogóle istnieje.

Ja też nie wiem. Nie piszę embedded.
O ile pamiętam w pliku cpp też mogę użyć słowa inline (nigdy nie
użyłem), które dla kompilatora jest jedynie wskazówką.
Zamiast tego wolę to co chciałbym inline zapisać w h.
Zazwyczaj funkcje w klasie, które korzystają z innej funkcji jedynie
wstawiając jakiś parametr zapisuję od razu w h.

Na przykład typową moją funkcją w klasie jest:
void RozkazACK(char c);
Czyli wysłanie rozkazu (w ramce, którą funkcja umie poskładać) i
odebranie potwierdzenia ACK i weryfikacja. Jak się nie zgadza to wyjątek.
I potem mam takie funkcje jak:
void Rozkaz_C(){RozkazACK('C');}
void Rozkaz_z(){RozkazACK('z');}
itd.
wszystko zapisane tylko w pliku h.

> Nowe C++ mają interesujace metody inicjacji struktur, może warto
> zainteresować się własnie dlatego standardami C++xx. Jedna już Ci
> pokazałem: { 10, 20 } konstruje strukturę z dwoma intami, jesli
> występuje w kontekscie, gdzie takie coś jest sensowne.

Czyli pod jakimś nowym C++ pewnie to co próbowałem to by zadziałało.

Przed pisaniem tego posta zrobiłem próby i przygotowałem sobie (na
drugim komputerze) plik do pokazania co dokładnie mi nie działało.
To jest cała treść pliku cpp:
--------------------------------
#include <windows.h>

GUID g= {0x00112233,
0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0x
FF}};

void fun(GUID g);

void fm()
{
fun(g);
fun({0x00112233,
0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0x
FF}});
}
-------------------------------------

Drugiego wywołania funkcji fun Builder 5 nie akceptuje.
Próbowałem dawać dodatkowe nawiasy i nic.

Mój problem rozwiązało by też jakbym potrafił przekonwertować ciąg
bajtów na GUID, bo ciąg bajtów daje się wpisać jak łańcuch.
Ale o ile się nie mylę to też mi to nie wychodziło jakoś prosto. Z tego
komentarza co sobie napisałem wynika, że jakoś problem dawał się
rozwiązać ale było bardziej zagmatwane niż deklaracje zmiennej GUID i
jej użycie i dlatego tak to powpisywałem.
A teraz miałem nadzieję, że jednak się jakoś da.

Czyli wygląda, że usiłowałem uzyskać coś co nowsze już umieją.
Możliwe, że teraz jak już (od niedawna) jestem pod Windows 10 z którym
Builder 2010 się nie gryzie to mogę się stopniowo przenieść pod niego.
Mimo, że to 2010 a kolejne wersje C++ zaczynają się od 11 to kto wie
mogli coś tam zrobić sami z siebie a potem zostało to wciągnięte w standard.
P.G.

do góry

On 25/07/2022 20:40, Piotr Gałka wrote:
>>> Dla Ciebie 'zysk' to jakieś oszczędności pamięci lub czasu realizacji.
>> Tak, to w końcu embedded, każdy bajt sie liczy.
> Już co najmniej kilka razy przewinęła się informacja, że ja pod
> Builderem, a nie embedded.

To Cie nie usprawiedliwia ;) Już w wątku narzekano na Javę, że taka
spasła...

>> To troche stoi w poprzek koncepcji hermetyzacji. Skogo GUID jest
>> specyficzny dla konkretnej implemetacji klasy, składanie ich w jednym
>> plików jest nierozsądne, nie powinny wiedzieć o swoim istnieniu.
> Od strony embedded - oczywiście masz rację. To są osobne urządzenia i
> nic jednemu do drugiego.
> Ale ja piszę o moim programie komunikującym się z nimi.

To akuratnie źle od embedded i od PC.

> Mi pasuje jak tabelki umiące wyszukiwać urządzenia o poszczególnych
> GUIDach są zdefiniowane w jednym pliku.

Architekturę zrobiłbym zupełnie odwrotnie, tzn moduły rejestrowały by do
tabelki co mają.

> Być może template miałoby tu faktycznie sens żeby do programu weszły
> tylko te wersje faktycznie użyte, ale jak poszczególne klasy to tylko
> inny konstruktor i być może (zapisany w h) robiony z automatu jako inline.

Niekoniecznie. Templates tutaj miały by sens, gdybyć chciał zyskać
jakies bajty w RAM kosztem bajtów Flash itp machloje. W przypadku
programowania PC nie ma to znaczenia i robisz, jak Ci wygodnie, choc
oczywiście złośliwy by się czepiał że nie prawilnie.

> O ile pamiętam w pliku cpp też mogę użyć słowa inline (nigdy nie
> użyłem), które dla kompilatora jest jedynie wskazówką.

To ma wtedy ograniczone znaczenie w tym pliku i jest mało uzyteczne -
kompialtor i tak inlineuje funkcje, któe uzna i nie inlineuje, nawet
tych oznaczonych, jesli mu się nie spodobają. To takie samo słowo jak
"register" w C, obecnie bez sensu.

> GUID g= {0x00112233,
> 0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0x
FF}};
>
> void fun(GUID g);
>
> void fm()
> {
>   fun(g);
>   fun({0x00112233,
> 0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0x
FF}});
> }
> Drugiego wywołania funkcji fun Builder 5 nie akceptuje.
> Próbowałem dawać dodatkowe nawiasy i nic.

void fun(GUID const& g);

fun( GUID(0x100,0x100,...) ); ?

> A teraz miałem nadzieję, że jednak się jakoś da.

Się da, ale nie wiem czy Builder nie ma jakiś problemów. Kiedy w nim
pisałem, 20 lat temu, miał masę problemów z C++.

> Czyli wygląda, że usiłowałem uzyskać coś co nowsze już umieją.
> Możliwe, że teraz jak już (od niedawna) jestem pod Windows 10 z którym
> Builder 2010 się nie gryzie to mogę się stopniowo przenieść pod niego.
> Mimo, że to 2010 a kolejne wersje C++ zaczynają się od 11 to kto wie
> mogli coś tam zrobić sami z siebie a potem zostało to wciągnięte w
> standard.

Wątpie. Builder nigdy nie był specjalnie nowoczesny.

do góry