🚀 go-pugleaf

W dniu 2020-01-29 o 18:24, heby pisze:
> On 29/01/2020 13:58, M.M. wrote:
>> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
>> C++
> 
> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> rozsądną.

Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++ 
na eksperymentalną platformę. Więc jeśli nie masz gotowych narzędzi 
kompilującej kod na daną platformę, to przystosowanie nawet już 
istniejącego kompilatora jest po prostu prostsze, więc zajmuje mniej 
czasu, a czasem może mieć to znaczenie.


-- 
http://kaczus.ppa.pl

On 30/01/2020 08:40, Tomasz Kaczanowski wrote:
>> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
>> rozsądną.
> Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++ 
> na eksperymentalną platformę.

Przypomnij mi który obecnie używany i popularny kompilator C/C++ 
generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?

> Więc jeśli nie masz gotowych narzędzi 
> kompilującej kod na daną platformę, to przystosowanie nawet już 
> istniejącego kompilatora jest po prostu prostsze, więc zajmuje mniej 
> czasu, a czasem może mieć to znaczenie.

Szczególnie jak odkrywasz że współczesne kompilatory to jakieś 
frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...

W dniu 2020-01-30 o 22:47, heby pisze:
> On 30/01/2020 08:40, Tomasz Kaczanowski wrote:
>>> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
>>> rozsądną.
>> Dzięki swojej prostocie, łatwiej jest przygotować kompilator C niż C++ 
>> na eksperymentalną platformę.
> 
> Przypomnij mi który obecnie używany i popularny kompilator C/C++ 
> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?

a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową 
do specyfiki nowego systemu?
> 
>> Więc jeśli nie masz gotowych narzędzi kompilującej kod na daną 
>> platformę, to przystosowanie nawet już istniejącego kompilatora jest 
>> po prostu prostsze, więc zajmuje mniej czasu, a czasem może mieć to 
>> znaczenie.
> 
> Szczególnie jak odkrywasz że współczesne kompilatory to jakieś 
> frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...

tak... rozmawiamy o c i c++, czy językach korzystających z maszyn 
wirtualnych?

-- 
http://kaczus.ppa.pl

On Thursday, January 30, 2020 at 10:45:28 PM UTC+1, heby wrote:
> On 30/01/2020 04:40, M.M. wrote:
> >> Ten przykład nie tłumaczy problemów w C++ tylko w białku.
> > W jakim białku?
> 
> Problemy z C++ to głównie problemy białkowe:
> a) muszę używać new bo inaczej się nie da
> b) szwagra kumpla zięcia ciotka to miała taki przypadek że zainkudowała 
> coś i exec zrobił się bilin razy większy
> c) void* jest czytelniejsze niż Foo*
> d) po C++ krowy mleka nie dają
> e) ten sam asembler, ale jest wolniejszy bo szwagier sprawdzał
> f) "mam swoje powody"
> 
> >> W sensie że jest bardziej restrykcyjny? Słyszałme kiedyś że to wada. Do
> >> dzisiaj nie wiem dlaczego.
> > Podałem przykład, ale Ty na to coś o jakimś białku.
> 
> Bo wszystkie problemy jakie padły w tym wątku sa białkowe.
> 
> >> Napisałem Ci że nic nie musisz szkolić poza "chłopaki, od dzisiaj w
> >> każdym przerwaniu na arma na początku ma stać scoped_interrupt_disable
> >> sid(); i h...". A jak któryś podskoczy to w łeb. Koniec szkolenia. Po
> >> roku nie dadzą sobie tego siła odebrać.
> > To faktycznie nie rozmawiamy o C++, tylko o czymś w rodzaju co napisałeś
> > "wystarczy jeden ficzer z C++". Co dobrego z takiej rozmowy wyniknie?
> 
> Być może komuś uratuje dupę jak zampomni postawić sei() przy returnie "w 
> przerwaniu ARMa".
> 
> Jeden mały ficzer ratujący dupę wydaje się być całkiem sensowny jak za 0zł.
> 
> Ale nie, bo "mam swoje powody".
> 
> >> Kiedyś ludzie uważali BCPL za spełenienie marzeń. Sam się kompiluje,
> >> można zrobić bootstrap na dziwnym systemie, architektura wręcz zdjęta z
> >> tablicy uczelni, *uproszczona* składnia.
> > Niestety nie miałem przyjemności z BCPL.
> 
> Śladowe ilości można było odszukać, najbliżej, w Amidze; w okolicy 
> połowy lat 80. DOSa miała napisanego w BCPLu. Skutkiem ubocznym 
> wszystkie pointery API DOSa wymagały arytmetyki >>2 <<2. H... wie po co :D
> 
> > Nie wiem jak używasz określenia białko.
> 
> Jako decydowanie o technologii na podstawie pozaracjonalnych doświadczeń 
> przez ludzie składających się z białka z domieszką uprzedzeń. Jedną z 
> najbardziej zdumiewających rzeczy jakie zrozumiałem o porogramistach 
> jest to że to ludzie bardziej uprzedzeni do wszystkiego niż przeciętny 
> wyborca konserwatystów.
> 
> >> Mam takie a takie doświadczenia, widziałem to i tamto, wnioskuje z tego
> >> to i owo.
> > Nie wiem w czym problem.
> 
> W tym że podejście racjonalne polega na czymś zgoła odmiennym.
> 
> >> A na koniec okazuje się że programy w C++ nie dość że są czytelniejsze
> >> od tych w C, to często są szybsze, łatwiejsze w analizie i refaktoringu.
> > Sekundę. Programy w C++ mogą być czytelniejsze od tych w C i to mogą być
> > znacznie czytelniejsze, tak samo jak mogą być łatwiejsze w analizie i
> > refaktoringu.
> 
> Nie, one *zazwyczaj* są. Pozawalają wyrazić algorytm bez pieprzenia się 
> z pisaniem go w asemblerze, do którego w gruncie rzeczy sprowadza się C, 
> a szczególnie taki poprzetykany void*.
> 
> > Ale jeśli są mocno zoptymalizowane pod kątem szybkości
> > działania, to na pewno nie są ani czytelne, ani łatwe w analizie, a już w
> > ogóle są fatalne w rozbudowie i refaktoringu.
> 
> Obawiam się że w programowaniu ważniejsza jest złożoność algorytmiczna 
> nad hackerskie optymalizacje kodu. Tym zajmuje się kompilator.
> 
> I uwaga: wszystkie sztuczki z C++ z szablonami generują równie szybki i 
> równie hackerski kod co C. Tyle że łatwiej to czytać, rozumieć i 
> refaktorować niż sieczkę kwadratowych kół w C.
> 
> >> I co to ma w ogóle do dyskusji o tym że zmiana z gcc na g++ dodaje od
> >> razu za darmo masę możliwosci które w C wymagają pisania kwadratowych kół?
> > Już pisałem jaka jest analogia i nie przeczyłem możliwościom C++. Nie można
> > jednej technologii ulepszać bez końca, a już na pewno nie można stałym
> > nakładem kosztów/pracy ulepszać o stałą wartość, efekty stają się coraz
> > mniejsze, a języki programowania są ulepszane od dawna. Dopóki  nie
> > będzie jakiegoś przełomu w technologiach wytwarzania oprogramowania, to
> > nie należy się już spodziewać, że taki czy inny zestaw nowych ficzerów
> > znacząco udoskonali technologię. W moim przypadku dobre biblioteki najbardziej
> > przyspieszają tworzenie oprogramowania.
> 
> Na 99% masz do nich dostęp w C++. Nastepny pusty argument.
> 
> > Bajeranckie cechy języka... to
> > nawet spowalniają, bo programista myśli czego lepiej użyć.
> 
> Odwrotnie. Programista nie myśli jak jest zbudowany std::container, 
> używa move i ma najszybszą z możliwych implementację. Pisanie w C++ 
> opiera się na pewnych obietnicach: napisz co chcesz a my zrobimy to tak 
> dobrze jak się da, albo przynajmniej najlepiej jak potrafimy.
> 
> Bibliteki nie są doskonałe. Ale są coraz doskonalsze a lata 90 słusznie 
> mineły.
> 
> > Bez kontekstu nie wiem jak się o to spierać. Templates można porównywać do
> > błędogennych makrodefinicji i void*.
> 
> Nijak się nie da. Templates nadają sens wskaźnikom. void* odbiera ten 
> sens. To tak jak byś pisał we wspomnianym BCPLu. Wszystko jest "wordem" 
> i sam se zgaduj co dostałeś jako argument. No wiec masa programistów C 
> pisze właśnie w takim BCPLu. Wszystko jest void* i tylko cicha modlitwa 
> pozwala upewnić się że to jest jednak Foo*.
> 
> >> Tylko że ja się o to nie spieram. Ja tylko protestuje przeciwko
> >> bredzeniu o tym że zmiana z gcc na g++ jest niemozliwa, bezsensowna
> >> i
> >> korutyny nie muszą mieć stosu a programiści muszą się szkolić z używania
> >> prymitywnego RAII.
> > Nie wiem, moje korutyny mają stos i są odporne na wątki - chyba że to co
> > ja mam jeszcze nie nazywa się korutyną.
> 
> Korutyna ma mieć stos. Piszą to w pierwszym zdaniu o korutynach na wiki.
> 
> Ale Maciek ma inny internet, inzynierię i wszechświat. U nie go nie 
> muszą. Stąd cała dyskusja, która tradycyjnie już odpłyneła w kierunku 
> nastepnego nudnego flame starych dziadków. Przypuszcalnie za 30 lat 
> będziemy się spierać w sanatoriach waląc się laskami po łbach.
> 
> >> Wieć programowanie w C++ to programowanie z dowolnym ficzerem dostępnym
> >> w g++ a niedostepnym w gcc. Na przykłd z użyciem RAII, które to jest
> >> swoją drogą krytycznie potrzebne w embedded i jednoczesnie skandalicznie
> >> olewane przez embedded. Bo kwadratowe koła łatwiej się produkuje niż
> >> kupuje okrągłe. 
> > A wyżej napisałeś że spieramy się o wyższość języka C nad C++ lub odwrotnie.
> 
> Bo tak wyszło. Pierowtny temat to napisanie kilku mark w celu emulacji 
> czegoś czego autor nie pojmuje jak ma działać.
> 
> > Język to nie jeden ficzer, a w praktyce nawet spór o cały język jest jałowy, bo
> > co komu nawet z najlepszego języka jak nie ma do niego narzędzi?
> 
> Do C++ jest całkiem sporo narzędzi. Nie narzekałbym.
> 
> >>>> Użycie składni obiektowej (struct/class) nie oznacza że używa się
> >>>> obiektowości.
> >>> Dlaczego?
> >> Bo obiektowośc wymaga *OBIEKTÓW* a nie klas.
> > Nie wiem, a co z tego rozgraniczenia dobrego dla Ciebie i dla mnie?
> 
> To dośc istotne przycięcie powoduje że ludzie przestają widzieć C++ jako 
> "coś gdzie obowiązkowo używa się new".
> 
> >> Że traits< int >::max to nie jest programowanie obiektowe, natomiast to
> >> jest programowanie w C++.
> > Też nie wiem co z tego dobrego dla mnie i dla Ciebie.
> 
> Dla innych może wynikać. Na przykład mogą w swoim zdumieniu zobaczyć że 
> powyższa linijka nie kompiluje się do milairda megabajtów. Ona się 
> kompiluje do ... niczego.
> 
> Zazwyczaj programiści C właśnie tak widzą C++: dużo pisania więc 
> wolniej. Nie przychdozi im do głowy że to pisanie jest po to aby 
> kompilator sprawdzał typy a nie generował kod.
> 
> >> Nie, znalezienie bładu w szablonach który ujawnia się w runtime jest
> >> naprawdę wyższą szkoła jazdy. Zrobienie błedu w void* który ujawnia się
> >> w runtime to trywializm.
> > Programowałem i z użyciem szablonów i z void*. Tyle że szablonów zwykle używam
> > do poprawy wydajności. Swoją osobistą statystykę mam zdecydowanie na korzyść
> > void* - w sensie że mniej błędów popełniałem. Ale powtarzam, ja czasami używam
> > szablonów zupełnie inaczej niż 90% programistów.
> 
> Mam doświadczenia dokładnie odwrotne. W dodatku moje są zbliżone do 
> obserwacji ludzi zajmujacych się teorią programowania - silne typy są 
> bezpieczniejsze niż uniwersalne dane. U mnie liczy się jakość, nie 
> wygoda pisania.
> 
> >> I w tym momencie zamieniasz gcc na g++. Znalazłeś jeden powód aby użyć
> >> C++ to go używasz, jest za darmo.
> > Nie rozumiem w jakim momencie, gcc szablonów nie kompiluje, a rozmawialiśmy w
> > tym akapicie o szablonach.
> 
> "gcc" to tylko taki koncept kompilatora C. Jak się uprzesz to oczywiście 
> za pomocą gcc skopilujesz plik .cpp (z pewnymi detalami, ale pal sześć). 
> Tu chodzi o metaforę: zamień swój kompilator z C na C++, to jest za darmo.
> 
> >>> gdy jeden szablon jest parametryzowany kilkoma innymi szablonami
> >> Poniżej promila z promila zastosowań szablonów wymaga takich wygibasów.
> > Jeśli podajemy jawnie wydajność jako zaletę templates, to zwykle używa
> > się tego typu wygibasów.
> 
> *W* środku biblitek. U klienta? Nie, raczej nie. Tam się to kończy 
> std::shared_ptr< Foo > a to że w środku ktoś sprawdza trywialnosc 
> konstruktora wielopoziomowymi szablonami to nie jest ani istotne ani 
> widoczne.
> 
> >> Ale dla user końcowego jest wręcz bajecznie prosta.
> > Tak, o to właśnie chodzi. Moje mikro-biblioteki też są w jakimś stopniu proste,
> > ale są wierzchołkiem góry lodowej. Niewidoczna część pod wodą stanowi
> > pierdylion eksperymentów z szablonami, makrami, opcjami kompilatora, z
> > oczekiwaniem na koniec pracy kompilatora, z uganianiem się za syntax error w
> > innym pliku niż pokazał kompilator....
> 
> Sprawdź co oferuje clang w kwesti przejrzystości błedów. gcc już od 
> dawna nie ma nic wspólnego z wygodą kompilowania. Da się? Da.
> 
> >> Te szablony w szablonach to taka Baba Jaga dla niegrzecznych
> >> programistów C. Straszy się nią i jak widać skutecznie.
> > Nie wiem do czego nawiązujesz.
> 
> Do bredzenia o tym że cośtam powiększa aplikacje o magabajty "bo trzeba 
> rozwijać szablony". Łomatko. Rozwijam szablony i raz mam 0 bajtów a raz 
> gigabajty. Na tego typu opinie nalezy natychmiast mówić "Stop". Generują 
> tylko atmosere podobną do antyszczepionkowców. Podobno użycie RAII 
> powoduje autyzm.
> 
> >>> pozbawionego błędów. Tak się mówi że szablony stanowią antidotum na błędy, bo
> >>> porównuje się je zwykle do najbardziej błędogennych konstrukcji języka, jak
> >>> wlaśnie do makr, albo do rzutowania na void*.
> >> Stanowią warstwę chroniącą przed pewną klasą problemów. Akurat tych
> >> upierdliwych, bo w runtime.
> > Może tak naprawdę spieramy się o to, że Ty uważasz iż szablony bardzo
> > usprawniają technologię oprogramowania, a ja że usprawniają ją w mniejszym
> > stopniu?
> 
> To zdajnie powyżej to nawet nie do końca się do szablonów odnosi. 
> Bardziej do silnych typów. Tak silnych że drą japę na kompilacji, czego 
> void* nie potrafi.
> 
> > Nie zgadzam się też, że trudno popełnić błąd w runtime programując z
> > wykorzystaniem szablonów.
> 
> Kawestia oceny. Przypadki kiedy typ nie pasuje są u mnie zredukowane do 
> prawie 0.
> 
> > Nie wiem, trudno mi się wypowiedzieć, bo od wielu lat void* zdarza mi
> > się użyć może raz na rok. Może z 15 lat temu używałem regularnie, też
> > dawałem radę. I nie chcę powiedzieć po prostu że kiedyś bez papieru
> > dawali radę, ale że jak dawali radę, to ten papier toaletowy nie jest aż
> > takim panaceum, tylko jakimś kolejnym małym ulepszeniem.
> 
> I jest za darmo. Znaczy nie papier tylko C++.
> 
> >> Myśle że 90% konstrukcji z boosta jest trywialna.
> > Pisałeś też że się napracowali przy booście, czy miałeś na myśli że
> > napracowali się przy pozostałych 10ciu procentach?
> 
> Nie jest istotne kto się naprawcował *przy* booscie. Istotne jest ile 
> napracuje się klient tego API. No więc niewiele. O wiele mniej niż 
> straszy się młodych studentów oferujac im w zamian łupanie kamieni void*.
> 
> >>> Gdy każde jeszcze ma jakieś parametry i
> >>> typy - to naprawdę zazwyczaj dostawałem oczopląsu gdy analizowałem swój własny
> >>> kod po krótkim czasie. Myślę że każdy programista uznałby za łatwiejszy w
> >>> analizie kod np. Javy.
> >> Więc masz kiepskie doświadczenia wynikające z kiespkiego doboru przykładów.
> > Czysta złośliwość czy kryje sie za tym coś konstruktywnego? Co to są
> > kiepskie doświadczenia?
> 
> Kiepskie przykład to na przykład analiza closures w boost::spirit. Tam 
> jest cieżko. I jestem pewny że jeśli ktoś chciałby mi złośliwie wykazać 
> że boost jest trudny to wyjmie przykłąd z okolicy boost::spirit, mpl czy 
> fusion. To są złe doświadczenia. Przy uzywaniu takim jak na początku 
> watku, czyli "małych kawałeczków C++ usprawniajacych pracę" takie 
> kobylaste szablony nie tylko się nie trafiają ale i sensu nie mają. 
> Przyjdzie czas to ktoś to doceni. Na razie wolałbym aby embedowcy 
> zauważyli że ktoś w zeszłym wieku wymyślił RAII. To już by było naprawdę 
> miłe.
> 
> >> Używam C++. W tym szablonów. Szablony są od dziesiątek lat coraz lepiej
> >> wspierane przez kompialtory (komunikaty błedów) i debuggery (pokazywanie
> >> zawartości). Nijak nie wiem czemu foo<int> miało by być bardzie
> >> skomplikowane do debugu. Jedyna przeszkoda to czasem dłuższe nazwy
> >> typów. Tylko że tam się zagląda raz na rok.
> > Na razie rozumiem, że dobre doświadczenia są wtedy gdy się tam zagląda
> > raz na rok, a gdy ktoś akurat nad tym pracuje, to nabiera kiepskich
> > doświadczeń.
> 
> Nie, to oznacza że kłopoty z debugiem kodu szablonowego praktycznie nie 
> wystepują w praktyce. Czasem się tam zagląda, w 50% przypadków brakuje 
> const albo miał być pointer a jest referencja. Ale to widać od razu, bez 
> debugowania. Ostatni raz rozwijałem mapę stl jakieś 2 lata temu szukając 
> dlaczego nie działa. Kodu biblitecznego stl/boost praktycznie sie nie 
> debuguje mimo że mój kod jest nimi przesiąknięty na wylot.
> 
> > Miałem na myśl nie nie tylko śledzenie linia po linii wykonania kodu w
> > programie do debugowania, tyko generalnie usuwanie błędów. Gdy oglądam
> > kod z 'wirtualnym typem' który dopiero w trakcie kompilacji będzie na
> > kilka sposobów konkretyzowany, to wcale nie jestem bardziej pewny jego
> > bezbłędności, niż gdy patrzę na kod zwykłej procedury. W zasadzie to
> > chyba mam odwrotnie, co do zwykłych procedur szybciej nabieram przekonania
> > że są poprawne. A swoją drogą w programach do debugowania też było
> > sporo błędów i gorzej sobie radziły na szablonach.
> 
> Znowu chciałem przypomnieć że lata 90 słusznie mineły.
> 
> >>> nie mam z nimi problemów. Ale gdy np. cały algorytm genetyczny parametryzuję
> >>> kilkoma klasami, to nawet nie mam wsparcia ze strony edytora, bo
> >>> edytor nie wie jakie metody będą miał parametry.
> >> Masz zły edytor.
> > Może, a jaki Ty masz?
> 
> Np. VS + Visual Assist. Visual assist poniekąd potrafi domyślać się 
> detali związanych z szablonami, i prawidłowo podpowiadać. I gubi się 
> czasem, tak. Trudny język, ciężko o dobry edytor, ale nie jest tak że 
> nie ma *nic*.
> 
> >> Mam młotek, ale lepiej wbijać gwoździe lutownicą.
> >> Mam szablony, ale przecież void* to tylko kilka wad z którymi da sie żyć.
> > Nie, nie to chciałem powiedzieć. Mam szablony, używam szablonów, ale jestem
> > świadomy że z void* też działało, więc te szablony to nie żadne panaceum, ale
> > jakieś kolejne ulepszenie.
> 
> Tu jest zupełnie inaczej. Silne typy są lepsze niż void*, mniej więcej 
> zawsze. Mimo to ludzie używający void*, czasami wymieniając ich wady, 
> dalej nie widzą sensu zmieny na silne typy. Problemem jest brak 
> logicznego argumentu dlaczego. W dodatku wielu reaguje skrajnie 
> alergicznie na pytanie "Dlaczego używasz void* skoro silne typy są za 
> darmo". To jest religia białkowa.
> 
> >> Ja rozumiem jeszcze jak by za używanie szblonów trzeba było płacić.
> > Bo trzeba, nic nie jest za darmo. Tą opłatą była/jest:
> >   - konieczność szkolenia personelu,
> 
> Używają int, float. Nagle muszą użyć Foo. To jakaś katastrofa?
> 
> >   - konieczność nabrania doświadczenia przez personel,
> 
> Mieli na to ostatnie 40 lat.
> 
> >   - wiele lat implementacji w kompilatorach,
> 
> Które od wielu lat je mają.
> 
> >   - problemy bo kompilatory różnie to wspierały,
> 
> Zaznaczam po raz kolejny że lata 90 słusznie mineły.
> 
> >   - targi o to jak powinny wyglądać w standardzie,
> 
> Zakończone standardem.
> 
> >   - próby łamania standardu przez niektóre firmy,
> 
> Które nie wpływają na 99.9% kodu pisanego w C++ najmniejszym stopniu 
> oraz identyczne problemy występują w każdym, dowlnym języku i kompilatorze.
> 
> >   - o wydłużonym czasie kompilacji, zwiększonym rozmiarze kodu i słabym
> 
> Atari 65XE słabo się sprawdza jako ciągła integracja, podobnie klikanie 
> w "rebuild".
> 
> >     pokazywaniu właściwej linii z syntax error - już pisałem.
> 
> To dobrze, bo w clangu też to zauważyli
> 
> >   - o tym jak to wygląda z punktu widzenia kogoś kto przygotowuje
> >     wygodny szablon - też już pisałem.
> 
> Ale to nikogo nie obchodzi po stronie klienta.
> 
> >> Szablony rozwiazują dobrze kreśloną klasę problemów z jakością kodu.
> > Zgoda, ale wprowadzają też inne problemy.
> 
> Nie. Ich naduzywanie może generować problemy. Zastapienie void* silnym 
> typem nie tylko jest oczywistym rozwiązaniem problemów z jakoscią kodu 
> ale wręcz zmusza do poprawy jego jakości podczas pisania.
> 
> Perwsze słyszę aby silne typy miał jakieś wady vs void*.
> 
> Na marginesie: void* to nie brak typu. To typ. Coś jak by pisać w javie 
> kastujac wszystko do Object i spowrtoem za każdym razem. Po h.. ?
> 
> > Choć podsumowanie dziś wypada na
> > korzyść szablonów, to po odjęciu wad, to podsumowanie nie jest rewelacyjne.
> 
> Stosujesz typową metodę dyskutowania: będę wyważony, to będę brzmiał 
> mądrze. Tylko że te "nie jest rewelacyjne" jest troche smutne w 
> zderzeniu z faktem że szablony są <division by zero exception> razy 
> lepsze od void*.
> 
> >> W C nie ma nic co mogło by to zastapić poza modlitwą.
> > Zewnętrzne programy narzędziowe pełny rolę generyków, sam jeden większy
> > generator napisałem do generowania sieci neuronowych. No i był void* i
> > makra ;-)
> 
> Kto komu broni generować kod z void*. Pisanie void* z palca jest porażką 
> a nie generowanie.
> 
> >> Jesteś pewien że masz wszystko dobrze że masz potrzebę pełnej rekompilacji?
> > Bym musiał napisać (i potem pilnować) specjalne pliki make, które uwzględniają
> > kompilację warunkową.
> 
> I robisz to co 30 sekund? Czy może robi to ciągła integracja?
> 
> > Nie wiem co gorsze, modlić się czy nie mam błędu w
> > pliku make, czy czekać te 30 sekund.
> 
> To nie ty czekasz. To ciągła integracja czeka. Ty popijasz kawę, albo 
> robisz coś innego.
> 
> >> Masz kiepski przypadek, przypuszczalnie jest on na tyle specyficzny że
> >> nie powinien być uważany za reprezentacyjny.
> > Nie wiem czy kiepski przypadek, sam przyznałeś że ludzie od boosta
> > się napracowali ciężko...
> 
> Nie widzę związku.
> 
> Zmieniasz globalnego define. Wymaga to rekompilacji wszystkiego. 
> Argument że wtedy jest wolno jest taki sam w C jak i w C++.
> 
> >> Z faktu że ktoś kiedyś robił kupę bez papieru nie wynika że papier jest
> >> zbędny obecnie.
> > No nie, mamy papier, żyje się trochę lepiej, ale musimy za niego zapłacić,
> > go produkować, oczyszczać [...]
> 
> Niekiedy daleko idace analogie są błedne.
> 
> C++ jest za friko.
> 
> Napisanie Foo* zamiast void* jest za friko.
> 
> RAII jest za friko.
> 
> W ogóle wszystko jest za friko.
> 
> Upierdiwy profesor powie że plik kompiluje się 1.7ms dłużej. I będzie 
> miał rację. Ten 3-ci rodzaj racji. Coś jak uszczędzanie na plastikowych 
> słomkach w prywatnych samolotach.
> 
> >>>> Na patrz, a ja miałem Amigę z 2MB pamięci chip i na tej konfiguracji
> >>>> poganiałem SaSC w trybie C++ pisząc obiektowe programy GUIowe. Może to
> >>>> czary?
> >>> Może czary, a może to (w jakimś stopniu) dzięki void* ?
> >> Nie, C++ z szablonami. SaSC miał translator z C++ na generowany C.
> > Tak. Były generyki i w C, tylko na poziomie narzędzi a nie języka.
> 
> Nie rozumiesz. SasC to był również normalny C++. To że w środku 
> konwertował to na C i kompilował, to detal. Nieistotny. Niewidoczny.
> 
> Miałem więc kompilator C++ na 2MB RAMu bez swapa i dało się w tym pisać 
> obiektowe i okienkowe aplikacje o przyzwoitej wydajnosci. Ba, o 
> wydajności zbliżonej do tej z C. Róznica była głównie w tym że ten 
> konwerter był *bardzo* kiepski.
> 
> >> Stawiam wniosek: obecnie rozpasanie programów nie ma *NIC* wspoónego z
> >> wyborem języka C czy C++. Ma związek jedynie z kiepskimi programistami,
> >> przyrostem danych i rozbudową OSów.
> > Też mi jest trudno się wypowiedzieć, w sumie nie biorę udziału w
> > programach których kod wynikowy nie mieści się na DVD. Myślę jednak
> > że zdublowanie kodu ma największy wpływ.
> 
> Całe szczęscie C++ nie dubluje kodu sam z siebie jesli ludzie nie piszą 
> byle jak.

