java czy c++

Dopiero zaczynam programować i jestem przed zakupem ksiżki która by mi to ułatwiła i nie wiem na jaki język się zdecydować JAVA czy C++
proszę o pomoc [sciana]

dziwne pytanie, jak chcesz byc programista to jeden jezyk ci nie wystarczy, tak mi sie wydaje

i jak zawsze polecam thinking in c++ & thinking in java

racja, ale zacząć trzeba od jednego...
ja bym zaczynał z c++, java jest bardziej do zastosowań sieciowych, <ort>rzadko</ort> się pisze aplikacje w javie...

Talib napisał(a)

rzadko się pisze aplikacje w javie...

Rzadko???? Ja mam uzasadnione obawy, że C++ odchodzi do lamusa.

Krolik napisał(a)

Talib napisał(a)

rzadko się pisze aplikacje w javie...

Rzadko???? Ja mam uzasadnione obawy, że C++ odchodzi do lamusa.

No to bedzie sie dzialo w swiatku linuxa i GNU w takim razie, oj bedzie sie dzialo ;]
Poki *nix zyja a z nimi C, poty C++ nie zniknie.
ALe te uzasadnieine bym uslyszal :)

Krolik napisał(a)

Rzadko???? Ja mam uzasadnione obawy, że C++ odchodzi do lamusa.

Oj bardzo odwazne stwierdzenie.
Uzasadnienia tez chetnie poslucham :)

Dopóki istnieje zapotrzebowanie na aplikacje działające w czasie rzeczywistym (np. gry, symulacje fizyczne) dopóty c++ nie zniknie. Java jest nadal za wolna do niektórych rzeczy. :P

Czy zaczniesz od c++ czy od javy to i tak bez znaczenia jesli obydwu chcesz sie nauczyć.

Znowu się zaczyna... A co za różnica który? To i tak będzie jeden z wielu. Nauczysz się każdego, jakiego będziesz potrzebował.

A tutaj jest pytanie, który jest pierwszy. Wobec tego z tych dwóch chyba prędzej bym Javę polecał. Chociaż to też nie jest jeszcze najlepszy wybór.

Może moje podejście jest trochę staroświeckie, ale... mimo wszystko zostałbym przy Pascalu jako pierwszym. Ew. może by Pythona spróbować. Wymusi od razu ładne formatowanie kodu, dosyć prosty i dosyć potężny. Dodatkowo nie ogranicza się tylko do programowania strukturalnego czy obiektowego, ale zawiera też elementy z języków funkcjonalnych. Bardziej istotne do nauki jest właśnie poznanie różnych podejść do programowania niż samego języka.

Ale wybierz sam (i nie słuchaj jaki język wyprze jaki. Za 5 lat może być jeszcze inna rewolucja).

Uzasadnienie jest takie, że w C++ a szczególnie w C można pomarzyć o takim bezpieczeństwie i o takich bibliotekach jak w Javie. W tej chwili middleware pisze się głównie w Javie. Jeśli biznes już używa powszechnie Javy, a C/C++ jest praktycznie w tej dzidzinie zapomniane, to siłą rzeczy wcześniej czy później to się przeniesie na większość pozostałych dziedzin. Jedyna szansa to C++ na platformie .NET, ale i tak ludzie wolą się uczyć Javy czy C# bo są łatwiejsze.

Co do systemów czasu rzeczywistego: w Javie można pisać systemy czasu rzeczywistego tak samo trudno jak w C. To, że piszesz program w C nie powoduje, że jest on od razu czasu rzeczywistego. Może wydajność jest nieco gorsza (maks. 1,5-3 krotnie) w przyp. Javy, ale w wielu zastosowaniach nie jest to problemem. W tel. komórkowych J2ME jest właśnie najpopularniejszą platformą tworzenia gier, a nie C/C++ (Symbian: bueee - dziurawy jak sito). Gry 3D na PCty też można pisać w Javie i wydajność wcale nie przeszkadza - obecnie procesory w grach i tak niewiele mają do roboty - muszą zajmować się prawie wyłącznie AI, grafikę generuje w 90% hardware na karcie.

C++ na pewno będzie nadal służył do projektów niszowych - systemy operacyjne, systemy baz danych i... maszyny wirtualne Javy. Oby to nie była prawda (nadal moim ulubionym językiem jest C++). Niestety wszystko na to wskazuje... :(

W każdym razie twierdzenie, że nikt nie używa Javy jest totalną bzdurą. Wystarczy zobaczyć na ogłoszenia dot. pracy. Dla programistów javy jest 2-3 razy więcej roboty (zwłaszcza J2EE).

O jakich biblotekach ty mowisz, co podobno mozna o nich pomazyc w C++.

A w sprawach bezpeiczenstwa, to w jakiej kwesti(jezeli chodzi o ochrone pamieci to proponuje sie zapoznac z zestawem biblotek boost). C/C++ jeszcze na dlugo pozostanie numero uno :] . Co do gier 3D w Javie, to pozostawiaja one wiele do zyczenia, Kazdy program napisany w OpenGl( ten sam kod), na bazie C++ jest o wiele wydajniejszy od tego w Javie. Dopoki Java nie przyspieszy, to nadal bedzie dobrym jezykiem, ale na pewno nie tak wszechstronnym jak C++. Jezeli chodzi o aplikacje sieciowe to w Javie pisze sie je szybciej, jednak ja i tak preferuje w tej sferze C++. Jest w nim o wiele wiekszy wybor biblotek do tych samych zadan, czego nie mozna powiedziec o Javie.

