Hva er forskjellen på C, C# og C++?

[Jankee]

Computer Science: The March of Progress

 

1980: C

printf("%10.2f", x);

 

1988: C++

cout << setw(10) << setprecision(2) << showpoint << x;

 

1996: Java

java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i < 10; i++) System.out.print(' '); System.out.print(s);

 

2004: Java

System.out.printf("%10.2f", x);

 

2008: Scala and Groovy

printf("%10.2f", x)

 

Legg merke til manglende semikolon i 2008. Massiv framgang!!!

 

Berre for å ødelegge gleda over framgangen

Python har aldri hatt semikolon, starta i 96.

[kernel]

Python har aldri hatt semikolon, starta i 96.

 

Ikke uvanlig det bandt scipt og/eller shell programmings språk.

[Giddion]

<snip>

Og hvordan vet du hvor mange kodelinjer Windows har?

 

Koden til win2k lakk vel ut på nettet for noen år siden......... 29M linjer for en kernel virket veldig mye da

[kernel]

29M kodelinjer i Win2K er opplyst i Modern Operating Systems av Tanenbaum.

 

En forskjell, er at Windows inkluderer GUI funksjoner, mens under UNIX/Linux kjøres X server i user space. Men for all del, det er mange måter å telle kodelinjer på, og metodene som er benyttet er nok forskjellige.

 

Uansett, Windows er et stort program, fryktelig stort i OS sammenheng.

[zotbar1234]

Berre for å ødelegge gleda over framgangen

Python har aldri hatt semikolon, starta i 96.

 

Neivel?

 

$ python -c 'import sys; print sys.argv'
['-c']

 

(...) så er alle system kall C API

 

Nøyaktig hva betyr akkurat dette utsagnet?

 

Ett system kall, er en funksjon som ikke kun eksekverer i CPU ring 1, men kjøres i CPU ring 0 (kernel space).

 

Så hvordan får du det utsagnet til å være ekvivalent med "er alle system kall C API"?

[GeirGrusom]

API er feil å si, det kalles ABI (Application Binary Interface)

Dessuten er det ingen regel at alle system kall bruker C ABI, det er mer en standard utviklere er blitt enige om uten at det er nedfelt i stein.

Grunnen er ganske enkelt at de aller, aller fleste programmeringsspråk støtter C ABI direkte eller indirekte, noe som gjør det gunstig i bruk for høynivåspråk (annet enn C++)

 

edit:

Windows er et stort program ja, er ikke til å komme bortifra.

 

Men, er det tatt høyde for at GUI-en (user32) til Windows støtter OpenGL, DirectDraw og Direct3D direkte?

Under linux må du bruke GLX som ikke engang er tilgjengelig under alle distroer. Dessuten har Windows flere innebyggede audio systemer, noe som ikke er definert under X Window System overhode.

Endret 5. juni 2009 av GeirGrusom

[kernel]

(...) så er alle system kall C API

 

Nøyaktig hva betyr akkurat dette utsagnet?

 

Ett system kall, er en funksjon som ikke kun eksekverer i CPU ring 1, men kjøres i CPU ring 0 (kernel space).

 

Så hvordan får du det utsagnet til å være ekvivalent med "er alle system kall C API"?

 

Jeg har ikke påstått ekvivalens, forstod det slik at du ikke visste hva et system kall var. Hvis det var et trick question, hva er så poenget ditt?!

[kernel]

API er feil å si, det kalles ABI (Application Binary Interface)

 

Nei det er ikke feil, libc (eller glibc) inneholder system kall, noen C API er definert i C standarden (exit, ...), andre C API er definert i POSIX standarden (open, read, write, close, ...).

 

ABI har å gjøre med hvordan linking gjøres.

 

Det skal være et ganske odde UNIX/Linux system, hvis ikke system kall har et C API gitt.

 

I gamle dager under DOS, så ble imidlertid "system services" eksportert fra OS via interrupts, man kunne fortsatt kalle noen av disse fra C, og det fantes implementasjons spesifikke metoder for å kalle de andre.

[zotbar1234]

(opprinnelig)

(...)så er alle system kall C API

 

... deretter meg:

Nøyaktig hva betyr akkurat dette utsagnet?

 

... deretter et svar:

Ett system kall, er en funksjon som ikke kun eksekverer i CPU ring 1, men kjøres i CPU ring 0 (kernel space).

 

... deretter meg igjen

Så hvordan får du det utsagnet til å være ekvivalent med "er alle system kall C API"?

 

Jeg har ikke påstått ekvivalens, forstod det slik at du ikke visste hva et system kall var. Hvis det var et trick question, hva er så poenget ditt?!

 

Poenget mitt var at jeg ikke forstod hva "så er alle system kall C API" betød (ikke minst fordi et systemkall kan soleklart gjøres utenom å gå veien om C). Jeg forstår det fortsatt ikke (enda jeg er klar over hva et systemkall er), og jeg forstår ikke helt hva du siktet til med det opprinnelige utsagnet. Men nå har du forklart hva du siktet til, og da er vel alle fornøyde.

