Witam
Zapadła męska decyzja i postanowiłem się zaprzyjaźnić trochę z "embedded" C++... Tzn. na razie to będzie (długo będzie...) raczej taki C-plus-minus / "C z wstawkami ++"

Do rzeczy - odświeżyłem sobie podstawy z kilku "prastarych" ksiąg, przeczytałem poradniki na forum i troszkę wygrzebałem z Internetów. W efekcie powstała lista kilku drobnych pytań i wątpliwości. Z góry dziękuję za wszelką pomoc, podpowiedź, wskazanie źródeł wiedzy, etc...

Primo - byłbym wdzięczny za wskazanie wszelkich wartościowych materiałów na temat C++ (szczególnie w kontekście łembeded) - poziom zdecydowanie zielono-początkowy W Internecie jest sporo materiałów, ale nie chciałbym sobie zrobić "krzywdy" na starcie jakimś poradnikiem "wątpliwej jakości" - a nie mnie oceniać ich jakość. Mile widziane również wskazanie porządnych kodów do "samodzielnej analizy".

Secundo - pytania "konkretne":
1. Jak wygląda rozmieszczenie składników klasy w pamięci? W C sprawa była prosta - składniki struktury lądowały w pamięci po kolei, ew. dochodził jakiś wypełniacz. A co z klasami? Co jeśli składniki prywatne i publiczne będą pomieszane, np:Kompilator ma prawo zmienić ich kolejność w pamięci? Jak wygląda sprawa z wyrównaniem danych - można "upakować" klasę?

2. W C zmienne globalne/statyczne są zerowane -> czy w C++ tworząc globalny obiekt jakiejś klasy, jej składniki też zostaną wyzerowane? Trochę się pobawiłem i z moich obserwacji wynika że tak, ale nie wiem czy to "zasada" czy akurat "tak mi się trafia". Mój "kod testowy" (testuję w GCC online):
Przykładowy wynik powyższego kodu:
Za każdym razem składniki obiektu globalnego mam wyzerowane. Konstruktor tego nie robi, stąd mój powyższy wniosek - czy słuszny?

3. Jak rozumieć taki zapis:Jak w C++ traktowany jest obiekt (jakiejś klasy) z atrybutem volatile? Czy volatile przenosi się na składniki obiektu tej klasy?

4. Jeżeli tworzę nowy obiekt za pomocą new to najpierw jest wywoływany operator new, a potem konstruktor - zgadza się? A co jeśli przydział pamięci się nie powiedzie - tzn. dokładniej - czy jestem w stanie (tworząc operator new dla swojej klasy) zapobiec wywołaniu konstruktora jeśli nie mogę przydzielić pamięci dla nowego obiektu? (wyjątki schowane na dnie szafy i niech tam pozostaną)

5. Wątpliwość dotyczy szablonów funkcji i specjalizacji dla konkretnego przypadku. Poniżej kod testowy - jest szablon funkcji i dwie wersje specjalne (dla int i float). Obie wersje działają tak jak bym chciał (jeśli chodzi o efekty na ekranie), kompilator nie krzyczy, ale przypuszczam, że to jednak nie jest "to samo". Kod testowy:


6. Można jakoś zabezpieczyć klasę przed utworzeniem kilku obiektów? (np. ten nieszczęsny jeden ADC w Atmedze). W "Internetach" pojawia się hasło "singleton", ale nie wiem czy to dobry trop?

7. Co łopatologicznie znaczy constexpr? Tu i tak znalazłem opis, że jest to "wyrażenie stałe na etapie kompilacji"... no dobra, ale jak kompilator traktuje ten "constexpr" - jako "zapewniam się kochany kompilatorze, że możesz to policzyć jeśli się postarasz" czy jako "prawdopodobnie możesz to policzyć" czy "jeśli możesz to policzyć to policz"?
Spłodziłem np. taki piękny kod:
Co z tym nieszczęsnym constexpr - kompilator tego nie policzy przy pracy (no bo jak), nie powinien więc delikatnie zasugerować, że "miało być stałe przy kompilacji a tu lipa"?

8. Przekazuję zmienną ulotną (a) do funkcji przyjmującej zwykły int bez jawnego rzutowania - czemu kompilator na to pozwala, przecież obiecywali ścisłą kontrolę typów