Chyba nie za bardzo odbieglem od pierwotnego tematu, ale tak dla pewnosci to sugeruje rozpoczac przygode od C++ [!!!]

Biblioteki do c++ owszem są. Nawet dużo. Problem z nimi jest jednak taki, że często nawzajem ze sobą kiepsko współpracują, stosowane są różne konwencje itp. Jak składasz jakikolwiek poważniejszy program, który używa kilku różnych bibliotek, to szybko robi się niezły bałagan. W Javie masz jedną wielką bibliotekę, w której masz 99% potrzebnych rzeczy. Jak jest potrzebne coś bardzo zaawansowanego od osobnego producenta to i tak masz gwarancję, że będzie współpracować z resztą API i będzie przestrzegać jedej konwencji.

Co do bezpieczeństwa:

• Nie wszystkie problemy z bezpieczeństwem w C++ są powodowane przez ochronę pamięci.
• STL jest tak zrobiony, że o naruszenie ochrony pamięci b. łatwo. Boost nie poprawia sprawy. Prawie nigdzie nie ma sprawdzania indeksów tablic, stringów.
• Smart pointery z Boost w porównaniu z jakimkolwiek garbage collectorem (z Javy czy .NET) są zabawką. Narzuty czasowe na kopiowanie wskaźnika ponad 1000%, niemożność zwalniania cykli referencji...
• Programiści C++ nie przywykli do używania GC, bo ulegają różnym mitom o niskiej wydajności. Fakt, używając wskaźników z boost można mieć takie fałszywe mniemanie.

Trollingowy temat... Zacząć od Pascala/Basica i tyle, po to są.

Ale jednego nie lubię, pisania bzdur i własnych wymysłów bez albo słabej znajomości tematu...

Krolik napisał(a)

Biblioteki do c++ owszem są. Nawet dużo. Problem z nimi jest jednak taki, że często nawzajem ze sobą kiepsko współpracują, stosowane są różne konwencje itp. (...)

No ta, bez urazy, ale kolejny zawodnik do "nie wiem jak tego użyć to se sam napiszę"?? I co ma biblioteka do języka??
Taki STL wywodzi się z obiektowego Smalltalka...
I chwała, że w C++ są szablony, a nie jakieś generics na poziomie byte-code :D

Krolik napisał(a)

Co do bezpieczeństwa:

• Nie wszystkie problemy z bezpieczeństwem w C++ są powodowane przez ochronę pamięci.

Oczywiście, większość przez głupote programistów. Co to ma wspólnego z językiem??

Krolik napisał(a)

• STL jest tak zrobiony, że o naruszenie ochrony pamięci b. łatwo. Boost nie poprawia sprawy. Prawie nigdzie nie ma sprawdzania indeksów tablic, stringów.

Taaaa... Widzisz, w języku nie wbudowanego ogólnego/standardowego sprawdzania zakresu tablic, ale dlatego można w nim robić "cuda" nie możliwe w innych językach...
Co do STL: że niby operator[] ci nie pasuje?? A myślisz, że po co jest at() w kontenerach?? Takie podejście daje ci przynajmniej wybór (czy wspominałem już o głupich programistach?)... Po co są algorytm (for_each, transform, itp.)?? Tam nawet nie musisz wiedzieć ile jest obiektów!
C++ nie jest prostym, łatwym i przyjemnym językiem, jego siła tkwi w prostocie, ale jest przez to tak bardzo trudny. Czy myślisz, że ludzie którzy stworzyli całe C++ i STL są tacy nierozgarnięci, żeby nie brać pod uwagę mnóstwa czynników dla których wybrali właśnie takie podejście (kontenery/iteratory/algorytmy)??

Krolik napisał(a)

• Smart pointery z Boost w porównaniu z jakimkolwiek garbage collectorem (z Javy czy .NET) są zabawką. Narzuty czasowe na kopiowanie wskaźnika ponad 1000%, niemożność zwalniania cykli referencji...

Haha, jeszcze dużo musisz się nauczyć o boost (ja zresztą też :) ), nie wiem co masz dokładnie na myśli, ale czy shared_ptr/weak_ptr nie są właśnie do tego przeznaczone...

GC? Cóż taka zabawka, no spróbuj sobie prawidłowo zamknąc socket w Javie w aplikacji wielowatkowej z przekazaniem socketa (referencji!) do watku obslugujacego klienta :D Ile to zabawy try{}/catch{}/finally{} parę razy, a jak nie zwolnisz to masz resource-leak, dlaczego?? Ano, bo gdy jest GC to nie ma destruktora, nie ma destruktora to potrzeba (kilka) try/catch/finally, inaczej zasób SYSTEMOWY nie zostanie zwolniony... Ja wiem, w programach na zalicznie można takie rzeczy olewać, itd.; ale nie mów mi, że to jest lepsze/gorsze...