Przepraszam, nie będę kontynuował, ponieważ za dużo tekstu bym musiał
napisać, żebym został zrozumiany tak jak wyobrażam sobie w chwili
pisania tegoż tekstu :) Zadam tylko pytanie: dlaczego według rankingów
aż około 5-7% programistów wybiera C, gdy język najbardziej popularny w
danym czasie wybiera np. 12-15%. Coś nie tak z tymi programistami od C
jeśli są tylko zalety z przejścia na C++, czy to jednak jakaś mądrość
tłumu? 

Pozdrawiam

W dniu piątek, 31 stycznia 2020 13:07:28 UTC+1 użytkownik M.M. napisał:
> 
> Przepraszam, nie będę kontynuował, ponieważ za dużo tekstu bym musiał
> napisać, żebym został zrozumiany tak jak wyobrażam sobie w chwili
> pisania tegoż tekstu :)

a to szkoda bo ten watek byl wbitnie rozrywkowy ;x przebul chyba nawet znacznie starsza tworczosc niejakiego A. Jarząbka (tutaj u mnie nagromadzenie zdumienia z tego co czytam bylo chyba kilkukrotnie wieksze ;c )

On 31/01/2020 13:07, M.M. wrote:
> pisania tegoż tekstu :) Zadam tylko pytanie: dlaczego według rankingów
> aż około 5-7% programistów wybiera C, gdy język najbardziej popularny w
> danym czasie wybiera np. 12-15%. Coś nie tak z tymi programistami od C
> jeśli są tylko zalety z przejścia na C++, czy to jednak jakaś mądrość
> tłumu?

Białko. W dodatku programiści zazwyczaj nie wybierają języka.

Mają:
a) ulubione
b) uprzedzenia
c) mentorów od 7 boleści
d) bibliteki
e) specyfikacje
f) ignorancje
g) gotowe zespoły
h) lenistwo
i) autyzm
...

Zakładanie że wybór języka programowania podyktowany jest suchą oceną 
jego przydatności w danym zastosowaniu jest naiwne. Białko nie wybiera 
uzywając logiki, przynajmniej w znacznej częsci tych %.

On 31/01/2020 08:35, Tomasz Kaczanowski wrote:
>> Przypomnij mi który obecnie używany i popularny kompilator C/C++ 
>> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?
> a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową 
> do specyfiki nowego systemu?

A co to ma do rzeczy kiedy ta bibliteka wymaga przystosowania do 
pozostałym dziesiątek języków programowania gdzie C++ jest tylko jednym 
z wielu frontendów? I w dodatku w 95% ta bibliteka składa się z wywołań 
C wiec musisz ją i tam napisać jeśli chcesz C.

Bibliteki std w C++ są w postaci kodu źródłowego i poza poprawą bugów i 
zdefiniowaniem ile ma size_t wiele pracy nie wymagają.

>> Szczególnie jak odkrywasz że współczesne kompilatory to jakieś 
>> frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...
> tak... rozmawiamy o c i c++, czy językach korzystających z maszyn 
> wirtualnych?

Rozmawiamy o maszynach wirtualnych w środku kompilatora.

Od prostych drzew, przez drzewa optymalizujące po wirtualną architekturę 
rejkestrową albo stosową. Na samym końcu, naprawdę na samiuteńkim, lezy 
sobie generator kodu do języka maszynowego danej architektury. To 
śladowy element całości procesu kompilacji jeśli chcemy porównać 
trudność pisania kompilatora.

Polecam nie bredzić tylko zainteresować się:

https://gcc.gnu.org/onlinedocs/gccint/index.html

(etapy pośrednie generacji kodu GENERIC, GIMPLE, RTL).

https://en.wikipedia.org/wiki/GNU_Compiler_Collection#GENERIC_and_GIMPLE

Oraz:

https://llvm.org/

Oczywiscie generowanie kodu pośredniego ma też przeciwników, np część 
naukowców uważa że to jest niewydajna metoda:

https://www.youtube.com/watch?v=pP_zIJSp3WA

Ale jest też bardzo stara:

https://en.wikipedia.org/wiki/UNCOL

Innymi słowy, mój przyjacielu: dopisanie do gcc/llvm *nowej* platformy 
sprowadza się do napisania backendu, który jest ułamkiem samego 
kompilatora. A jak już go napiszesz do dostajesz w zasadzie za darmo 
wsparcie dla *WSZYSTKICH* języków z fronendu. Do C i C++ tak samo 
dostaniesz jak do Pascala którego nawet nie planowałeś.

Odpowiedź więc na pytanie: czy ciezko napisać C++ na nową platformę? 
brzmi: prawie dokładnie tak samo ciezko jak do C.

On Friday, January 31, 2020 at 8:33:40 PM UTC+1, heby wrote:
> On 31/01/2020 08:35, Tomasz Kaczanowski wrote:
> >> Przypomnij mi który obecnie używany i popularny kompilator C/C++ 
> >> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?
> > a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową 
> > do specyfiki nowego systemu?
> 
> A co to ma do rzeczy kiedy ta bibliteka wymaga przystosowania do 
> pozostałym dziesiątek języków programowania gdzie C++ jest tylko jednym 
> z wielu frontendów? I w dodatku w 95% ta bibliteka składa się z wywołań 
> C wiec musisz ją i tam napisać jeśli chcesz C.
> 
> Bibliteki std w C++ są w postaci kodu źródłowego i poza poprawą bugów i 
> zdefiniowaniem ile ma size_t wiele pracy nie wymagają.
> 
> >> Szczególnie jak odkrywasz że współczesne kompilatory to jakieś 
> >> frontendy, backedy, kody pośrednie, maszyny wirtualne itd itp ...
> > tak... rozmawiamy o c i c++, czy językach korzystających z maszyn 
> > wirtualnych?
> 
> Rozmawiamy o maszynach wirtualnych w środku kompilatora.
> 
> Od prostych drzew, przez drzewa optymalizujące po wirtualną architekturę 
> rejkestrową albo stosową. Na samym końcu, naprawdę na samiuteńkim, lezy 
> sobie generator kodu do języka maszynowego danej architektury. To 
> śladowy element całości procesu kompilacji jeśli chcemy porównać 
> trudność pisania kompilatora.
> 
> Polecam nie bredzić tylko zainteresować się:
> 
> https://gcc.gnu.org/onlinedocs/gccint/index.html
> 
> (etapy pośrednie generacji kodu GENERIC, GIMPLE, RTL).
> 
> https://en.wikipedia.org/wiki/GNU_Compiler_Collection#GENERIC_and_GIMPLE
> 
> Oraz:
> 
> https://llvm.org/
> 
> Oczywiscie generowanie kodu pośredniego ma też przeciwników, np część 
> naukowców uważa że to jest niewydajna metoda:
> 
> https://www.youtube.com/watch?v=pP_zIJSp3WA

Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie 
pewnych optymalizacji. Maszyna pośrednia by musiała wiedzieć coś o 
kodzie C++, a to uniemożliwiłoby generowanie z innych języków do 
maszyny pośredniej.


> 
> Ale jest też bardzo stara:
> 
> https://en.wikipedia.org/wiki/UNCOL
> 
> Innymi słowy, mój przyjacielu: dopisanie do gcc/llvm *nowej* platformy 
> sprowadza się do napisania backendu, który jest ułamkiem samego 
> kompilatora. A jak już go napiszesz do dostajesz w zasadzie za darmo 
> wsparcie dla *WSZYSTKICH* języków z fronendu. Do C i C++ tak samo 
> dostaniesz jak do Pascala którego nawet nie planowałeś.
> 
> Odpowiedź więc na pytanie: czy ciezko napisać C++ na nową platformę? 
> brzmi: prawie dokładnie tak samo ciezko jak do C.

Pozdrawiam

On 31/01/2020 20:43, M.M. wrote:
> Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
> utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie
> pewnych optymalizacji.

Każdy kod pośredni daje gorsze wyniki niż kompilacja wprost 
(teoretycznie). Każda kompilacja wprost jest trudniejsza niż kod pośredni.