Tercio - pytania mniej konkretne... :

10. Jak to jest z tym narzutem dla konkretnych ficzerów z C++. Broń Boże nie chcę powielać baśni ludowych! Chodzi mi raczej o prosty przepis dla początkujących. Taki punkt startowy:
- te funkcje stosuj do woli
- przy tych pomyśl / doczytaj / poczekaj / zastanów się bo...
- te są bee i ani-misie-wasz!

Empirycznie sprawdziłem, że wszystkie moje programy napisane w "Cy", które skompilowały się w "Cy-py-py" były mniejsze od oryginałów w "Cy" - głównie za sprawę mądrzej dobranych rozkazów _call/_jmp.

Wydaje mi się, że elementy takie jak: szablony, przeładowanie nazw, argumenty domyślne, klasy - przy odrobinie ostrożności wprowadzają praktycznie pomijalny narzut (jeśli w ogóle jakiś wprowadzą).

Co jest w następnym kroku? Chyba dziedziczenie/funkcje wirtualne - próbowałem przebrnąć przez mądre opisy o vtable'ach ale mnie to pokonało... Można jakoś pi*drzwi określić jakie konstrukcje jaki narzut powodują?

Z tego co się naczytałem to wyjątków raczej należy unikać. Są inne ficzery paskudne z definicji ?

11. Jak się przyzwyczaić do referencji, tzn. obawiam się, że analizując kod będę miał podejście "typu C". Tj. widząc wywołanie funkcji z argumentem bez "&" podświadomie zakoduję, że - ona nie modyfikuje argumentu bo pracuje na kopii. Są jakieś sprawdzone sposoby jak się przestawić i nie wpadać w taką pułapkę?

Finito tymczasowo
Pozdrawiam Wojtek

Przepraszam, że tak bezczelnie podłączę się do dyskusji z lekką dygresją od tematu, ale czy istnieje jakiś kurs Kolegi Mokrowskiego do C++? -bo masz Kolego dar do przekazywania wiedzy, a nie każdy to posiada. Nie chodzi mi zaraz o całą "Symfonię C++" Kolegi Mokrowskiego. Wychodzę z założenia, że najistotniejsze jest podać we właściwy sposób wiedzę i ew. źródła gdzie można ją znaleźć w przypadku bardziej rozległych wywodów (których z reguły nie chcę drugi raz pisać).

Widziałem tutaj na forum różne Twoje kursy oraz np. porównania języka C i C++ Kolego Mokrowski, ale teraz mam na myśli bardziej całościowe ujęcie tego razem (podkreślam o odwołaniach/linkach tego co już napisałeś).

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

O kurczę! Bardzo dziękuję za odpowiedź! Bałem się, że nikomu nie będzie się chciało przebrnąć przez ten mój tasiemiec

Ad. 1,2,3 - O! Wreszcie coś w tym Ce-pepe co nie wywraca światopoglądu i zachowuje się kulturalnie jak w Cy
Tzn. nie do końca, bo z tym statycznym elementem inicjowanym w konstruktorze to nie mogłem się powstrzymać i jednak mi działa "Dzieło":
Wynik:Chyba, że przez "inicjalizację w konstruktorze" mam rozumieć tylko i wyłącznie listę inicjalizacyjną? (bo wtedy rzeczywiście kompilator krzyczy)

Ad. 6 (singleton i szablony) - tak coś czułem że statyczna flaga wskazująca, że jedyny dopuszczalny obiekt klasy istnieje to mało ambitne rozwiązanie. Znowu te paskudne... Szablony są super! Do momentu kiedy kończy się opis jak zrobić prostą funkcję/klasę szabloniastą i zaczynają się meta-potworki Obliczanie silni "szablonowe" jeszcze jako-tako rozkminiłem... ale jak znalazłem kilka "ciekawszych" przykładów to się poddałem.

