Rynek pracy STM32

Powiem krótko, pierdol się, jesteś bucem i tyle.

Fakty potafią boleć. Ja wiem.

Dupa a nie fakty, ja dyskutując z tobą starałem się ciebie nie obrażać a ty ciągle robisz wycieczki osobiste i mnie obrażasz, nazywasz mnie kłamcą, nieukiem itd. a tymczasem ja mam prawo mieć swoje zdanie, programować można na wiele różnych sposobów bel osiągnąć właściwy cel. A ty tonem wszystkowiedzącego narzucasz tylko swój punkt widzenia a co nie pasuje to mieszasz z błotem. Czyli zachowujesz się jak typowy gbur, zarozumiały buc i prostak który bez wycieczek osobistych nie potrafi dyskutować.

Jesteś na etapie ich negowania.

Ale Ci nie wychodzi.

Oczywiście. Informacja o potoku jest w 2-gim akapicie wikipedii o 486. Zanim napisałeś, nawet nie sprawdziłeś.

To się świetnie sprawdza w sztuce, ale nie w naukach ścisłych. Szczególnie że nie piszesz "moim zdaniem 486 nie ma potoków" tylko piszesz, że nie ma i już. To jest kłamstwo. Do sprawdzenia w 3 sekundy. To samo ze statycznym i dynamicznym polimorfizmem, co do których nie masz śladu pojęcia czym są. To nie są opinie. To są kłamstwa.

Ale mimo to ludzkośc znalazła wspólne nazwy i techniki, pozwalajace jej porozumiewać się w sposób ścisły. Tu nie ma miejsca na swoje koncepcje. Szczególnie, że w Twoim przypadi te koncpecje są biegunowo odległe od rzeczywistości.

Ostatnio głównie cytuje definicje, z którymi się nie zgadzasz i prezentuje przykłady, które w/g Ciebie nie mają prawa działać. To nie jest mój punkt widzenia.

Tak naprawdę masz nikłą wiedzę w tych tematów. Zgaduje, że najzwyczajniej świat Ci uciekł jakieś 20 lat temu i nie dogoniłeś go. Ale dalej uważasz, że *wydaje* Ci sie, jak to ma działać, więc na pewno tak działa. No więc nie.

Cytujac definicje? Jesteś jednym z tych ludzi, którzy uważają prawdę za obraźliwą? Kompilatory C++ nie działają, jak myślisz. Runtime generowanego kudu nie działa, jak myślisz. Procesory mają potoki, odwrotnie jak myślisz. To Cie miesza z błotem? Że świat działą inaczej?

Przecież sam wpadłeś w środek *grzecznej* i bardzo miłej dyputy z butam, wrzeszcząć coś o Harvardzie, nie mając pojęcia jak działa współczesny procesor, posługując się stosem kłamstw i bredni. Buc? Oglądałeś się ostatnio w lusterku? Gdybys tu nie wpadł ze swoją ignorancją dysputa grzecznie by się zakończyła. A tak, nie możesz odpuścić, zamiast dopuścić fakt, ze nie wiesz co mówisz.

Dostałeś to, z czym przyszedłeś. Dostałeś w łeb starając się ustawić dyskutanta do pionu. Obnażono trudne do przełknięcia fakty, że nie masz pojęcia o czym mówisz. Być może myślałeś że znasz się na czymś, ale nie bierzesz pod uwagę, że *zawsze* są ludzie znający się na czymś lepiej i należy najzwyczajniej uważać w pewności siebie. Tu jest pełno ludzi, którzy znają się lepiej ode mnie na masie tematów i nie przyszło by do głowy spierać się znimi o czymś, czego nie rozumiem. Dyskusja to nie narzucanie punktów widzenia. Za to wpadanie w środek grzecznej dysputy z ignorancją w ręku, już tak.

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.

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 ;)

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.

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

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

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 mi wieloletni zgryz wyjaśniłeś :)

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.

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.

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

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.

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

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

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,0x1E9404){} };

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.

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.

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

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 ) { }; };

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.

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.

W dniu 2022-07-25 o 16:31, heby pisze:

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.

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.

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.

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.

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

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

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.

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

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 ;)

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.

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.

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.

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.

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.

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,0xFF}};

void fun(GUID g);

void fm() { fun(g); fun({0x00112233,

0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF}}); }

-------------------------------------

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.

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

To akuratnie źle od embedded i od PC.

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

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.

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.

void fun(GUID const& g);

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

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

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

W dniu 2022-07-25 o 21:29, heby pisze:

Tak mi było dla mnie naturalnie. Jak wyszukuję według GUID i jest ich kilka to zakładam, że przyszły użytkownik tego kodu (czyli ja za ileś tam lat) w takiej sytuacji będzie musiał np wypisać na ekranie numery urządzeń i zapytać użytkownika o które urządzenie mu chodzi. Czyli już w momencie wyszukiwania jest mi potrzebna tabelka. Jeśli chciałbym mieć tabelkę wszystkich, które w danej aplikacji w sumie używam to wtedy byłaby to tabelka do której wszyscy zgłaszają co używają.