A najlepsze jest to, że w C/C++ mogę mieć GC kiedy tylko (JA) chcę!
np. Boehm-Demers-Weiser conservative garbage collector.

Krolik napisał(a)

• Programiści C++ nie przywykli do używania GC, bo ulegają różnym mitom o niskiej wydajności. Fakt, używając wskaźników z boost można mieć takie fałszywe mniemanie.

Fju, mocny argument...
{GC: No to jak, zamknąc tego socketa już czy nie... Może jeszcze nie... Te trochę zajętej pamięci na bufory nie szkodzi chyba nikomu...} :D

A co do J2EE, wydaje mi się, że w Polsce (polskich "firmach") Java EE jest potrzebna tylko i wyłącznie dlatego, że baza Oracle ma narzędzia które nie dość, że są w Javie to jeszcze można w Javie wewnątrz Oracle napisać całą aplikację bazodanową :) A nie dla jakiś głębszych celów :>

[sorki za trochę czytania, jeśli się gdzieś walnąłem to proszę mnie poprawić, tylko bez polemik bez sensu... najlepiej EOT]

Dobra, masz sporo racji i piszesz o rzeczach, które wiem. Też mnie się podoba to że w C++ mogę mieć GC, a mogę nie mieć (i to w jednym programie na raz). Java ma parę istotnych wad, nie będziemy tu dyskutować o tym który język jest lepszy i do jakich celów.

Napisałem tylko, że zauważam powszechną tendencję wchodzenia Javy w miejsca, które do tej pory były zarezerwowane dla C/C++ i próbuję podać jakieś przyczyny. Wg TIOBE Java też jest popularniejsza niż C++. To nie jest moja opinia tylko fakt, że na komórkach króluje J2ME, a systemy rozproszone pisze się na ogół używając EJB. C/C++ uchodzi wśród większości programistów za język trudniejszy i zarazem ułatwiający popełnianie błędów bardziej niż Java. To, że ja, czy Ty umiesz pisać bezpieczne aplikacje w C++ nie oznacza, że tak jest ze wszystkimi. Aplikacje w Javie jakoś mi nie zamykają nagle niezapisanej pracy z błędem "Access violation" i nie umożliwiają wykonania zdalnego kodu. W każdym razie naprawdę trzeba się bardzo mocno nagłowić, żeby aplikacja w Javie miała takie dziury. Java była projektowana z myślą o bezpieczeństwie, C++ z myślą o wydajności. Bezpieczeństwo jest potrzebne w większości przypadków, wydajność jedynie w nielicznych*. Dlatego na początek polecałbym Pascala, później Javę, a dopiero na końcu C++. Inaczej można się zniechęcić.

P.S. Odpowiedz mi szczerze: ile projektów korzysta z shared_ptr w boost? Ile projektów korzysta z Boehm GC (BDW)? Kilkanaście? Kilkadziesiąt? Kilkaset? Raczej nie więcej. Na tym forum zrobiłem kiedyś ankietę, z której wynikło, że prawie połowa nie wie co to jest GC, a większość nie wie, że coś takiego jest dostępne dla C++. Wybór GC dla C++ jest zresztą mizerny. No cóż, popyt steruje podażą.

*Problemy z wydajnością zawsze można rozwiązać w dosyć prosty sposób - dokupić mocniejszą maszynę. Problemy z bezpieczeństwerm można rozwiązać przez zatrudnienie lepszych i bardziej zdyscyplinowanych projektantów i programistów. To drugie jest na ogół o wiele droższe.

marcinEc napisał(a)

C++ nie jest prostym, łatwym i przyjemnym językiem, jego siła tkwi w prostocie...

Podoba mi sie to zdanie!

Kolejna duskusja na temat teego co jest lepsze i dlaczego.... Niektórzy zapominają o najważniejszym: Java nie jest do wszystkiego. W problemach, do rozwiązywania ktrych została zaprojektowana jest bazkonkurencyjna, a wszystkie pozostałe ma głęboko gdzieś... I dobrze.

NoLoginException napisał(a)

Kolejna duskusja na temat teego co jest lepsze i dlaczego....(...)
Może tak, może nie, ale przynajmniej dyskusja z racjonalnymi argumentami z której czytelnik (np. ja) może się wiele dowiedzieć.

Niektórzy zapominają o najważniejszym: Java nie jest do wszystkiego. W problemach, do rozwiązywania ktrych została zaprojektowana jest bazkonkurencyjna, a wszystkie pozostałe ma głęboko gdzieś... I dobrze.
Ja śmiem to rozszerzyć to twierdzenia, że każdy języka ma zastosowania do których jest idealny i takie do których można go użyć tylko "na siłę".

hejhejhej napisał(a)

marcinEc napisał(a)

C++ nie jest prostym, łatwym i przyjemnym językiem, jego siła tkwi w prostocie...

Podoba mi sie to zdanie!

Wyciagniete z kontekstu :)