On 2012-05-05 19:47, Jerry1111 wrote:
> Ale u mnie co projekt to pisanie _wszystkiego_ od nowa. Wisi mi czy mam
> debugowac konstruktor, makro czy funkcje.

Tym fajniej busi być debugować te same błedy za każdym razem.

> U mnie typowy. Od 10 lat nie napisalem ani jednego kodu embedded w
> sposob *typowy* dla wiekszych maszyn. Tego sie nie da oderwac od warstwy
> sprzetu jesli sie chce zarobic.

Nie piszę tu o nietypowości że piszesz na uC. Mowię o tym że piszesz
nietypowo jak na uC skoro emulujesz priorytety przerwać na cli/sei
porozrzucancyh po kodzie. Na ten (mizerny) przykład u mnie są same
przypadki CriticalSection a kod jest RT jak najbardziej. Byc może mamy
rózne style pisania kodu. I nie, nie piszę firmware do migania diodą,
problemy są realne i raczej żyłują procesor na pełne osiągi.

> Taaa... a kto zaplaci za pierwsze 2 miesiace zonkow podczas takiej
> transformacji?

Jakiej transformacji? ScopedWhatever masz za 30 sekund w kodzie. Już.
Działa. 0 zonków.

> Po kilku latach pracownik sie nauczy i co? Odejdzie i bedzie problem -
> szukaj drugiego takiego...

Pięknie ujmujesz poziom kwalifikacji przeciętnego klepacza firmware :)

> Nie jest za darmo, jesli wstawi gdzies ciag znakow "virtual" (bo nie wie
> ze nie wolno) i 3 dni bedzie szukal czemu "Hello world" nie miesci sie
> do flasha.

Gorzej, jeśli wstawi gdzieś printf to może i 3 flaszy zabraknąć. I co,
porzucamy C i piszemy w asm? Fakt, dla wielu żadna różnica.

>> Bierz BASCOma.
> Zrozumiales co napisalem?
> Moze jeszcze masz plugin Matlab->Bascom?

Ani razu w tej dyskusji nie padło słowo "matlab" o ile dobrze widzę.
Więc argumentujesz używając ukrytej wiedzy. To nie fair.

> Prosze bardzo - czy ja nie mowie ze nie? Niektorym zalezy na zrobieniu,
> wsadzeniu do produkcji i braniu sie za inny _produkt_.

Słusznie. Dzieki takiem podejściu zawsze zaczynasz od int main() { } i
odkrywasz kwadratowe koła za każdym razem. Ekonomia, ja rozumiem. Ja tak
nie potrafie. Może z tego wynika brak porozumienia.

>> Kompilator/składnia identyczna.
> O!

Oczywiście, jesli nie narobiłeś straszliwej kupy w C to skompiluje się
jako C++.

>> Większośc kodu
>> przekompiluje się na tyle gładko, że jak nawet lemmingowi podstawić g++
>> zamiast gcc to nie zauważy.
> Znaczy nie identyczna.

Nie, z dokładnością do kupy w kodzie. Zazwyczaj wychodzi na zdrowie jej
poprawienie.

> Opor ma zrodlo w koncie bankowym. Inaczej wszyscy by robili jak piszesz,
> bo by wiecej zarabiali.

Masz jednokierunkowe podejście do ekonomi. Faktycznie, jesli robisz małe
projekty to moje rady nie mają żadnego zastosowania. Jeśli jednak robisz
większe to nagle potrzeba refaktoringu, ponownego użycia, abstrakcji
staje sie bezpośrednio przekładalna na pieniądze. Zawodowo co prawda mam
do czynienia ze znacznie więszymi apliakcjami od strony kodu, ale zasady
są podobne - tracisz czas (i pieniądze) używając prymitywnych narzędzi,
choć pozornie wydaje się że tworzą produkt szybciej. Bez realiów cięzko
dyskutować czy Tobie taki model biznesu pasuje. Jak widze nie. To jednak
oznacza coś bardzo niefajnego: nie masz realnego przykładu na którym
możesz wykazać mizernośc C++. Bo masz tylko argument ekonomiczny i to
popraty raczej mizerną argumentacją. A taki argument jest zawsze
subiektywny, więc nie ma sensu ciągnąć dyskusji.

Mi potrzeba abstrakcji, destrutorów, traits wyszła na AVR. Dzieki temu
ostatnio firmware (specyficzny, RT) napisałem w 0.5 dnia wykorzystując
90% kodu optymalnie (tzn w C nie dało by się lepiej, musiałbym dlubac w
ASM) i 10% dopisując. Mógłbym to samo mieć w C z pomocą kilku
pokracznych makr, ale szacuje że bym się nie wydłubał przez tydzień z
ifdefów. I szacunek popieram próbą którą zarzuciłem po 3 dniach.

Byc może mi pomaga doświadczenie z duzych systemów, bo zawodowo pisuję w
C++ spore rzeczy. Myslę że to zawsze jednak ok poznać inny punkt
widzenia, nawet w ostrej dyskusji (którą to raz na jakiś czas próbuje
wzniecić). Ktoś mi tu zarzucił mesjanizm, może i racja.