Nauka programowania, przydatne poradniki i książki

[JamesVoo]

@Hakken - mógłbyś wyjaśnić różnice między zastosowanie C++ i C#?

Wolałbym zweryfikować i naprawić to co mi wbito do głowy w technikum

[Sevard]

C# wykorzystuje się głównie w aplikacjach biznesowych, które trzeba napisać szybko i jest to raczej konkurencja dla Javy, a nie dla C++.

C++ wykorzystywany jest w większych projektach oraz tam, gdzie niskopoziomowa optymalizacja może sporo zmienić. Ponadto C++ jest jednak dużo bardziej przenośny niż C#, więc jeśli ktoś będzie chciał napisać coś, co będzie działało wszędzie (lub chociaż na innej platformie niż Windows), to wybierze raczej C++, a nie C#.

C# nie jest i raczej nie będzie następcą C++. To są różne języki, które tak naprawdę więcej dzieli niż łączy.

Zresztą tak samo C++ nie do końca jest następcą C. Nadal są zadania, w których C sprwadza się zdecydowanie lepiej.

Tylko będziesz musiał poznać niuanse i różnice między językami.

Taa, niuanse (a to nie jest pełna lista).

[[Ekspert] Hakken]

Warto wspomnieć o garbage collectorz.

C# takowy posiada, C++ nie. To oznacza, że o C# można praktycznie zapomnieć przy systemach czasu rzeczywistego, bo jak GC się odpali to ryzyko zawalenia deadlinu jest bardzo realne.

[JamesVoo]

Okej, dzięki za odpowiedź, będę na przyszłość o tym pamiętał

[webtom]

Nadal są zadania, w których C sprawadza się zdecydowanie lepiej.

Mógłbyś rozwinąć? Zawsze mi się wydawało, że C++ to z grubsza to samo, co C, tylko z (opcjonalną) obiektowością i większą liczbą bibliotek.

Hej... poleciłby mi ktoś jakieś książki/strony skąd mogę się czegoś nauczyć o Javie ?

Np. "Thinking in Java".

[[Ekspert] Hakken]

C jest lepszy niż C++ przy pisaniu bardzo niskopoziomowo - sterowniki, jądra, moduły systemu operacyjnego. Również jeśli zależy komuś bardzo mocno na czasie - C się lepiej optymalizuje.

[Sevard]

Mógłbyś rozwinąć? Zawsze mi się wydawało, że C++ to z grubsza to samo, co C, tylko z (opcjonalną) obiektowością i większą liczbą bibliotek.

W C również da się pisać obiektowo. Tak naprawdę najwięcej zmieniają wzorce i klasy wirtualne, większość innych rzeczy da się w C zrobić bez jakiegoś większego kombinowania.

Ułatwienia mają jednak wpływ na wydajność (np. użycie funkcji wirtualnych dodaje dodatkowe kroki przy wołaniu funkcji, co nieco spowalnia wszystko, choć z drugiej strony dobrze użyte wzorce potrafią znacząco przyspieszyć program) oraz wielkość wynikowych plików wykonywalnych (w przypadku C++ są one nieco większe). Tu naprawdę dużo zależy od tego co chcemy osiągnąć i na jaką platformę piszemy (niektóre platformy nie mają nawet kompilatora C++).

[mikoma]

A coś z internetowych poradników?

[webtom]

A coś z internetowych poradników?

Może ktoś zna jakąś lepszą propozycję, ale Thinking in Java możesz pobrać przykładowo stąd.

wzorce

Co przez to rozumiesz? Jakbym miał strzelać, to obstawiałbym template'y, ale przecież one pozwalają na unikanie kopiowania kodu, a funkcjonalności języka zbytnio nie rozszerzają.

klasy wirtualne

Zakładam, że chodzi Ci o klasy z funkcjami wirtualnymi (a nie jakieś wirtualne dziedziczenie czy inne cuda).

większość innych rzeczy da się w C zrobić bez jakiegoś większego kombinowania.

Zgodnie z wikipedią, cztery podstawowe cechy OOP to abstrakcja, hermetyzacja, polimorfizm i dziedziczenie. Hermetyzacji nie zapewnisz, polimorfizm to chyba przez wskaźniki na funkcje (jak dla mnie takie rozwiązanie podpada pod "większe kombinowanie", ale z drugiej strony pozwoliłoby na jakąś formę dynamicznego typowania, czy może raczej swoistą odmianę wzorca decorator).

