För/nackdelar med Java om man jämför med C++

der argummentet var svårt att möta

10 poäng till Sunray! En som fattat galoppen

Är ju inte alltid man kan ge bort källkoden hur som helst Och kompilera programmen själv.. I Linux är det rätt vanligt, men hur många windowsanvändare har en C-kompilator tro? (iof e inte inte så jobbigt o kompilera till win men men). En fördel som ni inte tagit med e att man i java kan göra java-applets.
Iaf så har du inte programmerat förut så e det nog lättare o lära sig o göra enkla java-program än c++-motsvarigheten skulle jag tro. Sen e det ju aldrig en nackdel o kunna både java o c++, dom är ju bra på olika saker, precis som svoctor skrev.

några snabba kommentarer till ett fåtal av dina minus...

Operator overloading kan kanske kännas som "trevligt", "kul" och "tufft" hos C++/C# människor men det finns ett perfekt skäl till varför det inte finns i Java... Det är helt enkelt onödigt svårt att överblicka koden.. Tänk på att en stor del av programmering på lite mer professionell nivå går ut på att gemensamt jobba med samma kod... Du vill helt enkelt förenkla koden för de andra... samt så hör det till en god sed inom OOP att använda metoder istället för kryptiska operators..

med andra ord...

MyCollection stuff1
MyCollection stuff2
....
....
MyCollection allStuff = stuff1.addMoreStuff(stuff2);

istället för..

MyCollection stuff1
MyCollection stuff2
....
....
MyCollection allStuff = stuff1 + stuff2;

är väl betydligt snyggare.. eller?

Multipelärvning går som någon nämnde här att lösa till en viss del med interfaces och "smart" användning av ordinär ärvning i Java..

En av Javas absolut största styrkor är faktiskt portabiliteten... även om du nu saknar en SDK så är det busenkelt att installera och få igång...

Samma argument som i fallet med op-overload gäller även ditt påpekande med mer restriktiv syntax... se det som en fördel och inte en nackdel

en mycket enkel och bra sammanfattning faktiskt...

misko: Fördrar nog + istället för AddMoreStuff() (utan tvekan)

Som i min CMesh klass där [] är överlagrad, så går Mesh[GroupIndex][TriangleIndex][VertexIndex], det går alltså inte i Java? Värdelöst!
Om man vill göra en matrisklass t.ex., då vill man nog ha [][].

Eller en vektorklass:
CVector a,b,c;
c = (a + b).Normalize()

Att se att operatoröverlagring inte finns som nått positivt var det sjukaste jag hört. Sen att det inte finns några pekare i Java, så begrännsande!

Och templates, hur ska man klara sig utan metaprogrammering?

Argh! Skräp språk!

Java känns väldigt mycket som en barnvakt... bara för att man kan göra sig illa om man använder en riktig kniv så förbjuds man att använda allt annat än smörkniv. Det borde väl snarare vara upp till programmeraren att skriva bra kod än till språket. Java är designat för att vara lätt för nybörjare men helvetiskt för riktiga programmerare.

Försök använda en Complex-klass utan operatoröverlagring...
Complex a,b,c,d;
a = a.add( b.multiply( c.subtract(d).add(b) ).pow(a, d) ) );
Hur fint blir det?

Den här diskussionen känns gammal och uttjatad. Den förekom redan för 20 år sedan när man dödförklarade cobol, som fortfarande lever kvar i högönsklig välmåga. Jag räknar C++/C/Java/C# o.s.v. till samma språkfamilj och detta är "min" språkfamilj som jag huvudsakligen programmerar i. Alla fördelar för de olika språken gäller endast när man sätter dem i sitt sammanhang där behov och tillgång avgör val. Hittills har väldigt få språk helt och hållet "dött" ut (undantag finns) utan de flesta lever kvar, även om det sker i marginalen.
Hela "min" språkfamilj är väl värd att kunna och vilket av språken du lär dig först är helt upp till dig själv.

Det finns fler språk som är bra att kunna, t.ex. VB/ASP...

Jaja... det var förståss oundvikligt att en tråd som handlade om för/nackdelar med java vs C/C++ skulle börja innefatta diskussioner om vilket språk som är "bäst".
Eightys sammanställning i det allra första svaret är det som bidragit mest imo. Objektivt, klart och tydligt, även om vissa tydligen vill ha med "Tjejigt" på minussidan också...

Som utvecklare kring stordatorsystem med krav på plattformsoberoende och snabba lösningar (kunderna blir ju ledsna o kinkiga om man sitter för länge) så är java det som passar bäst för mitt dagliga arbete.

är inte C#(seesharp) en hybrid av C/C++ och java? *lekman* har bara gått en sunkig c/c++ kurs på gymn. där man fick VG för att skriva av ett papper per lektion

