Hva gjør at folk lærer C# framfor C++?

[arna]

Etter det jeg har forstått er C++ OOP-språk imens C# er et prosedyrespråk, er det ikke dumt å starte på dette da kontra C++? Vil ikke C++ erstatte C# på mange måter isåfall, eller er det slik at de overlapper hverandre på mange måter? (Mener å ha lest dette i en bok av Robert Lafore men har egentlig aldri fått noen skikkelig forklaring på det)

 

Og så leste jeg dette utsagnet i en artikkel fra 2002 om .NET:

Microsofts nye C#, som er en mellomting mellom C++ og Java.

Har jeg misforstått hvis jeg sier at C er det samme som C#?

[Mr.Garibaldi]

Og så leste jeg dette utsagnet i en artikkel fra 2002 om .NET:

Microsofts nye C#, som er en mellomting mellom C++ og Java.

Har jeg misforstått hvis jeg sier at C er det samme som C#?

 

Ja, C# (også kalt C sharp) er et nytt språk som MS har utviklet etter at de mistet lisensen til å lage sin egen java kompilator. Den har mye likt med både C++ og java og er et OOP språk.

C uten noe etter (også kalt ANSI C) er det originale C språket som C++ bygger på, og er et prosedyrespråk.

Endret 10. november 2005 av Mr.Garibaldi

[Manfred]

For en enkel oversikt:

 

- C -> kom først -> prosedyrespråk

- C++ -> videreutvikling av C -> OOP

- C# -> nyeste. en kombinasjon av C++ og Java -> OOP

 

Og ja, du har misforstått hvis du tror C er det samme som C#.

[buskmann]

C# er Microsofts konkurrent til Java, selv om Microsoft bedyrer noe annet.

 

C# har flere likheter med Java enn med C++.

[GeirGrusom]

Egentlig ikke... når du tenker over det...

 

Men det er mange ting i C# som er tatt fra C++, som Java rett og slett ikke har.

for å lage en liten liste:

 

delegates (pointer to member i C++, pointer to function i C, dette er noe Java virkelig kunne trengt)

peker aritmetikk (kan brukes i unsafe context)

dynamic loading (System.Assembly, i C/C++ kan du bruke LoadLibrary og GetProcAddess)

unmanaged memory (stackalloc, og funksjoner fra Marshal)