Świat nie jest optymalny. Jest wystarczająco dobry.

Kompilacja wprost przy obecnych językach to by była katastrofa ponieważ 
złożoność frontendu i backendu u jest absurdalna. Relaksujemy nieco 
jakość i znajdujemy jakiś punkt w rozsądnej odległości od optimum przy 
okazji dostając unifikacje bardzo ciezkiego kodu kopilatora, 
odpowiedzielnego za optymalizacje.

> Maszyna pośrednia by musiała wiedzieć coś o
> kodzie C++, a to uniemożliwiłoby generowanie z innych języków do
> maszyny pośredniej.

I maszyna na niektórych etapach ma specyficzne dla danej plaformy 
konstrukcje. Przykładowo wysokopoziomowe drzewo C++ ma specyficzną 
konstrukcję co pozwala na propagacje pewnych cech C/C++ niżej do 
następnej warstwy:

https://gcc.gnu.org/onlinedocs/gccint/C-and-C_002b_002b-Trees.html#C-and-C_002b_002b-Trees

Im niżej tym mniej wiadomo o fronendzie a więcej o backendzie.

On Friday, January 31, 2020 at 8:53:27 PM UTC+1, heby wrote:
> On 31/01/2020 20:43, M.M. wrote:
> > Uważam w ogóle że oddzielenie kodu C++ od kodu maszynowego tak bardzo
> > utrudnia optymalizację, że w praktyce uniemożliwia przeprowadzenie
> > pewnych optymalizacji.
> 
> Każdy kod pośredni daje gorsze wyniki niż kompilacja wprost 
> (teoretycznie). Każda kompilacja wprost jest trudniejsza niż kod pośredni.

Zgadzam się.


> Świat nie jest optymalny. Jest wystarczająco dobry.

Tego już nie wiem. Ale zazwyczaj każda optymalizacja jest optymalizacją
wielokryterialną, a jednym z kryteriów jest też czas napisania kompilatora, a
nie tylko jakość generowanego przez niego kodu.

 
> Kompilacja wprost przy obecnych językach to by była katastrofa ponieważ 
> złożoność frontendu i backendu u jest absurdalna. Relaksujemy nieco 
> jakość i znajdujemy jakiś punkt w rozsądnej odległości od optimum przy 
> okazji dostając unifikacje bardzo ciezkiego kodu kopilatora, 
> odpowiedzielnego za optymalizacje.

Tak, to bardzo rozsądne.


> 
> > Maszyna pośrednia by musiała wiedzieć coś o
> > kodzie C++, a to uniemożliwiłoby generowanie z innych języków do
> > maszyny pośredniej.
> 
> I maszyna na niektórych etapach ma specyficzne dla danej plaformy 
> konstrukcje. Przykładowo wysokopoziomowe drzewo C++ ma specyficzną 
> konstrukcję co pozwala na propagacje pewnych cech C/C++ niżej do 
> następnej warstwy:

Nie wiedziałem, to faktycznie poszerza możliwości optymalizacji kodu
wynikowego.


> https://gcc.gnu.org/onlinedocs/gccint/C-and-C_002b_002b-Trees.html#C-and-C_002b_002b-Trees
> 
> Im niżej tym mniej wiadomo o fronendzie a więcej o backendzie.

Nie znam zagadnienia, ale logika tak właśnie podpowiada.


Pozdrawiam

On 31/01/2020 21:09, M.M. wrote:
>> Świat nie jest optymalny. Jest wystarczająco dobry.
> Tego już nie wiem. Ale zazwyczaj każda optymalizacja jest optymalizacją
> wielokryterialną, a jednym z kryteriów jest też czas napisania kompilatora, a
> nie tylko jakość generowanego przez niego kodu.

I w efekcie opłaca się pisać nieoptymalne kompilatory, ale rózniące się 
tylko o promile od optimum, za to pisać je 100x szybciej (sprawdzić czy 
to nie gcc).

LLVM powstał praktycznie w mgnieniu oka tylko dlatego że dobrał 
*sensowny* kod pośredni i sensowne abstrakcje. Kiedy gcc miotało się w 
dziesiątkach lat legacy kodu o żałosnej jakości LLVM przyszedł i pozamiatał.

2020-01-31 o 21:07 +0100, heby napisał:
> Serio nie słyszałeś nigdy o jakiś podstawach inzynierii
> programowania, standardach, pracy zespołowej, normach,
> specyfikacjach, coding standardach, zabronionych konstrukcjach,
> wzorcach proejktowych, code review?

To w dużych i poważnych korpo, które rzucają pieniędzmi na prawo i lewo.

Ale tak, jak nie każdemu pasuje C++, tak samo nie każdy ma ochotę kisić
się w korpo. W zdrowym startupie kod ma być na wczoraj, ma działać na
tyle dobrze żeby klient się nie zorientował że są bugi, a jeśli już coś
się skitłasi to z marszu musi to naprawić na produkcji ktokolwiek, kto
akurat jest pod ręką.

> A więc jednak na serio myślisz że to się tak odbywa ...

Zależy gdzie. Ale tak - odbywa się.

Mateusz

On 31/01/2020 21:34, Mateusz Viste wrote:
>> A więc jednak na serio myślisz że to się tak odbywa ...
> Zależy gdzie. Ale tak - odbywa się.

Dlatego sugerowałbym nie pokazywać patologii jako normy. Patologie 
istnieją tak samo w C++ jak i w C. I odpowiada za nie głównie białko a 
nie język.

2020-01-31 o 21:51 +0100, heby napisał:
> Dlatego sugerowałbym nie pokazywać patologii jako normy.

To niekoniecznie patologia. Tzn. z punktu programisty, który poza kodem
niczego nie widzi, to może i jest - ale taki lamentuje kilka tygodni,
że "nie mam czasu sobie porefaktoryzować", "to nie moja wina że robię
błędy, to CI nie wychwyciło" itp. A potem się zwalnia i idzie do korpo,
gdzie będzie mógł masturbować się z kolegami nad wirtualnymi funkcjami,
wielodziedziczeniem, lambdą czy innym polimorfizmem. W startupie nie ma
czasu na takie rozmyślania - ma być szybko i skutecznie, coby
handlowiec mógł zafakturować i szukać następnego klienta.

> Patologie istnieją tak samo w C++ jak i w C. I odpowiada za nie
> głównie białko a nie język.

W 100% się zgadzam. Niestety tego "białka" nie da się wyeliminować,
więc póki co trzeba działać w taki sposób, by to białko było możliwie
łatwo wymienialne i robiło możliwie jak najmniej szkód. Trzymanie się C
to nie jest panaceum, ale z braku laku może być prostym i tanim sposobem
na utrzymanie jako takiej spójności i zapewnienie że każdy ziom z
zespołu będzie w stanie ogarnąć co i jak, jeśli na niego trafi pilny
core dump do zdiagnozowania.

Mateusz

W dniu piątek, 31 stycznia 2020 21:07:02 UTC+1 użytkownik heby napisał:

> > I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery
> 
> A więc jednak na serio myślisz że to się tak odbywa ...

Nie jest tak, że "myślę, że to się tak odbywa".
Jest tak, że widzałem, że to się tak odbywa.
W poważnych międzynarodowych firmach technologicznych.

Przy okazji, co z tymi linkami?
Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie dotyczące "pure coroutines", też jest poniżej godności, tak jak ilustrowanie kodem potencjalnych problemów, które mogą się pojawić w kodzie przy stosowaniu takich czy innych rozwiązań?

On 31/01/2020 22:28, Maciek Godek wrote:
> Nie jest tak, że "myślę, że to się tak odbywa".
> Jest tak, że widzałem, że to się tak odbywa.
> W poważnych międzynarodowych firmach technologicznych.

I dlatego to wszystko wina C++ a RAII powoduje autyzm.

> Przy okazji, co z tymi linkami?

Jakimi linkami?

> Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie

Udostępniłem Ci artykuł na Wiki gdzie kilku ważnych ludzi umarło ze 
śmiechu na widok jeszcze jednego kwadratowego koła z 
switch/case/__LINE__. Naprawdę nie jesteś ani pierwszy ani ostatni. Ale 
bronisz tego chorego pomysłu jak niepodległości bo przecież nie może być 
tak że to obiektywne g. Ojczyzna potrzebuje takich.

https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

W dniu piątek, 31 stycznia 2020 22:40:46 UTC+1 użytkownik heby napisał:
> On 31/01/2020 22:28, Maciek Godek wrote:
> > Nie jest tak, że "myślę, że to się tak odbywa".
> > Jest tak, że widzałem, że to się tak odbywa.
> > W poważnych międzynarodowych firmach technologicznych.
> 
> I dlatego to wszystko wina C++ a RAII powoduje autyzm.
> 
> > Przy okazji, co z tymi linkami?
> 
> Jakimi linkami?

Napisałeś tak:
> Radze poczytać internety w kwesti co to jest pure.
>
> Korutyna to nie jest funkcja w rozumieniu "pure function" ale moze byc
> "pure coroutine".

No, to ja czekam na linki do tych internetów.

> > Czy udostępnianie źródeł do artykułów, które potwierdziłyby Twoje teorie
> 
> Udostępniłem Ci artykuł na Wiki gdzie kilku ważnych ludzi umarło ze 
> śmiechu na widok jeszcze jednego kwadratowego koła z 
> switch/case/__LINE__.

No, "umarło ze śmiechu" to chyba nie.
Dokładny kontekst, z którego pochodzi podany przez Ciebie cytat, jest właśnie na tej stronie, do której linkujesz poniżej. I brzmi on w pełnej okazałości tak:

"PuTTY is a Win32 Telnet and SSH client. The SSH protocol code contains real-life use of this coroutine trick. As far as I know, this is the worst piece of C hackery ever seen in serious production code."

Autorem cytatu jest jednocześnie autor programu PuTTY.
Czyli "umiera ze śmiechu", jednocześnie korzystając z tego rozwiązania.

> Naprawdę nie jesteś ani pierwszy ani ostatni. Ale 
> bronisz tego chorego pomysłu jak niepodległości bo przecież nie może być 
> tak że to obiektywne g. Ojczyzna potrzebuje takich.

Nie "bronię tego chorego pomysłu jak niepodległości". Podzieliłem się tym pomysłem, gdyby ktoś miał ochotę z niego skorzystać. W kontekście problemów, z którymi w ostatnim czasie się zmagałem, jest użyteczny (i to bardziej użyteczny, niż bardziej ogólne rozwiązania, które proponowałeś).

Ale ma swoje ograniczenia (jak zresztą wszystko).

W każdym razie nie o to pytam. Pytam o "pure coroutine".
Bo na Wiki nic o tym nie ma.

On Friday, January 31, 2020 at 8:18:09 PM UTC+1, heby wrote:
> On 31/01/2020 13:07, M.M. wrote:
> > pisania tegoż tekstu :) Zadam tylko pytanie: dlaczego według rankingów
> > aż około 5-7% programistów wybiera C, gdy język najbardziej popularny w
> > danym czasie wybiera np. 12-15%. Coś nie tak z tymi programistami od C
> > jeśli są tylko zalety z przejścia na C++, czy to jednak jakaś mądrość
> > tłumu?
> 
> Białko. W dodatku programiści zazwyczaj nie wybierają języka.
> 
> Mają:
> a) ulubione
> b) uprzedzenia
> c) mentorów od 7 boleści
> d) bibliteki
> e) specyfikacje
> f) ignorancje
> g) gotowe zespoły
> h) lenistwo
> i) autyzm
> ...
> 
> Zakładanie że wybór języka programowania podyktowany jest suchą oceną 
> jego przydatności w danym zastosowaniu jest naiwne. Białko nie wybiera 
> uzywając logiki, przynajmniej w znacznej częsci tych %.

Nie wiem jaka jest prawda, nie mam dostępu do stosownych danych aby
wyciągnąć rzetelne wnioski. Ale myślę sobie tak... Jak ktoś cokolwiek
programuje, to podstawy logiki i matematyki musi mieć ogarnięte, a to
wymaga pewnego poziomu intelektualnego. Jak używa języka programowania w 
którym jest arytmetyka wskaźników i sporo ryzykownych elementów, i do tego 
jak radzi sobie, to też wskazuje na jego jakiś sensowny poziom intelektualny.
I taka osoba nieracjonalnie wybiera gorszy język programowania... Coś mi
tutaj nie pasuje.

Pozdrawiam

On 01/02/2020 05:20, M.M. wrote:
> wymaga pewnego poziomu intelektualnego. Jak używa języka programowania w
> którym jest arytmetyka wskaźników i sporo ryzykownych elementów, i do tego
> jak radzi sobie, to też wskazuje na jego jakiś sensowny poziom intelektualny.
> I taka osoba nieracjonalnie wybiera gorszy język programowania... Coś mi
> tutaj nie pasuje.

Poziom intelektu nie wiele wspólnego z  racjonalnymi wyborami. 
Przeceniasz siłe logiki w podejmowaniu decyzji.


Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia, 
jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec 
lat 90. Nie był to zły wybór.

Pech chce że projekt ewoluuje. W następnych wersjach wymagają obliczeń. 
Takich raczej męczących dla CPU. Dodatkowo okazuje się że muszą ogarniać 
już system RT bo obliczeń duzo, zdarzeń dużo i zaczyna brakować czasu CPU.

Wydawało by się że sensowne jest przejscie na szybszy procesor.

Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na 
PICach. Tych samych. Prawie tych samych, one są już na wylocie i z 
którymi jest kłopot z zakupem bo są nieprodukowane lub produkcja się 
kończy. Dlaczego? "Jak działa to nie ruszaj". W rzeczywistości mają 
kolosalny dług technologiczny bo rozwijali soft w asemblerze i tylko 
dorabiają idiotyczne wiejskie powiedzonka żeby to jakoś usprawiedliwić.

Problem w tym że tak naprawdę nie działa i muszę ruszać bo za chwile ich 
nie kupią. Ale nowych ich nie kupią bo mają asembler. Wybór języka 
okazał się być dead end projektu.

To taki przykład "na gorąco" jak wygląda dynamika dostosowania się do 
zmian. I używanie logiki przez ludzi naprawdę dobrze rozumiejących 
arytmetykę wskaźnikową. Jeden z tych ludziów zapytał mnie co mogą 
zrobić. O 20 lat za późno. Pytam o powody tego asm do dzisiaj i dlaczego 
PICe. "Kolega znał tośmy wybrali". Przypuszczam że ten "kolega" nie 
potrzebował już asemblera po 20 latach pracy, pisał wprost binarnie kod.

Rozmawiamy o małej firmie która miała możliwość w ciągu tych 20 lat 
posprzątania. Tymczasem doskonalili się w produkcji gówna void* w asm i 
wylądowali tam gdzie każdy taki projekt czyli na śmietniku.

Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością 
wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy 
to duże korpo czy mała firemka, podobne.

W dniu 2020-02-01 o 09:07, heby pisze:

> Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia, 
> jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec 
> lat 90. Nie był to zły wybór.

Jesteśmy malutką firmą.
Na początku lat 90-tych klient zamówił opracowanie urządzenia 
dostarczając nam narzędzia do PICa (programator produkcji Microchipa, 
rozmiaru prawie A4 z wymiennymi modułami do różnych obudów). Na potrzeby 
projektu mieliśmy 10 szt PICów. Pierwsze 5 spaliliśmy bo ten ich 
programator włączając VPP między stanem początkowym 5V a końcowym 21V 
przechodził po drodze przez 45V. Zwykłe blank-check zabijało scalak.
Po namierzeniu problemu i zmodyfikowaniu tego programatora natknęliśmy 
się następnie na 3 różne błędy w PICu. Dwa udało nam się obejść, ale 
trzeci nas rozłożył. Według naszych pomiarów procesor przegapiał mniej 
więcej jedno na 3000 zboczy które miały dawać przerwanie, a odbieranie 
tych przerwań to była kluczowa sprawa.
Wysyłaliśmy faxy do Microchipa - bez odpowiedzi. Jakiś rok później 
odbyło się pierwsze seminarium Microchipa w W-wie. Tam obiecali, że 
przyślą nam erratę. Półtora miesiąca później dostaliśmy faxem tę erratę 
- zawierała 6 błędów (w tym te 3 które sami odkryliśmy). Aby obejść ten, 
który nas rozłożył proponowali dołożenie zewnętrznego układu 
synchronizującego zbocza przerwań z zegarem procka.
Gdybyśmy to wiedzieli przed projektem płytki....

Nasza decyzja - nigdy więcej PICów.

> Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na 
> PICach.

Siedzimy od wielu lat na Xmegach.

> W rzeczywistości mają  
> kolosalny dług technologiczny bo rozwijali soft w asemblerze....

> Pytam o powody tego asm do dzisiaj

Bootloader mamy w assemblerze.
Nigdy nie programowałem mikrokontrolerów i żaden z nas nie jest 
wykształconym programistą. Z tego co brat mi mówi to on nie widzi 
możliwości napisania efektywnego SHA256 na Xmega w C. O ile pamiętam 
(rozmowa była z 5 lat temu) to problem polega na tym, że C zabiera z 
definicji kilka rejestrów i brakuje dla przechowywania stanu SHA256. A 
ciągłe przerzucanie danych między rejestrami a RAMem kilkukrotnie 
spowalnia obliczenia.

> i dlaczego PICe.

Z mojego punktu widzenia (projektuję schematy/płytki) Xmegi są na prawdę 
fajne. 7 UARTów, 3 SPI, 2 I2C, 16 wejść analogowych, przerwania z każdej 
nogi pozwala mi zawsze tak podłączyć peryferia abym nie musiał korzystać 
z drugiej strony płytki dla ścieżek sygnałowych.

> Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością 
> wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy 
> to duże korpo czy mała firemka, podobne.

Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
Ja to widzę inaczej.
Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas 
przy tej okazji na skok technologiczny, co spowoduje opóźnienie go 
szacunkowo o pół roku. Nasze doświadczenie nam mówi, że jak się nam 
wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.
No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na 
wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy 
jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż 
znajdziemy na to czas.
P.G.