Ad. 7. Tego constexpr nie "czuję" ani trochę
"a*2" - jak to może być stałe wyrażenie dla kompilatora? Jeśli funkcja będzie wywołana ze stałym argumentem to ok w porządku... tyle, że bez constexpr kompilator też ją chyba "wywali" (zauważy, że zwraca stałą wartość). Myślę, że błędnie sobie to zaszufladkowałem na początku i teraz na siłę próbuję dopasować do mojego wyobrażenia, stąd mi nie pasuje. A zaszufladkowałem sobie tak: constexpr oznacza, że wyrażenie jest "obliczalne" na etapie kompilacji, więc kompilator może je policzyć, wychrzanić i wstawić konkretną wartość. Np. "sin(2)" jest stałe na etapie kompilacji, ale "sin(zmienna_o_wartości_nieznanej_w_chwili_kompilacji)" już nie jest constexpr - ale coś nie widzę, że to nie do końca tak

Cytat z wiki: "C++ has always had the concept of constant expressions. These are expressions such as 3+4 that will always yield the same results, at compile time and at run time." Jak u licha a*2 ma zwracać to samo przy kompilacji i "at run time" ?

Chyba, że constexpr to tylko sugestia dla kompilatora nie obligująca go do niczego (jak inline) i w powyższym przykładzie pomimo mojego constexpr kompilator zauważa, że nie może tego policzyć i olewa const...? Ale wtedy mógłby chociaż jakiś mesydż podrzucić z łaski swojej No i na tej zasadzie to wszystko można by opisać jako stałe wyrażenie, a potem niech gcc sobie wybiera

Asemblera podglądam, ale z/bez constexpr - nie ma różnicy w tym moim przykładzie ;/

---- o moment... chyba coś "łapię" (przynajmniej mniej śnieży)
Cytat: "constexpr functions are guaranteed to be evaluated at compile time if all arguments are compile time constants." (źródło) - zakładając, że zacytowane zdanie jest prawdziwe (jest ?) - czy można jakoś wymusić na kompilatorze aby krzyczał jeśli funkcja z constexpr nie daje się policzyć?

Ad 8. Dobra dobra, faktycznie pojechałem po całości. To pytanie przyszło mi do głowy "przy okazji" przy eksperymentach z constexpr i tak się skupiłem na "szczególe" że nie dostrzegłem oczywistej oczywistości... (nie widzę lasu bo drzewa mi zasłaniają). Także ten... nie było tego pytania

Ad 9. Dziewięć nie ma, bo pytania z grupy "mniej szczegółowe" miały mieć "osobną" numerację jak numeracja pokoi na różnych piętrach

Ad 10. "virtual naucz się i unikaj" A już takie śliczne hierarchiczne maszyny stanów mi się zamarzyły. Tylko nie mów, że da się szablonami
Ok o resztę będę pytał w razie potrzeby jak się oswoję z tym co do tej pory

polecam http://miroslawzelent.pl/

_________________
невозможно ?

Słyszałem i uczyłem się z tych kursów (właściwie nadal się uczę jeśli coś akurat zapomnę), może oprócz tych od Pana Mirosława Zalenta. "Symfonię C++" i "Pasję C++" Pana Grębosza posiadam i jeszcze parę innych książek, ale mniejsza o to. Chciałem podkreślić Kolego Mokrowski, że Ty jako programista posiadasz ten dar przekazywania wiedzy, a nie tylko implementacji dobrych programów. Piszę to całkowicie obiektywnie, po tym co już tutaj zdążyłem zaobserwować na forum.

Trzymam kciuki i niecierpliwie oczekuję "kilku" słów wprowadzenia.

Pozdrawiam! j23 Jarek

_________________
"O sygnałach bez całek" Czesław Frąc

@D_C - dziękuję za link

@mokrowski - no właśnie najciekawsze wydają się te najnowsze fiuczery, o których najmniej napisano jak dotąd Co do meta-maszyny - dziękuję za link, ogarnięcie tego trochę mi zajmie.

Ja to właściwie chyba nie lubię języków "wyższego" poziomu i wszystkich dobrodziejstw z nimi związanych (z bibliotekami włącznie) Co to za przyjemność z programowania jak "wszystko już jest". Może to jakieś odchylenie (syndrom NIH?), ale największą frajdę dają mi takie niskopoziomowe zabawy i poniekąd odkrywanie koła na nowo. Jak próbowałem coś napisać w Python'ie to każdą funkcję (np. operującą na stringach) traktowałem podejrzliwie i zastanawiałem się "czy nie napisałbym tego 'lepiej' po swojemu".

