Java / C++

Java har jo klassen Object som altid er øverst i hierakiet. Derfor kan bare bare bruge Object som parametertype, så kan metoden kaldes med alle typer af objekter. Dog skal objektet så downcastes til en specifik type før du kan anvende de metoder objektet har (bortset fra equals, toString osv som jo ligger i Object klassen)
Men det er jo lidt besværligt at skulle caste så meget, så det er nok derfor at templates kommer med i den næste version af Java

OK. det lyder fornuftigt..

Hvordan løser Java så Call by value?

Simple typer (int, float osv) er altid by value.
Objekter (inklusiv arrays) er altid by reference.
Hvis man har behov for at kalde en metode med en kopi af et objekt, ligger der i Object klassen metoden clone() til selvsamme formål. Men der skal du nok lige læse i javadoc'en for den metode, da der er nogle ting man lige skal være opmærksom på - eksempelvis skal klassen implementere Clonable interfacet før man kan clone.

Java har ikke noget der matcher C++ templates idag (kommer i 1.5 under navnet
generics).

Object svarer ikke til template snarere til void *.

Simple typer er helt normal by value.

Objekter er strengt taget reference by value. I det fleste tilfælde er forskellen
ikke stor. Men man kan kun ændre på objektet - man kan ikke udskifte objektet.

Er interfaces en erstatning for multipel arv?

Nej.

Det eneste implementation du kan arve fra interfaces et konstanter.

Interfaces er en speciel måde at lave en klasse med ene abstrakte metoder.

Så implementere multiple interfaces svarer til at arve fra flere klasser
med ene abstrakte metoder.

Det er separeret ud for at markere vigtigheden af at definere en kontrakt
for interface men fuld frihed for implementation.

->Arne.. Jeg tror ikke at du forstod mit sidste spørgsmål korrekt.. Det jeg mente var om man kunne opnå det samme ved hjælp af at benytte interfaces, som man jo kan med multipel arv...

Er det ikke det jeg klart svarer nej til 19:12:58 ?

Ang interfaces for multipel arv:
Jeg opfatter spørgsmålet på en anden måde end Arne. Og jo interfaces er en måde at opnå multipel arv i Java, idet en klasse her kan implementere et interface og derved få adgang til metoderne i interfacet, altså kan en klasse få adgang til mere end den ene klasse det er muligt at nedarve fra.

Interfaces er *ikke* multipel arv.

En klasse får ikke adgang til metoderne i et interface den implementerer - den
er tvunget til at have metoderne i et interface den implementerer.

Det er en "forpligtigelse" ikke en "service".