typeof (bare i C#)

 

alle disse funksjonene er heller avanserte (untatt delegates)

 

Men uansett er Java litt mer crossplatform en C#, en grunn til det tror jeg er at .NET Framework er altfor stort.

 

En stor forskjell mellom C#, Java og C/C++ er at C/C++ lager programkode direkte, Java og C# lager noe man kaller bytecode (ikke helt tilfellet for C#, men for å holde det enkelt) og denne koden blir oversatt mens programmet er igang.

Det første som skjer i C#, er at .exe fila kaller mscoree.dll, som starter å oversette programmet til native code etterhvert som kode blir kalt.

Java fungerer nogenlunde på samme måten.

 

C/C++ lager en exe fil ferdig med native code, det eneste windows trenger å gjøre for å starte programmet er å legge det i RAM, og aligne det etter NT_HEADER.MemoryAlignment, laste alle dller som programmet trenger, bytte ut pekerne i import table, og programmet er klart, og kan mates til prosessoren. Men et program laget på denne måten kan ikke kjøres på et annet OS, eller prosessor, uten at programmet må bli kompilert på nytt

 

Nå ser jeg ut til å høre til en døende rase med hardcore native code tilhengere... go hastighet og kort loading tid!

[Gjakmarrja]

Går det ann å gjøre kode laget med .NET framework om til native kode.

 

Altså, det må jo gå ann. Bare lurte om det fantes en kompilator for det?

[GeirGrusom]

Programmet vil fortsatt være avhengig av .NET Framework, mye av koden til programmet koples til System.dll og mscoree.dll, og er uansett avhengig av de to, pluss mange andre.

.NET gjør det delvis om til native, men det er store mekanismer rundt dette.

[dayslepr]

har ikke lest tråden her, men svarer på emne-feltet: «buzzwords», og nyheter som egentlig har eksistert lenge andre steder

[GeirGrusom]

Dessuten er det vel få som velger C# framfor C++, siden dette er to forskjellige verktøy, og konkurerer vel egentlig ikke.

 

Man kan velge C# framfor Java eller Visual Basic, men C++ har den sjeldne egenskapen at det lager native code, og kan være nært knyttet til hardware og operativsystem.

 

Mens C#, Java og Visual Basic er avhengig av biblioteker skrevet i C++ for å i det hele tatt gjøre noe som helst.

[abcd423417984]

Det ser ut som det er en smule forvirring her. C# er et språk, .NET er en _implementasjon_ av språket + biblioteker for det meste.

 

C# som språk er IKKE avhengig av .NET og kan for all del kompileres til native maskinkode HVIS det eksisterer en kompilator for det formålet. Det mange ovenfor i diskusjonen mener er nok at C# brukes nettopp pga .NET sine geniale egenskaper, og .NET programmer kan ikke kjøres native uten at det går gjennom en interpreter.

 

Hvorvidt C# og C++ er konkurrenter kan vi godt ta en diskusjon på. I utgangspunktet vil jeg påstå at C#/.NET er rettet mot et typisk RAD miljø, mens C++ passer bedre til den som ønsker å gjøre ting selv raskere og mer spesifikk. Alikevel betyr det ikke at den ene ikke duger til det andre, eller at de ikke kan gjøre det mye bedre hvis man bruker begge deler sammen og samtidig. Man kan bruke C++ win32 .dll filer sammen med C#/.NET applikasjoner ihvertfall

 

For å forvirre enda mer; Man kan kode elementer av win32 api i C#/.NET, og man kan kode .NET i C++. C++ vil også i fleste tilfeller kreve biblioteker for å kunne gjøre det samme som C#/.NET med mindre man koder det selv. F.eks. bare sjekk hva et native win32 program linker mot når du kjører det...

[abcd423417984]

typeof (bare i C#)

 

instanceof i java.

[GeirGrusom]

instanceof er ikke det samme som typeof

 

instanceof:

Tree a;
bool isTree;
isTree = a instanceof Tree;

isTree vil bli true

 

typeof:

Tree a;
bool isTree;
isTree = a.GetType() == typeof(Tree);

gir samme effekt som instanceof, men typeof kan du også bruke til dette:

System.Type t = typeof(Tree);
System.Reflection.MethodInfo[] info = t.GetMethods();
foreach(System.Reflection.MethodInfo i in info)
 Console.WriteLine(i.Name);

[abcd423417984]

Du har selvfølgelig rett angående den operatoren. Det betyr alikevel ikke at du ikke har samme mulighet i java gjennom Object sin .getClass().getName() eller .class.getName() (for statisk sammenheng).

 

Vil tro følgende gir noe av samme resultatet;

java.lang.reflect.Method metoder[] = KlasseNavn.class.getDeclaredMethods();
for(int i=0;i<metoder.length;i++)
System.out.println(metoder[i].getName());

 

Så jeg vil påstå at påstanden din ikke holder mål dessverre.

 

Det skal også nevnes at dynamisk loading av klasser i java også er fullt mulig.

Endret 20. november 2005 av invictus

[GeirGrusom]

Du har helt rett, men Java hadde i utgangspunktet masse designfeil, mange av disse er rettet på med samme metode som f.eks. interfaces eller strings i C++ (ja, jeg er C++ programmerer så jeg er fullstendig klar over at C++ har multiple inheritance istedet for interfaces)

 

Nå i nyeste versjon av Java kan du plutselig legge kontroller hvor du vil på en dialog! wow, det kaller jeg framtidsrettet.

 

ontopic:

 

C++ har det geniale at for å bruke Win32 trenger du kun å linke mot user32.dll og bruke de funksjonene du trenger, i C++ kan du også skrive en ren exe fil, som ikke trenger en eneste dll, men f.eks. bruke int 22 for å kommunisere med OS (int 22h er et DOS interrupt)

 

Denne muligheten finnes ikke i C#, Java, Visual Basic, Python, Ruby, Fortran, Cobol, Eiffel eller Prolog (men du kan det i Pascal)

 

Derfor blir C++ brukt i så stor grad som det gjør.

 

Jeg bruker C++ og Assembly hver dag nå, og C# til all gui programering, og jeg vil si, at jeg bruker Assembly for å linke til så få biblioteker som mulig, og C++ fordi logikken der gjør at programmering av minnehåndteringsrutiner er enklere

 

vertex *fp = (vertex*)GetBuffer(BUFFER_VERTEX);

for(uint x = 0; x < vertex_count;x++, fp++)
 *fp = vertex(32.0f, 32.0f, 32.0f);

 

ikke et utdrag fra koden min, men for å vise minnehåndtering som ikke kan gjøres i C# eller Java, grunnen til at jeg bruker fp++ framfor fp[x] er at sizeof(vertex) er 12, hadde det vært 16 hadde jeg brukt fp[x] pga. scale/index/base. Dette er slike ting jeg må tenke på når jeg skriver kode, det å bruke ++ istedet for [] gjør at jeg kan kanskje spare et par millisekunder i koden, det valget finnes ikke i Java eller Visual Basic (men det finnes i C#, men det spiller ingen rolle, er ikke interresert i å lage et managed spill allikevel)

 

Det jeg også liker med C++ er _read(filehandle, &my_struct, sizeof(my_struct)) framfor å spesifisere hver enkelt felt lsik du må i C#

pga buffering er det ikke noe raskere, men mye enklere for meg.

 

Jeg gjentar "go native code!"

[dayslepr]

hm .. multiple inheritance er ikke C++'s «versjon» av interface .. abstrakte klasser er:

 

class Doer {

public:

  virtual void doIt() = 0;

};

 

C++ har det geniale at for å bruke Win32 trenger du kun å linke mot user32.dll og bruke de funksjonene du trenger, i C++ kan du også skrive en ren exe fil, som ikke trenger en eneste dll, men f.eks. bruke int 22 for å kommunisere med OS (int 22h er et DOS interrupt)

 

Denne muligheten finnes ikke i C#, Java, Visual Basic, Python, Ruby, Fortran, Cobol, Eiffel eller Prolog (men du kan det i Pascal)

 

«ja, jævli genialt; det er helt fantastisk» ... forbasket vissvass du kommer med her .. herregud; så klart det går å kalle funksjoner i eksterne biblioteker fra andre språk enn C/C++ ....

 

som mulig, og C++ fordi logikken der gjør at programmering av minnehåndteringsrutiner er enklere

 

det er dedikert 10-talls kapitler i flere 1000-siders bøker om minnehåndtering i C/C++ .. alle vet at det er et helvette, og noe man kun bruker der det er mest nødvendig

 

hold deg til assemblyen din du .. lavnivå-koding er det eneste du noen gang kommer til å skjønne noe av.. hah

[Gjakmarrja]

AHAHAHAHHAAH OWND :!:

Endret 26. november 2005 av chills

[GeirGrusom]

jeg skratter av inlegget ditt, dayslepr.

 

hm .. multiple inheritance er ikke C++'s «versjon» av interface .. abstrakte klasser er:

 

...finnes ikke direkte i C++

virtual har ikke direkte noen ting med multiple inheritance, eller interfaces for den saks skyld.

Men uansett: Multiple inheritance og interfaces er der av samme grunn, kanskje du har lest om det i boka di, hva kalles det? jo, jeg tror du klarer å huske det, det er et vanskelig ord på M.

 

«ja, jævli genialt; det er helt fantastisk» ... forbasket vissvass du kommer med her .. herregud; så klart det går å kalle funksjoner i eksterne biblioteker fra andre språk enn C/C++ ....

 

forsåvidt poeng

men i standard C bibliotek er det mulig.

og i Visual C++ kan du bruke __asm

i QuickBasic hadde du Call Absolute for å gjøre slike ting, men det var maskinkode though, og det er hardt å sitte og skrive.

 

det er dedikert 10-talls kapitler i flere 1000-siders bøker om minnehåndtering i C/C++ .. alle vet at det er et helvette, og noe man kun bruker der det er mest nødvendig

 

Selvsagt, det er ikke implementert i språket noen andre steder.

For n-te gang, C++ er ikke laget for å være enkelt

kanskje du skal fortsette litt mer med Java?

 

kanskje du vil se grafikkmotoren min? skrevet i C++ og Assembly? nei, fordi du er så frekk.

 

elsker deg, dayslepr

[A_N_K]

En klasse med bare ikke-implementerte (husker ikke C++-lingoen) virtuelle funksjoner tilsvarer et interface. Til kontrast kan man se på Ruby som forbyr multippel arv, men hvor man fint kan implementere en rekke interfaces (implementert funksjonalitet kan introduseres i en klasse vha. mixins dog). Virtuelle funksjoner i seg selv har fint lite med saken å gjøre, men til forskjell fra vanlige funksjoner i en klasses grensesnitt i C++ kan de mangle definisjon.

 

Når det gjelder C++ og kompleksitet kan man spørre seg hvor mye som kommer av nytteverdi og hvor mye som kommer av kildekompabilitet med C (melder behovet for kildekompabilitet med C seg i større grad?).

[Dead_Rabbit]

En interface klasse (altså «a pure virtual class»), trenger bare en ikke-implementert funksjon. Har den det går det ikke ann å instansiere (tror det er det det heter på norsk, heh ) den.

[teflonpanne]

det heter abstract (base) class. for at en klasse skal være abstrakt må den ha en pure virtual funksjon, altså virtual void f() = 0; som daysleper skrev