har fått för mig att programmerings-språket brainfuck är det enklaste om man e nybörjare !
--

Hello World program

>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[-]>++++++++[<++++>-]
<.#>+++++++++++[<+++++>-]<.>++++++++[<+++>-]<.+++.------.--------.[-]>++++++++[
<++++>-]<+.[-]++++++++++.

/tjipp

edit : och JA det är ren brainfuck-source i [ code ] taggen härovan

Hybrid eller inte, det finns orsaker till att MS gjorde det...
Vad gäller det andra hm... språket vet jag inte om jag vill lägga till det i "min" språkfamilj. Har du lagt till det i din? Kanske rent av modersmål ;-). Det är kanske det som ungarna mumlar när de kommer till världen?

är det inte mysigt? det finns tillochmed converters, som gör om C till brainfuck helt underbart om man inte vill förstå ett dyft

[offtopic]

Finns brainfuck på riktigt alltså? Jag läste om ett språk som skulle bestå av endast whitespace. Roligt koncept.

http://compsoc.dur.ac.uk/whitespace/
http://search.cpan.org/author/DCONWAY/Acme-Bleach-1.12/lib/Ac...

inte speciellt fint.. men du får faktiskt vidga dina vyer här lite...

i det här fallet så hade det varit att föredra, att exempelvis implementera en hjälpklass där man erbjuder metoder för diverse manipulering av Complex...

det är ett extremt vanligt misstag att tro att det som kan skrivas kortast/snabbast/snyggast är det som också är mest optimalt...

andra kommer att ändra/vidareutveckla/felsöka din kod... och då vill man inte förlora en massa tid på att behöva lista ut vad varje operator egentligen gör med objekten... skapar man istället metoder eller hjälpklasser på ett korrekt sätt, så undviker man det problemet..

Vad är problemet här egentligen?
Är det så otroligt mycket jobbigare för dina händer att skriva:

c = a.add(b).normalize();

?

[QUOTE]
Att se att operatoröverlagring inte finns som nått positivt var det sjukaste jag hört.
[/QUOTE]

om "operatoröverlagring är negativt" är verkligen det absolut sjukaste du nånsin hört i hela ditt liv, så borde du kanske lämna den mörka källare du sitter i och gå ut utomhus

Det är fulare och det är jobbigare. Kanske inte så mycket i detta fall, men i Complex exemplet.

Varför tror du man gjorde högnivåspråk, som har + på vanliga tal? Lite jobbigt att skriva add a,b (asm) osv..

som sagt.. tänk i lite större banor än enkel vektor-addition... vad händer om du definierar fler egna varianter på additionen av vektorer? hur ska du skilja på dem på ett begripligt sätt?

metoder erbjuder dig möjligheten att explicit förklara för alla vad som händer med objekten..

prata med lite programmerare som jobbat lite med OOP och då gärna i större team med "alla äger koden" principen, så får du se vad de tycker om op-overloading

C++ är ju gjort för att man ska kunna använda det till stora projekt.

Självklart kan man flumma bort sig om man använder operatoröverlagring felaktigt eller överdrivet, men använder man det som det ska användas är det bara bra.

Du har rätt när du säger att kortare kod inte behöver vara bättre, men i fallet (a+b) så är det mer intuitivt än a.add(b) eller add(a,b), och det senare beskriver inte mer än det första. Om det finns flera olika saker man vill göra som handlar om addition överlagrar man givetvis inte + till en av dem (eller i värsta fall andra operatorer)... bara för att nybörjare inte kan hantera det måste man inte förbjuda det... det är bara begränsande.

Övertydlig kod kan bara vara förvirrande ibland om det är uppenbart vad den renare koden gör (exempel: if (var) vs if (var != null)).

brainfuck finns och frodas, har ingen url i huvudet, men sök på brainfuck på google bara

Det är inte bara scalärer som har en additiv identitet, så jag tycker det känns naturligt att kunna definiera en additions operator t.ex. När man definierar en matematiskt operator ska den vara matematisk korrekt, därför ska inga egna varianter existera (inte som en operator iallafall). Sen är det inte bara matematiska operatorer man vill överlagra, andra kan vara t.ex. new och delete.

Jag snackar med spelprogrammerare dagligen, men du är då den första som säger så här. Med extremt dåliga argument dessutom, som "svårt att överblicka koden", vilket det inte är om man följer matematiken när det gäller matematiska operatorer. Själv tycker jag detta är mycket svårt att överblicka: "a = a.add( b.multiply( c.subtract(d).add(b) ).pow(a, d) ) );"

