Jak mam obsluge bledow w funkcji, to sie zaczynaja wyjscia mnozyc. Bo bledow moze byc mnostwo - np brak portu, brak prawa dostepu do portu, brak odpowiedzi w zalozonym czasie, niezrozumiala odpowiedz, zgloszony bład przez urzadzenie na porcie, błędna wartosc.
Moim sztandarowym przykladem jest raczej przeszukanie dwuwymiarowej tablicy.
To IMO jakos tak bylo, ze jak poczatkujacy pisze w Basicu czy Fortranie, to wkrotce pisze kod pelny "dzikich" goto.
Wirth to chyba zauwazyl, wymyslil jezyk strukturalny, ale czasem naprawde przykro patrzec, jakie cuda wyprawiali programisci w Pascalu, aby nie użyć zadnego goto. Ktore w jezyku było, ale przeciez nie wypada ...
Prawidłowe założenie brzmi: masz N wyjśc z funkcji. Zakładanie że "N jest małe i sobie jakoś poradzimy" jest absurdalnie niebezpiecznie.
Wylatujesz za drzwi nie tylko z kopniakiem, ale jeszcze z wilczym biletem na pracę w IT.
Wlasnie napisałeś kiepski, ale emulator RAII. I po co było bredzić o goto?
To nie jest innowacja, tylko codzienność pracy programisty C++.
Widzę.
Podany przykład jest uproszczony na potrzeby usenetu. Jeśli nie widzisz abstrakcyjnie zastosowania RAII, ale widzisz przykład włączenia przerwań jako jedyne zastosowanie, to nic nie poradzę.
Ja się nie obrażam, mnie w ogóle ciezko obrazić.
Poważniejszy przykład mogę podrzucić jeśli chcesz, ale czy aby na pewno pojmiesz o co chodzi? Sprawdźmy jakiś trywialny:
char value = cast_with_range_check< char >( intValue );
W kodzie produkcyjnym nic się nie zmienia, w kodzie dla unit testów masz tam w środku zaawansowane sprawdzanie czy wartość mieści się w zakresie typu.
Wyżej napisałes emulację RAII. I napisałeś ja w zasadzie tylko po to aby nie użyć C++, ale użyć RAII. Troche żałosne.
Mam kolegę, głeboko wierzącego w wyższosć C nas wszystkim, w którego kodzie napotkałem prawie kompletną emulację obiektowości, wliczając tablice wirtualne, na C i z kupą bugów. Zapytany o to po ch... to pisać od zera, skoro to samo ma w C++, obraził się.
Napisałeś kiepski emualtor RAII tylko po to aby nie używać RAII. Widzę podobieństwa między tymi sytuacjami.
Kod sprawdzający statycznie flagi przekazywane do rejestrów sprzetowych? Ma bardzo dużo.
Kodu Ci nie pokaże, bo został sprzedany i nie jest moją własnościa. Musiałbym napisac go ponownie ale mi się najzwyczajneij nie chce, ponieważ nigdy go nie użyjesz. A udowanianie oczywistości nie jest tego warte.
Ja tu bronie jakiejś idei? Robisz gówniany kod na goto, który świadczy o zerowej wiedzy z zakresu bezpieczeństwa kodu i to w imię "Łojezu, nie wolno używać C++, bo przyjdzie babajaga i zje!" i to ja czegoś zaciekle bronię? Żartujesz?
To co, piszesz to zabezpieczneie przed podaniem złej flagi do uartu, w C?
Elektronika na PWr 1982: programowanie to byl Fortran 66, czesc grup Pascal. W tym czasie PWr kupila sporo ZX81, tam faktycznie byl Basic. Mikroprocesory to byl 8080 (bylo tez o Z80), programowanie w asemblerze. Na RIAD-ach byl tez PL/I i Algol. Byl tez Prolog, ale chyba tylko dla malej grupki wybrancow. 2-3 lata pozniej na komputerki domowe byl Pascal, C, Forth, Logo (Basic tez...). Sporo bylo pisane w asemblerze.
Inna sprawa ze w 1982 dostep do komputerow byl ograniczony i sporo studentow tego nie lapalo. Ale jak ktos zalapal i glebiej wchodzil w programowanie to dosc szybko zostawial Basic i Fortran za soba.
Przypomnę, że pisałeś wcześniej że "w C nie da się tego zrobić". Teraz ci po prostu łyso. :-)
goto ma swoje niszowe zastosowania. To, co dziś nazywa się "RAII" istniało przed C++ i wykorzystywało właśnie goto. Zresztą nie tylko ja o tym bredzę:
formatting link
"The goto statement comes in handy when a function exits from multiple locations and some common work such as cleanup has to be done. If there is no cleanup needed then just return directly."
Ciekawa konstrukcja. Nie mam pewności, czy to w praktyce mogłoby być mi użyteczne, bo jeśli castuję większe do mniejszego to obwarowuję operację stosownymi asercjami. Czy w takiej sytuacji ten cast_with_range_check<> ma jakieś zalety? Pytam szczerze i bez przekąsu.
Tak, bronisz. Podałeś tezę pt. "C++ najlepszy do programowania w embedded" i uargumentowałeś ją kiepskim przykładem. Zapytałem o lepszy. I zaczęło się.
Ja zupełnie tego nie potrzebuję. To ty podałeś te flagi jako kolejny przykład wyższości C++ "w embedded"... Ale okazało się niestety, że to przykład tylko wirtualny.
Nie, dalej twierdze że nie da się zrobic RAII w C. Można emulatowac pojedyncze przypadki, jak Twój przykłąd. Przeciez oba są Turing-complete, więc można napisać żałosny kod o identycznej logice jak inny kod.
Ma. Ale prawde mówiąc są tak niszowe, że nie użyłem go od chyab 20 lat. Mimo zawodowej pracy w C++.
Nie. To nie ma jedno z drugim nic wspólnego. RAII to nie jest inne goto. To w ogóle nie jest nawet obok.
Jak chcesz już analogii, to Twoje "goto" jest bliżej exceptionów z C++, one też przerywają flow kodu.
RAII jest najbliżej konstrukcji try {} finally {}.
Podałeś przykład kodu, w którym religijnośc jest ważna, wazniejsza niż zdrowy rozsądek. Nic dziwnego, że nie ma wyjścia i trzeba korzystać z mechanizmów, które są śmieszne, żałosne i niebezpieczne, bo C++ nie wolno bo nie wolno.
Ja oczywiście znam rozsądne argumenty za C w kernelu, ale znam też głośno powtarzane, nierozsądne.
No widzisz, a reszta świata ma finally. Czyli reszta świata się myli.
Kolesie od kernela nie mają wyjścia: pracują w toksycznym środowisku w którym jednym pytaniem o coś lepszego niż C zbywa się "you're full of shit" i podobnyumi argumentami merytorycznymi. Wiem, słyszałem wielokrotnie. Kernel linuxa to nie jest specjalnie dobry argument w jakiejkolwiek dyspucie o jakosci i bezpieczeństwie kodu, chyba że potrzebujesz wyznaczyć poziom zerowy.
Potraktuj to jaki uniwersalną, generyczną asercję.
Tak. Jeśli popełniasz błąd, to raz a nie 500 razy w każdym możliwym miejscu.
Wyobraź sobie że musisz rozpatrzeć: a) signed/unsigned b) mały/duży c) float/int d) double/single e) ttmath/magic_int256_t
I wszystkie ich kombinacje. To jest kilkaset asercji i czasami cieżkich obliczeń, z gwarnacja buga.
Twoja metoda to technika rozpryskowa, czyli wpierniczmy te asercje wszędzie po kodzie, a każda inna.
Moja technika to generalizacja i abstrakcja problemu to template, którego nie da się użyć źle. W dodatku o jakości zapewnianej unit testami. C++ daje mi do tego calu trywialne i wygodne narzędzie.
Oczywiscie, za chwile wyskoczy jakiś hacker z hasłem "ale ja to mogę zrobic na #define, potrzymaj mi kota".
Tak, wszystko jest turing-complete, brainfuck, whitespace, intersil też. Da się zrobic na #define. I w brainfucku. I ja też kiedyś robiłem na #define. Ale już nie robie. To dziecinada.
Nie. Podalem tezę "można zerowym kosztem pisać kod lepszy niż w C" bo niczym się od gołego C nie różni.
Do programowania embedded jest najlepszy język, który najlepiej pasuje do zagadnienai które chcesz rozwiązać.
W przypadku C vs C++ argumentacja że "C++" jest gorszy od C, wymagała odpowiedzi. I tak doszliśmy do twojego goto, jako panaceum na problemy
3-go świata programistów z epoki kamienia łupanego.
Wiec zauważ o czym dysputa była. Dysputa jest o tym, że C nie jest lepszy od C++, bo C++ to C + *przydatne* rzeczy. Więc niejako na bazie czystej logiki nawet...
No własnie. Innymi słowy jesteś wyznawcą podejścia hackerskiego do programowania.
"Ja się nie mylę, po co mi to całe bezpieczeństwo".
Ja wręcz odwrotnie: "bezpieczeństwo i testowanie a potem kodowanie".
I różnica jest taka, że ja wiem jak to przenieśc do embedded.
Ja bym go nazwał konkretnym, ale ja pracuje zawodowo w takim języku, więc co ja tam mogę wiedzieć.
W tym wypadku też mnogość wyjść może być problemem, bo szybko wychodzą tego typu rzeczy:
if (!alokuj_bufor()) return(fail);
if (!otworz_port()) { zwolnij_bufor(); return(fail); }
if (!napisz_na_port()) { zwolnij_bufor(); zamknij_port(); return(fail); }
if (!odbierz_z_portu()) { zwolnij_bufor(); zamknij_port(); return(fail); }
i prędzej czy później o czymś zapomnisz. Tzn. może nie ty, ale ja na pewno. Zamiast tego można w ten sposób:
void *buf = NULL; int port = 0;
buf = alokuj_bufor(); if (!buf) goto poleglem;
if (!napisz_na_port() goto poleglem;
if (!odbierz_z_portu() goto poleglem;
return(sukces);
poleglem:
if (buf) zwolnij_bufor(); if (port) zamknij_port(); return(fail);
albo, jeśli kto naprawdę uczulony na goto, to całość ubrać w jakąś niby-pętlę która wykonuje się raz, a wychodzić z niej breakiem... Ale to już kombinowanie na siłę, aby tylko nie zhańbić się goto przed pryszczatą młodzieżą.
No właśnie, C++. Bo w C++ masz milion konstrukcji które zostały wymyślone aby nie użyć goto/define. Co kto woli, ale to dalej nie jest postęp (w tym szczególnym kontekście).
Czyli ludzkość przez dekady pisała (i pisze dalej) brzydki, śmierdzący i niebezpieczny kod, Linus i jego koledzy to idioci i tylko jeden heby z internetu osiągnął zrozumienie świata i dzielnie niesie światło pogańskim narodom. Może tak faktycznie jest.
Zauważ, że to zupełnie tak, jak duża część twoich odpowiedzi w tym wątku.
No tak, ale ty też możesz przecież się pomylić: zapomnieć wstawić range_check<>, albo wstawić mu nieodpowiedni typ... To znów przesuwanie problemu.
Od tego jest #define, żeby takie rzeczy elegancko sobie opakować. Znane od 1978 (a może i trochę wcześniej).
Niekoniecznie inna. Jeśli sprawdzam tylko range typu, to może być taka sama, wówczas opakowana w jakimś #define. Ale często sprawdzam granice różne od typu, np. zwracany int ma być -1 >= x < CHAR_MAX.
Ja rozumiem zamysł, i szanuję ideę. Miałem tylko nadzieję dowiedzieć się z tego wątku o jakichś rewolucyjnych wynalazkach które C++ posiada, ale to co przedstawiasz to raczej luźne wariacje w tematach znanych od prehistorii. I nie żeby to było coś złego, fajnie że się młodzież dobrze bawi, to z pewnością rozwijające jest.
Jeśli miałbym mieć jakiś jeden zarzut do C++, to chyba właśnie tylko to, że namnożył miliony bytów, przez co człowiekowi ciężko wszystko ogarnąć i o wszystkim pamiętać. Ja sam ograniczam się w mojej pracy do C89 (no, w praktyce do gnu89), dlatego właśnie, że lubię grać w gry o prostych zasadach. NASM też bardzo doceniam swoją drogą.
Była taka argumentacja? Jeśli tak, to przeoczyłem. W każdym razie nie wyszło to ode mnie. Ja czepiam się tylko konkretnych przykładów.
Ot, to. Ale z tą logiką to nie tak. Bo jeden lubi grać w Go, a inny woli współczesne gry planszowe z kilometrowymi regułami. Pewno powiesz, że ten pierwszy jest niepełnosprytny, że nie potrafi ogarnąć kilku tysięcy zasad i egzotycznych ruchów. I może masz rację, on po prostu gra w to, w czym idzie mu najlepiej.
w przypadku sukcesu tez mozemy chciec zwolnic zasoby, wiec raczej
int err_code=0;
if (!buf) {err_code=BUF_ALL; goto poleglem;} if (!napisz_na_port() {err_code=PORT_Write; goto poleglem;} if (!odbierz_z_portu() {err_code=PORT_READ; goto poleglem;}
err_code=SUCCESS
poleglem: if (buf) zwolnij_bufor(); if (port) zamknij_port(); return(err_code);
Jak krokow wiecej to moze byc nieglupie - przygotowac taki mini program do wykonania.
Mozna tez int err_code=0;
if (!buf) err_code=BUF_ALL; if (!err_code && !napisz_na_port()) err_code=PORT_Write; if (!err_code && !odbierz_z_portu()) err_code=PORT_READ;
err_code=SUCCESS
if (buf) zwolnij_bufor(); if (port) zamknij_port(); return(err_code);
no i niby poprawniej, tylko program niepotrzebnie sprawdza pare razy blad ... a co tam, szybkie procki mamy
ewentualnie
int err_code=0; if (!buf) err_code=BUF_ALL; else if (!napisz_na_port()) err_code=PORT_Write; else if (!odbierz_z_portu()) err_code=PORT_READ;
err_code=SUCCESS
if (buf) zwolnij_bufor(); if (port) zamknij_port(); return(err_code);
Detale zależą już od założeń konkretnego przypadku - API może przewidywać, że po nawiązaniu komunikacji port pozostaje otwarty na potrzeby dalszych operacji. Jeśli nie, to oczywiście masz słuszność.
Można. Tylko po co? Aby zmniejszyć czytelność kodu i dodać niepotrzebnych kroków, coby za wszelką cenę uniknąć goto?
No właśnie, czytelność na tyle słaba, że zapomniałeś o końcowym "else" i awaria gotowa. A w efekcie kompilator i tak przetłumaczy to wszystko na kilka goto...
Nie ma ani jednej konstrukcj w C++ która była robiona z myślą o usunięciu goto. Goto usuneliśmy wieki temu, jako idityczny koncept, w praktycznie każdego języka. Zastapiliśmy je break, exception, None i wieloma innymi konstrukcjami w wielu róznych językach. Być może przespałeś. Bywa.
To nigdy nie jest postęp w opini kogoś, kto go nie dostrzega. Pamietaj, że Twoja opinia o postępie jest subiektywna i mało kompatybilna z teoriami języków programowania. Ogólnie wszystkie języki wyższego poziomu starają się uzyskać kod bezpeiczniejszy na etapie pisania i kompilacji a nie na teapie runtime. Ty zatrzymałeś się w latach 70 ze swoimi rozwiązaniami problemów, które nijak nie przystaja do tego co osigneliśmy do dzisiaj. I spoko, ale nie chwal się tym. To żenujące.
Tak.
Nie. Ale są pod wpływem zaklęcia z okolic "C jest nalpeszy". Ja nawet znam czarnoksięznika, który je rzucił. Trzymał ich twardę ręką i kilku odeszło m.in. z podobnych powodów.
Nie. Jakieś kilka milionów ludzi nie piszących w C oprogramowania w którym chodzi o bezpieczeństwo.
Pozwól że Ci wyjaśnie: kernel Linuxa napisano w C *tylko* dlatego, że napisano go dawno i nic innego nie było. Reszta tej historii nazywa się inercją. Stawianie jej jako obrony dla wyboru C w nowych projektach świadczy o niepojmowaniu podstaw programowania. Język C był *dawno* temu sensownym wyborem. Obecnie nie jest. W zasadzie do niczego nie nadaje się lepiej niż cokolwiek innego.
Moje odpowiedzi w tym wątku są specjalnie przerysowane, aby spuścić z Ciebie powietrze z farfoclami goto.
Jesteś jak ci miszczofie z Watykanu, którzy twierdzą że jesli prezerwatywa nie chroni w 1 promilu przypadków to nie nalezy jej używać.
Zaskocze Cię: zdecydowana większość współczesnego embedded jest tak skomplikowana, że od jakiś 20 lat, a obecnie bardzo intensywanie, stosujemy metody *statystyczne* oceny jakości kodu. Na przykład przez randomizacje unit testów. To może być szokujące dla Ciebie: w duzym software może okazać się że nie da się usunąc wszystkich bugów, ale można zrobić coś aby na wyjsciu było ich mniej. ta twoja pogradzana statystyka gra obecnie pierewsze skrzypce w dużym embedded.
Oczywiście miganie diodą na goto ujdzie, ale software mające kilka gigabajtów kodu źrodłowego (tak, dalej mowa o embedded) nie ma wyjścia, musi być pisane używajac wszystkiego co mamy w kwestii bezpieczeństwa i znając ograniczenia białkowe.
I teraz wyjasnij mi po co stosować dziadowskie pisanie z goto, skoro lepsze, bezpieczniejsze techniki są stosowane w dużym sofcie i masz je za darmo?
Zwróć uwagę, że nie padł z twojej strony ani jeden argument po co *nie* stosować.
Ja ciągle pytam czemy nie stosujesz odkurzacza, tylko szczoteczką do zębów zamiatasz salon. Oba narzędzie są w schowku.
Od tego są szablony, aby sobie takie rzeczy opakować. Mają o wiele więcej możliwości, są bezpieczne pod względem typów i czytelniejsze niż milion #define. Po ch... komu uzywać #define? Bryczką też jeździsz, bo starsza od samochodu, a więc na pewno lepsza? Co to za idiotyczny argument?
A czemu nie szablonem? Powody religijne czy reglamentacja narzędzi?
A ja mówie o przypisaniu, nie o wartosci zwracanej. Wartość zwracana ogarniana jest m.in. w unit testach, asercjami, itp.
Dowiedziałeś się. To że jesteś za słaby z programowania aby zrozumieć stojącą za tym abstrakcję nie jest moją winą. Jesteś typowym assemblerowcem który nie jest w stanie ruszyć sie ze swojej strefy komfortu, bo zakładasz że jesteś najmądrzejszy i każdy problem możesz rozwiązać lepiej niż reszta świata uzywająca innych, "skomplikowanych" technik. W rzeczywistości strach cie oblatuje za każdym razem kiedyu widzisz kod, którego nie rozumiesz i pojawia się, typowa dla legacy programmers, reakcja alergiczna i emulowanie. Widzę to bardzo często u starszych programistów. Co gorsza sam się do nich powoli zaliczam.
Pomysliłeś fanaberie z czymś co jest dostepne powszechnie od 30 lat na rynku i na czym pracuje niezliczona ilość programistów. Prawdopodobnie przegapiłeś te lata debugując swój gówniany kod z goto. Co zrobić, nie każdemy dane będzie oświecenie.
Namnożył wiele użytecznych narzędzi.
To dlatego, że w przeciwieństwie do wszelakich kiepskich programistów, zebrali się ludzie widzący *abstrakcje* w kodzie i wytworzyli generyczną obsługę tych abstrakcji. Jeśli używasz goto na codzień, to tego nie pojmiesz, jesteś programistą w asemblerze.
I nie milion. Na razie te dwie, czyli RAII i szablony, załataiają większośc problemów niedzielnego programisty embeede i zaawansowanego programisty embedded, w tejsamej cenie. Poza Mateuszami, oczywiście. Ktoś musi być kustoszem w tym skansenie.
Tobie jest cieżko. Pracuje w C++ od 20 lat. Ani mi, ani kolegom pracującym ze mną nie jest cieżko. Ciezko to by było, gdyby nas ktoś zmuszał do używania, z powodów religijnych, goto, zamiast wyrażania poprawnie swoich celów używając wysokich abstrakcji z C++.
Tak, prostactwo przede wszystkim.
Wyjasnie Ci, na czym polega róznica między prostotoą a prostactwem:
Prostota: używam RAII, bo mam, przez co kod jest którki i wiadomo co chciałem uzyskać.
Prostactwo: używam goto bo nie potrafię inaczej i nie rozumiem abstrakcji.
Czepiasz się ich prezentując workaroundy. Nie wiem jaki masz w tym cel, ale mam wrażenie, że ośmieszanie się.
Tak, ja też jestem w stanie napisać dowolny kod na goto. Bo pisałem w swoim zyciu bardzo dużo w asemblerze. Ale mimo to potrafie określić dlaczego jest to zło i to to jest turing-completeness. Dla mnie to że da się coś napisać inaczej i niebezpiecznie nie jest argumentem, tylko zaoraniem.
To nie jest kwestia "wolę". Masz używać narzędzie optymalnego do problemu.
Narzędziem optymalnym do problemu "transakcja w scope" jest RAII a nie goto.
Jeśli używasz goto to robisz to źle, ponieważ nie masz argumentu przeciwko.
jeśli używasz #define zamiast szabolu, to robisz to źle, bo nie masz argumentu przeciwko.
Jedyny argument jaki pada Twojej strony jak d otej pory to "że to Trudne". Myślełeś nad karierą rolnika? Tam jest łatwiej.
Słusznie. Też uważam, że jesli ktoś potrafi sprawnie kopać rowy łopatą to głupotą będzie wzywać koparkę, mierzeje przekopać można używają goto, bo tak robili za pradziada.
void *buf = NULL; int port = 0; buf = alokuj_bufor(); if (!buf) goto poleglem_buf; if (!napisz_na_port() goto poleglem_write; if (!odbierz_z_portu() goto poleglem_read; return(sukces);
Nie, jesteś po prostu cham i krzykacz, a zamiast merytorycznych argumentów wolisz naubliżać zza anonimowego nicka. Nie dziwię się, bo to częste w tej branży.
Wyciąłem z twojej wypowiedzi wszelkie chamstwo, odniosę się więc do tego, co zostało (niewiele).
Nie, nie pogardzam. Sam stosuję.
Bo ja niczego nie bronię. Ja tylko pytam o rozwinięcie twojej tezy "C++ jest najlepsze w embedded" na konkretnych przykładach.
C++ to jednak nieco szerszy temat niż tylko RAII i szablony. Jak rozumiem, sugerujesz używanie C++ "tak, jak by to było C, z dodatkiem dwóch-trzech nowości bo przecież to darmo jest". Ja uważam takie podejście ze nieodpowiedzialne, bo jeśli używam narzędzia do poważnych zastosowań, to muszę panować nad nim w 100% aby nie dać się zaskoczyć jakimś nieznanym zachowaniem. To trochę tak, jakbyś doradzał pilotowi lecieć samolotem z milionem gałek, bez znajomości większości z nich ("bo te trzy tutaj po lewej załatwią większość sytuacji, a tych innych po prostu nie dotykaj"). A potem okazuje się, że drugi pilot zna inny zestaw gałek i tak sobie dłubią każdy w inny sposób i wpadają we własne pułapki.
Maszynowo niewątpliwie czyściej, ale dostrzegam potencjalny problem w czynniku ludzkim - bo teraz programista musi wiedzieć, do którego labela wykonać jmp.
Metoda "sprawdzam wszystko w jednym miejscu" ma tę zaletę, że jest bardzo łatwo w użyciu i trudno o pomyłkę. Fakt, zmarnujemy na tym kilka instrukcji JZ/JE, ale jeśli zależałoby nam na tak daleko posuniętej oszczędności, to po prostu użylibyśmy NASM... Swoją drogą, ciekawe jak RAII w C++ to tłumaczy. Domniemywam, że właśnie tak - bo przecież musi pamiętać/sprawdzać co zostało zainicjalizowane, a co nie. Sprawdzi ktoś?
Muszę tu uściślić, że przy bardzo małej ilości możliwości, kiedy trudno by programista się pomylił, to podejście z paroma labelami *może* być fajne. Kwestia wyczucia punktu równowagi.
Tutaj jest ładny przykład w ten deseń:
formatting link
Swoją drogą - w kodzie git-a naliczyłem 759 wystąpień goto. Ale to przecież poziom migania diodą, więc nic dziwnego. :-)
Narzędzie jak każde inne. Dobre do tego do czego zostało stworzone. Nigdy nie korzystałem, ale ostatnio zaszła taka potrzeba. Trza było umieścić wsad grbl do atmegi, poszło prawie gładko. Z punktu widzenia osób które nie chcą się doktoryzować z :
- języka c, konfiguracji IDE
- obsługi programatora
- softu do projektowania pcb
- trawienia, wiercenia, zakupów każdej drobnej części osobno w celu zaświecenia diodą
... ten soft jest idealny:) Zaoszczędza dobrych kilka dni pracy.
Tak poza tym najtańsze pice są tańsze od najtańszych avr.
Mój nick nie zmienił się od 20 kilku lat. Trudno o coś mniej anonimowego, wystraczy śladowa ilośc woli.
Nie spotykam się na codzień z ludzmi uważającymi że goto to coś lepszego od RAII, więc wypacz napływ emocji. Czuję się tak samo podekscytowany, jak ktoś kto wykopuje dinozaura.
Wymyslasz jak obejśc rozwiązania gotowe, robiąc takie same, tylko znacznie gorsze. Nie uzasadniasz dlaczego (albo inaczej: uzasadnienie jest poniżające). Bronisz więc tak naprawdę faktu, że każdy program da się napisać w innym języku. Gubiąc po drodze wszytkie zalety jakie istnieją z generalizacji, skupiajac się na bezsensownych przykładach i uważając e statystyka bezpieczeństwa kodu nie ma znaczenia.
Nie jest najlepze w embedded, nigdzie taka teza nia padła.
Ale.
Padła teaz: jesli już musisz uzywać C w embedded to nie ma ani jednego powodu dla którego to nie powinien być C++ lub jego fragment.
Nie ma obowiązku używania czegokolwiek, co nie jest optymalne do problemu jaki rozwiązujesz.
Nie ma też obowiazku używania czegokolwiek optymalnego do problemu, ale to już jest odpierniczanie byle jak.
W miejscach gdzie rowiązuje problemy lepiej niż żałosne goto. I w tysiącu innych miejsc, gdzie pomaga utrzymać bezpieczeństwo.
Gdybyśmy rozmawiali o technologi wymysolnej wczoraj, to bym się zgodził. Rozmawiamy o technologi będącej na rynku do 30 lat, które najzwyczajniej przespałeś i teraz dorabiasz głupie filozofie "jest niepewna" itd. Chowasz swoją ignorancję za głupimi argumentami.
Uzywamy tego, co jest wygodniejsze, bezpieczniejsze, prostsze.
RAII spełnia te założenia, goto nie.
W połowie lat 90 mogło nie spełniać. Od tamtego czasu było dość wolnych wieczorów, aby poczytać jakąś ksiązkę o C++.
Nie ma nieznanych zachowań w RAII na poziomie o którym dyskutujemy. Wymyślasz problemy które nie istnieją. To czysta, pusta ideologia "nie, bo nie".
Jesli nie wiesz do czego te gałki to faktycznie lepiej lecieć w balonie.
Chyba nie zakładasz, że komuś kto nie ma pojęcia o C++ polecam jego używanie? Polecam *zapoznanie* się.
Na szczęscie Arduino, nie patrząc na kiepskie opinie wszelakich Mateuszy, wproawadziło ten C++ prosto w środek hobbystycznego dziargania embedded, dzieki czemu poglądy o goto i #define mają szansę szybko wymrzeć.
Typowe brednie z ignorancją w tle.
Od 30 lat dłubiemy kod w C++, produkcyjnie, na szeroką skalę.
A tu się uchowali jezcze ludzie, którzy nie potrafią wyjśc z asemblera i nawet majac nowoczesne języki programowania, muszą używać goto, no bo jak inaczej.
Powiedz że żartujesz i to wszystko to tylko głupi trolling, bo nie wierzę własnym oczom, że to nie jest połowa lat 90.
Reasumując, spotkał się cham z ignorantem. No to skoro ustaliliśmy na czym stoimy, to może uda się dojść do jakichś budujących wniosków.
Podałem sposób, w jaki można rozwiązać problem który ilustrowałeś przykładem. Nie twierdzę, że to lepsze niż nowoczesne RAII. Twierdzę natomiast, że RAII nie jest tak naprawdę żadną rewolucją i przykład który podałeś słabo odzwierciedla jego ewentualną wartość dodaną. A tak promowałeś C++, że naprawdę spodziewałem się jakiegoś life-changera.
Nie nie, ja niczego nie wymyślam. Ja to po prostu stosuję, bo to codzienność w pracy programisty C. Ja rozumiem, że cię to brzydzi. Mnie brzydzą lambdy, funkcje wirtualne i templaty.
Przecież ja od początku pisałem, że te przykłady są bez sensu i prosiłem o jakąś dobitniejszą demonstrację.
Nie pisałem nic o "niepewnej technologii". Pisałem, że C++ to nie tylko C z RAII, tylko dużo większy kombajn i zanim programista zacznie cokolwiek w nim dłubać to musi go całego ogarnąć. Włącznie z tymi milionami rzeczy, których sam nie będzie używał - bo nie wiadomo czy kolega obok ich nie użyje i trzeba będzie z tym kodem potem walczyć.
Nawołujesz do używania "fragmentów". Dodatkowo argumentując, że "to jest za darmo", a to bardzo myląca promocja. Zapoznać się oczywiście warto - ze wszystkim. I żeby nie było: ja nie jestem żadnym przeciwnikiem C++. Kilka lat temu przeczytałem książkę o nim, i wstukałem nawet kilka hello-worldów. Po prostu nie przekonało mnie to, by zgłębiać temat dalej.
Na zakończenie zapytam zupełnie z innej beczki, bo chodzi to za mną cały dzień: dlaczego używasz/zachwalasz git-a, skoro jego kod to (cytując twoje słowa) "szambo"?
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.