W dniu sobota, 1 lutego 2020 13:04:30 UTC+1 użytkownik Piotr Gałka napisał:
> W dniu 2020-02-01 o 09:07, heby pisze:
> 
> > Przykład: firma robi sterowniki. Tak nie za trudne, jakieś wejścia, 
> > jakieś sterowanie, ogólnie nic skomplikowanego. Wybrali PICa, pod koniec 
> > lat 90. Nie był to zły wybór.
> 
> Jesteśmy malutką firmą.
> Na początku lat 90-tych klient zamówił opracowanie urządzenia 
> dostarczając nam narzędzia do PICa (programator produkcji Microchipa, 
> rozmiaru prawie A4 z wymiennymi modułami do różnych obudów). Na potrzeby 
> projektu mieliśmy 10 szt PICów. Pierwsze 5 spaliliśmy bo ten ich 
> programator włączając VPP między stanem początkowym 5V a końcowym 21V 
> przechodził po drodze przez 45V. Zwykłe blank-check zabijało scalak.
> Po namierzeniu problemu i zmodyfikowaniu tego programatora natknęliśmy 
> się następnie na 3 różne błędy w PICu. Dwa udało nam się obejść, ale 
> trzeci nas rozłożył. Według naszych pomiarów procesor przegapiał mniej 
> więcej jedno na 3000 zboczy które miały dawać przerwanie, a odbieranie 
> tych przerwań to była kluczowa sprawa.
> Wysyłaliśmy faxy do Microchipa - bez odpowiedzi. Jakiś rok później 
> odbyło się pierwsze seminarium Microchipa w W-wie. Tam obiecali, że 
> przyślą nam erratę. Półtora miesiąca później dostaliśmy faxem tę erratę 
> - zawierała 6 błędów (w tym te 3 które sami odkryliśmy). Aby obejść ten, 
> który nas rozłożył proponowali dołożenie zewnętrznego układu 
> synchronizującego zbocza przerwań z zegarem procka.
> Gdybyśmy to wiedzieli przed projektem płytki....
> 
> Nasza decyzja - nigdy więcej PICów.
> 
> > Rzeczywistośc wygląda tak że od kilkudziesięciu lat siedzą dalej na 
> > PICach.
> 
> Siedzimy od wielu lat na Xmegach.
> 
> > W rzeczywistości mają  
> > kolosalny dług technologiczny bo rozwijali soft w asemblerze....
> 
> > Pytam o powody tego asm do dzisiaj
> 
> Bootloader mamy w assemblerze.
> Nigdy nie programowałem mikrokontrolerów i żaden z nas nie jest 
> wykształconym programistą. Z tego co brat mi mówi to on nie widzi 
> możliwości napisania efektywnego SHA256 na Xmega w C. O ile pamiętam 
> (rozmowa była z 5 lat temu) to problem polega na tym, że C zabiera z 
> definicji kilka rejestrów i brakuje dla przechowywania stanu SHA256. A 
> ciągłe przerzucanie danych między rejestrami a RAMem kilkukrotnie 
> spowalnia obliczenia.
> 
> > i dlaczego PICe.
> 
> Z mojego punktu widzenia (projektuję schematy/płytki) Xmegi są na prawdę 
> fajne. 7 UARTów, 3 SPI, 2 I2C, 16 wejść analogowych, przerwania z każdej 
> nogi pozwala mi zawsze tak podłączyć peryferia abym nie musiał korzystać 
> z drugiej strony płytki dla ścieżek sygnałowych.
> 
> > Potwarzam, intelekt praktycznie nic nie ma wspólnego z mądrością 
> > wyborów. Decydują czynniki pochodzące czysto z biologii. Mechanizmy, czy 
> > to duże korpo czy mała firemka, podobne.
> 
> Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
> Ja to widzę inaczej.
> Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas 
> przy tej okazji na skok technologiczny, co spowoduje opóźnienie go 
> szacunkowo o pół roku. Nasze doświadczenie nam mówi, że jak się nam 
> wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.
> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na 
> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy 
> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż 
> znajdziemy na to czas.
> P.G.

no taka jest realnosc firm, ale szczerze mowiac, ona nie jest dobra..

a czy ta firma lub takie firmy nie zarabiaja na tyle wystarczajao zeby moc poswiecic 20-30% czasu na rozwoj/research ? (zwlaszcza jesli to jest sensowny potrzebny research a nie siedzenie przy kompie i ogladanie netu)..?

W dniu piątek, 31 stycznia 2020 22:28:22 UTC+1 użytkownik Maciek Godek napisał:
> W dniu piątek, 31 stycznia 2020 21:07:02 UTC+1 użytkownik heby napisał:
> 
> > > I finalnie wychodzi, że kod jest niespójny, bo jakaś młodzież zapragnęła wcisnąć jakieś nowe ficzery
> > 
> > A więc jednak na serio myślisz że to się tak odbywa ...
> 
> Nie jest tak, że "myślę, że to się tak odbywa".
> Jest tak, że widzałem, że to się tak odbywa.
> W poważnych międzynarodowych firmach technologicznych.

Nota bene, niektóre duże firmy nawet całkiem otwarcie chwalą się jakością kodu, którą uzyskali dzięki użyciu C++ do swoich projektów:

https://www.youtube.com/watch?v=rHIkrotSwcc

On Saturday, February 1, 2020 at 1:04:30 PM UTC+1, Piotr Gałka wrote:
 
> Sugerujesz jakoby decyzje były głównie na zasadzie 'przyzwyczajenie'.
> Ja to widzę inaczej.
> Prawie przy każdym kolejnym projekcie zastanawiamy się, czy stać nas 
> przy tej okazji na skok technologiczny, co spowoduje opóźnienie go 
> szacunkowo o pół roku. 

Ja to powyżej w swoich kilku wypowiedziach nazwałem, może trochę 
błędnie, kosztem szkolenia.

> Nasze doświadczenie nam mówi, że jak się nam 
> wydaje, że coś nam zajmie t to zazwyczaj zajmuje 3t.

3t przy skoku technologicznym to raczej bardzo optymistyczny scenariusz, 3t
i 5t w inżynierii oprogramowania zdarza się przy znanej technologii.


> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na 
> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy 
> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż 
> znajdziemy na to czas.

A jakby kogoś zatrudnić, albo wynająć z zewnętrznej firmy, kto ma wyczucie
kompilatora C++ i mniej/więcej wie jak zaimplementować, albo jakie 
eksperymenty przeprowadzić, aby uzyskać dany efekt? W niektórych firmach
odpowiadali mi, że głównym problemem jest ryzyko z wdrażania nowej osoby. Co u
Was uniemożliwia zwerbowanie dodatkowych mocy przerobowych - jeśli mogę spytać?

Pozdrawiam

W dniu 2020-01-31 o 20:33, heby pisze:
> On 31/01/2020 08:35, Tomasz Kaczanowski wrote:
>>> Przypomnij mi który obecnie używany i popularny kompilator C/C++ 
>>> generuje kod w asemblerze wprost z C/C++ bez warstwy pośredniej?
>> a co to ma do rzeczy, jeśli musisz przystosować bibliotekę standardową 
>> do specyfiki nowego systemu?
> 
> A co to ma do rzeczy kiedy ta bibliteka wymaga przystosowania do 
> pozostałym dziesiątek języków programowania gdzie C++ jest tylko jednym 
> z wielu frontendów? I w dodatku w 95% ta bibliteka składa się z wywołań 
> C wiec musisz ją i tam napisać jeśli chcesz C.
> 
> Bibliteki std w C++ są w postaci kodu źródłowego i poza poprawą bugów i 
> zdefiniowaniem ile ma size_t wiele pracy nie wymagają.

Powiem tak, nie wiem, nie ja przystosowywałem kompilatory, a pracowałem 
kilka lat temu przy tym. O ile kompilator C dało się zrobić bardzo 
szybko, to kompilator C++ (trochę tez przez brak czasu osoby tym się 
zajmującej, ale i powstające problemy, bo jednak kod wynikowy był z 
niewiadomych przyczyn niestabilny, możliwe że chodziło o zarządzanie 
pamięcią, nie wiem, nie zajmowałem się tym, mogę stwierdzić tylko na 
podstawie tego, że jednak nie było to ot pstryknięcie palcami) powstał 
jak odchodziłem z firmy i był wciąż eksperymentalny i tylko uzywany do 
testów, ze względu właśnie na brak stabilności kodów wynikowych.

Więc jak to jest takie pstryknięcie palcami to fajnie, pewnie na wielu 
platformach tak jest, przynajmniej tych popularnych, ale nie zawsze z 
takich się korzysta i tu koszt jest dużo wyższy.

-- 
http://kaczus.ppa.pl

W dniu 2020-02-02 o 00:00, M.M. pisze:

>> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na
>> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
>> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy
>> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż
>> znajdziemy na to czas.
> 
> A jakby kogoś zatrudnić, albo wynająć z zewnętrznej firmy, kto ma wyczucie
> kompilatora C++

Chyba nie zdajesz sobie sprawy ile to by było komplikacji na wstępie i 
później jakby trzeba było coś w tym poprawić.

C++ uczyłem się w 92 z ksera oryginału książki Stroustrupa. Jak w 93 
ukazało się polskie tłumaczenie przeczytałem jeszcze raz.
Na tej podstawie napisałem w C++ makro assembler'51 i coś mnie podkusiło 
(ambicja), że koniecznie muszę go przerobić na jednoprzebiegowy (nie 
załapałem, że to miało sens gdy źródło było na tasiemce perforowanej a 
gdy źródło jest na HDD to co za problem przeczytać kod jeszcze raz). 
Konieczność przechowania różnych danych do drugiego przebiegu zjadała 
pamięć i natknąłem się na problemy przy dłuższych źródłach (PC miał 640k 
RAMu). Przeciążenie operatora new pozwoliło mi wydłużyć assemblowane 
źródło 2x.
Dopóki używaliśmy 51-ki brat korzystał wyłącznie z mojego assemblera bo 
inne się wykładały na wyliczeniach danych do ustawiania UARTa z 
częstotliwości zastosowanego kwarca (liczyły na 16 bitach a ja na 32).

Uważam, że mam wyczucie C++ (w wersji z tamtych czasów), ale 
programowaniem zajmuję się tydzień/dwa w roku więc ... nie nadążam za 
nowymi standardami. Poza tym używam nadal głównie C++ Buildera 5 (on też 
nie nadąża :) ).
Mam też Buildera 2010. Pewnie bym się przeniósł gdyby nie jego fjuczer - 
tylko raz daje się uruchomić po jednym resecie komputera. Znalazłem w 
sieci jakieś obejścia do tego, ale nie miałem wystarczającej presji aby 
je wdrażać.

W związku z treścią dyskusji właśnie przeszukałem wszystkie moje *.h w 
poszukiwaniu void* i wyskoczył mi tylko ten mój assembler z 1996r. 
Pewnie przeciążenie operatora new tego wymagało.

Nigdy nie nauczyłem się korzystać z zewnętrznych bibliotek.
AES, CMAC, HMAC, SHA napisałem sobie sam (w C++).
Moje źródło zawierające:
- CRC32,
- AES128,
- AES256,
- szyfrowanie tymi AES w trybie CTR (counter),
- CMAC,
- SHA256,
to jedynie 87 linijek h i 268 liniej cpp (ale może nie być przenoszalne 
do środowiska o odwrotnym ułożeniu bajtów, choć nie jestem tego pewien).
Jakby ktoś chciał mogę zapodać.

> i mniej/więcej wie jak zaimplementować, albo jakie
> eksperymenty przeprowadzić, aby uzyskać dany efekt?

Każdy nasz program wymaga ciągłego rozwoju, a czasem natychmiastowej 
interwencji (zdarzało nam się siedzieć w pracy do 4-ej rano).
Musiałby to być ktoś na stałe i o takiej samej dyspozycyjności jak my.

> W niektórych firmach
> odpowiadali mi, że głównym problemem jest ryzyko z wdrażania nowej osoby.

Ryzyko i czas, czas, czas.

> Co u Was uniemożliwia zwerbowanie dodatkowych mocy przerobowych - jeśli mogę spytać?

Dzień wolności podatkowej, który w Polsce przypada pod koniec czerwca, a 
w USA w połowie kwietnia. To jest czynnik, który tam pozwala małym 
firmom się rozwijać, a u nas je zabija.

Poza tym nie jesteśmy pełną gębą biznesmenami i bycie człowiekiem 
stawiamy wyżej od rachunku ekonomicznego (pracownikom od montażu zawsze 
płaciliśmy bliżej średniej niż minimalnej).
Kryzys 2008 dopadł nas w 2010 (i trzymał do 2015). Biorąc kolejne 
kredyty udało nam się nie zwolnić żadnego pracownika choć nie mieliśmy 
dla nich roboty. Jeszcze się nie wygrzebaliśmy, a tu już się szykuje 
kolejny kryzys :(

Poza tym.
Nasze dotychczasowe kontakty z firmami ściśle softwareowymi każą nam 
przyjmować, że większość programistów nie umie myśleć o ograniczeniach 
sprzętu.

Przykład z ostatniego miesiąca.
Brat coś grzebie w kontrolerze korzystając po stronie PC z 
oprogramowania jednej z takich firm. Coś zmienia w ustawieniu kart i 
klika jakiś przycisk w stylu "Uaktualnij dane w kontrolerze". W 
kontrolerze ma 5 kart więc uaktualnienie to powinny być jakieś ms więc 
od razu sprawdza, czy działa - nie działa to klika jeszcze raz i jeszcze 
raz. Na ekranie żadnej informacji, że trwa jakiś proces więc wydaje się, 
że program uważa, że zrobił co trzeba. Przyczyną nie było to co napiszę 
dalej ale przy okazji prześledzenie komunikacji ujawniło, że oni w 
takiej sytuacji zamiast wysłać 2 rozkazy:
- wpisz te 5 kart,
- wykasuj karty od 6 do 32000.
robią:
- usuń kartę 1,
- wpisz kartę 1,
....
-usuń kartę 32000,
-wpisz puste dane dla karty 32000.
I kolejne naciśnięcia klawisza wstawiały w kolejkę kolejne takie procesy.

To jakaś kpina.
Rozkaz wpisz karty, gdy dane są zgodne z zawartością nie zużywa flasha 
bo najpierw jest sprawdzane, czy dane są zgodne.
Rozkaz wpisujący wszystkie karty danej strony wymaga tylko jednokrotnego 
jej przeprogramowania.
Ale rozkaz skasuj kartę (która jest) wymaga przeprogramowania strony 
flash. Potem wpisanie tych samych danych w to samo miejsce - znów.
Nie wiem ile kart jest na stronie, ale jeśli np 30 to taka procedura 
powoduje konieczność 60 krotnego przeprogramowania flash (zamiast 
średnio 0.5 raza (0 lub 1 raz)).
Kontroler, który załóżmy powinien przeżyć 30 lat, zużyje się 120 razy 
szybciej - czyli po 3 miesiącach.
Gdybym nie wiedział, że głupota pomyślałbym, że sabotaż.

Pomysł 'my robimy hardware' firma softwareowa robi oprogramowanie na PC 
(bo zrobi to na pewno lepiej od nas) mieliśmy w okolicy +- 1997. 
Przepytaliśmy pod tym kątem wszystkie firmy softwareowe na Infosystemie 
- absolutne zero zainteresowania. Nie chcieli bawić się z hardware. 
Pisali wtedy programy typu kosztorysowanie budowlanki, czy zarządzanie 
aptekami - więc pomysł upadł.

W okolicy 2014 zgłosiło się da nas kilka firm softwareowych, że chcieli 
by mieć sprzętową kontrolę dostępu, rejestrację czasu pracy, czy podobne 
zagadnienia dobrze zintegrowane z ich oprogramowaniem.
Opracowaliśmy więc system pod takim kontem.
Współpracę utrudnia to, że o komunikacji rozmawiamy innymi językami :)
Oni mają problem się dostosować do nas, a my nie jesteśmy w stanie się 
dostosować do nich.

A to, że jesteśmy nadal w Xmega a nie w jakimś linuxie to ....
Firma przeprowadzająca audyt bezpieczeństwa nie była w stanie w żaden 
sposób się wpiąć w naszego RS485, czy dobrać do komunikacji z serwerem. 
Jedyne co zasugerowali to zablokowanie strony www kontrolera po 
instalacji bo np. ataki przez przepełnienie bufora.
Odpisaliśmy, że z tego co wiemy to taki atak może być skuteczny tylko, 
gdy program jest wykonywany z RAMu - więc nie u nas. Nie wiem, czy 
blokujemy to www, czy nie - to brat pisze.
P.G.