[kernel]

Jeg har ikke påstått ekvivalens, forstod det slik at du ikke visste hva et system kall var. Hvis det var et trick question, hva er så poenget ditt?!

 

Poenget mitt var at jeg ikke forstod hva "så er alle system kall C API" betød (ikke minst fordi et systemkall kan soleklart gjøres utenom å gå veien om C).

 

Du husker vel at jeg snakket om UNIX/Linux? Hvis du mener SUS spesifikasjonen [1] definerer system API grensesnitt i andre språk enn C, så må du nesten forklare hva det er for noe språk. Linux er ikke SUS sertifisert, men kommer jo med full POSIX støtte m.h.p. C API'et.

 

Alle UNIX systemer kommer med C kompilator og ferdig C API out-of-the box. Den mest nærliggende måten å implementere system kall i andre språk, er rett og slett å benytte en wrapper som kaller de aktuelle C funksjonene.

 

[1] Singel Unix Specification

[zotbar1234]

Poenget mitt var at jeg ikke forstod hva "så er alle system kall C API" betød (ikke minst fordi et systemkall kan soleklart gjøres utenom å gå veien om C).

 

Du husker vel at jeg snakket om UNIX/Linux?

 

Det er interessant for diskusjonen hvordan?

 

Hvis du mener SUS spesifikasjonen [1] definerer system API grensesnitt i andre språk enn C, så må du nesten forklare hva det er for noe språk.

 

SUS definerer et C API, ja. Det endrer ikke det faktumet at systemkall kan fortsatt gjøres uten å gå veien om C.

 

Linux er ikke SUS sertifisert, men kommer jo med full POSIX støtte m.h.p. C API'et.

 

Igjen, ja, og så? Det utelukker ikke det faktum at systemkall kan gjøres uten å gå veien om C.

 

Alle UNIX systemer kommer med C kompilator og ferdig C API out-of-the box. Den mest nærliggende måten å implementere system kall i andre språk, er rett og slett å benytte en wrapper som kaller de aktuelle C funksjonene.

 

Systemkall kan fortsatt gjøres uten å gå veien om C. Derav min misforståelse av hva du mente med "er alle system kall C API" (min uthevelse).

[GeirGrusom]

Systemkall kan fortsatt gjøres uten å gå veien om C. Derav min misforståelse av hva du mente med "er alle system kall C API" (min uthevelse).

Som igjen er grunnen til at jeg skrev ABI, siden en ikke nødvendigvis trenger å gå veien om C for å utføre systemkall, noe som gjør C API til feil terminologi.

[kernel]

Alle UNIX systemer kommer med C kompilator og ferdig C API out-of-the box. Den mest nærliggende måten å implementere system kall i andre språk, er rett og slett å benytte en wrapper som kaller de aktuelle C funksjonene.

 

Systemkall kan fortsatt gjøres uten å gå veien om C. Derav min misforståelse av hva du mente med "er alle system kall C API" (min uthevelse).

 

Vel, POSIX.1 er jo et C API, og dette API'et har alle UNIX/Linux systemer.

 

Hvilke andre API'er som støttes, eller kompilatorer som måtte være installert, er helt systemavhengig.

[kernel]

Som igjen er grunnen til at jeg skrev ABI, siden en ikke nødvendigvis trenger å gå veien om C for å utføre systemkall, noe som gjør C API til feil terminologi.

 

POSIX eller Open Group har ikke spesifisert noe felles ABI, dette er system avhengig og kan i tillegg endres fra en OS release til en annen.

 

ABI er relevant for de som implementerer standard biblioteker, og dette er faktisk en del av implementasjonen som applikasjons programmer ikke trenger å tenke på.

 

På UNIX/Linux er systemkall definert i POSIX.1, ABI har å gjøre med hvordan dette API'et er implementert, dvs. lav-nivå implementering og linking.

[GeirGrusom]

På UNIX/Linux er systemkall definert i POSIX.1, ABI har å gjøre med hvordan dette API'et er implementert, dvs. lav-nivå implementering og linking.

Javisst, men er ikke dette mer relevant til systemkall en det overordnede API-et?

 

Det finnes masse operativsystem, og det er langt ifra alle som er skrevet i C, og det finnes OS som ikke engang støtter C systemkall.

[kernel]

På UNIX/Linux er systemkall definert i POSIX.1, ABI har å gjøre med hvordan dette API'et er implementert, dvs. lav-nivå implementering og linking.

Javisst, men er ikke dette mer relevant til systemkall en det overordnede API-et?

 

For de som utvikler kompilator og systembiblioteker, må forholde seg til begge deler, resten av oss trenger normalt ikke det.

 

Det finnes masse operativsystem, og det er langt ifra alle som er skrevet i C, og det finnes OS som ikke engang støtter C systemkall.

 

Jada, det finnes mye rart, og derfor begrenset jeg påstanden til en gruppe OS'er, men kunne jo tatt med langt flere: BSD, OS X, MS med Win32 API, osv. osv.