🚀 go-pugleaf

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