W dniu poniedziałek, 3 lutego 2020 12:58:37 UTC+1 użytkownik Piotr Gałka napisał:
> W dniu 2020-02-02 o 00:00, M.M. pisze:
> 
> >> No i dotychczas zawsze było, że oprócz tego mamy do zrobienia 'na
> >> wczoraj' jeszcze kilka rzeczy i na pewno teraz nie możemy opóźniać.
> >> Takich zaplanowanych, różnych skoków technologicznych do wykonania mamy
> >> jeszcze kilka. Do niektórych powstał nawet hardware i czeka od 4 lat aż
> >> znajdziemy na to czas.
> > 
> > A jakby kogoś zatrudnić, albo wynająć z zewnętrznej firmy, kto ma wyczucie
> > kompilatora C++
> 
> Chyba nie zdajesz sobie sprawy ile to by było komplikacji na wstępie i 
> później jakby trzeba było coś w tym poprawić.
> 
> C++ uczyłem się w 92 z ksera oryginału książki Stroustrupa. Jak w 93 
> ukazało się polskie tłumaczenie przeczytałem jeszcze raz.
> Na tej podstawie napisałem w C++ makro assembler'51 i coś mnie podkusiło 
> (ambicja), że koniecznie muszę go przerobić na jednoprzebiegowy (nie 
> załapałem, że to miało sens gdy źródło było na tasiemce perforowanej a 
> gdy źródło jest na HDD to co za problem przeczytać kod jeszcze raz). 
> Konieczność przechowania różnych danych do drugiego przebiegu zjadała 
> pamięć i natknąłem się na problemy przy dłuższych źródłach (PC miał 640k 
> RAMu). Przeciążenie operatora new pozwoliło mi wydłużyć assemblowane 
> źródło 2x.
> Dopóki używaliśmy 51-ki brat korzystał wyłącznie z mojego assemblera bo 
> inne się wykładały na wyliczeniach danych do ustawiania UARTa z 
> częstotliwości zastosowanego kwarca (liczyły na 16 bitach a ja na 32).
> 
> Uważam, że mam wyczucie C++ (w wersji z tamtych czasów), ale 
> programowaniem zajmuję się tydzień/dwa w roku więc ... nie nadążam za 
> nowymi standardami. Poza tym używam nadal głównie C++ Buildera 5 (on też 
> nie nadąża :) ).
> Mam też Buildera 2010. Pewnie bym się przeniósł gdyby nie jego fjuczer - 
> tylko raz daje się uruchomić po jednym resecie komputera. Znalazłem w 
> sieci jakieś obejścia do tego, ale nie miałem wystarczającej presji aby 
> je wdrażać.
> 
> W związku z treścią dyskusji właśnie przeszukałem wszystkie moje *.h w 
> poszukiwaniu void* i wyskoczył mi tylko ten mój assembler z 1996r. 
> Pewnie przeciążenie operatora new tego wymagało.
> 
> Nigdy nie nauczyłem się korzystać z zewnętrznych bibliotek.
> AES, CMAC, HMAC, SHA napisałem sobie sam (w C++).
> Moje źródło zawierające:
> - CRC32,
> - AES128,
> - AES256,
> - szyfrowanie tymi AES w trybie CTR (counter),
> - CMAC,
> - SHA256,
> to jedynie 87 linijek h i 268 liniej cpp (ale może nie być przenoszalne 
> do środowiska o odwrotnym ułożeniu bajtów, choć nie jestem tego pewien).
> Jakby ktoś chciał mogę zapodać.
> 
> > i mniej/więcej wie jak zaimplementować, albo jakie
> > eksperymenty przeprowadzić, aby uzyskać dany efekt?
> 
> Każdy nasz program wymaga ciągłego rozwoju, a czasem natychmiastowej 
> interwencji (zdarzało nam się siedzieć w pracy do 4-ej rano).
> Musiałby to być ktoś na stałe i o takiej samej dyspozycyjności jak my.
> 
> > W niektórych firmach
> > odpowiadali mi, że głównym problemem jest ryzyko z wdrażania nowej osoby.
> 
> Ryzyko i czas, czas, czas.
> 
> > Co u Was uniemożliwia zwerbowanie dodatkowych mocy przerobowych - jeśli mogę spytać?
> 
> Dzień wolności podatkowej, który w Polsce przypada pod koniec czerwca, a 
> w USA w połowie kwietnia. To jest czynnik, który tam pozwala małym 
> firmom się rozwijać, a u nas je zabija.
> 
> Poza tym nie jesteśmy pełną gębą biznesmenami i bycie człowiekiem 
> stawiamy wyżej od rachunku ekonomicznego (pracownikom od montażu zawsze 
> płaciliśmy bliżej średniej niż minimalnej).
> Kryzys 2008 dopadł nas w 2010 (i trzymał do 2015). Biorąc kolejne 
> kredyty udało nam się nie zwolnić żadnego pracownika choć nie mieliśmy 
> dla nich roboty. Jeszcze się nie wygrzebaliśmy, a tu już się szykuje 
> kolejny kryzys :(
> 
> Poza tym.
> Nasze dotychczasowe kontakty z firmami ściśle softwareowymi każą nam 
> przyjmować, że większość programistów nie umie myśleć o ograniczeniach 
> sprzętu.
> 
> Przykład z ostatniego miesiąca.
> Brat coś grzebie w kontrolerze korzystając po stronie PC z 
> oprogramowania jednej z takich firm. Coś zmienia w ustawieniu kart i 
> klika jakiś przycisk w stylu "Uaktualnij dane w kontrolerze". W 
> kontrolerze ma 5 kart więc uaktualnienie to powinny być jakieś ms więc 
> od razu sprawdza, czy działa - nie działa to klika jeszcze raz i jeszcze 
> raz. Na ekranie żadnej informacji, że trwa jakiś proces więc wydaje się, 
> że program uważa, że zrobił co trzeba. Przyczyną nie było to co napiszę 
> dalej ale przy okazji prześledzenie komunikacji ujawniło, że oni w 
> takiej sytuacji zamiast wysłać 2 rozkazy:
> - wpisz te 5 kart,
> - wykasuj karty od 6 do 32000.
> robią:
> - usuń kartę 1,
> - wpisz kartę 1,
> ....
> -usuń kartę 32000,
> -wpisz puste dane dla karty 32000.
> I kolejne naciśnięcia klawisza wstawiały w kolejkę kolejne takie procesy.
> 
> To jakaś kpina.
> Rozkaz wpisz karty, gdy dane są zgodne z zawartością nie zużywa flasha 
> bo najpierw jest sprawdzane, czy dane są zgodne.
> Rozkaz wpisujący wszystkie karty danej strony wymaga tylko jednokrotnego 
> jej przeprogramowania.
> Ale rozkaz skasuj kartę (która jest) wymaga przeprogramowania strony 
> flash. Potem wpisanie tych samych danych w to samo miejsce - znów.
> Nie wiem ile kart jest na stronie, ale jeśli np 30 to taka procedura 
> powoduje konieczność 60 krotnego przeprogramowania flash (zamiast 
> średnio 0.5 raza (0 lub 1 raz)).
> Kontroler, który załóżmy powinien przeżyć 30 lat, zużyje się 120 razy 
> szybciej - czyli po 3 miesiącach.
> Gdybym nie wiedział, że głupota pomyślałbym, że sabotaż.
> 
> Pomysł 'my robimy hardware' firma softwareowa robi oprogramowanie na PC 
> (bo zrobi to na pewno lepiej od nas) mieliśmy w okolicy +- 1997. 
> Przepytaliśmy pod tym kątem wszystkie firmy softwareowe na Infosystemie 
> - absolutne zero zainteresowania. Nie chcieli bawić się z hardware. 
> Pisali wtedy programy typu kosztorysowanie budowlanki, czy zarządzanie 
> aptekami - więc pomysł upadł.
> 
> W okolicy 2014 zgłosiło się da nas kilka firm softwareowych, że chcieli 
> by mieć sprzętową kontrolę dostępu, rejestrację czasu pracy, czy podobne 
> zagadnienia dobrze zintegrowane z ich oprogramowaniem.
> Opracowaliśmy więc system pod takim kontem.
> Współpracę utrudnia to, że o komunikacji rozmawiamy innymi językami :)
> Oni mają problem się dostosować do nas, a my nie jesteśmy w stanie się 
> dostosować do nich.
> 
> A to, że jesteśmy nadal w Xmega a nie w jakimś linuxie to ....
> Firma przeprowadzająca audyt bezpieczeństwa nie była w stanie w żaden 
> sposób się wpiąć w naszego RS485, czy dobrać do komunikacji z serwerem. 
> Jedyne co zasugerowali to zablokowanie strony www kontrolera po 
> instalacji bo np. ataki przez przepełnienie bufora.
> Odpisaliśmy, że z tego co wiemy to taki atak może być skuteczny tylko, 
> gdy program jest wykonywany z RAMu - więc nie u nas. Nie wiem, czy 
> blokujemy to www, czy nie - to brat pisze.
> P.G.

to szkoda ze tak malo zarabiecie.. o ile dzis programistom placi sie przyzwoicie to wgladaloby ze i firmom powinno sie plaic przyzwoicie, wiec to troche chyab dziwi ze tak kiepsko w takim biznesie

W dniu 2020-02-03 o 16:49, (fir) pisze:
> 
> to szkoda ze tak malo zarabiecie.

Też tak myślę :)
Ale lubię robić to co robię.

Produkcja sprzętu to w pewnym sensie konkurowanie z chińczykami :(

> . o ile dzis programistom placi sie przyzwoicie to wgladaloby ze i firmom powinno sie plaic przyzwoicie, wiec to troche chyab dziwi ze tak kiepsko w takim biznesie

Bo trzeba być firmą z kapitałem i prowadzić bezwzględnie biznes i to w 
dużej skali.
A my 'kapitał zakładowy' gromadziliśmy z naszych pensji wynoszących 
rzędu 13$ :(.

Gdyby Dzień Wolności Podatkowej był ze 2 miesiące wcześniej to przez te 
30 lat moglibyśmy się rozwinąć, a tak to ..... piiiip.
P.G.

On 03/02/2020 08:27, Tomasz Kaczanowski wrote:
> O ile kompilator C dało się zrobić bardzo 
> szybko, to kompilator C++ (trochę tez przez brak czasu osoby tym się 
> zajmującej, ale i powstające problemy, bo jednak kod wynikowy był z 
> niewiadomych przyczyn niestabilny

W wątku jest mowa o gcc w którym przystosowanie go do C++ zajmuje prawie 
tyle samo czasu co do C. Z grubsza róznica jest w tym że muisz napisać 
unwind stosu. Resztą zajmuje się frontend kompiatora którego nie 
zmieniasz oraz bibliteki które są w postaci kodu źrodłowego.

>, możliwe że chodziło o zarządzanie 
> pamięcią,

Niczym się nie rózni w C++, pod spodem jest zwykły malloc/free 
owrapowany new/delete.

> nie wiem, nie zajmowałem się tym, mogę stwierdzić tylko na 
> podstawie tego, że jednak nie było to ot pstryknięcie palcami) powstał 
> jak odchodziłem z firmy i był wciąż eksperymentalny i tylko uzywany do 
> testów, ze względu właśnie na brak stabilności kodów wynikowych.

Ponieważ ktoś wziął kiepski kompilator C++ i starał się go przystosować 
do innej architektury. Trudno to doświadczenie generalizować na clang 
albo gcc. Tak, są kiepskie kompilatory, tak są powszechnie używane w 
świecie embedded, tak świat embedded to zbiór absurdów.

Setki sukcesów w tej dziedzinie wśród pryszczatych nastolatków 
odpalających gcc/g++ na wszystkim co jest turing complete pokazuje że to 
kosztuje tyle samo co C.

> Więc jak to jest takie pstryknięcie palcami to fajnie, pewnie na wielu 
> platformach tak jest, przynajmniej tych popularnych, ale nie zawsze z 
> takich się korzysta i tu koszt jest dużo wyższy.

Koszt, dla g++, jest taki sam jak dla samego gcc i jak zarobisz jeden to 
drugi masz za darmo.

> W dniu 2020-01-29 o 18:24, heby pisze:
> > On 29/01/2020 13:58, M.M. wrote:
> >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> >> C++
> > 
> > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > rozsądną.

Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:

https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde

W dniu poniedziałek, 10 lutego 2020 13:47:35 UTC+1 użytkownik Maciek Godek napisał:
> > W dniu 2020-01-29 o 18:24, heby pisze:
> > > On 29/01/2020 13:58, M.M. wrote:
> > >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> > >> C++
> > > 
> > > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > > rozsądną.
> 
> Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:
> 
> https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde

moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w prawdziwym programowaniu czyli chyba cos z nim jest nie tak

aczkolwiek dodam jednak ze smieszna est ta sprawa z void*, ja programujac w c 20 lat (co prawda powiedzmy z 5-7 latami przerwy) void* uzylem mzoe raz i to tylko dla eksperymentu (moze przez to ze kompiluje swoje c czesto kompilatorejm c++ zeby moc uzyc const int tab_max) kraszow zwiazanych z pointerami mialem kilka (na przestrzeni 20 lat, i to glownie w rzeciagu 3 dni z 2 late temu
gdy pisalem biblioteke opartą na pointerach..poza tym przypadkiem krasze w c mialem jeden raz na 2 lata jeden na 5 lat, mw z czestotliwoscia spotkania krasnoludka w lesie ) czyli generalnie kraszy w c nie uswiadczam - tymczasem jak przesiadlem sie na moment na c++ z jego wskaznikami na inne obiekty trzymanymi jako pola kraszy sie wyroilo ze hej, jak robactwa po zimie ;C) - dlatego ta argumentacje kompletnych matolkow o void*  wydaje mi sie wyjatkowo komiczna w tym respekcie ;c

W dniu poniedziałek, 10 lutego 2020 16:00:33 UTC+1 użytkownik (fir) napisał:
> W dniu poniedziałek, 10 lutego 2020 13:47:35 UTC+1 użytkownik Maciek Godek napisał:
> > > W dniu 2020-01-29 o 18:24, heby pisze:
> > > > On 29/01/2020 13:58, M.M. wrote:
> > > >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> > > >> C++
> > > > 
> > > > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > > > rozsądną.
> > 
> > Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:
> > 
> > https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde
> 
> moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> 
> aczkolwiek dodam jednak ze smieszna est ta sprawa z void*, ja programujac w c 20 lat (co prawda powiedzmy z 5-7 latami przerwy) void* uzylem mzoe raz i to tylko dla eksperymentu (moze przez to ze kompiluje swoje c czesto kompilatorejm c++ zeby moc uzyc const int tab_max) kraszow zwiazanych z pointerami mialem kilka (na przestrzeni 20 lat, i to glownie w rzeciagu 3 dni z 2 late temu
> gdy pisalem biblioteke opartą na pointerach..poza tym przypadkiem krasze w c mialem jeden raz na 2 lata jeden na 5 lat, mw z czestotliwoscia spotkania krasnoludka w lesie ) czyli generalnie kraszy w c nie uswiadczam - tymczasem jak przesiadlem sie na moment na c++ z jego wskaznikami na inne obiekty trzymanymi jako pola kraszy sie wyroilo ze hej, jak robactwa po zimie ;C) - dlatego ta argumentacje kompletnych matolkow o void*  wydaje mi sie wyjatkowo komiczna w tym respekcie ;c