I raczej chodziło mi o wykorzystanie C++ jako narzędzie umożliwiające napisanie tego samego nieco prościej (konstruktory zamiast malloców, czy też metody zamiast przekazywania obiektu jako parametru funkcji). W takim przypadku C nadal wypada zauważalnie lepiej od C++ i lepiej się optymalizuje?

[[Ekspert] Hakken]

wzorce

template'y, ale przecież one pozwalają na unikanie kopiowania kodu, a funkcjonalności języka zbytnio nie rozszerzają.

Template'y w C++ są równoważne maszynie Turinga, co dość istotnie rozszerza funkcjonalność języka (mianowicie o metaprogramowanie).

[MikaelDorren]

A coś z internetowych poradników?

Zależy czego oczekujesz. Jeśli prostych kursów mających wprowadzić w język i zachęcić do dalszego samodzielnego rozwoju, możesz spróbować np. Udemy, learnjava, http://www.java2s.com, http://www.tutorials.../java/index.htm, http://www.webdevelo...pl/manual_java/ (tu mam nieco mieszane uczucia).

Poza tym, tradycyjnie chyba przy każdym języku - dokumentacja. Przy okazji znajdziesz tam tutorial.

[[Ekspert] Mormegil]

C jest lepszy niż C++ przy pisaniu bardzo niskopoziomowo - sterowniki, jądra, moduły systemu operacyjnego. Również jeśli zależy komuś bardzo mocno na czasie - C się lepiej optymalizuje.

"C jest lepszy niż C++ przy pisaniu bardzo niskopoziomowo" i "C się lepiej optymalizuje" - czy mógłbyś podać jakieś źródła takiej wiedzy?

[[Ekspert] Hakken]

To wyniki z założeń samych języków: przykładowo w C znamy dokładne rozmiary typów zmiennych, a w C++ nie. Co to oznacza? Otóż przy niewielkiej pamięci ze stronicowaniem na żądanie może to spowodować istotny wzrost liczby błędów braku strony co mocno wpłynie na szybkość działania programu (będzie więcej operacji wejścia/wyjścia). Można zauważyć, że C++11 wprowadził typy int32_t, int8_t, ale to bez większego znaczenia. W językach wyższego poziomu powstają ukryte koszty, jak chociażby wirtualne funkcje dorzucają wskaźniki (dodatkowy krok przy wywoływaniu). Również biblioteki C++ są większe, przez co powstają większe programy.

Zresztą zastanówmy się czego byś chciał używać z C++ pisząc kod tuż przy sprzęcie/systemie:

obiektowości z dziedziczeniem itp.? Tracisz na szybkości (za wyższy poziom abstrakcji płacimy efektywnością).

Szablonów klas/funkcji? To faktycznie fajne, ale spowalnia kompilację (co też jest ważne np. dla jądra systemu).

Wyjątków? Ten mechanizm w C++ jest skomplikowany (zbyt skomplikowany!) co prowadzi do wielu problemów. Źle jest, kiedy program ma wycieki pamięci. Ale jeżeli ma je system operacyjny, to jest to absolutny koniec.

I żeby uniknąć docinków w stylu "nie rozumiesz wyjątków C++ i dlatego narzekasz, jestem ekspertem i są świetne!" - wiem jak działają. W Google też wiedzą i dlatego ich nie używają.

A jeśli to nie jest przekonujące, to spójrz na linuksa - jest w C (nie tylko ze względów historycznych i awersji doń Linusa)

EDIT:

jeszcze wspomnę, bo w sumie zapomniałem: w samym jądrze, tak głęboko jak się da, nie masz nawet dostępu do bibliotek, więc nawet zarządzanie pamięcią jest trudne, to klasy i biblioteki z C++ nie do końca są tym, co tam jest potrzebne,

[Sevard]

wzorce

Co przez to rozumiesz? Jakbym miał strzelać, to obstawiałbym template'y, ale przecież one pozwalają na unikanie kopiowania kodu, a funkcjonalności języka zbytnio nie rozszerzają.

Bardzo częsty błąd. Do tego są najczęściej używane, ale sposób ich działania jest dużo bardziej skomplikowany i pozwala na dużo ciekawsze zabawy. Właściwie szablony są największą różnicą między C, a C++.

