21.11.2013 17:52
[#1]
TinyGL na MorphOS-ie, tutorial
Zainspirowany co nieco wątkiem scenowym postanowiłem swoje zmagania z 3D na MorphOS-ie, a w szczególności z TinyGL, opisać w formie tutoriala. Dwa pierwsze artykuły są już gotowe na stronie MorphOS - podręcznik programisty. Jako pierwszy przykład służy słynący już z twórczych przeróbek ;) program rysujący dwa kolorowe trójkąty. Zapraszam do lektury i ekslporacji świata 3D pod MorphOS-em. W następnym odcinku mam zamiar zakręcić w końcu sześcianem.
23.11.2013 15:22
[#3]
Re: TinyGL na MorphOS-ie, tutorial
@MorphOS_pl, post #1
fajny podrecznik, poczytalem o MUI i rozjasnilo sie pod czupryna, w koncu widze w tym wygode, teraz tylko rozszerzyc pozostaje wiedze o kolejne klasy i mozna trzaskac normalne interfejsy :), skoro juz udalo sie uruchomic przyklady i troche nimi pobawic w modyfikacje rozne. Ciekawy jest tez ten opis dt. wlasnego kodu startowego, co na pewno przyda sie :).
Ciekawi mnie, na ile MUI w MOS jest kompatybilne z ostatnia wersja 68k tj. 3.8 ?.
ps. bylem zdziwiony nieco faktem, a wczesniej znalem tylko gole intuition itd.., ze MUI jest w zasadzie obiektowe, a nie wymaga uzywania C++, nawet nie jest do niczego potrzebne C++. C++ nie za bardzo lubie, nie chodzi wcale o wstret do programowania obiektowego, tylko wstret do pogmatwanych lub pogmatwania sobie samemu obiektow w C++.
Ciekawi mnie, na ile MUI w MOS jest kompatybilne z ostatnia wersja 68k tj. 3.8 ?.
ps. bylem zdziwiony nieco faktem, a wczesniej znalem tylko gole intuition itd.., ze MUI jest w zasadzie obiektowe, a nie wymaga uzywania C++, nawet nie jest do niczego potrzebne C++. C++ nie za bardzo lubie, nie chodzi wcale o wstret do programowania obiektowego, tylko wstret do pogmatwanych lub pogmatwania sobie samemu obiektow w C++.
23.11.2013 18:52
[#7]
Re: TinyGL na MorphOS-ie, tutorial
@kiero, post #5
Chyba trochę się źle wyraziłem, chodziło o: "zmniejszeni złożoności związanej z wyrażaniem programu" (cyt. "Thinking in C++", wyd. Helion, str. 42) jak i w tej samej książce na stronie 59 mamy rozdział o tytule "Lepsze C" ;).
Oczywiście parę uproszczeń się pojawiło w C++ w stosunku do C, np. referencje zamiast wskaźników ;)
A twój przykład z autami jest doskonały, na pewno prościej jest odpalić fiata 500 (kluczyk) niż 126p :P, nie wspomnę o innych ułatwieniach typu klima i ogrzewanie na postoju :P.
Ostatnia aktualizacja: 23.11.2013 18:57:33 przez tygrysekHD
Oczywiście parę uproszczeń się pojawiło w C++ w stosunku do C, np. referencje zamiast wskaźników ;)
A twój przykład z autami jest doskonały, na pewno prościej jest odpalić fiata 500 (kluczyk) niż 126p :P, nie wspomnę o innych ułatwieniach typu klima i ogrzewanie na postoju :P.
Ostatnia aktualizacja: 23.11.2013 18:57:33 przez tygrysekHD
23.11.2013 20:52
[#9]
Re: TinyGL na MorphOS-ie, tutorial
@MorphOS_pl, post #8
Po krótkim romansie z C++ wróciłem do C. W nim jednak chyba program wyraża się prościej.
Pewnie romans był za krótki, by dostrzec zalety C++ ;), namawiam by jeszcze trochę poromansować, bo w mojej ocenie podejście obiektowe jest znacznie fajniejsze ;) i to nie tylko w C++.
23.11.2013 20:56
[#10]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #9
Pewnie nie był za krótki. Z mojego punktu widzenia C++ ma dwie zasadnicze wady:
1. Jego obiektowość ma się nijak do obiektowości implementowanej w systemach amigowych przez BOOPSI, co m.in. wyłazi przy próbie pogodzenia C++ z MUI.
2. W C++ kompilator robi za dużo "za plecami" programisty. Bardzo łatwo w C++ napisać zaskakująco nieefektywny kod.
Poza tym po prostu lubię być blisko procesora. Za dużo warstw abstrakcji utrudnia mi pracę. No i to nieprawda, że w C nie można stosować technik obiektowych...
1. Jego obiektowość ma się nijak do obiektowości implementowanej w systemach amigowych przez BOOPSI, co m.in. wyłazi przy próbie pogodzenia C++ z MUI.
2. W C++ kompilator robi za dużo "za plecami" programisty. Bardzo łatwo w C++ napisać zaskakująco nieefektywny kod.
Poza tym po prostu lubię być blisko procesora. Za dużo warstw abstrakcji utrudnia mi pracę. No i to nieprawda, że w C nie można stosować technik obiektowych...
23.11.2013 23:27
[#11]
Re: TinyGL na MorphOS-ie, tutorial
@MorphOS_pl, post #10
Oczywiście że nieprawda, w kastelhaku mamy semi-obiektówkę ze struktur posiadających wskaźniki na funkcje. I działa to szybciej i sprawniej niż kiedykolwiek jakikolwiek kompilator cpp by na to pozwolił ze swoimi natywnymi klasami i metodami. :)
Jestem gorącym zwolennikiem C i zawziętym przeciwnikiem cpp. Czemu? Bo cpp ma za dużo tłuszczu w pliku wykonywalnym, ma za dużo pierdół typu private/public/protected, ma przeładowanie operatorów i polimorfizm, który wielokrotnie więcej razy są frustrujące niż pożyteczne. No i jest trudniejszy do optymalizacji dla kompilatorów, przez co C nadal jest szybsze od cpp na większości platform.
Żeby nie było tak kolorowo to w C mi szalenie brakuje bajeru typu inline i wspomnianego przekazywania przez referencję. Co prawda wszystko da radę załatwić definami i wskaźnikami, ale długie makra czytelne nie są.
Naprawdę, cały czas nie mogę pojąć tej całej zajawki programowaniem obiektowym. Okej, czasem się przydaje, czasem takie podejście jest łatwiejsze, czasem wręcz oczywiste i jedynie słuszne. Ale jak widzę, jak ktoś pisze byle pierdółkę i robi do tego pierdylion klas, setterów, getterów z uprawnieniami... po co?
Ostatnia aktualizacja: 23.11.2013 23:28:11 przez teh_KaiN
Jestem gorącym zwolennikiem C i zawziętym przeciwnikiem cpp. Czemu? Bo cpp ma za dużo tłuszczu w pliku wykonywalnym, ma za dużo pierdół typu private/public/protected, ma przeładowanie operatorów i polimorfizm, który wielokrotnie więcej razy są frustrujące niż pożyteczne. No i jest trudniejszy do optymalizacji dla kompilatorów, przez co C nadal jest szybsze od cpp na większości platform.
Żeby nie było tak kolorowo to w C mi szalenie brakuje bajeru typu inline i wspomnianego przekazywania przez referencję. Co prawda wszystko da radę załatwić definami i wskaźnikami, ale długie makra czytelne nie są.
Naprawdę, cały czas nie mogę pojąć tej całej zajawki programowaniem obiektowym. Okej, czasem się przydaje, czasem takie podejście jest łatwiejsze, czasem wręcz oczywiste i jedynie słuszne. Ale jak widzę, jak ktoś pisze byle pierdółkę i robi do tego pierdylion klas, setterów, getterów z uprawnieniami... po co?
Ostatnia aktualizacja: 23.11.2013 23:28:11 przez teh_KaiN
24.11.2013 00:19
[#13]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #9
Nie ma o co kruszyc kopi 
. Nikt nie neguje przeciez C++ jako jezyka programowania.
byc moze upraszcza, byc moze nie, wszystko zalezy od kontekstu uzycia. na pewno praca w C++ w polaczeniu z biblioteka boost (ktorej portu chyba nawet nie ma na amigowe systemy, bo to nie takie STL, jak kazdy wie) pozwala dosc szybko implementowac zlozone problemy zachowujac sensowna wydajnosc poszczegolnych operacji, choc przy bardziej zlozonych problemach lepiej uzywac jezykow naprawde wysokiego poziomu - C++ jest gdzies po srodku blizej niskiego, niz babrac sie ze skomplikowana/pogmatwana skladnia C++. W kontekscie programow pisanych pod systemy amigowe to zalet C++ na razie nie dostrzegam. Byc moze w bardziej zaawansowanych programach warto poswiecic cenne zasoby dla tych zalet C++, teraz jednak tego nie dostrzegam. Natomiast klasy, metody wirtualne, przeciazenia, wzorce, wyjatki, przestrzenie nazw..., rozbudowane typy danych itd. itd. sa mi tu zbedne, prawde mowiac, to chyba nawet wolalbym zrezygnowac ze std. biblioteki C na rzecz funkcji systemowych, poczynajac od wyswietlania tekstow, zarzadzania pamiecia, poprzez operacje na plikach itd. itd., nie wspominajac o cechach jakich nie udostepnia std. C/C++ pod amigowym systemem - uzyskuje w ten sposob pewna jednolita calosc w "obejsciu", a sam jezyk dostarcza mi tylko "wyrazu", potocznie mowiac. Oczywiscie da sie zaimplementowac w C wiele tych technik programistycznych znanych w C++, jednak tylko na miare potrzeb pisanego programu i "wyrazu" w C. No coz, tak mowiac najogolniej, uzywam tutaj C zamiennie za assembler
.
Ostatnia aktualizacja: 24.11.2013 00:23:40 przez sigma2pi
. Nikt nie neguje przeciez C++ jako jezyka programowania. #3
byc moze upraszcza, byc moze nie, wszystko zalezy od kontekstu uzycia. na pewno praca w C++ w polaczeniu z biblioteka boost (ktorej portu chyba nawet nie ma na amigowe systemy, bo to nie takie STL, jak kazdy wie) pozwala dosc szybko implementowac zlozone problemy zachowujac sensowna wydajnosc poszczegolnych operacji, choc przy bardziej zlozonych problemach lepiej uzywac jezykow naprawde wysokiego poziomu - C++ jest gdzies po srodku blizej niskiego, niz babrac sie ze skomplikowana/pogmatwana skladnia C++. W kontekscie programow pisanych pod systemy amigowe to zalet C++ na razie nie dostrzegam. Byc moze w bardziej zaawansowanych programach warto poswiecic cenne zasoby dla tych zalet C++, teraz jednak tego nie dostrzegam. Natomiast klasy, metody wirtualne, przeciazenia, wzorce, wyjatki, przestrzenie nazw..., rozbudowane typy danych itd. itd. sa mi tu zbedne, prawde mowiac, to chyba nawet wolalbym zrezygnowac ze std. biblioteki C na rzecz funkcji systemowych, poczynajac od wyswietlania tekstow, zarzadzania pamiecia, poprzez operacje na plikach itd. itd., nie wspominajac o cechach jakich nie udostepnia std. C/C++ pod amigowym systemem - uzyskuje w ten sposob pewna jednolita calosc w "obejsciu", a sam jezyk dostarcza mi tylko "wyrazu", potocznie mowiac. Oczywiscie da sie zaimplementowac w C wiele tych technik programistycznych znanych w C++, jednak tylko na miare potrzeb pisanego programu i "wyrazu" w C. No coz, tak mowiac najogolniej, uzywam tutaj C zamiennie za assembler
.Ostatnia aktualizacja: 24.11.2013 00:23:40 przez sigma2pi
24.11.2013 00:48
[#14]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #12
Nieduży, jeśli liczyć języki kompilowane. Kastelhak jest chyba największy i specjalnie go dla Ciebie policzyłem. Ma coś koło 3.5k linii nie licząc plików .h, a że piszemy we dwójkę to licząc bardzo luźno 1.75k na łeb. Ale to tak jak mierzenie pewnej części ciała - o niczym ta liczba nie świadczy. :) Bo raczej to nie ma nic do jakości kodu produkowanego przez kompilatory C i cpp ani do innych, podanych przeze mnie rzeczowych, namacalnych argumentów. A może raczej nie argumentów, tylko subiektywnych opinii na dany temat.
Nie przeczę, w dużych projektach o wiele fajniej jest zawrzeć moduły w obiektach, itd. Tylko że obiektówka jest według mnie jednym z tych rozwiązań w programowaniu, które najczęściej używane są w sposób niepotrzebny, tuż obok korzystania z baz danych do byle pierdoły (zwłaszcza widziane przy www!) i frameworków do js.
I tak, C jest o tyle wdzięczny na Amidze, że pozwala na pewną przejrzystość językową, której brakuje w asmie, nie tracąc przy tym zbyt dużo przy wydajności i nie rezygnując całkowicie z dotykania hardware'u. Tak przynajmniej do tej pory mi mówią wszystkie znaki na niebie i ziemi podczas mojej przygody z amigowym programowaniem. :)
Nie przeczę, w dużych projektach o wiele fajniej jest zawrzeć moduły w obiektach, itd. Tylko że obiektówka jest według mnie jednym z tych rozwiązań w programowaniu, które najczęściej używane są w sposób niepotrzebny, tuż obok korzystania z baz danych do byle pierdoły (zwłaszcza widziane przy www!) i frameworków do js.
I tak, C jest o tyle wdzięczny na Amidze, że pozwala na pewną przejrzystość językową, której brakuje w asmie, nie tracąc przy tym zbyt dużo przy wydajności i nie rezygnując całkowicie z dotykania hardware'u. Tak przynajmniej do tej pory mi mówią wszystkie znaki na niebie i ziemi podczas mojej przygody z amigowym programowaniem. :)
24.11.2013 13:00
[#15]
Re: TinyGL na MorphOS-ie, tutorial
@teh_KaiN, post #14
niestety, programisci c++ maja programistow c za ulomnych, ograniczonych i zacofanych w tej profesji, nie potrafiacych pisac prawdziwych programow itd., niemal na kazdym kroku wykazuja wyzszosc c++ nad c itd. , wg. programistow c++ to programista ktory za dlugo przysiadzie do c jest juz niezdolny do programowania i nie powinien sie tym dalej zajmowac itd. Std. pytanie o wielkosc programu ma wykazac wyzszosc c++ nad c oraz programisty c++ nad programista c itd. , wiadomo, ze programisci c++ pisza tylko wielkie programy, doslownie i w przenosni, podczas gdy programisci c drepcza w miejscu i odkrywaja kolo na okraglo itd. 
, wiadomo, ze programisci c++ pisza tylko wielkie programy, doslownie i w przenosni, podczas gdy programisci c drepcza w miejscu i odkrywaja kolo na okraglo itd. 24.11.2013 15:09
[#17]
Re: TinyGL na MorphOS-ie, tutorial
@sigma2pi, post #15
Pytałem o wielkość programów, dlatego że przy "dużych" projektach użyteczność C++ jest szczególnie widoczna i wtedy również można wszystkie te "magiczne" właściwości C++ doskonale wykorzystać. Krótko mówiąc im większy projekt tym więcej korzyści z obiektowości.
Nie miałem nic złego na myśli, faktem jednak jest, że umiejąc programować strukturalnie jest trudniej przestawić się na programowanie obiektowe, bo stare nawyki i schematy już w nast tkwią. Sam tego doświadczyłem. Zbierając się za C++ wcześniej pisałem trochę strukturalnie w pascalu i w C z tego powodu chwilę to trwało zanim przestawiłem się w myśleniu na obiekty, gdyż na początku podświadomie chciałem stosować znane mi rozwiązania. Każda kolejna aplikacja pokazywała mi w coraz większym stopniu jakie to fajne i proste ;). Nie uważam się za eksperta ale widzę jak wiele daje podejście obiektowe i jak ułatwia pracę, dużo by o tym można pisać...
Nie miałem nic złego na myśli, faktem jednak jest, że umiejąc programować strukturalnie jest trudniej przestawić się na programowanie obiektowe, bo stare nawyki i schematy już w nast tkwią. Sam tego doświadczyłem. Zbierając się za C++ wcześniej pisałem trochę strukturalnie w pascalu i w C z tego powodu chwilę to trwało zanim przestawiłem się w myśleniu na obiekty, gdyż na początku podświadomie chciałem stosować znane mi rozwiązania. Każda kolejna aplikacja pokazywała mi w coraz większym stopniu jakie to fajne i proste ;). Nie uważam się za eksperta ale widzę jak wiele daje podejście obiektowe i jak ułatwia pracę, dużo by o tym można pisać...
24.11.2013 18:55
[#18]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #17
Pytałem o wielkość programów, dlatego że przy "dużych" projektach użyteczność C++ jest szczególnie widoczna
172 pliki *.c (bez nagłówków), łącznie 1687 kB źródeł. Program jest napisany obiektowo w C. Nie wyobrażam sobie masakry, jaka by powstała przy próbie pisania tego w C++.
172 pliki *.c (bez nagłówków), łącznie 1687 kB źródeł. Program jest napisany obiektowo w C. Nie wyobrażam sobie masakry, jaka by powstała przy próbie pisania tego w C++.
24.11.2013 20:23
[#19]
Re: TinyGL na MorphOS-ie, tutorial
@MorphOS_pl, post #18
To jest tylko przykład na to, że masz bardzo duży projekt w C ;) i nic nie mówi o C++.
Ja też mogę napisać, że np. jeden mój projekt napisany w C++ składa się z 116 plików *.cpp, które mają 621 kB objętość. Program obsługuje 90 okien - formatek, działa pod windows ;) i nie mam problem z poruszaniem się po nim ;). Przy okazji jego pisania stworzyłem sobie mały "framework" do obsługi typowych działań z oknem ;), który z powodzeniem - praktycznie bez zmian - wykorzystałem w kilku innych projektach. Projekt jest znacznie mniejszy objętościowo niż Twój, ale też nie robi nic aż tak skomplikowanego ;) i oczywiście korzysta z bibliotek obiektowych do GUI ;).
Inny projekt pod Arosa na razie 32 pliki *.cpp 138 kB i w tej chwili chyba potrafi otworzyć dwa okna ;) i jest moja próbą przeniesienia wcześniejszej wersji tego programu na Arosa z OS 3.x i zrobienie go pod MUI/Zune ;) co idzie mi jak krew z nosa ;).
Ja też mogę napisać, że np. jeden mój projekt napisany w C++ składa się z 116 plików *.cpp, które mają 621 kB objętość. Program obsługuje 90 okien - formatek, działa pod windows ;) i nie mam problem z poruszaniem się po nim ;). Przy okazji jego pisania stworzyłem sobie mały "framework" do obsługi typowych działań z oknem ;), który z powodzeniem - praktycznie bez zmian - wykorzystałem w kilku innych projektach. Projekt jest znacznie mniejszy objętościowo niż Twój, ale też nie robi nic aż tak skomplikowanego ;) i oczywiście korzysta z bibliotek obiektowych do GUI ;).
Inny projekt pod Arosa na razie 32 pliki *.cpp 138 kB i w tej chwili chyba potrafi otworzyć dwa okna ;) i jest moja próbą przeniesienia wcześniejszej wersji tego programu na Arosa z OS 3.x i zrobienie go pod MUI/Zune ;) co idzie mi jak krew z nosa ;).
24.11.2013 20:52
[#20]
Re: TinyGL na MorphOS-ie, tutorial
@sigma2pi, post #3
MUI z morphosa jest calkowicie kompatybilne z mui3.8. Natomiast jest, także mocniej rozwiniete i mocniej obiektowe (więcej metod/interfejsów do implementacji we wlasnych klasach zamiast hookow). Wszystkie programy pisane przez mui (nawet te z 92 roku) zyskują nowoczesny interfejs i możliwości po uruchomieniu pod morphosem.
25.11.2013 06:18
[#21]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #19
To jest tylko przykład na to, że masz bardzo duży projekt w C ;) i nic nie mówi o C++.
To była odpowiedź na sugestię, że odpowiednio duży projekt jest w C jest trudny do utrzymania i mógłby odczuwać zalety C++. Pewnie mógłby, ale nie lubię, gdy język programowania zaczyna mi dyktować formę programu.
co idzie mi jak krew z nosa
Ot, zalety C++...
To była odpowiedź na sugestię, że odpowiednio duży projekt jest w C jest trudny do utrzymania i mógłby odczuwać zalety C++. Pewnie mógłby, ale nie lubię, gdy język programowania zaczyna mi dyktować formę programu.
co idzie mi jak krew z nosa
Ot, zalety C++...
25.11.2013 08:29
[#22]
Re: TinyGL na MorphOS-ie, tutorial
@MorphOS_pl, post #21
To była odpowiedź na sugestię, że odpowiednio duży projekt jest w C jest trudny do utrzymania i mógłby odczuwać zalety C++.
Nic takiego nie napisałem ;). Stwierdziłem jedynie, że przy dużych i złożonych projektach "użyteczność C++ jest lepiej widoczna" w przeciwieństwie do krótkich małych programików. Nie uważam, że w C nie da się robić dużych projektów, wręcz przeciwnie np. jądro linux'a pokazuje, że się da. Po prostu każdy robi tak jak lubi ;).
Ot, zalety C++...
Nie sądzę by tyła to wina C++, raczej moja nieznajomość MUI i brak doświadczenia z tym związany ;) i brak czasu ;).
25.11.2013 10:18
[#23]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #22
Stwierdziłem jedynie, że przy dużych i złożonych projektach "użyteczność C++ jest lepiej widoczna" w przeciwieństwie do krótkich małych programików
w przypadku malych i mniej zlozonych projektow powinna byc rownie jezeli nie bardziej widoczna
, tak sadza programisci C++, prawda ? , baa, w przypadku mniej zlozonych nawet powinna bardziej widoczna z uwagi na "wyzszy poziom" (jezyka) C++ np: zamiast meczyc sie ze wskaznikami do char, wchar_t itp., wystarczy uzyc wygodnego string i np: chcac polaczyc ze soba dwa napisy, wystarczy uzyc operatora +, zamiast jakiejs magicznej funkcji np: strcat lub wlasnej:), nie mowiac o przypisaniu ciagu lub ciagow znakow do wskaznika etc..., ze wspomne jeszcze o dbaniu o wlasciwa rezerwacje pamieci etc.,,, do tego jak jeszcze dodamy prosty mechanizm try catch w C++ gdyby cos poszlo nie tak, to jest w ogole latwiej niz niezbedne operowanie np: malloc/free lub tutaj odpowiednikami z systemu amigowego (exec/Alloc......) ITD.wiec ja nie wiem czemu wycofujesz sie lagodnie ze swoich poczatkowych twierdzen
---
Tak jak napisalem wczesniej. Nie cierpie C++ wlasnie za to jak latwo sobie tym "bogactwem" pogmatwac projekt - juz takie widzialem... Nie widze zalet C++ pod amigowym systemem z drugiej strony, pod swoje potrzeby :). Lubie C z tego samego powodu co asembler, jednak robienie wszystkiego w asm to bylby juz masochizm, nie mowiac o przenoszeniu tego ;).
25.11.2013 12:14
[#24]
Re: TinyGL na MorphOS-ie, tutorial
@tygrysekHD, post #22
Najbardziej irytujące w C++ jest to, że już się myśli - znam C++ -, a tu policzek. Widzisz coś i się dziwisz, że takie coś istnieje i jeszcze działa (WTF?). Rozgryzasz to, co Ci zabiera czas, znów się myśli że jest się kozakiem z C++ (teraz już wiem o co chodzi z tym C++), a tu znów policzek i od nowa. Znając nawet podstawy C++ nie wiem ile czasu jest potrzebne, żeby poznać wszystkie zawiłości C++ i jego bibliotek. Żeby z niego w pełni korzystać, trzeba praktycznie wiedzieć tyle, co twórca kompilatora.
http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/
Podobno Stroustrup dla żartu na jakiejś konferencji powiedział, że wymyślił C++ po to, żeby skomplikować ludziom życie, że uczelnie produkowały za dużo dobrych programistów C i powstawały za szybko dobre programy
P.S.
Programowanie boli
http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who-says-he-knows-c/
Podobno Stroustrup dla żartu na jakiejś konferencji powiedział, że wymyślił C++ po to, żeby skomplikować ludziom życie, że uczelnie produkowały za dużo dobrych programistów C i powstawały za szybko dobre programy
P.S.
Programowanie boli