ew inna czesc argumentaci przeciw c przez uzytkowanikow c++ moze wynikac z tego ze ci ludzi nie potrafia/nie wiedza jak sie porzadnie pisze w c (tak jak mm, user ktory prawdopodobnie jest w miare porzadnym koderem ale chyba cos nie bardzo wie jak sie pisze w c - mm szanuje za umiejetnosc odnalezenia sie w warunkach pracy w firmie, bo to ciezka sztuka, ja dla przykladu, mimo ze mam swiadomsoc ze jestem dosyc utalentowanym koderem w c, przynajmiej jak na dzis, jestem totalnym freelnacerem w tym sensie ze zawsze mialem ogromna trudnosc odnalezenia sie w dalekich od optymalnych warunkach klepania kodu w firmach, b to niestety zawsze dla mnie bylo odzielna kwestia zagadnienia (a wine za to zrzucilbym jednak za firmy ktore potrafia uczynic te warunki kodowania dosyc absurdalnymi.. choc oczywiscie i na mnie spada czaes odpowiedzialnosci za slabe odnajdywanie sie w niektorych srodowiskach przez kwiestie programowania 'będąc noobem' (kiedys bo na dzis to juz nieco inna sprawa) - z tym ze gdyby firmy nie zatrudnialy noobow to by mialy pewnie z 1/3 albo i mnie programistow, z kolei jeslis ie jednak ich zatrudnia to trzabby nimi umiec zarzadzac..ale jak mowie to akurat inna kwestia )

W dniu poniedziałek, 10 lutego 2020 16:18:56 UTC+1 użytkownik (fir) napisał:
> W dniu poniedziałek, 10 lutego 2020 16:00:33 UTC+1 użytkownik (fir) napisał:
> > W dniu poniedziałek, 10 lutego 2020 13:47:35 UTC+1 użytkownik Maciek Godek napisał:
> > > > W dniu 2020-01-29 o 18:24, heby pisze:
> > > > > On 29/01/2020 13:58, M.M. wrote:
> > > > >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> > > > >> C++
> > > > > 
> > > > > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > > > > rozsądną.
> > > 
> > > Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:
> > > 
> > > https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde
> > 
> > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > 
> > aczkolwiek dodam jednak ze smieszna est ta sprawa z void*, ja programujac w c 20 lat (co prawda powiedzmy z 5-7 latami przerwy) void* uzylem mzoe raz i to tylko dla eksperymentu (moze przez to ze kompiluje swoje c czesto kompilatorejm c++ zeby moc uzyc const int tab_max) kraszow zwiazanych z pointerami mialem kilka (na przestrzeni 20 lat, i to glownie w rzeciagu 3 dni z 2 late temu
> > gdy pisalem biblioteke opartą na pointerach..poza tym przypadkiem krasze w c mialem jeden raz na 2 lata jeden na 5 lat, mw z czestotliwoscia spotkania krasnoludka w lesie ) czyli generalnie kraszy w c nie uswiadczam - tymczasem jak przesiadlem sie na moment na c++ z jego wskaznikami na inne obiekty trzymanymi jako pola kraszy sie wyroilo ze hej, jak robactwa po zimie ;C) - dlatego ta argumentacje kompletnych matolkow o void*  wydaje mi sie wyjatkowo komiczna w tym respekcie ;c
> 
> ew inna czesc argumentaci przeciw c przez uzytkowanikow c++ moze wynikac z tego ze ci ludzi nie potrafia/nie wiedza jak sie porzadnie pisze w c (tak jak mm, user ktory prawdopodobnie jest w miare porzadnym koderem ale chyba cos nie bardzo wie jak sie pisze w c - mm szanuje za umiejetnosc odnalezenia sie w warunkach pracy w firmie, bo to ciezka sztuka, ja dla przykladu, mimo ze mam swiadomsoc ze jestem dosyc utalentowanym koderem w c, przynajmiej jak na dzis, jestem totalnym freelnacerem w tym sensie ze zawsze mialem ogromna trudnosc odnalezenia sie w dalekich od optymalnych warunkach klepania kodu w firmach, b to niestety zawsze dla mnie bylo odzielna kwestia zagadnienia (a wine za to zrzucilbym jednak za firmy ktore potrafia uczynic te warunki kodowania dosyc absurdalnymi.. choc oczywiscie i na mnie spada czaes odpowiedzialnosci za slabe odnajdywanie sie w niektorych srodowiskach przez kwiestie programowania 'będąc noobem' (kiedys bo na dzis to juz nieco inna sprawa) - z tym ze gdyby firmy nie zatrudnialy noobow to by mialy pewnie z 1/3 albo i mnie programistow, z kolei jeslis ie jednak ich zatrudnia to trzabby nimi umiec zarzadzac..ale jak mowie to akurat inna kwestia )

tak czy owak porownywanie szybkosci c i c++ nie ma za wiale sensu (przynajmniej w pewnym sensie)..sporo zalezy od bibliotek i do jakiego podsystemu sie apka laczy, czyli szybkosc mozna powiedziec nie zalezy od jezyka co bardziej od binarki i to nie tylko wlasnej ale tej uzywanej, co jest dosyc banalnym stwierdzeniem ale mw poprostu chyba znaczyz eby zwracac na to uwage

sam ostatnio zaczalem lekko uzywac c++ i nie ejstem na niegos pecjalnie ciety (zaczalem uzywac bo moja kolezanka emo w tym pisze i zcasem do niej dolaczam choc c++ mnie wpienia i jak wracam do c to mam wraznie o wiele wiekszej 'mocy' ;c

On Monday, February 10, 2020 at 4:00:33 PM UTC+1, (fir) wrote:
> W dniu poniedziałek, 10 lutego 2020 13:47:35 UTC+1 użytkownik Maciek Godek napisał:
> > > W dniu 2020-01-29 o 18:24, heby pisze:
> > > > On 29/01/2020 13:58, M.M. wrote:
> > > >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> > > >> C++
> > > > 
> > > > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > > > rozsądną.
> > 
> > Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:
> > 
> > https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde
> 
> moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> prawdziwym programowaniu czyli chyba cos z nim jest nie tak

Nie tylko, czasami można było się też czegoś nauczyć.


> 
> aczkolwiek dodam jednak ze smieszna est ta sprawa z void*, ja programujac w c 20 lat (co prawda powiedzmy z 5-7 latami przerwy) void* uzylem mzoe raz i to tylko dla eksperymentu (moze przez to ze kompiluje swoje c czesto kompilatorejm c++ zeby moc uzyc const int tab_max) kraszow zwiazanych z pointerami mialem kilka (na przestrzeni 20 lat, i to glownie w rzeciagu 3 dni z 2 late temu
> gdy pisalem biblioteke opartą na pointerach..poza tym przypadkiem krasze w c mialem jeden raz na 2 lata jeden na 5 lat, mw z czestotliwoscia spotkania krasnoludka w lesie ) czyli generalnie kraszy w c nie uswiadczam - tymczasem jak przesiadlem sie na moment na c++ z jego wskaznikami na inne obiekty trzymanymi jako pola kraszy sie wyroilo ze hej, jak robactwa po zimie ;C) - dlatego ta argumentacje kompletnych matolkow o void*  wydaje mi sie wyjatkowo komiczna w tym respekcie ;c

Krasz kraszowi nierówny.

Pozdrawiam

On Tuesday, February 11, 2020 at 2:58:07 PM UTC+1, (fir) wrote:
> W dniu poniedziałek, 10 lutego 2020 16:18:56 UTC+1 użytkownik (fir) napisał:
> > W dniu poniedziałek, 10 lutego 2020 16:00:33 UTC+1 użytkownik (fir) napisał:
> > > W dniu poniedziałek, 10 lutego 2020 13:47:35 UTC+1 użytkownik Maciek Godek napisał:
> > > > > W dniu 2020-01-29 o 18:24, heby pisze:
> > > > > > On 29/01/2020 13:58, M.M. wrote:
> > > > > >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie 
> > > > > >> C++
> > > > > > 
> > > > > > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną 
> > > > > > rozsądną.
> > > > 
> > > > Jeden gość z KC++ napisał ostatnio dość interesującą odpowiedź na ten temat:
> > > > 
> > > > https://www.quora.com/C-is-faster-and-more-portable-than-C-How-true-is-it/answer/David-Vandevoorde
> > > 
> > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > > 
> > > aczkolwiek dodam jednak ze smieszna est ta sprawa z void*, ja programujac w c 20 lat (co prawda powiedzmy z 5-7 latami przerwy) void* uzylem mzoe raz i to tylko dla eksperymentu (moze przez to ze kompiluje swoje c czesto kompilatorejm c++ zeby moc uzyc const int tab_max) kraszow zwiazanych z pointerami mialem kilka (na przestrzeni 20 lat, i to glownie w rzeciagu 3 dni z 2 late temu
> > > gdy pisalem biblioteke opartą na pointerach..poza tym przypadkiem krasze w c mialem jeden raz na 2 lata jeden na 5 lat, mw z czestotliwoscia spotkania krasnoludka w lesie ) czyli generalnie kraszy w c nie uswiadczam - tymczasem jak przesiadlem sie na moment na c++ z jego wskaznikami na inne obiekty trzymanymi jako pola kraszy sie wyroilo ze hej, jak robactwa po zimie ;C) - dlatego ta argumentacje kompletnych matolkow o void*  wydaje mi sie wyjatkowo komiczna w tym respekcie ;c
> > 
> > ew inna czesc argumentaci przeciw c przez uzytkowanikow c++ moze wynikac z tego ze ci ludzi nie potrafia/nie wiedza jak sie porzadnie pisze w c (tak jak mm, user ktory prawdopodobnie jest w miare porzadnym koderem ale chyba cos nie bardzo wie jak sie pisze w c - mm szanuje za umiejetnosc odnalezenia sie w warunkach pracy w firmie, bo to ciezka sztuka, ja dla przykladu, mimo ze mam swiadomsoc ze jestem dosyc utalentowanym koderem w c, przynajmiej jak na dzis, jestem totalnym freelnacerem w tym sensie ze zawsze mialem ogromna trudnosc odnalezenia sie w dalekich od optymalnych warunkach klepania kodu w firmach, b to niestety zawsze dla mnie bylo odzielna kwestia zagadnienia (a wine za to zrzucilbym jednak za firmy ktore potrafia uczynic te warunki kodowania dosyc absurdalnymi.. choc oczywiscie i na mnie spada czaes odpowiedzialnosci za slabe odnajdywanie sie w niektorych srodowiskach przez kwiestie programowania 'będąc noobem' (kiedys bo na dzis to juz nieco inna sprawa) - z tym ze gdyby firmy nie zatrudnialy noobow to by mialy pewnie z 1/3 albo i mnie programistow, z kolei jeslis ie jednak ich zatrudnia to trzabby nimi umiec zarzadzac..ale jak mowie to akurat inna kwestia )
> 
> tak czy owak porownywanie szybkosci c i c++ nie ma za wiale sensu 

Szczególnie gdy C i C++ są kompilowane do identycznego kodu 
pośredniego ;-)