klasy wirtualne

Zakładam, że chodzi Ci o klasy z funkcjami wirtualnymi (a nie jakieś wirtualne dziedziczenie czy inne cuda).

O metody wirtualne i klasy abstrakcyjne, zjadło mi się parę słów.

większość innych rzeczy da się w C zrobić bez jakiegoś większego kombinowania.

Zgodnie z wikipedią, cztery podstawowe cechy OOP to abstrakcja, hermetyzacja, polimorfizm i dziedziczenie. Hermetyzacji nie zapewnisz, polimorfizm to chyba przez wskaźniki na funkcje (jak dla mnie takie rozwiązanie podpada pod "większe kombinowanie", ale z drugiej strony pozwoliłoby na jakąś formę dynamicznego typowania, czy może raczej swoistą odmianę wzorca decorator).

C pozwala na naprawdę sporo i wbrew pozorom nie trzeba aż tak bardzo kombinować. Trzeba jednak naprawdę nieźle znać język.

Enkapsulacja

Polimorfizm

Tak w ogóle do przeczytania do poduszki.

A jeśli to nie jest przekonujące, to spójrz na linuksa - jest w C (nie tylko ze względów historycznych i awersji doń Linusa)

Na chwilę obecną Linux na platformy x86/x64 jest napisany w C, a nie w C++ wyłącznie z tych dwóch powodów (historyczność + awersja Linusa oraz paru innych programistów do C++). Większości tych mechanizmów, które powodują spadek wydajności można po prostu unikać. C++ tak naprawdę nie jest dużo wolniejszy od C (w niektórych zastosowaniach jest nawet szybszy). Przez te wszystkie lata kompilatory poszły naprawdę mocno do przodu i szybkość kompilacji jest bardzo podobna, a i jakość wynikowego programu jest dużo lepsza niż jeszcze parę lat temu.

Poza tym Mormegilowi raczej nie musisz tłumaczyć czemu wyjątki nie zawsze są najlepszym rozwiązaniem.

[[Ekspert] Mormegil]

A źródeł wiedzy wciąż brak. To może ja sobie pozwolę na przykład.

Mamy N typów urządzeń do obsłużenia. Mają identyczny interfejs, ale każde wymaga nieco innej obsługi.

Rozwiązanie w stylu C:

enum Type { Type_1, Type_2, ... , Type_N };

int dispatch(Type type, Params* params)
{
   switch (type)
   {
   case Type_1: handle_type_1(params); break;
   case Type_2: handle_type_2(params); break;
   ...
   case Type_N: handle_type_N(params); break;
   }
}

Rozwiązanie w stylu C++

class Base
{
   public: virtual handle(Params* params) = 0;
}

int dispatch(Base* obj, Params* params)
{
   obj->handle(params);
}

Pytanie brzmi: dla jakiego N rozwiązanie w stylu C jest szybsze i dlaczego tak jest?

C znamy dokładne rozmiary typów zmiennych

Tego chyba nie zrozumiałem. Typy bazowe nie mają zdefiniowanego konkretnego rozmiaru ani w C, ani w C++. Zakładam więc, że nie o typy bazowe chodzi. W C są jeszcze struktury, które w C++ mają odpowiednik w formie POD, ale rozmiar jest "znany", więc też pewnie nie o to chodziło.

W C++ mamy dodatkowo klasy. Tutaj rozmiar nie może być znany, ze względu na polimorfizm. Przecież nie wiemy z jakim typem mamy do czynienia. Siłą rzeczy nie możemy polegać na rozmiarze typu.

Szablonów klas/funkcji? To faktycznie fajne, ale spowalnia kompilację (co też jest ważne np. dla jądra systemu).

Co do używania szablonów. No wydłużają czas kompilacji, mogą też generować więcej kodu. W zamian generują kod dostosowany do sytuacji, a co za tym idzie, potencjalnie szybszy.

Co do wyjątków. Ja z nich nie korzystam. Moje interfejsy zwracają int. Z moich testów wynika, że sama obecność mechanizmu obsługi wyjątków trawi około 10% czasu CPU w aplikacji pokroju gry 3d.

Za to ciekawi mnie skąd założenie, że napiszę coś w stylu "nie rozumiesz wyjątków C++ i dlatego narzekasz, jestem ekspertem i są świetne!" ?