Ett exempel som kan förekomma både i Java och C++ (eftersom jag inte tror datorgrafik hör till Javas utvecklingsområde) är om man vill göra en LargeInt-klass, som skall representera stora integers. Då kan man t.ex. välja antal bytes som den skall representeras av som ett template-argument (LargeInt<16> MyInt;). Men sen vill man ju gärna att den ska uppföra sig som vanliga int, eller hur? Alla vanliga matematiska operatorer, men sen även iostreams operatorer så man kan skriva ut värdet på skärmen/fil, eller läsa in ett värde från tgb/fil. = och == krävs också för tilldelning och jämförelse osv... Men allt detta är totalt omöjligt i Java av det jag sett.

problemet är att det du pratar om är undantag.. och hade man använt op-overload vid tillfällen där det inte går att missförstå vad dessa innebär, så är det naturligtvis uppenbart att det hade fungerat relativt bra...

men problemet är att man inte kan vara så naiv och tro att det slutar där.. istället så hamnar man i kod där hardcore-puckon helt plötsligt op-överlagrar på alla möjliga sätt...

du tycker att "a.add(b)" är otroligt förvirrande jämfört med "a + b".. jag tycker att det är tvärtom eftersom jag förlorar kontrollen över vad som sker med objekten.. i metodnamnet kan jag explicit berätta vad som exakt sker med "a" och "b"... i det andra fallet så försöker jag göra en addition på två stycken objekt, något som inte är definierat på ett generellt sätt..

Nej!, "a.add(b)" sa jag inte var förvirrande, däremot "a = a.add( b.multiply( c.subtract(d).add(b) ).pow(a, d) ) );".

Bara för att du sett nån nisse som verkar överlagra + som - och * som ^, behöver inte alla göra det. Som mitt exempel med LargeInt, bevisar svagheten i att inte ha operatoröverlagring. T.ex. kanske du får konstiga resultat när du utvecklar LargeInt och switchar därför till vanliga int för att testa. Då vill man då inte sitta och översätta + till add osv..

Tycker du är löjlig... Nuff said.

MyCollection stuff1
MyCollection stuff2
....
....
MyCollection allStuff = stuff1.addMoreStuff(stuff2);

MyCollection stuff1
MyCollection stuff2
....
....
MyCollection allStuff = stuff1 + stuff2;

Nr2 är bättre och tydligare. Jag funderar direkt om i Nr1 om stuff1 kommer innehålla stuff1 och stuff2 eller om den bara returnerar en ny MyCollection.

jag skulle kanske inte ha gett mig in i den här diskussionen.. för att att döma av den ovanstående meningen ("nuff said" är så förbannat tufft att säga nämligen) så har du fortfarande inte lämnat den tidiga tonåren..

Jag tänkar quota en mycket välutbildad kompis till mig.

-"Java är bara för bankbögar som programmerar GUI bara så att bankernas datorer skall se mer avancerade ut"

Du är den första programmeraren jag träffat på som inte tycker att operator overloads är guld!

Huh? Ska du börja gnälla på mig nu med!? Du dömmer hela mig på "Nuff said", en liten "förkortning". Mycket lågt!, trodde det handla om Java/C++?

Isåfall anser jag dig vara en liten fjortisgamer enligt din signatur.

Appro på overloads så skall du ta en titt på Lua. Där har dom något som heter metatabell som funkar lite som overloads och gör språket riktigt flexibelt. I Lua finns inte klasser t.ex. men du kan implementera dom själv just för denna metatabell.

C++          Java med JITC      Java utan
Integer division                               1.8  	1.8  	4.8
Dead code 	                        	3.7 	 3.7 	 9.5
Dead code with Integer division      5.4      5.7     20
Floating-point division 	            1.6      1.6     8.7
Static method 	                               1.8 	1.8 	6.0
Member method 	                           1.8      1.8     10
Virtual member method 	                1.8 	 1.8 	 10
 -||- with down cast and RTTI          11  	4.3  	12
(värdena är sekunder, så färre är bättre)

Villen Runtime användes i testerna ? Är du säker på att samma Runtime användes vid C++ och Java med JITC och att exakt samma optimeringsinställningar användes ? Om inte så är ju en helt orelevant mätning.....

En till sak. C++ har operator overloading, men det betyder inte att man måste använda det. Vet många som använder C++ men använder inte alla funktioner som finns i det. I Java kan du inte ens använda det för det finns inte.

Java har även en starttid som är bedrövlig tycker jag personligen.
Sedan det där med portabiliteten i Java ger jag inte mycket för. Inte ofta jag träffar på saker som funkar över flera platformar, om dom ens funkar dvs... Python och lite andra sköna scriptspråk tycker jag har visat på större portabilitet och smidighet.

Undrar också_hur det det mättes upp. Skulle vilja se koden för testerna. Btw, hur många platformar har JITC?