> (przynajmniej w pewnym sensie)..sporo zalezy od bibliotek i do jakiego podsystemu sie apka laczy, czyli szybkosc mozna powiedziec nie zalezy od jezyka co bardziej od binarki i to nie tylko wlasnej ale tej uzywanej, co jest dosyc banalnym stwierdzeniem ale mw poprostu chyba znaczyz eby zwracac na to uwage
> 
> sam ostatnio zaczalem lekko uzywac c++ i nie ejstem na niegos pecjalnie ciety (zaczalem uzywac bo moja kolezanka emo w tym pisze i zcasem do niej dolaczam choc c++ mnie wpienia i jak wracam do c to mam wraznie o wiele wiekszej 'mocy' ;c

I zależy od tego, co kiedyś baaaardzo mądrze napisał w jednej ze swoich
książek (nieżyjący już niestety) prof Bielecki, mianowicie, że jak uczył
ludzi programowania w np. javie, to widział ludzi jak programowali w 
javie w fortanie, w javie w c++, w javie w pascalu. Chodzi o to, że jeśli
decydujemy się na jakiś język programowania, to programujemy w tym języku 
na który się zdecydowaliśmy i zgodnie z tym, jak autorzy tegoż języka 
wyobrażali sobie że ludzie będą rozwiązywać dane problemy. Jeśli w
Javie programujesz w C++, a w C++ programujesz w C, to co w tym dziwnego, że
Java jest tak samo wydajna jak C++, a C++ tak samo wydajny jak C, zwłaszcza
jeśli zostanie wygenerowany (prawie) taki sam kod pośredni przed generowaniem
kodu asemblera? W C++ pisze się tworząc wiele małych klas, używając często
new, używając metod wirtualnych, wyjątków - a nie tylko szablonów aby
zoptymalizować kod. Optymalizacja to nawet swego rodzaju patologia, szczególnie
przedwczesna.

Pozdrawiam

W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > 
> > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> 
> Nie tylko, czasami można było się też czegoś nauczyć.
> 

raczej rzadko szczerze mowiac ;c

jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia bic piane ale sa to tematy na ktore sie odpowiada na jakims relatywnie wczesnym 
etapie rozwoju programistycznego wtajemniczenia a pozniej sie jedzie dalej i sie zajmuje innymi tematami, ja jak widze ludzi zajmujacych sie tymi samymi tematami relatywnych noobow przez 20 lat to mam wrazenie ze cos z nimi jest nietak, tj ze mimo zajmowanie sie tym dluga wyglada jakby eni calkiem opuscili noob sfere

tak jakby nie bylo w programowaniu dziesiatek naprawde waznych i ciekawych tematow ktorych nauczenie sie naprawde duzo da/spowoduje

(co prawda dzis akurat chyba jestem programowaniem przemeczony i niespecjalnie chce mi sie je poruszac.. trzeba sie wogole zastanowic co tu robic..

innego dni amoze jednak dam jakas mala liste ciekawszych problemow i tematow)

On Saturday, February 15, 2020 at 11:28:45 AM UTC+1, (fir) wrote:
> W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > > 
> > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > 
> > Nie tylko, czasami można było się też czegoś nauczyć.
> > 
> 
> raczej rzadko szczerze mowiac ;c
> 
> jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia 
> bic piane 

Co to jest bicie piany dla Ciebie, ja tego używasz?


> ale sa to tematy na ktore sie odpowiada na jakims relatywnie wczesnym 
> etapie rozwoju programistycznego wtajemniczenia 

Bo ja wiem... programowanie to trudna dziedzina. Nie wiem na co można sobie 
raz na całe życie odpowiedzieć? 

Jeden z moich ulubionych przykładów to historia (jaką raz kiedyś czytałem)
algorytmu sympleks. Napisano algorytm i opublikowano kod w periodyku. Wielu
wybitnych programistów uznało ten problem za rozwiązany. Tymczasem po wielu
latach okazało się że w algorytmie (który może ma 30 linijek) był błąd i nikt
tego błędu nie zauważył. Chyba że to nie jest temat o który 'lubi
się bić pianę'. Ale mnie właśnie fascynuje to, że jakiś drobiazg decyduje o 
jakości i przydatności danego ciągu instrukcji. Ludzie, nawet wybitni, poza
oklepanymi algorytmami, nie dostrzegają takich drobiazgów i ogólnie nawet po
intensywnych kilkudziesięciu latach rozwoju algorytmiki, nie wiadomo jak 
efektywnie rozwiązywać trudne zadania przy pomocy komputerów.


> a pozniej sie jedzie dalej i sie zajmuje innymi tematami, 

Np. jakimi tematami? Rozumiem że teraz piszesz o tych nie nadających się
na bicie piany.


> ja jak widze ludzi zajmujacych sie tymi samymi tematami relatywnych noobow 
> przez 20 lat to mam wrazenie ze cos z nimi jest nietak, tj ze mimo zajmowanie
> sie tym dluga wyglada jakby eni calkiem opuscili noob sfere

Nie wiem dlaczego długie zajmowanie się jedną tematyką źle świadczy o 
osobie. Ja nie mogę jedną się zajmować i czasami tego żałuję, nie mogę
się wyspecjalizować.

 
> tak jakby nie bylo w programowaniu dziesiatek naprawde waznych i 
> ciekawych tematow ktorych nauczenie sie naprawde duzo da/spowoduje

Ale slowa 'dużo' można używać tylko gdy się poda co mierzysz i jaką
miarą mierzysz. Nie wiem o czym piszesz, co mierzysz i w jaki sposób?


> (co prawda dzis akurat chyba jestem programowaniem przemeczony i 
> niespecjalnie chce mi sie je poruszac.. trzeba sie wogole zastanowic co 
> tu robic..

> 
> innego dni amoze jednak dam jakas mala liste ciekawszych problemow i tematow)

Zapodaj koniecznie.

Pozdrawiam

W dniu sobota, 15 lutego 2020 13:41:26 UTC+1 użytkownik M.M. napisał:
> On Saturday, February 15, 2020 at 11:28:45 AM UTC+1, (fir) wrote:
> > W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > > > 
> > > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > > > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > > > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > > > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > > 
> > > Nie tylko, czasami można było się też czegoś nauczyć.
> > > 
> > 
> > raczej rzadko szczerze mowiac ;c
> > 
> > jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia 
> > bic piane 
> 
> Co to jest bicie piany dla Ciebie, ja tego używasz?
> 

tutaj biciem piany nazywam wyklucanie sie na temat z ktorego malo co wynika (a nawet moze wyniknac) marytorycznie

(wtedy jest duzo pisana a malo pozytku, w kazdym razie merytorycznego, bo nikomu nie zabraniam bic piany o ile prowadzi to do czegos co wydaje mi sie mocno alternatywne ;c)


ogolenie mysle ze wielu ludzi niezbyt slusznie zaklada (sam kiedys popelnialem ten blad) ze robienie czekogolwiek w programowaniu daje realna korzysc (w zwiekszaniu wiedzy itd) tak naprawde jest masa o niebo lepszych tematow niz bicie piany czy c czy c++ jest szybsze albo czy optymalizowac czy nie

te lepsze tematy to jednak raczej te,maty konkretnych 'projektow' (rozniastych byle ciekawych) a z tym jest nieststy ten problem ze nei kazdy na forach siedzi w takim temacie zwlaszcza w danym czasie

stad tez nieststy fora wydaje sie byc lepsze na bicie piany w noobsferze niz 
pisnie postow o internalsach ciekawych projektow (so niby moglbym robic ic czasem troce robie ale wtedy mi pisza ze pisze bloga, i nieststy maja chyba troche racji (zalezy nieststy od tego czy jest ktos w stanie z sensem na to odpowiedziec a zwykle nikogo nie ma) totez takie pisanie nie zawsze ma sens)

co do tej noobsfery to mzoe jest troche niesprawiedliwe okreslenie, choc w czesci wydeje sie tez sluszne (o tyle niesprawiedliwe ze ja kiedys siedzac 10 lat w noobsferze (tym co teraz tak nazywam) czul;em sie generalnie madrzejszy i uwazniejszy logicznie niz teraz, klepiec kod bardziej jak dziki osiol ;c no ale cuz nie wiem jeszcze co z tego wyniknie, sporo sie poprostu zmienilo)



> 
> > ale sa to tematy na ktore sie odpowiada na jakims relatywnie wczesnym 
> > etapie rozwoju programistycznego wtajemniczenia 
> 
> Bo ja wiem... programowanie to trudna dziedzina. Nie wiem na co można sobie 
> raz na całe życie odpowiedzieć? 
> 
> Jeden z moich ulubionych przykładów to historia (jaką raz kiedyś czytałem)
> algorytmu sympleks. Napisano algorytm i opublikowano kod w periodyku. Wielu
> wybitnych programistów uznało ten problem za rozwiązany. Tymczasem po wielu
> latach okazało się że w algorytmie (który może ma 30 linijek) był błąd i nikt
> tego błędu nie zauważył. Chyba że to nie jest temat o który 'lubi
> się bić pianę'. Ale mnie właśnie fascynuje to, że jakiś drobiazg decyduje o 
> jakości i przydatności danego ciągu instrukcji. Ludzie, nawet wybitni, poza
> oklepanymi algorytmami, nie dostrzegają takich drobiazgów i ogólnie nawet po
> intensywnych kilkudziesięciu latach rozwoju algorytmiki, nie wiadomo jak 
> efektywnie rozwiązywać trudne zadania przy pomocy komputerów.
> 
> 
> > a pozniej sie jedzie dalej i sie zajmuje innymi tematami, 
> 
> Np. jakimi tematami? Rozumiem że teraz piszesz o tych nie nadających się
> na bicie piany.
> 
> 
> > ja jak widze ludzi zajmujacych sie tymi samymi tematami relatywnych noobow 
> > przez 20 lat to mam wrazenie ze cos z nimi jest nietak, tj ze mimo zajmowanie
> > sie tym dluga wyglada jakby eni calkiem opuscili noob sfere
> 
> Nie wiem dlaczego długie zajmowanie się jedną tematyką źle świadczy o 
> osobie. Ja nie mogę jedną się zajmować i czasami tego żałuję, nie mogę
> się wyspecjalizować.
> 
>  
> > tak jakby nie bylo w programowaniu dziesiatek naprawde waznych i 
> > ciekawych tematow ktorych nauczenie sie naprawde duzo da/spowoduje
> 
> Ale slowa 'dużo' można używać tylko gdy się poda co mierzysz i jaką
> miarą mierzysz. Nie wiem o czym piszesz, co mierzysz i w jaki sposób?
> 
> 
> > (co prawda dzis akurat chyba jestem programowaniem przemeczony i 
> > niespecjalnie chce mi sie je poruszac.. trzeba sie wogole zastanowic co 
> > tu robic..
> 
> > 
> > innego dni amoze jednak dam jakas mala liste ciekawszych problemow i tematow)
> 
> Zapodaj koniecznie.
> 
> Pozdrawiam

On Saturday, February 15, 2020 at 3:31:50 PM UTC+1, (fir) wrote:
> W dniu sobota, 15 lutego 2020 13:41:26 UTC+1 użytkownik M.M. napisał:
> > On Saturday, February 15, 2020 at 11:28:45 AM UTC+1, (fir) wrote:
> > > W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > > > > 
> > > > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > > > > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > > > > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > > > > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > > > 
> > > > Nie tylko, czasami można było się też czegoś nauczyć.
> > > > 
> > > 
> > > raczej rzadko szczerze mowiac ;c
> > > 
> > > jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia 
> > > bic piane 
> > 
> > Co to jest bicie piany dla Ciebie, ja tego używasz?
> > 
> 
> tutaj biciem piany nazywam wyklucanie sie na temat z ktorego 
> malo co wynika (a nawet moze wyniknac) marytorycznie

Tak, to dobra definicja, ale cóż, po sobie wiem, że za rzadko pytam o to, co
dobrego z danej rozmowy może wyniknąć, a rozmowy ciągną się nie wiadomo po co,
ani dlaczego.


> (wtedy jest duzo pisana a malo pozytku, w kazdym razie merytorycznego, bo
> nikomu nie zabraniam bic piany o ile prowadzi to do czegos co wydaje mi sie
> mocno alternatywne ;c)

To ja zapytam, jaki pożytek z rozmowy, która prowadzi do czegoś 
mocno alternatywnego?

 
> ogolenie mysle ze wielu ludzi niezbyt slusznie zaklada (sam kiedys
> popelnialem ten blad) ze robienie czekogolwiek w programowaniu daje realna
> korzysc (w zwiekszaniu wiedzy itd) tak naprawde jest masa o niebo lepszych
> tematow niz bicie piany czy c czy c++ jest szybsze albo czy optymalizowac 
> czy nie

Jeśli bicie piany to rozmowa z której nic dobrego nie wynika, to nawet z
definicji jest masa lepszych tematów :D

 
> te lepsze tematy to jednak raczej te,maty konkretnych 'projektow' 
> (rozniastych byle ciekawych) a z tym jest nieststy ten problem ze nei 
> kazdy na forach siedzi w takim temacie zwlaszcza w danym czasie

I nie każdy chce ujawniać szczegóły techniczne. Ostatnio padła masa naprawdę
baaaardzo ciekawych tematów na grupie AI, ale zazwyczaj do szczegółów 
techniczno-programistycznych w ogóle nie można było się dokopać, albo
(rzadziej) dokopanie wymagało czasochłonnego wgryzienia się w trudną
pracę naukową.

 
> stad tez nieststy fora wydaje sie byc lepsze na bicie piany w noobsferze niz 
> pisnie postow o internalsach ciekawych projektow (so niby moglbym robic ic 
> czasem troce robie ale wtedy mi pisza ze pisze bloga, i nieststy maja chyba
> troche racji (zalezy nieststy od tego czy jest ktos w stanie z sensem na to
> odpowiedziec a zwykle nikogo nie ma) totez takie pisanie nie zawsze ma sens)

Jeśli napiszesz na forum szczegóły programistyczne, to jest związanych z tym
kilka niebezpieczeństw. Po pierwsze Ty jesteś w chwili pisania na bieżąco ze
swoim problemem i dobrze go ogarniasz. Bardzo trudno jest napisać zwięzły post
który oddaje sens tego o czym myślisz, tak trudno, że może to być w ogóle
niemożliwe. Jeśli napiszesz rozwlekle, to nikomu nie będzie chciało się 
czytać, każdy ma ograniczone zasoby czasowe. Jeśli się w dodatku potkniesz w
trakcie pisania, obojętnie czy to będzie potknięcia językowe, czy techniczne,
to (niestety) znajdują się chętni o rozmowie na temat potknięcia, a nie o 
rzeczy samej - choć czasami przez takie potknięcie naprawdę traci się sens
wypowiedzi i wypowiedź, pomimo dobrych intencji interpretacyjnych, bywa 
niezrozumiała. 

Osobiście przeszkadza mi najbardziej inny problem w rozmawianiu na forum, 
mianowicie, konieczność utrzymywania w tajemnicy tego co najbardziej 
istotne.


> co do tej noobsfery to mzoe jest troche niesprawiedliwe okreslenie, choc w
> czesci wydeje sie tez sluszne (o tyle niesprawiedliwe ze ja kiedys siedzac 
> 10 lat w noobsferze (tym co teraz tak nazywam) czul;em sie generalnie
> madrzejszy i uwazniejszy logicznie niz teraz, klepiec kod bardziej jak dziki
> osiol ;c no ale cuz nie wiem jeszcze co z tego wyniknie, sporo sie poprostu 
> zmienilo)

Nie wiem co rozumiesz przez 'klepanie kodu jak dziki osioł', ale to ma też
swoje ogromne zalety, a może zalety biorą górę nad wadami?


Pozdrawiam

W dniu niedziela, 16 lutego 2020 16:22:51 UTC+1 użytkownik M.M. napisał:
> On Saturday, February 15, 2020 at 3:31:50 PM UTC+1, (fir) wrote:
> > W dniu sobota, 15 lutego 2020 13:41:26 UTC+1 użytkownik M.M. napisał:
> > > On Saturday, February 15, 2020 at 11:28:45 AM UTC+1, (fir) wrote:
> > > > W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > > > > > 
> > > > > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > > > > > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > > > > > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > > > > > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > > > > 
> > > > > Nie tylko, czasami można było się też czegoś nauczyć.
> > > > > 
> > > > 
> > > > raczej rzadko szczerze mowiac ;c
> > > > 
> > > > jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia 
> > > > bic piane 
> > > 
> > > Co to jest bicie piany dla Ciebie, ja tego używasz?
> > > 
> > 
> > tutaj biciem piany nazywam wyklucanie sie na temat z ktorego 
> > malo co wynika (a nawet moze wyniknac) marytorycznie
> 
> Tak, to dobra definicja, ale cóż, po sobie wiem, że za rzadko pytam o to, co
> dobrego z danej rozmowy może wyniknąć, a rozmowy ciągną się nie wiadomo po co,
> ani dlaczego.
> 
> 
> > (wtedy jest duzo pisana a malo pozytku, w kazdym razie merytorycznego, bo
> > nikomu nie zabraniam bic piany o ile prowadzi to do czegos co wydaje mi sie
> > mocno alternatywne ;c)
> 
> To ja zapytam, jaki pożytek z rozmowy, która prowadzi do czegoś 
> mocno alternatywnego?
> 
>  
> > ogolenie mysle ze wielu ludzi niezbyt slusznie zaklada (sam kiedys
> > popelnialem ten blad) ze robienie czekogolwiek w programowaniu daje realna
> > korzysc (w zwiekszaniu wiedzy itd) tak naprawde jest masa o niebo lepszych
> > tematow niz bicie piany czy c czy c++ jest szybsze albo czy optymalizowac 
> > czy nie
> 
> Jeśli bicie piany to rozmowa z której nic dobrego nie wynika, to nawet z
> definicji jest masa lepszych tematów :D
> 
>  
> > te lepsze tematy to jednak raczej te,maty konkretnych 'projektow' 
> > (rozniastych byle ciekawych) a z tym jest nieststy ten problem ze nei 
> > kazdy na forach siedzi w takim temacie zwlaszcza w danym czasie
> 
> I nie każdy chce ujawniać szczegóły techniczne. Ostatnio padła masa naprawdę
> baaaardzo ciekawych tematów na grupie AI, ale zazwyczaj do szczegółów 
> techniczno-programistycznych w ogóle nie można było się dokopać, albo
> (rzadziej) dokopanie wymagało czasochłonnego wgryzienia się w trudną
> pracę naukową.
> 
>  
> > stad tez nieststy fora wydaje sie byc lepsze na bicie piany w noobsferze niz 
> > pisnie postow o internalsach ciekawych projektow (so niby moglbym robic ic 
> > czasem troce robie ale wtedy mi pisza ze pisze bloga, i nieststy maja chyba
> > troche racji (zalezy nieststy od tego czy jest ktos w stanie z sensem na to
> > odpowiedziec a zwykle nikogo nie ma) totez takie pisanie nie zawsze ma sens)
> 
> Jeśli napiszesz na forum szczegóły programistyczne, to jest związanych z tym
> kilka niebezpieczeństw. Po pierwsze Ty jesteś w chwili pisania na bieżąco ze
> swoim problemem i dobrze go ogarniasz. Bardzo trudno jest napisać zwięzły post
> który oddaje sens tego o czym myślisz, tak trudno, że może to być w ogóle
> niemożliwe. Jeśli napiszesz rozwlekle, to nikomu nie będzie chciało się 
> czytać, każdy ma ograniczone zasoby czasowe. Jeśli się w dodatku potkniesz w
> trakcie pisania, obojętnie czy to będzie potknięcia językowe, czy techniczne,
> to (niestety) znajdują się chętni o rozmowie na temat potknięcia, a nie o 
> rzeczy samej - choć czasami przez takie potknięcie naprawdę traci się sens
> wypowiedzi i wypowiedź, pomimo dobrych intencji interpretacyjnych, bywa 
> niezrozumiała. 
> 
> Osobiście przeszkadza mi najbardziej inny problem w rozmawianiu na forum, 
> mianowicie, konieczność utrzymywania w tajemnicy tego co najbardziej 
> istotne.
> 
> 
> > co do tej noobsfery to mzoe jest troche niesprawiedliwe okreslenie, choc w
> > czesci wydeje sie tez sluszne (o tyle niesprawiedliwe ze ja kiedys siedzac 
> > 10 lat w noobsferze (tym co teraz tak nazywam) czul;em sie generalnie
> > madrzejszy i uwazniejszy logicznie niz teraz, klepiec kod bardziej jak dziki
> > osiol ;c no ale cuz nie wiem jeszcze co z tego wyniknie, sporo sie poprostu 
> > zmienilo)
> 
> Nie wiem co rozumiesz przez 'klepanie kodu jak dziki osioł', ale to ma też
> swoje ogromne zalety, a może zalety biorą górę nad wadami?
> 
> 
> Pozdrawiam

problem jest taki ze w swiecie dyskusji o programowaniu sa tematy ciekwe i nieciekawe (powiedzmy miliony cieciekawych i tysiace ciekawych) mam wraznie ze jak tkwilem w noobsferze to akceptowalem jedne i drugie a teraz szkoda mi czasu na nieciekawe (byc moze podobny problem mam z czytaniem bo z ksiazkami jest podobnie) (podobnie jest tez pewnie i z innymi rzeczami..coz zrobic)

On Sunday, February 16, 2020 at 6:25:26 PM UTC+1, (fir) wrote:
> W dniu niedziela, 16 lutego 2020 16:22:51 UTC+1 użytkownik M.M. napisał:
> > On Saturday, February 15, 2020 at 3:31:50 PM UTC+1, (fir) wrote:
> > > W dniu sobota, 15 lutego 2020 13:41:26 UTC+1 użytkownik M.M. napisał:
> > > > On Saturday, February 15, 2020 at 11:28:45 AM UTC+1, (fir) wrote:
> > > > > W dniu piątek, 14 lutego 2020 23:14:44 UTC+1 użytkownik M.M. napisał:
> > > > > > > 
> > > > > > > moja odpowiedz na dzis bylaby takze ze to nie to czy c czy c++ jest 
> > > > > > > szybsze jest istotna tylko to ciagle bicie piany o to jest glupie, 
> > > > > > > jesli komus sie chce bic o to piane to chyba nie ma nic do roboty w
> > > > > > > prawdziwym programowaniu czyli chyba cos z nim jest nie tak
> > > > > > 
> > > > > > Nie tylko, czasami można było się też czegoś nauczyć.
> > > > > > 
> > > > > 
> > > > > raczej rzadko szczerze mowiac ;c
> > > > > 
> > > > > jest kilka klasycznych tematow w programowaniu o ktore ludzie lubia 
> > > > > bic piane 
> > > > 
> > > > Co to jest bicie piany dla Ciebie, ja tego używasz?
> > > > 
> > > 
> > > tutaj biciem piany nazywam wyklucanie sie na temat z ktorego 
> > > malo co wynika (a nawet moze wyniknac) marytorycznie
> > 
> > Tak, to dobra definicja, ale cóż, po sobie wiem, że za rzadko pytam o to, co
> > dobrego z danej rozmowy może wyniknąć, a rozmowy ciągną się nie wiadomo po co,
> > ani dlaczego.
> > 
> > 
> > > (wtedy jest duzo pisana a malo pozytku, w kazdym razie merytorycznego, bo
> > > nikomu nie zabraniam bic piany o ile prowadzi to do czegos co wydaje mi sie
> > > mocno alternatywne ;c)
> > 
> > To ja zapytam, jaki pożytek z rozmowy, która prowadzi do czegoś 
> > mocno alternatywnego?
> > 
> >  
> > > ogolenie mysle ze wielu ludzi niezbyt slusznie zaklada (sam kiedys
> > > popelnialem ten blad) ze robienie czekogolwiek w programowaniu daje realna
> > > korzysc (w zwiekszaniu wiedzy itd) tak naprawde jest masa o niebo lepszych
> > > tematow niz bicie piany czy c czy c++ jest szybsze albo czy optymalizowac 
> > > czy nie
> > 
> > Jeśli bicie piany to rozmowa z której nic dobrego nie wynika, to nawet z
> > definicji jest masa lepszych tematów :D
> > 
> >  
> > > te lepsze tematy to jednak raczej te,maty konkretnych 'projektow' 
> > > (rozniastych byle ciekawych) a z tym jest nieststy ten problem ze nei 
> > > kazdy na forach siedzi w takim temacie zwlaszcza w danym czasie
> > 
> > I nie każdy chce ujawniać szczegóły techniczne. Ostatnio padła masa naprawdę
> > baaaardzo ciekawych tematów na grupie AI, ale zazwyczaj do szczegółów 
> > techniczno-programistycznych w ogóle nie można było się dokopać, albo
> > (rzadziej) dokopanie wymagało czasochłonnego wgryzienia się w trudną
> > pracę naukową.
> > 
> >  
> > > stad tez nieststy fora wydaje sie byc lepsze na bicie piany w noobsferze niz 
> > > pisnie postow o internalsach ciekawych projektow (so niby moglbym robic ic 
> > > czasem troce robie ale wtedy mi pisza ze pisze bloga, i nieststy maja chyba
> > > troche racji (zalezy nieststy od tego czy jest ktos w stanie z sensem na to
> > > odpowiedziec a zwykle nikogo nie ma) totez takie pisanie nie zawsze ma sens)
> > 
> > Jeśli napiszesz na forum szczegóły programistyczne, to jest związanych z tym
> > kilka niebezpieczeństw. Po pierwsze Ty jesteś w chwili pisania na bieżąco ze
> > swoim problemem i dobrze go ogarniasz. Bardzo trudno jest napisać zwięzły post
> > który oddaje sens tego o czym myślisz, tak trudno, że może to być w ogóle
> > niemożliwe. Jeśli napiszesz rozwlekle, to nikomu nie będzie chciało się 
> > czytać, każdy ma ograniczone zasoby czasowe. Jeśli się w dodatku potkniesz w
> > trakcie pisania, obojętnie czy to będzie potknięcia językowe, czy techniczne,
> > to (niestety) znajdują się chętni o rozmowie na temat potknięcia, a nie o 
> > rzeczy samej - choć czasami przez takie potknięcie naprawdę traci się sens
> > wypowiedzi i wypowiedź, pomimo dobrych intencji interpretacyjnych, bywa 
> > niezrozumiała. 
> > 
> > Osobiście przeszkadza mi najbardziej inny problem w rozmawianiu na forum, 
> > mianowicie, konieczność utrzymywania w tajemnicy tego co najbardziej 
> > istotne.
> > 
> > 
> > > co do tej noobsfery to mzoe jest troche niesprawiedliwe okreslenie, choc w
> > > czesci wydeje sie tez sluszne (o tyle niesprawiedliwe ze ja kiedys siedzac 
> > > 10 lat w noobsferze (tym co teraz tak nazywam) czul;em sie generalnie
> > > madrzejszy i uwazniejszy logicznie niz teraz, klepiec kod bardziej jak dziki
> > > osiol ;c no ale cuz nie wiem jeszcze co z tego wyniknie, sporo sie poprostu 
> > > zmienilo)
> > 
> > Nie wiem co rozumiesz przez 'klepanie kodu jak dziki osioł', ale to ma też
> > swoje ogromne zalety, a może zalety biorą górę nad wadami?
> > 
> > 
> > Pozdrawiam
> 
> problem jest taki ze w swiecie dyskusji o programowaniu sa tematy ciekwe i nieciekawe (powiedzmy miliony cieciekawych i tysiace ciekawych) mam wraznie ze jak tkwilem w noobsferze to akceptowalem jedne i drugie a teraz szkoda mi czasu na nieciekawe (byc moze podobny problem mam z czytaniem bo z ksiazkami jest podobnie) (podobnie jest tez pewnie i z innymi rzeczami..coz zrobic)

Nie rozumiem.

Pozdrawiam

On 2020-01-29 18:24, heby wrote:
> On 29/01/2020 13:58, M.M. wrote:
>> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie
>> C++
> 
> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną
> rozsądną.
Gdy kompilator C na daną platformę istnieje, a kompilator C++ nie
istnieje, wtedy lepiej jest użyć kompilatora C. :-) Ot, np. małe PIC-e.

On 04/03/2020 06:45, JDX wrote:
>> Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną
>> rozsądną.
> Gdy kompilator C na daną platformę istnieje, a kompilator C++ nie
> istnieje, wtedy lepiej jest użyć kompilatora C. :-) Ot, np. małe PIC-e.