A jeśli to nie jest przekonujące, to spójrz na linuksa - jest w C

Wolę mieć własną opinię bazującą na faktach, niż cudzą.

[[Ekspert] Hakken]

Dokładne rozmiary zmiennych:

w C są typy, które mają stałą szerokość (czyli na przykład właśnie int8_t, int32_t), podczas gdy w C++ pojawiły się dopiero przy C++11 (wcześniej były tylko standardowe inty, na które jest tylko dolne ograniczenie). Przez to mogły powstawać problemy z pamięcią, o których wspominałem wyżej.

Co więcej, nie jestem pewny czy klasy w C++ trzymają kolejność zmiennych. Structy tak, przez co odpowiednie posortowanie zmiennych ma znaczenie, nie wiem jak w C++.

N urządzeń:

Przy takiej implementacji oczywiście okaże się, że C++ jest o rzędy wielkości szybszy, ale to jednak powinno sugerować, że w C też da się to zrobić lepiej. Trzeba po prostu w C zrobić mechanizm analogiczny do polimorfizmu.

Jak?

W C++ model jest taki: klasa urządzenie z metodą wirtualną zrób, po której dziedziczy N różnych urządzeń, każde jakoś nadpisuje tę metodę.

W C natomiast należałoby zrobić N structów, w których trzymasz wskaźnik na funkcję której to specyficzne urządzenie wymaga.

Takie rozwiązanie da wyniki już bardzo zbliżone, bo w gruncie rzeczy tak działa polimorfizm w C++. Ponieważ wykonujemy nie więcej operacji niż w C++ (a zapewne pomijamy jakiś narzut związany z obiektowością), to program w C powinien być nawet nieco szybszy.

Co do szablonów to zgadzam się, że są bardzo wygodne i daję za nie plusa C++. Polemizowałbym z tym, że kod lepiej dostosowany do sytuacji - po prostu w C trzeba by go więcej napisać, żeby pokryć te pokryć wszystkie przypadki użycia. Na niskim poziomie raczej nie potrzebujemy aż tak mocnej ogólności, żeby szablon był konieczny.

Wyjątki:

Nie zakładałem, że tak napiszesz, to raczej dla innych czytelników którzy mogliby się przyczepić. Może faktycznie trochę zabrzmiałem agresywnie.

[[Ekspert] Mormegil]

Zasadniczo switch powinien być realizowalny jako look-up table i jako taki być szybszy niż dynamiczne wywołanie funkcji.

Jednak wzrost ilości typów dość szybko sprawi, że tablica zrobi się duża. Kompilator zacznie stosować jakieś sztuczki, żeby ograniczyć rozmiar kodu, a te z kolei wpłyną na wydajność.

Na procesorze Core 2 Duo, kompilator C++ z VS 2010, switch był szybszy dla N poniżej 20 - 30.

Zaproponowane przez Ciebie rozwiązanie jest oczywiście słuszne. Masz też rację, że pewnie będzie szybsze. Oczywiście standard tego nie definiuje, ale w praktyce będzie szybsze o jedną dereferencję tablicy wirtualnej. W zamian obiekty C++ mogą być mniejsze, bo same nie przechowują wskaźników do swoich metod (w C też tak można).

Rzecz w tym, że robisz ręcznie coś co C++ może zrobić za Ciebie. Przewaga C++ polega na tym, że Ty masz mniej kodu. Mniej kodu oznacza mniej błędów. No i warto pamiętać, że w C++, też można zrobić strukturę ze wskaźnikiem na funkcję.

No i ostatnia sprawa. Koszt wywołania funkcji wirtualnej jest często znikomy w porównaniu z kosztem wykonania samej funkcjonalności. Także warto się zastanowić czy ta dodatkowa praca ma sens. Może lepiej poświęcić ten czas na optymalizację algorytmów?

Te typy ze zdefiniowanymi rozmiarami to są chyba zrobione jako typedefy w pliku stdint.h. Nic nie stoi na przeszkodzie zrobić coś takiego samemu. Nie wiem jak Linux, ale WINAPI też dostarcza typedefy tego typu.

Koszmarne rozwiązanie. Zaśmieca globalną przestrzeń nazw oraz wymaga włączenia nagłówka, w efekcie średnio się nadaje do publicznych interfejsów.