ok, det er vist for længe siden jeg har beskæftiget mig med Java :(

Man kan dog godt simulere multipel arv i Java vha inner classes:
class Ydre extends Parent1 {
  private class Indre extends Parent2{
    //herfra er adgang til både Parent1 og Parent2
  }
}

Jo, men funktionaliteten er alligevel ikke helt den samme da man skal
instantiere både ydre og indre klasse.

Det jeg mente med at interfaces fungerer som multipel arv er at man kan kommunikere på tværs af systemet mellem objekter som ikke har noget at gøre med hinanden, og på den måde dele funktionalitet fra flere objekter. Jeg er udemærked klar over at funktionaliteten skal være implemteret i begge objekter og har initialiseringen i det fælles interface.. For mig ser jeg den samme funktionalitet som eksisterer i multipel arv.. Jeg kan i hvert fald opnå det samme langt hen ad vejen..

Med interfaces kan du kun dele "forpligtigelse til at implementere funktionalitet"
ikke selve funktionaliteten.

(med undtagelsen konstanter)

Men der er gode grunde til at Java (og C# !) har fjernet multipel implementations
arv. Det bliver ofte noget forfærdeligt roderi. Og de tilfælde hvor det er
en god løsning i C++ er få.

Og så vil jeg også ligge et svar

Ja, det her du ret i Arne, men du kan godt se at du faktisk kan det samme som multipel arv.. Og jo, multipel arv er noget roderi, men det handler jo om at modulere virkeligheden og det er det en styrke når det behøves synes jeg. Men lad det nu ligge.. Mit næste spørgsmål går på om styrke og svagheder ved at alting er objekter i Java, og den GB collecter som jo tager sig af oprydningen, og forhindre en i at lave realtime applikationer i Java.. Hvad er jeres mening om den sag?

Jeg tror du er den eneste, der mener at man "faktisk kan det samme som multipel arv"
når man bruger interfaces. Det kan man ikke. Det har Arne tydeligt demonstreret.
Det er lidt skuffende du ikke kan læse det ud af hans indlæg. Hvad er det du
ikke forstår?

Garbage collection undgår de fleste memory leaks, som er en plage for
de fleste større C/C++ applikationer. Jeg tror at de fleste er enige
om at GC er vejen frem. C# bruger også GC. Jeg tror at det bliver standard
for alle nye general purpose sprog fremover.

Det er ikke godt til real time applikationer. Men det er en niche. Og det vil
kræve specielle operativ systemer og speciell sprog at opnå de helt rigtige
real time egenskaber.

Det jeg mener er at hvor man arver metoder fra flere klasser ved multipel arv, og på den måde har metoderne fra begge klasser, er som jeg ser det det "samme" om at lave et interface mellen to objekter og instantiere metoderne der, og så implementere metoderne i begge objekter. Altså interfacet fungere nu som en slags samlingstabel ml. de to objketer. Det er en anden måde, ja, - men jeg opnår da det samme. Nu er de pludselig i familie med hinanden. Sådan opfatter jeg det i al fald.. Er det da helt forkert opfattet..?

Jow, og jeg er sikkert også i familie med kongen af Bhutan, hvis vi går langt nok ud.
Men det er jo blot ikke det samme som multipel arv. En arving til interface
arver en tom skal, som han selv skal fylde ud, og hver arving gør det sikkert
på sin egen måde. En arving, der deltager i en multipel arv, får det hele
serveret i allerede realiserede metoder.

Der er en verden til forskel.

Men det sjove er jo så at man kan bruge interfaces til noget, og ret beset ikke
savner multipel arv.

Når man implementerer et interface arver man kun abstrakte metoder.

At arve en abstrakt metode og at arve en ikke abstrakt metode lyder måske
nok som lidt af det samme, men er i virkeligheden meget forskelligt.

*S* Ja ja, erik.. Du er skam meget morsom.. Og jeg har aldrig påstået at multipel arv og interfaces er det samme, men kun at man kan opnå det samme som du jo åbenbart også giver mig ret i til sidst.. Når du nu åbenbart er så klog at så vær lige rar at forklarer mig at hvordan Java kompencerer for dets mangel på overloading af operators?

Jeg kan godt sætte pointene op hvis i vil.. Jeg har stadig et par spørgsmå endnu..

Overloading af operators er blot syntaktisk sukker - i Java bruger man bare metoder.

"man kan opnå det samme" - nej, jeg giver dig slet, slet, slet ikke ret i
at man kan opnå det samme med interfaces som med multipel arv. Det kan man
ikke, og det er det vi forsøger at få dig til at forstå. Igen: hvad er det
du ikke forstår i det vi skriver?

Metoder?? Hvordan foregår det om jeg må spørge? Du vil sammeligne to objekter med hinanden? Hvordan gør du det?

x.compareTo(y)

->Arne, Er der indbygget metoder for alle operatorer i Java? Og dette kun muligt fordi de alle objekter stammer fra samme moder OBJEKT?

Nej.

Man laver de metoder der er brug for. Ligesom man i C++ overloader
de operatorer man har brug for.

Du kunne godt lave en metode "sammenlign". Men man kalder den normalt
compareTo - og der er nogen praktiske fordele ved det, da noget kode
forventer at den hedder det.

Okay, jeg er med.. Men selv at lave sine metoder, er det smartere eller mere besværgeligt end operator overloading? Hvad er din erfaring?

Ved du om C++ har innerclasses?

Java blev designet med et formål om at være simpelt. Operator overload røg ud
på den konto. Jeg bruger af og til operator overload i C++ og C#. Så jeg ville
ikke have noget imod at man tilføjede det til Java i en eller anden form. Men
på den anden side er det ikke noget stort problem. Det er ikke så tit at det virkeligt betyder noget for læseligheden af koden (primært når man laver
klasser som der kan regnes på: matricer, komplekse tal etc.).

Man kan godt definere classes indeni classes i C++.

Men det virker på en lidt anden måde.

Tilfældigt faldt jeg over denne fil:
http://pami.uwaterloo.ca/tizhoosh/Similarities%20and%20Differences%20Between%20Java%20and%20C-CPP.pdf

Den behandler desværre emnerne ret overfladisk, men du kan da lige skimme den...

Der er også en del fejl i den.

Hm ok, jeg syntes nu ikke der var noget der sprang i øjnene.. Men generelt er der udemærkede Java vs. C++ sider på nettet (og bøger, men i den forbindelse vil jeg fraråde Timothy Budd's Java for C++ Programmers der er en noget rodet fornøjelse)

The C++ preprocessor basically performs an intelligent search and replace all
identifiers that have been declared using the #define or #typedef directives.

(det er typedef ikke #typedef)

Java forces programmers to use classes when the functionality of structures
and unions is desired.

(det er ikke ligetil at lave en union med en class)

C and C++ have no built-in support for text strings.

(STL strings er altså opfundet)

Ikke fordi at de har nogen speciel betydning for sammenligningen mellem
Java og C++, men det gør et lidt sjusket indtryk.

Okay Søren, kigger lige lidt på den.. Ja, og ærgeligt at der er fejl i den, som Arne påpeger..

Kan jeg regne med det som står under punktet MISCELLANIES?

De eneste som falder mig i øjnene er:

Unlike C++, Java provides a true boolean type.

jeg mener at bool idag er standard

The "namespace" issues prevalent in C++ are handled in Java by including
everything in a class, and collecting classes into packages.

C++ har namespaces idag

Ja, namespaces har c++ i al fald.. Kan du komme på nogle fordele og ulemper ved at Java har den single root hierarki, som det jo har?

Du mener at alt arver fra Object ?

Fordele:
  - nødvendig erstatning for void*
  - nem måde for SUN at ligge metoder på alt (toString, equals etc.)

Jeg kan ikke umiddelbart se nogen specielle ulemper.

Har lige sat pointene op med 50. Er meget glad for den hjælp her..

En ulempe må vel være at downcaste vil jeg selv mene. Det er jo der Templates har sin styrke. Jeg går ud fra at Templates fungerer som OBJEKT i Java, eller det forkert da?

Templates er en meget god ting. De kommer i Java 1.5 som generics.

Så man undgår al det casteri. Husk at cast kun er besværligt ikke farligt
i Java, da man får en exception på forkert cast.

Jeg mener at Object er en erstatning for void* ikke for templates.

Ja, det er kun besværgeligt.. Øhm, det der generics.. Hvad er det nu lige det er?

Det er templates for Java.

Jeg har skrevet en artikel om Java 1.5, hvis du læser den er der eksempler
på brug af generics.

Hvor er den artikel henne? Den vil jeg da gerne se..

http://www.eksperten.dk/artikler/167

Ja, det ser da spændene ud Arne, men den må jeg lige nærlæse når jeg får bedre tid. *S* Det er jo noget kompliceret stof du har skrevet der.

Kender du den Modifiers som kaldes 'transient' den er vist ikke implementeret endnu, men den skulle være lidt mystisk..

transient er implementeret idag i Java.

Det er en markering af at en instans variabel ikke skal med når man serialiserer
objekter af den pågældende type.

Ja, meget fint..

Er errors så noget besværgeligt noget at benytte i Java?

Du mener exceptions ?

Java exceptions ligner faktisk C++ exceptiosn en del. Den største forskel er
at Java har både checked og unchecked exceptions.

Nææ, ikke bare exceptions, men også errors som skulle være noget low level noget.. Synes jeg har læst om det et sted, kan bare ikke huske hvor..Hm, måske husker jeg forkert..

Fandt lige det her..Fra Ålborg universitet

Error:

Afspejler alvorlige problemer (interne fejl i Java systemet) som normalt ikke forekommer i et kørende Java system

Håndteres ikke under normale omstændigheder

Er ikke underlagt 'catch or specify' princippet

Kastes kun sjældent af vore egne programmer

Eksempler: For dyb rekursion, ikke mere arbejdslager, manglende metode eller felt, instantering af abstrakt klasse
 

At Error exceptions ikke er underlagt catch or specify princippet betyder at disse exceptions ikke skal specificeres i metoders throws clauses


De sidstnævnte to eksempler på Errors forekommer ikke i 'normale' java programmer, idet de fanges under oversættelsen. Hvis man imidlertid tilgår objekter, som er lagret persistent på disken, eller hvis man via et klassenavn tilgår selv klassen med henblik på instantiering, kan disse fejl opstå

Det er det jeg kalder unchecked exceptions.

Og "normalt ikke forekommer" skal tages med et gran salt eller måske en hel kop fuld.

Ja, det tror jeg også du har ret i.. Nåå, men kun nogle få spørgsmål tilbage nu..

Det der downcasting.. Hvad går det helt præcist ud på?

downcast er ikk ete udtræk jeg bruger, men det dækker over:

B extender A og kode:

A x = new B(); // implicit upcast
...
... (B)x ... // eksplicit downcast

Kan man nøjes med at importere en enkelt klasse til sit program, eller skal det være en hel pakke?

Du kan sagtens importere en enkelt klasse.

import java.util.*; // hele pakken
import java.util.ArrayList; // kun klassen

Det anses endda for pænest kun at importere klasser.

Virker GC når det handler om tråde?

Ja.

Okay... Jeg siger tak for denne gang og deler nogle point ud...

MVH