Małe PICe mają wiele więcej wad niż brak C++, np brak normalnego stosu, 
dziwaczne długości słów w ROM, idiotyczne ograniczenia instrukcji itd 
itp które są kłopotliwe nawet w C. Dodatkowo Microchip miał alergię na 
wszystko co nowoczesne wiec nie dostarczyli kompilatora współczesnego a 
ten co dostarczyli było poniżająco badziewny [1]. Trudno nazwać to 
problemem braku C++, to raczej był problem projektowania odpierdzielania 
architektury na kolanie z ignorowaniem reszty wszechświata co 
uniemozliwiło stosowanie normalnych kompilatorów w zamian za to dostając 
pistolet na wodę o nazwie "kompialtor C do PICów".

[1] Używałem z pół roku, naście lat temu. Nigdy więcej PICów, dokładnie 
tak jak nigdy więcej 8051.

On Wednesday, March 4, 2020 at 6:45:15 AM UTC+1, JDX wrote:
> On 2020-01-29 18:24, heby wrote:
> > On 29/01/2020 13:58, M.M. wrote:
> >> No właśnie, są pewne okoliczności w których lepiej użyć C, albo użycie
> >> C++
> > 
> > Pokaż okoliczność kiedy lepiej użyć kompilator C zamiast C++. Dowolną
> > rozsądną.
> Gdy kompilator C na daną platformę istnieje, a kompilator C++ nie
> istnieje, wtedy lepiej jest użyć kompilatora C. :-) Ot, np. małe PIC-e.

Jak to jest obecnie z programowaniem wszelkiego rodzaju GPU? Z tego co
słyszałem, na początku też to był niepełny język C, a obecnie jak 
wygląda sprawa programowania w C++ na GPU?

Pozdrawiam

On 06/03/2020 13:36, M.M. wrote:
> jak wygląda sprawa programowania w C++ na GPU?

https://en.wikipedia.org/wiki/OpenCL#OpenCL_2.2

On 2020-03-06 09:33, heby wrote:
[...]
> ten co dostarczyli było poniżająco badziewny [1]. Trudno nazwać to
> problemem braku C++, to raczej był problem projektowania odpierdzielania
> architektury na kolanie z ignorowaniem reszty wszechświata co
> uniemozliwiło stosowanie normalnych kompilatorów w zamian za to dostając
> pistolet na wodę o nazwie "kompialtor C do PICów".
IMO to raczej problem drogiego (wówczas) krzemu. Poza tym, gdy powstawał
PIC, to C++ jeszcze nie było, a C był bardzo młody.

> [1] Używałem z pół roku, naście lat temu. Nigdy więcej PICów, dokładnie
> tak jak nigdy więcej 8051.
W porównaniu do współczesnych MCU to badziew jest, ale ciekawą rzeczą
jest to, że MCS48 (rówieśnik PIC) umarł dawno temu, MCS51 chyba już
umarł, a staruszek PIC ciągle żyje. :-)

Natomiast "dziwaczne" długości słów w ROM to nic dziwnego wśród MCU i
DSP opartych na (zmodyfikowanej) architekturze harwardzkiej.

On 08/03/2020 03:55, JDX wrote:
>> ten co dostarczyli było poniżająco badziewny [1]. Trudno nazwać to
>> problemem braku C++, to raczej był problem projektowania odpierdzielania
>> architektury na kolanie z ignorowaniem reszty wszechświata co
>> uniemozliwiło stosowanie normalnych kompilatorów w zamian za to dostając
>> pistolet na wodę o nazwie "kompialtor C do PICów".
> IMO to raczej problem drogiego (wówczas) krzemu. Poza tym, gdy powstawał
> PIC, to C++ jeszcze nie było, a C był bardzo młody.

Nie wiem czy drogiego krzemu, AVR nie ma takich problemów, krzemu 
potrzebują, o ile pamietam, podobną ilość.

PICe były projektowane przez assemblerowca. Stąd widoczne elementy kodu 
maszynowego charakterystyczne dla optymalizacji ręcznych jak choć ten 
nieszczęsny stos wyjęty wprost z otchłani absurdu.

Dlatego protestuje przed stawianiem PICa jako argumentu że "nie ma C++". 
Tam nawet porządnego i normalnego C nie ma bo to gówniany kawałek CPU z 
bardzo fajnymi peryferiami (odwrotnie jak w AVR).

>> [1] Używałem z pół roku, naście lat temu. Nigdy więcej PICów, dokładnie
>> tak jak nigdy więcej 8051.
> W porównaniu do współczesnych MCU to badziew jest, ale ciekawą rzeczą
> jest to, że MCS48 (rówieśnik PIC) umarł dawno temu, MCS51 chyba już
> umarł, a staruszek PIC ciągle żyje. :-)

'51 nie umarł. Jeszcze kilka lat temu ktoś tego uczył na uczelni 
okolicznej. Widać "zostało tylko kilka lat do emerytury". '51 umrze wraz 
z całym niereformowalnym pokoleniem wykładowców, nauczycieli i pewną 
firmą z Bytomia. Swoją drogą '51 też nie miał kompilatora C tylko 
pistolet na wodę o nazwie Keil z którego C++ nie sposób zrobić.

> Natomiast "dziwaczne" długości słów w ROM to nic dziwnego wśród MCU i
> DSP opartych na (zmodyfikowanej) architekturze harwardzkiej.

AVR jest harvard i nie ma z tym problemu. PICe nigdy nie byly 
projektowane z myślą o uzywaniu kompilatorów. Pochodzą z czasów 
wczesnego hackerstwa inspirowanego nieortogonalnymi architekturami z 
masą glitchy i workaroundów.

On 2020-03-08 10:22, heby wrote:
> On 08/03/2020 03:55, JDX wrote:
>>> ten co dostarczyli było poniżająco badziewny [1]. Trudno nazwać to
>>> problemem braku C++, to raczej był problem projektowania odpierdzielania
>>> architektury na kolanie z ignorowaniem reszty wszechświata co
>>> uniemozliwiło stosowanie normalnych kompilatorów w zamian za to dostając
>>> pistolet na wodę o nazwie "kompialtor C do PICów".
>> IMO to raczej problem drogiego (wówczas) krzemu. Poza tym, gdy powstawał
>> PIC, to C++ jeszcze nie było, a C był bardzo młody.
> 
> Nie wiem czy drogiego krzemu, AVR nie ma takich problemów, krzemu
> potrzebują, o ile pamietam, podobną ilość.
No jak nie ma jak ma. Przecież szerokość słowa pamięci programu wynosi
16 bitów, co jest wartością "dziwną" dla MCU pracującego na danych
8-bitowych. Poza tym co za różnica czy to jest 12, 14 czy 16 bitów?
Programista i tak tego nie widzi. Fakt, AVR ma normalny stos umieszczony
w pamięci danych, co jest ogromną zaletą.

> PICe były projektowane przez assemblerowca. Stąd widoczne elementy kodu
> maszynowego charakterystyczne dla optymalizacji ręcznych jak choć ten
> nieszczęsny stos wyjęty wprost z otchłani absurdu.
PIC i AVR dzieli 20 lat, gdy PIC się rodził, to i C było jeszcze w
powijakach, więc nie ma czemu się dziwić.

> Dlatego protestuje przed stawianiem PICa jako argumentu że "nie ma C++".
> Tam nawet porządnego i normalnego C nie ma bo to gówniany kawałek CPU z
> bardzo fajnymi peryferiami (odwrotnie jak w AVR).
Mimo wszystko, lepsze jest takie C niż rzeźbiarstwo w assemblerze. :-)

> '51 nie umarł. Jeszcze kilka lat temu ktoś tego uczył na uczelni
> okolicznej. Widać "zostało tylko kilka lat do emerytury". '51 umrze wraz
> z całym niereformowalnym pokoleniem wykładowców, nauczycieli i pewną
> firmą z Bytomia. 
Czy chodzi o tę firmę, która już w tym tysiącleciu wyrzeźbiła w VHDL-u
jakąś szybką wersję 51? Na pierwszy rzut oka to brzmi zabawnie, ale może
to mieć uzasadnienie ekonomiczne bo zasoby FPGA kosztują. A 51 dlatego,
że wszyscy to znają.

> Swoją drogą '51 też nie miał kompilatora C tylko
> pistolet na wodę o nazwie Keil z którego C++ nie sposób zrobić.
Nie używałem, ale AFAIR Keil jak i IAR robiły/robią też kompilatory C++
na 51.

On 08/03/2020 13:31, JDX wrote:
>> '51 nie umarł. Jeszcze kilka lat temu ktoś tego uczył na uczelni
>> okolicznej. Widać "zostało tylko kilka lat do emerytury". '51 umrze wraz
>> z całym niereformowalnym pokoleniem wykładowców, nauczycieli i pewną
>> firmą z Bytomia.
> Czy chodzi o tę firmę, która już w tym tysiącleciu wyrzeźbiła w VHDL-u
> jakąś szybką wersję 51? Na pierwszy rzut oka to brzmi zabawnie, ale może
> to mieć uzasadnienie ekonomiczne bo zasoby FPGA kosztują. A 51 dlatego,
> że wszyscy to znają.

A celebryci są znani z tego że są znani.

Co to za argument że architektura jest "znana"? Od 40 lat większość 
software jest pisana w językach wysokiego poziomu. Jakim cudem argument 
"znamy '51" ma jakikolwiek związek z podejmowaniem decyzji współcześnie? 
Serio, przychodzi taki koleś do Samsunga i mówi "wiecie, mamy zajeb... 
modemy LTE, ale kod w asm pisał 40 lat temu kolega i własnie wyciągnął 
kopyta wiec mamy tylko wersję na '51 a ponadto zgubiliśmy kod źródłowy 
...". Serio? Czasami bardzo współczuje biedakom z embedded. Pozimo 
toksyczności pracy jest szkodliwy dla myślenia logicznego.

Wolałbym rdzeń w czymś co jest szeroko wspierane a nie znane. Bo to 
rodzielne rzeczy. Ale cóź, nagroda "najszybszej furmanki świata" może 
była warta pracy ludzi z Bytomia, w końcu przez chwile w mediach zaistnieli.

>> Swoją drogą '51 też nie miał kompilatora C tylko
>> pistolet na wodę o nazwie Keil z którego C++ nie sposób zrobić.
> Nie używałem, ale AFAIR Keil jak i IAR robiły/robią też kompilatory C++
> na 51.

Ale oczyście, "with sufficient thrust, pigs fly just fine". Jestem 
przekonany że stosowny kompilator pojawi się i na Gigatronie. Bo w sumie 
też jest turing complete.

On 2020-03-08 13:41, heby wrote:
> On 08/03/2020 13:31, JDX wrote:
>>> '51 nie umarł. Jeszcze kilka lat temu ktoś tego uczył na uczelni
>>> okolicznej. Widać "zostało tylko kilka lat do emerytury". '51 umrze wraz
>>> z całym niereformowalnym pokoleniem wykładowców, nauczycieli i pewną
>>> firmą z Bytomia.
>> Czy chodzi o tę firmę, która już w tym tysiącleciu wyrzeźbiła w VHDL-u
>> jakąś szybką wersję 51? Na pierwszy rzut oka to brzmi zabawnie, ale może
>> to mieć uzasadnienie ekonomiczne bo zasoby FPGA kosztują. A 51 dlatego,
>> że wszyscy to znają.
> 
> A celebryci są znani z tego że są znani.
> 
> Co to za argument że architektura jest "znana"? Od 40 lat większość
> software jest pisana w językach wysokiego poziomu. Jakim cudem argument
> "znamy '51" ma jakikolwiek związek z podejmowaniem decyzji współcześnie?
Bo zdarzają się jeszcze nieźle sprzedające się produkty na 51, które
zostały zaprojektowane w czasach, gdy ten rdzeń nie był jeszcze
przestarzały. A jeśli się chce ten produkt nadal sprzedawać, to trzeba
go utrzymywać, aby był w zgodzie z obowiązującym prawem. No to i paru
ludzi do tego potrzeba. W każdym razie pewnie łatwiej w Polsce znaleźć
ludzi od 51 niż np. od rodziny H8, niestety, również umierającej.

> Serio, przychodzi taki koleś do Samsunga i mówi "wiecie, mamy zajeb...
> modemy LTE, ale kod w asm pisał 40 lat temu kolega i własnie wyciągnął
> kopyta wiec mamy tylko wersję na '51 a ponadto zgubiliśmy kod źródłowy
> ...". Serio? Czasami bardzo współczuje biedakom z embedded. Pozimo
> toksyczności pracy jest szkodliwy dla myślenia logicznego.
Ale dlaczego współczujesz? Wspomniany Samsung to też embedded –
smartfony, telewizory i inne diwajsy. A tam zdaje się obowiązywać inne
podejście – dosypiemy gigaherców i gigabajtów, dodamy rdzeni i będzie
pan zadowolony. :-)

> Wolałbym rdzeń w czymś co jest szeroko wspierane a nie znane. Bo to
> rodzielne rzeczy. Ale cóź, nagroda "najszybszej furmanki świata" może
> była warta pracy ludzi z Bytomia, w końcu przez chwile w mediach
> zaistnieli.
Nie zapominaj, że są jeszcze kwestie licencyjne. Przecież taki Arm nie
żyje z tego, że sprzedaje krzem, tylko z tego, że sprzedaje IP. Tak BTW,
sugestia dla firmy z Bytomia:
https://en.wikipedia.org/wiki/SuperH#J_Core. :-)

On 08/03/2020 21:29, JDX wrote:
>> Co to za argument że architektura jest "znana"? Od 40 lat większość
>> software jest pisana w językach wysokiego poziomu. Jakim cudem argument
>> "znamy '51" ma jakikolwiek związek z podejmowaniem decyzji współcześnie?
> Bo zdarzają się jeszcze nieźle sprzedające się produkty na 51, które
> zostały zaprojektowane w czasach, gdy ten rdzeń nie był jeszcze
> przestarzały.

Czyli jakie unikatowe cechy rdzenia '51 lub peryferiów nie występują w 
ByleCzym?

Myślisz że ten rdzeń z Bytomia to jest do urządzeń "zaprojektowanmcyh w 
czasach ..."? Nie, to do nowych. Troche jas stosowanie parowozów w kolei 
magnetycznej. Przecień to nie jest technicznie niemożliwe a i 
specjaliści od parowozów się znajdą.

> A jeśli się chce ten produkt nadal sprzedawać, to trzeba
> go utrzymywać

Nie, to już nie jest utrzymywanie. To prosta droga do katastrofy.

>, aby był w zgodzie z obowiązującym prawem. No to i paru
> ludzi do tego potrzeba. W każdym razie pewnie łatwiej w Polsce znaleźć
> ludzi od 51 niż np. od rodziny H8, niestety, również umierającej.

Natomiast milion razy łatwiej jest znaleźć ludzi do ARMa. Ba, nawet do 
AVRa znajdziesz w byle liceum. Nie bardzo rozumiem dlaczego przewagą '51 
ma być idiotyczny rdzeń procesora, o kiepskich możliwościach, bez 
sensownaych kompialtorów którego programiści są częsciej na emeryturze 
niż gotowi do pracy. Co jest w nim takiego magicznego? Nie myśl że tego 
pytania nie zadaję embedowcom. Zazwyczaj po paru Yyyy dowiaduje się że 
jest po prostu, no ... po prostu ... ciągle użyteczny ... znaczy kod 
mamy. PO chwili dłubania okazuje się że w asm. No i nic dziwnego że 
ciągle użyteczny. Przecie to nie kwestia wyboru tylko vendor-lockin, on 
jest jedynym użytecznym jaki mogą użyć.

>> Serio, przychodzi taki koleś do Samsunga i mówi "wiecie, mamy zajeb...
>> modemy LTE, ale kod w asm pisał 40 lat temu kolega i własnie wyciągnął
>> kopyta wiec mamy tylko wersję na '51 a ponadto zgubiliśmy kod źródłowy
>> ...". Serio? Czasami bardzo współczuje biedakom z embedded. Pozimo
>> toksyczności pracy jest szkodliwy dla myślenia logicznego.
> Ale dlaczego współczujesz? Wspomniany Samsung to też embedded –
> smartfony, telewizory i inne diwajsy. A tam zdaje się obowiązywać inne
> podejście – dosypiemy gigaherców i gigabajtów, dodamy rdzeni i będzie
> pan zadowolony. :-)

Ależ nie o to chodzi. Bierzesz '51 i masz jakieś plusy. Bierzesz ARMa i 
masz jakieś plusy. Tak mi to przedstawiają. Tylko że w pierszym wypadku 
nie potrafie żadnych znaleźć a i pytania o nie kończą się machaniem 
rękami jako argumentacją. Jesli ktoś robi swojego ASICa to niby po 
cholere ma tam wciskać gówniany '51 skoro wciśnięcie MIPSa albo nawet 
licencjonowanego ARMa, co przy obecnych rozmiarach krzemu nie robi na 
nikim wrażenia? Obecnie pół świata dostało sraczki na widok RISC-V, za 
chwile będzie implementowany w jednej obudowie z diodami RGB i 
superkomputerach wykonując ten sam kod bazowy.

> Nie zapominaj, że są jeszcze kwestie licencyjne. Przecież taki Arm nie
> żyje z tego, że sprzedaje krzem

Wiec nie stosuj ARMa. Stosuj coś bez komercyjnej licencji, skoro taka u 
Samsunga bieda że muszą oszczędzać na licencjach. Ponadto idę o zakład 
że na stosowanie Niosa czy innego cpu który mają w komplecie z software 
ich stać.

Problemem nie jest pieniądź. Od 40 lat słyszę jakie to szerokie i 
głębokie zalety posiada '51, ale jakoś bez detalicznego enumerowania 
tychże. O kasie nikt nie wspomina. Tam bez wątpienia jest jakiś inny 
powód, po tych wszystkich rozmowach dochodzę do wniosu że jest tylko 
jeden: religia.

I potem się dziwie że na C++ w embedded przeciętny Pan Zdzisław od 40 
lat robiący sterowiki zegarów szkolnych reaguje alergicznie. Skoro się 
nie da użyć w "najszybszym procesorze świata" to najlepiej nie używać 
wcale i nigdzie.