Kiedyś uczyłem się C++ z http://cpp0x.pl/. Polecam

Jeżeli Trzymającym Władzę to nie przeszkadza, to ja nie mam nic przeciwko zjeżdżaniu na pobocza w tym topicu

@mg101 - dziękuję za kolejny link do zbioru

Nie twierdzę, że biblioteki standardowe są złe. Po prostu moje doświadczenia z programowaniem to w 80-90% zabawy z avr/stm. Pozostała część (programy na "normalne komputery") to przede wszystkim prościutkie programiki pisane żeby coś sprawdzić/przetestować/pobawić się (bo PC daje "instant effect" bez debuggera, szukania płytki stykowej i ledów etc etc...). Mam zerowe doświadczenie jeśli chodzi o pisanie "normalnych" programów.

I teraz do sedna: wydaje mi się, że biblioteki są pisane przede wszystkim z myślą o "głównym nurcie" i w prostych systemach wbudowanych często okazują się... nie najlepszym rozwiązaniem. Myślę, że stąd bierze się ta podejrzliwość względem wszystkiego co gotowe - bo może można prościej, bez bajerów itd... Dodatkowo to przeświadczenie "dokarmiane" jest często po porównaniu funkcji gotowych i własnych.

Gdzieś/kiedyś trafiłem na przykład serwera http w pythonie - to były z grubsza 3 linijki kodu na krzyż. Przeraża mnie to w pewnym sensie Zaletą C i poniekąd asm'a jest dla mnie prostota - mam ograniczony zestaw prostych narzędzi i z ich pomocą jestem w stanie zrobić sobie wszystko (cały czas mówię o AVR'o podobnych). Kiedyś próbowałem przebrnąć przez manual bascom'a - poddałem się bo tego wszystkiego było za dużo. Być może dla niektórych to zabrzmi niedorzecznie, ale według mnie taki bascom czy biblioteki Arduino wymagają o wiele więcej nauki niż C - przynajmniej raz trzeba przebrnąć przez opis funkcji, żeby potem wiedzieć jakie zabawki się ma do dyspozycji. O Pythonie nawet nie wspomnę

Na pewno inaczej bym to wszystko postrzegał, gdybym był związany z programowaniem zawodowo a nie hobbystycznie. Zalety, o których wspominasz (efektywność tworzenia projektów) dla mnie są... gdzieś na końcu listy zalet. Może kiedyś ten punkt widzenia się zmieni

W *.lss spędzam więcej czasu niż we wszystkich pozostałych plikach projektu razem wziętych Jak dotąd AVR-G++ nie dał się przyłapać na czymś paskudnym. Przy Cortex'ie nie do końca rozumiem wszystko czym mnie toolchain uszczęśliwia - np. "frame_dummy", funkcje _init/_fini które nic mądrego nie robią, udziwniony (według mnie) sposób wywoływania konstruktorów obiektów globalnych i statycznych - ale małymi kroczkami dochodzę z G++ do porozumienia

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

Witam ponownie Że tak powiem, "podbijam temat" z okazji pojawienia się nowego problemu/ów. A problem/y wygląda/ją tak:

1. Czy jest jakiś sposób, aby w konstruktorze dokonać statycznego (w czasie kompilacji) sprawdzania wartości parametrów (np. czy ">0" itp...)? Próbowałem następujących opcji:
- static_assert - nie działa bo parametr wewnątrz funkcji nie jest constexpr
- konstruktor "szablonowy" i parametr przekazywany jako parametr szablonu - też nie działa - tylko nie mogę dojść do tego, czy to ja nie wiem jak to zapisać, czy konstruktor nie może być szablonowy w taki sposób jak ja bym tego chciał:


2. Jeżeli korzystam z szablonów klas, to każda "wersja" klasy wygenerowanej z szablonu ma swój zestaw metod - bez względu na to, czy kod danej metody zależy od parametrów szablonu czy też nie. Jest jakiś elegancki sposób aby metody "niezależne" od parametrów szablonu (identyczne dla wszystkich klas utworzonych z szablonu) nie były powtarzane i nie zajmowały pamięci?