Oczywiście, że kolejność pól jest zachowana w C++. Zresztą nie tylko przy samym układzie pamięci, ale także przy inicjalizacji i deinicjalizacji pól.

Podsumowując. Nie przekonałeś mnie, że:

- przy tworzeniu niskopoziomowego oprogramowania C++ jest gorszy od C;

- C się lepiej optymalizuje.

Moim zdaniem C++ jest lepszym wyborem. Przede wszystkim dlatego, że C++ to tak naprawdę C + masa przydatnych narzędzi.

No i w C++ nie muszę robić typdefa, żeby zdefiniować enuma czy strukturę.

[JamesVoo]

To ja sobie pozwolę wciąć się w te dyskusję i zdać bardzo laickie pytanie, ale po tym co przeczytałem tutaj widzę że muszę bardzo mocno zweryfikować swoje informacje

Planuje się zacząć bawić w pisanie mobilnych aplikacji.

Na razie podstawy C++ mam w miarę opanowane i chce się za to wziąć na poważniej.

Więc pytanie.

W którym kierunku najlepiej iść aby tworzyć multiplatformowe aplikacje?

I głównie chodzi o game design.

Według wcześniejszej wiedzy myślałem że to czas aby przerzucić się w pełni na C# i ogarniać ten język, ale po tym co tutaj przeczytałem myślę o tym aby wziąć się porządnie za C++

[[Ekspert] Hakken]

Rzecz w tym, że robisz ręcznie coś co C++ może zrobić za Ciebie. Przewaga C++ polega na tym, że Ty masz mniej kodu. Mniej kodu oznacza mniej błędów.

Tak, jest to wybór między drobnym zyskiem na czasie, a krótszym kodem. Zasadniczo to cała przewaga czasowa C nad C++ jest w tym, że możesz pominąć krok lub dwa, który wykona C++. To miałem na myśli pisząc o lepszej optymalizacji.

W dzisiejszych czasach faktycznie różnice w czasach są minimalne, dawniej kompilator C++ był znacznie gorszy.

Może lepiej poświęcić ten czas na optymalizację algorytmów?

Algorytmy można oczywiście zoptymalizować tak samo w obu językach, natomiast w systemach czasu rzeczywistego nawet ta milisekunda narzutu przez funkcje wirtualne może coś zmienić.

Warto jednak ciągle pamiętać o problemie, który jest w samym centrum jądra, mianowicie w systemie musi być pewien kawałek kodu w assemblerze, a potem po kolei dodawane są elementy, więc tworzenie klas może być uciążliwe, bo oczywiście nie działa tam jeszcze nawet zwykły malloc.

[Sevard]

Przy takiej implementacji oczywiście okaże się, że C++ jest o rzędy wielkości szybszy, ale to jednak powinno sugerować, że w C też da się to zrobić lepiej. Trzeba po prostu w C zrobić mechanizm analogiczny do polimorfizmu.

Niekoniecznie. Konstrukcja switch case w C oraz C++ jest kompilowana do jednej z kilku możliwych postaci (zależy to od kompilatora oraz kodu, który obrabiamy). Do przeczytania.

Czyli sporo zależy od tego co z tym zrobi kompilator.

[[Ekspert] Mormegil]

JamesVoo << "mobilne", "multiplatformowe" i "game design", zainteresuj się jakimś gotowym silnikiem. Unity3D czy UE4.

[JamesVoo]

Właśnie rozważałem Unity, ale z tego co ogarniam Unity bardzo się lubi z C#, a z tego co wyczytałem w tej dyskusji w takim zastosowaniu lepszy by był C++

[[Ekspert] Hakken]

Ta dyskusja chyba nijak się nie odnosi do unity, ani do gamedevu ogólnie.

[JamesVoo]

@Hakken - Odnoszę się konkretnie do tego posta Sevarda

http://forum.cdaction.pl/index.php?showtopic=245248&st=100#entry3951946

[Sevard]

C++ również nie ma problemów z Unity. Zresztą kilka sporych gierek wyszło lub niedługo wyjdzie w oparciu o połączenie C++ i Unity. Może i w przypadku C# jest łatwiej, ale coś za coś. Użycie C# będzie prostsze i przełoży się na krótszy czas pisania aplikacji, a użycie C++ da Ci program, który jest bardziej przenośny i najpewniej lepiej zoptymalizowany jeśli chodzi o wydajność.