laoo/ng napisał/a:Kompatybilność z C jest oczywista - aby korzystać z bazy bibliotek napisanych w C, które kompilują się po kosmetycznych poprawkach / uściśleniach. Mógłbyś podać jednak kilka konkretów tych dziwactw? Nie twierdze, że C ich nie miał, ale np.
Uściślenia w bibliotekach napisanych w C na pewno im nie zaszkodziły, natomiast z argumentem odnośnie korzystania z bibliotek napisanych w C nie mogę się zgodzić. Inne języki nie mają z tym problemu, mimo że składniowo od C są bardziej odległe. Jak to możliwe? Łatwiej chyba jest skompilować kod w C kompilatorem C i przekazać zadanie połączenia linkerowi.
Wśród innych dziwactw wymieniłbym m.in. daleko posuniętą wymienność pojęć tablicy i wskaźnika, ułatwiającą generowanie niewykrywalnych błędów, jak ten zaproponowany przez Foxa. Wymieniłbym również składnię deklaracji, której niezgodności z intuicją dowiedli już jej autorzy, pisząc translator na język angielski. :)
laoo/ng napisał/a: nie rozumiem uwagi o powielaniu tekstu w nagłówkach? Chciałbyś żeby C++ porozumiewał się pomiędzy modułami jak C# - bez includów? To chyba inna para kaloszy nie możliwa do sensownego zaimplementowania.
Tak, chciałbym i mam to w D, dzięki czemu nie muszę uwzględniać prywatnych składowych w publicznym interfejsie ani chować ich za pImpl, jak również nie muszę się martwić, czy któryś z dołączanych nagłówków jest wrażliwy na to, co było wcześniej w dołączającym kodzie. No i nade wszystko nie muszę się pisać i utrzymywać powielonego tekstu.
laoo/ng napisał/a:Nie za bardzo czuję obiekcje to std::vector. Rozumiem, że boisz się pomieszania iteratorów, ale ja tu nie widzę żadnego problemu. Jak piszesz w C to też nie masz pewności, że dwa wskaźniki wskazują na tę samą tablicę, ale w przypadku vectora tak źle nie jest.
Jak piszę w C to nie mam tej pewności, ale C++ jest ponoć lepszy. :)
laoo/ng napisał/a:Np. w microsoftowej implementacji STLa można włączyć feature "checked iterators", dzięki któremu operacje na iteratorach dokonują dodatkowych sprawdzeń czy dotyczą tego samego kontenera itd. Dzięki niej spokojnie wykryjesz takie błędy, a najlepsze jest to, że to jest opcja, którą w każdej chwili możesz wyłączyć i cieszyć się pełną wydajnością równoważną operacjom na wskaźnikach bez żadnego ukrytego sprawdzania zakresów jak w C# czy w Javie
Implementacja microsoftowa jest, jak rozumiem, poza standardem, ale to już coś. Przyjrzę się, jak to wygląda w implementacjach STLa, których mam szansę użyć prędzej niż tej z MS.
laoo/ng napisał/a:Uwagi do iostream niestety nie rozumiem. Wyjaśnij proszę.
Nie podoba mi się, że formatowane wyjście przeplata formatowanie z danymi do wyświetlenia oraz składnia formatowania jest rozwlekła. Nie podoba mi się również, że obiekt reprezentujący standardowe wyjście przechowuje stan definiujący formatowanie i nie zawsze mam kontrolę nad tym, w jakim stanie zostawi go kod, który wywołuję.
W nowszych rozwiązaniach to podejście nie wygląda na zbyt chętnie powielane, co moim zdaniem jest argumentem za tym, że nie było ono dobrze przemyślane.
laoo/ng napisał/a:Biblioteka C jest dla kompatybilności, jakbyś chciał skompilować kod w C. Nikt nie każe Ci jej używać, bo powszechnie wiadomo, że biblioteka C++ jest lepsza ;)
No właśnie kiedy chciałbym jej użyć, ponieważ w niektórych sytuacjach znajduję jej rozwiązania wygodniejszymi, to cały czas czuję nad sobą bat "biblioteka C to zło". ;)
Natomiast chcąc skompilować kod w C, użyję kompilatora C.
laoo/ng napisał/a:iostream i wyjątki: nie zgodzę się. Operacje na strumieniach są naturalnie narażone na niepowodzenia (użytkownik podał literkę, a chciałeś cyfre, plik się skończył itd.).
Miałem na myśli nieco tylko poważniejsze problemy, jak urwany kabel czy zniknięcie karty pamięci, na które normalnie nie jesteś przygotowany i zwykle rozwiązanie w postaci zwinięcia stosu byłoby najwygodniejsze. Na szczęście jednak byłem niedouczony - doczytałem sobie, że mogę już wybrać (co się chwali), czy chcę być obrzucony wyjątkiem. Niestety nieopatrznie upaprałem sobie spodnie grząskim gruntem. ;)
W pozostałych sytuacjach, o których mówisz, jak parsowanie wejścia od usera - pełna zgoda, wyjątki tylko utrudniają.
laoo/ng napisał/a:Czy przytoczę z pamięci reguły wiązania? Nie. Ale nawet programista C powinien wiedzieć, że tam gdzie ma wątpliwości, to czytelnik kodu też pewnie będzie je miał i trzeba dodać nawiasy. Czy to wada C++?
Chyba mówimy o czymś innym. Mam na myśli wiązanie identyfikatora z funkcją, która się za nim kryje, co (przynajmniej dla mnie, być może standardem są hardkorowcy, którzy to pojmują) nie jest łatwe ze względu na szablony i przeciążenia. Czy to wada? Jeśli za jedno z kryteriów w ocenie jakości narzędzia przyjmiemy łatwość jego użycia, to skomplikowanie jest wadą.
Co do ostatniej części (x czy y), to masz rację, czepiam się, natomiast znajomość konwencji, a zwłaszcza jej umotywowania, wymaga sporo nauki, a pogodzenie się z nią bywa ciężkie, jeśli nie pasuje do przyzwyczajenia lub trudno ją powiązać z intuicją.
laoo/ng napisał/a:Ogólnie bardzo niezbornie wyraziłeś te swoje uwagi i średnio przekonująco (z wyjątkiem przypadkowej deklaracji funkcji czy prawie leniwych operatorów). Ogólnie nie widzę, dlaczego wg Ciebie powinno to dyskredytować w jakiś sposób C++.
Dziękuję za wyczerpującą odpowiedź, mam nadzieję, że udało mi się ją wykorzystać do uściślenia uwag niezbornych i nieprzekonujących.
Nie zamierzałem dyskredytować C++, ponieważ trochę go (masochistycznie ;)) lubię i nadal używam, choć już nie tak intensywnie jak, powiedzmy, 2 lata temu i już swoich umiejętności w nim nie rozwijam.
Nie pod tym kątem więc były moje uwagi. Chciałem jedynie wykazać, że podobnie jak MADS, C++ został zaprojektowany z uwzględnieniem kompatybilności z poprzednikiem na poziomie kodu źródłowego, a w toku jego rozwoju dodawano do niego często nowe featury (znów to brzydkie słowo), które nie zawsze dobrze pasowały do już istniejących, a rzadko decydowano się na potencjalne zerwanie zgodności z istniejącym kodem.
Skutkiem tego w obu istnieje bagaż, którego zrozumienie wymaga znajomości ich ewolucji. Domagam się zatem równego traktowania błędogennych cech MADSa i C++. :)