Wstawiłem ten const&, żeby nie było, że kombinuję inaczej. Żadna z poniższych kombinacji nie przechodzi: fun(GUID{0x00112233,0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF}}); fun(GUID(0x00112233,0x4455,0x6677,{0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF})); fun(GUID(0x00112233,0x4455,0x6677,(0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF))); fun(GUID(0x00112233,0x4455,0x6677,0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF)); fun(GUID(0x00,0x11,0x22,0x33,0x44,0x55,0x66,0x77,0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF));

W obu ostatnich przypadkach: Error: Cannot cast from 'int' to '_GUID'.

To są wszystko próby jakie ja już te 5+ lat temu robiłem.

Ale właśnie sprawdziłem, że takie coś przechodzi:

unsigned int a=0x00112233; unsigned short b=0x4455; unsigned short c=0x6677; unsigned char d[8]={0x88,0x99,0xAA,0xBB,0xCC,0xDD,0xEE,0xFF};

GUID g= {a,b,c,{d[0],d[1],d[2],d[3],d[4],d[5],d[6],d[7]}};

Dlaczego ten dziadowski GUID, który w sumie jest przecież ciągiem bajtów, jest definiowany w taki dziwny sposób to dla mnie zagadka.

Pamiętam, że wtedy próbowałem podawać dane inaczej (może jest inny konstruktor), ale nie trafiłem w nic sensownego.

To w sumie oznacza, że mógłbym jako parametr konstruktora podać ciąg bajtów zapisany jako łańcuch (bo inaczej to chyba nie da się (w moim Builderze) wpisać od razu w linijce). W konstruktorze klasy bazowej musiałbym to korzystając z tej metody zamienić na GUID i przypisać tę wartość zmiennej w tej klasie bazowej (ale raczej po prostu GUID a nie referencji do GUID).

A może bardziej zgodne z defaultową postacią zapisu tych GUID będzie jakby konstruktorowi klasy bazowej dać 4 zmienne (dword,word,word,byte*). Zakładam, że da się wpisać (byte*)".....". Jak nie to ostatni parametr char*. byte, word, dword to moje typedef stosowane we wszystkich programach.

To chyba jest metoda, aby uzyskać mniej więcej to co chciałem. Sprawdzę jak zadziała i może przerobię wszystko, co w tym temacie mam napisane, ale zdecydowanie nie teraz.

Możliwe, ale chodzi mi po głowie, że jakieś rzeczy, które oni wcześniej zrobili widziałem gdzieś jako nowość w C++11. Nie pamiętam o co chodziło - po prostu zapamiętałem zdziwienie, że czytam, że coś jest nowe, gdy ja to już od dawna znam. P.G.

W dniu 2022-07-26 o 13:53, Piotr Gałka pisze:

A może zamiast byte* jednak dać tam 8 pojedynczych bajtów. Po co oszczędzać na liczbie parametrów - powinny wylądować ciurkiem na stosie. Ale komputer 64 bitowy obrabiając bajty chyba dużo kombinuje. Zaczynam się skłaniać do podania 4 liczb dword. Ale i tak będę musiał z tego powydzielać bajty do tej nieszczęsnej definicji GUID czyli i tak robotę z pojedynczymi bajtami mu zapewnię to może jednak zostawić tak, aby wyglądało podobnie do standardu - czyli (dword,word,word,byte,byte,byte,byte,byte,byte,byte,byte). P.G.

Jesteś pewny tego "_" ?

Ogólnie kod zachowuje sie, jak gdyby GUID nie miał konstruktora przyjmującego cokolwiek, poza konstruktorem kopiującym, stworzonym automatycznie.

Taki jest komunikat.

Ogólnie to chyba kiedyś dawno czytałem, że Builder do wielu identyfikatorów dodaje sobie z przodu '_'. Być może to było jak kiedyś mi coś pisałeś jak zrobić bibliotekę. Może wtedy się okazywało, że jak ja nazywam jakąś funkcję ala to ona przez innych musi być wołana jako _ala. Było jakieś uzasadnienie, ale nie pamiętam. A może ten GUID to jakieś makro i tak faktycznie głębiej jest _GUID a kompilator po rozwinięciu makr zna już tylko _GUID.

Ja zakładałem, że to raczej struktura niż klasa, tylko, że w C++ to się prawie niczym nie różni. Nie chciało mi się szukać po windows.h bo to jest zazwyczaj mało czytelne dla mnie.

Ale skoro mogę wpisać GUID{dword,word,word{byte,byte,byte,byte,byte,byte,byte,byte}} to pasowało by chyba do struct zawierającej te dane w takich rozmiarach i takiej kolejności, a kopiowanie dla struktur to nawet w C było jak w ogóle słowo konstruktor w odniesieniu do języka nie istniało dla mnie. P.G.

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

