Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

Jaką przewagę ma C++ nad C w przypadku mikrokontrolerów

grzegorz_3739 03 Lis 2016 20:25 5205 82
  • #61 03 Lis 2016 20:25
    Jado_one
    Poziom 22  

    Skoro dyskusja o językach się już nieco wyczerpała, to pytanie dodatkowe: A czy znajomość elektroniki w programowaniu embedded się przydaje czy może nie? :-)
    Zdarzyło mi się już widzieć "programistę" embedded, który nie wiedział jak się używa oscyloskopu, a jedynym jego przyrządem pomiarowym był miernik uniwersalny LCD za 11zł z Wolumenu :-)
    Może oprócz uczenia się C/C++ warto również trochę przysiąść do elektroniki, której teraz chyba coraz mniej uczą w szkołach?

  • #62 03 Lis 2016 22:59
    grko
    Poziom 32  

    Cytat:
    Ciekawe czy więcej ludzi zrozumie normalny kod w C++ czy to "piękne" makro container_of() [;


    Czyli to jednak C uchodzi za język skomplikowany, tak? Sorry ale to już ociera się o ewangelizm. Ciekawe jak na bieżąco są programiści C++ z super prostymi i łatwymi do nauczenia się ficzerami języka wprowadzanymi z standardu na standard. Containter_of wygląda przy tym rzeczywiście jak Hipoteza Riemana;)

  • #63 03 Lis 2016 23:19
    2675900
    Użytkownik usunął konto  
  • #64 03 Lis 2016 23:19
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Ale jesteś świadomy tego, że owe container_of() nie jest nawet rozwiązaniem zgodnym ze standardem i działa tylko w GCC, jeśli przypadkiem nie wyłączysz wszelkich rozszerzeń?

    Kod: bash
    Zaloguj się, aby zobaczyć kod


    Wciąż obstaję więc przy swoim, że kod w C++ jest bardziej zrozumiały niż czary w preprocesorze korzystające jeszcze z mało znanych rozszerzeń GCC.

  • #65 03 Lis 2016 23:24
    grko
    Poziom 32  

    @Freddie Chopin A czy wiesz, że jest możliwe napisanie tego makra bez typeof? W pełni zgodnie ze standardem. Nie jest żadną niespodzianką, że w Kernelu chętnie korzystają z rozszerzeń gcc. Dodam jeszcze do tego to, że jądro mogą skompilować jeszcze dwa inne kompilatory: Intel oraz Clang.

  • #66 03 Lis 2016 23:39
    2675900
    Użytkownik usunął konto  
  • #67 03 Lis 2016 23:40
    Freddie Chopin
    Specjalista - Mikrokontrolery

    grko napisał:
    A czy wiesz, że jest możliwe napisanie tego makra bez typeof?

    A wiesz, że typeof nie jest tam jedynym rozszerzeniem?

  • #68 03 Lis 2016 23:44
    grko
    Poziom 32  

    @Freddie Chopin Wiem, są jeszcze ({}). Co nie zmienia faktu, że nadal to makro można napisać zgodnie ze standardem więc ostatnie nasze posty są bezcelowe. Czy może nie wierzysz i oczekujesz abym pokazał wersję zgodną ze standardem? :)

  • #69 03 Lis 2016 23:47
    Freddie Chopin
    Specjalista - Mikrokontrolery

    I wszystko to, żeby tylko nie użyć C++, w którym żadne cudowanie z makrami nie jest potrzebne... Overhead samego dziedziczenia jest zerowy, więc gdzie jest problem? <:

  • #70 04 Lis 2016 12:14
    Zaquadnik
    Poziom 27  

    To ja tylko udzielę się a'propos C (albowiem w tym języku mam największe doświadczenie). Na początek poleciłbym książkę o wzorcach projektowych dla C ("Patterns in C" by Adam Tornhill). W tej książce w przystępny sposób opisano 5 wzorców, które pozwalają na zgrabną implementację enkapsulacji oraz czegoś w rodzaju konstruktorów i destruktorów (wzorzec First Class ADT), a także elegancką implementację maszyny stanów (wzorzec STATE). Oczywiście w żadnym wypadku nie jest to próba implementacji obiektowości w C, a po prostu zestaw wzorców, które czynią kod bardziej czytelnym i łatwiej rozszerzalnym. Oczywiście nie neguję programowania obiektowego i konieczności poznawania nowych języków. Nie chcę tylko debatować nad wyższością C++ nad C lub odwrotnie. Programuję w C zawodowo i mogę powiedzieć, że dzięki tym wzorcom można pisać kod w C z dobrą enkapsulacją modułów i eleganckimi rozwiązaniami.

    Moderowany przez dondu:

    Link reklamowy zastąpiłem tytułem i autorem.

  • #71 07 Lis 2016 14:23
    Marico
    Poziom 19  

    Zaquadnik napisał:
    Na początek poleciłbym książkę o wzorcach projektowych dla C ("Patterns in C" by Adam Tornhill).


    Jak ta książka ma być wzorcem, gdy autor na pierwszych już stronach już daje przykłady używając typedef struct??

  • #72 07 Lis 2016 14:33
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Marico napisał:
    Jak ta książka ma być wzorcem, gdy autor na pierwszych już stronach już daje przykłady używając typedef struct??

    Przecież to nic złego... Tak jak nadużywanie preprocesora, operacji na wskaźnikach, rzutowanie wszystkiego co się da na "void*" i tym podobne "normalności" (;

  • #73 07 Lis 2016 14:52
    Zaquadnik
    Poziom 27  

    To co jest takiego złego w "typedef struct..." ? Trochę nie rozumiem.

  • #74 07 Lis 2016 15:02
    Freddie Chopin
    Specjalista - Mikrokontrolery
  • #75 07 Lis 2016 15:08
    grko
    Poziom 32  

    @Zaquadnik A możesz napisać jaka jest korzyść ze stosowana typedef wobec struktur? Bo dla mnie typedef dla struktur, enumów i nie daj Boże wskaźników to tylko zaśmiecanie jednej przestrzeni nazw. Tak naprawdę tylko to zaciemnia kod:

    Kod: c
    Zaloguj się, aby zobaczyć kod


    Nie wiadomo co jest tak naprawdę strukturą, enumem, wskaźnikiem na funkcje czy czymkolwiek. Pierwsza wersja przynajmniej wzbudza podejrzenia jak ktoś deklaruje całe struktury na stosie. Poza tym nie można zrobić forward declaration typedefa.

    Zresztą cytat z książki, która jest coś naprawdę warta:
    Expert C Programming by Peter Van der Linden:
    Cytat:

    "Don't bother with typedefs for structs. All they do is save you writing the word "struct", which is a clue that you probably shouldn't be hiding anyway."

  • #76 07 Lis 2016 16:11
    Zaquadnik
    Poziom 27  

    Ideą typedef struct, do którego prawdopodobnie pijecie jest możliwość definiowania typu niekompletnego. Definiujemy wskaźnik na strukturę, której zawartości nie znamy jeszcze w momencie tej deklaracji. Tu chodzi właśnie o enkapsulację i blokowanie możliwości dowolnego grzebania sobie po strukturze. To się całkiem dobrze sprawdza w przypadku np. kontekstu jakiegoś modułu, który, zamiast udostępniać jako zmienną globalną, można odwoływać się do niego poprzez dobrze zdefiniowany interfejs. Ponadto, łatwo można, przy pomocy dynamicznej alokacji, tworzyć wiele instancji takiej struktury danych.

  • #77 07 Lis 2016 16:23
    2675900
    Użytkownik usunął konto  
  • #78 07 Lis 2016 16:29
    Zaquadnik
    Poziom 27  

    Nie o to chodzi :) Po prostu w pracy zawodowej czasem język jest z góry narzucony. A C++ swoją drogą się uczę i chcę używać w swoich projektach. Chciałem tylko pokazać, że w C też istnieją fajne rozwiązania pozwalające tworzyć lepszy, bardziej czytelny kod.

    EDIT:
    A swoją drogą, czy wiecie może jak duży narzut w zużyciu pamięci daje obsługa wyjątków w C++? Chodzi oczywiście o zastosowania w systemach wbudowanych (Cortex-M, Cortex-A).

  • #79 07 Lis 2016 16:48
    grko
    Poziom 32  

    @Zaquadnik

    Cytat:
    Definiujemy wskaźnik na strukturę, której zawartości nie znamy jeszcze w momencie tej deklaracji. Tu chodzi właśnie o enkapsulację i blokowanie możliwości dowolnego grzebania sobie po strukturze. To się całkiem dobrze sprawdza w przypadku np. kontekstu jakiegoś modułu, który, zamiast udostępniać jako zmienną globalną, można odwoływać się do niego poprzez dobrze zdefiniowany interfejs.


    I konieczne jest użycie typedef? Bardzo prosiłbym o taki przykład gdzie użycie typedef daje rzeczywistą korzyść w stosunku do deklarowania typów ze słowem kluczowym struct.

    Oczywiście są typy dla których typedef jest ok. Np typedefy z stdint.h, size_t, ptrdiff_t itd.

    <ciach>

    Moderowany przez dondu:

    Zbędne wyciąłem.

  • #80 07 Lis 2016 16:48
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Zaquadnik napisał:
    EDIT:
    A swoją drogą, czy wiecie może jak duży narzut w zużyciu pamięci daje obsługa wyjątków w C++? Chodzi oczywiście o zastosowania w systemach wbudowanych (Cortex-M, Cortex-A).

    Niestety dosyć znaczny - wszystko zależy od konkretnej sytuacji, ponieważ głównym "winowajcą" są tzw. "unwind tables", które są generowane w zależności od Twojej aplikacji. Niemniej jednak mowa o rzędzie wielkości typu kilkadziesiąt kB, typowo jest to powiedzmy 20-60. Jak wiadomo rozmiar nie jest na świecie największym problemem, dlatego żeby nie było za dobrze, to z wyjątkami jest tak, że ich użycie kłóci się z ideą real-time - nie istnieją żadne narzędzia pozwalające ocenić ile potrwa propagacja wyjątku od miejsca w którym został on rzucony do odpowiedniego handlera. Z tego co czytałem, właśnie to jest największą przeszkodą w ich użyciu w embedded...

    Ciekawy artykuł o tej kwestii -> http://ep.com.pl/artykuly/9085-Wyjatki_C_a_mi...plementacji_wyjatkow_w_systemie_ISIXRTOS.html

    Dane które tam widać należy jednak traktować z mocnym przymrużeniem oka - są one nad wyraz optymistyczne (z dolnych rejestrów mojego przedziału). Problem z tymi danymi jest taki, że zostały one wygenerowane dla "trywialnego" przykładu, wiec tutaj za bardzo tych "unwind tables" to nie będzie - co to za problem zrobić propagację przez 1 poziom i to jeszcze bez żadnych destruktorów po drodze... Propagacja przez 10 poziomów z różnych modułów i z jakimiś destruktorami po drodze - to byłby lepszy przykład...

  • #81 07 Lis 2016 17:33
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Piotrus_999 napisał:
    ale tu taki mały artykulik do krytycznej oceny:

    Przeglądałem go już kiedyś. Wyjątkowo słaby, bo tym razem ten program testowy nawet nie jest "trywialny" tylko wprost "tępy" (; Takie pomiary są bez sensu. W rzeczywistej sytuacji tablice związane z wyjątkami zajmą 10x tyle co rozmiar kodu który ten artykuł zmierzył.

  • #82 05 Gru 2016 07:15
    qazpylades
    Poziom 12  

    Programowanie w C i w C++ na kontrolery może być używane równolegle. każde ma swoje zalety w pewnych zastosowaniach. Podam prosty przykład:
    Fuzzy logic pisany w C jest pomyłką. Zrobienie tego samego w C++ jest proste i kod jest czytelny.
    Dzieje się tak dzięki przciążaniu operatorów, którego nie ma w C. Za to C łatwiej się optymalizuje.
    Więc nie wieszajcie psów na jednym bądź drugim języku. Oba warto znać i łączyć wtedy kiedy to ułatwia pracę i przyspiesza pisanie kodu.

  • #83 05 Gru 2016 08:28
    Freddie Chopin
    Specjalista - Mikrokontrolery

    qazpylades napisał:
    Za to C łatwiej się optymalizuje.

    Niby w jaki sposób, skoro większość optymalizatorów w kompilatorach i tak działa na abstrakcyjnych "operacjach" niezależnych od języka? No chyba że mowa o "optymalizacji ręcznej", to wtedy jest ona zależna jedynie od tego jak dobrze ktoś dany język zna.