Odgrzebię starą wypowiedź bo małe! co nieco mogę powiedzieć. Z tą objętością to pewnie przesadziłem. Nie wiem co to flaga -0s Make ostatnio używałem z Turbo C++ 1.0 w okolicy 1990. Od tamtej pory używam po prostu środowiska więc nie znam żadnych flag.

Dziś brat trochę mi opowiedział o tym przykładzie USB który ma z jakimś ich systemem uruchomieniowym. To jest przykład, ale to wygląda jakby stosowany zestaw funkcji miał być (według słów brata olbrzymią) biblioteką do obsługi USB w tych procesorach.

To co mogę powiedzieć jest trochę jak głuchy telefon bo wiem, że choć ma się jakieś wyrobione zdanie trudno jest czasami wszystko wyłożyć komuś (czyli mi) kto nie zna szczegółów. Mówi się wtedy tylko o prostych najważniejszych rzeczach i wiele szczegółów ginie.

Mówił mniej więcej tak: Jakoś w końcu udało mi się przebić przez ten przykład. Wreszcie mi to zadziałało - urządzenie zgłasza się jako nasze. Tylko tyle tam mi śmieci zostało z tego co oni napisali... Nie uwierzysz jak idiotycznie to jest napisane. Po pierwsze wszystko robią w przerwaniach. Kto to widział. Przerwanie powinno być krótkie, a nie że jak się zaczyna to końca nie widać. Całe ramki analizują w przerwaniach. Na dokładkę na cały czas przerwania blokują wszystkie inne. No jak takie coś ma potem w ogóle działać. Jest taki endpoint kontrolny do którego przychodzą tylko ramki sterujące. Jest ramka z danymi z którymi trzeba coś zrobić i jest ramka na którą ja mam odpowiedzieć. Jak odpowiem to mam dostać potwierdzenie w postaci pustej ramki. Wyobraź sobie, że oni jak wyślą te dane to przestawiają cały endpoint kontrolny na odbiór zwykłych ramek (a przecież do enpointa kontrolnego takie ramki nie mogą w ogóle trafiać) i w ten sposób odbierają tę pustą ramkę i potem znowu przestawiają wszystko na odbiór ramek sterujących bo może taka się zdarzy. Zapytałem, a czy muszą się przestawiać: Nie w życiu. Tę pustą ramkę swobodnie odbieram bez przestawiania czegokolwiek. Program jest tak pisany jakby było wiadomo, że teraz ma przyjść akurat ta pusta ramka. A jak nie dotrze to będzie to wisiało bo się nie przestawi na ramki sterujące. Przecież tak nie może program wyglądać. I potem ktoś się wzoruje na czymś takim i mamy jak mamy. Ja: Jak przestawiony na normalne to kontrolnych nie odbierze? Nie odbierze.

To był trochę przycinek do mnie, bo moje programy na PC komunikujące się z naszymi urządzeniami ja tak piszę, że czekam na to co wiem, że ma przyjść i jak jest coś innego to wywalam błąd. Brat w ogóle nie akceptuje takiego podejścia i nie omieszka mi tego zawsze wytknąć. Podobno ratuje mnie tylko to, że moje programiki to są do prostych operacji z naszymi urządzeniami i jak się coś wysypie to można powtórzyć. Ale ja uważam, że skoro ja rządzę na łączu to mogę zakładać, że wszyscy się podporządkują. Według niego nie można nigdy czekać na to co się wię, że ma przyjść i nie wiedzieć co zrobić z nieoczekiwanymi ramkami i co zrobić jak się nie doczekamy (ja w niektórych sytuacjach je celowo gubię i czekam (z timeoutem) na tę jedną jedyną co wiem, że ma przyjść). Zawsze trzeba być przygotowanym na wszystko bo może na łącze dostanie się wcześniej jakaś inna ramka. To jego podejście chyba głównie jest kopiowaniem podejścia z RS485 gdzie kompletnie nie wiadomo co przyjdzie, czy do mnie, czy w ogóle inni rozmawiają, czy może zderzenie ramek. I urządzenie ma w każdej chwili wiedzieć (czyli tyle co przerwanie na zbocze - a w sensie całej szyny RS485 najdalej po czasie propagacji zbocza - około 10us), że linia jest zajęta i jak się ma chęć coś nadać to trzeba poczekać na koniec czyjejś transmisji. To wynika z tego, że my na RS485 nie stosujemy odpytywania tylko każdy, kto coś ma do nadania nadaje. Informacje są przekazywane prawie najszybciej jak się da. Minimalne przerwy na łączu wynikają z dodawania losowych opóźnień aby jak dwaj wejdą na raz to przy następnym razie już jeden był wcześniej od drugiego. P.G.