---

hvad er forskellen på c og c++ ??

Mvh
BHP

---

bent petersen skrev:

>hvad er forskellen på c og c++ ??

C ligner Pascal, men C++ kan *meget* mere. Det har nemlig
mulighed for objektorienteret programmering. Men alt hvad man kan
i C, kan man på præcis samme måde i C++.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

"Bertel Lund Hansen" <nospam@lundhansen.dk> wrote in message
> C ligner Pascal, men C++ kan *meget* mere. Det har nemlig
> mulighed for objektorienteret programmering.

Hvilke problemer er det lige du mener man kan løse i C++, men ikke i C ?

/peter

---

Peter Gade Jensen skrev:

>Hvilke problemer er det lige du mener man kan løse i C++, men ikke i C ?

Ingen. Det skrev jeg heller ikke. Med tid og tålmodighed til sin
rådighed kan en drevet programmør lave det samme i C som man kan
i C++ - blot meget mere besværligt.

C++ har OOP. Det har C ikke. De problemer der løses elegant med
OOP, er besværlige uden. Derudover er templates og overloadede
operatorer altså rare at have, og en lille ting der letter livet
betragteligt er default værdier til parametre.

Men funktionaliteten i det færdige program kan naturligvis laves
uden.

--
Bertel
http://bertel.lundhansen.dk/   FIDUSO: http://fiduso.dk/

---

Den Mon, 17 Jun 2002 15:51:27 +0200 skrev Bertel Lund Hansen:
>Peter Gade Jensen skrev:
>
>>Hvilke problemer er det lige du mener man kan løse i C++, men ikke i C ?
>
>Ingen. Det skrev jeg heller ikke. Med tid og tålmodighed til sin
>rådighed kan en drevet programmør lave det samme i C som man kan
>i C++ - blot meget mere besværligt.
>
>C++ har OOP. Det har C ikke. De problemer der løses elegant med
>OOP, er besværlige uden.

Det kan skam godt lade sig gøre at skrive OO-programmer i C. Der er
endda noget der gør det!

Der er bare lidt mere arbejde man skal lave selv, som compileren
overtager i "rigtige" OO-sprog.

Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds

---

leeloo@phreaker.net (Kent Friis) writes:

> Den Mon, 17 Jun 2002 15:51:27 +0200 skrev Bertel Lund Hansen:
> >C++ har OOP. Det har C ikke. De problemer der løses elegant med
> >OOP, er besværlige uden.
>
> Det kan skam godt lade sig gøre at skrive OO-programmer i C. Der er
> endda noget der gør det!

Hvis man vil se et eksempel på det så prøv at skrive et simpel Gnome
eller gtk+ program, de har et C bibliotek der er fuldstændigt
objektorienteret. Det er absolut en times tid værd at skrive et hello
world program for at se at OOP også virker fint i alm. C.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Bertel Lund Hansen <nospam@lundhansen.dk> skrev:
> alt hvad man kan
> i C, kan man på præcis samme måde i C++.

Nej. Jeg mindes f.eks. at det tidligere har været oppe her i gruppen
at man ikke i C++ kan initialisere enhvert af felterne i en union.
Det kan man i C. Det er sikkert også andre nye C99-ting som ikke
findes i C++ selv om jeg ikke kan nævne flere her.

---

Den Mon, 17 Jun 2002 15:00:45 GMT skrev Byrial Jensen:
>Bertel Lund Hansen <nospam@lundhansen.dk> skrev:
>> alt hvad man kan
>> i C, kan man på præcis samme måde i C++.
>
>Nej. Jeg mindes f.eks. at det tidligere har været oppe her i gruppen
>at man ikke i C++ kan initialisere enhvert af felterne i en union.
>Det kan man i C. Det er sikkert også andre nye C99-ting som ikke
>findes i C++ selv om jeg ikke kan nævne flere her.

Og så er der jo alle de snedige *GG*

int class=10;

Mvh
Kent
--
What was your username?
<Clicketyclick> - B.O.F.H.

---

In article <dmbrguc65btj701g68q5dmmai4q9vgdcg9@sunsite.auc.dk>,
Bertel Lund Hansen <nospam@lundhansen.dk> wrote:

> bent petersen skrev:
>
> >hvad er forskellen på c og c++ ??
>
> C ligner Pascal, men C++ kan *meget* mere. Det har nemlig
> mulighed for objektorienteret programmering. Men alt hvad man kan
> i C, kan man på præcis samme måde i C++.

Omvendt. Alt hvad du kan i C++ kan du også i C. C++ var/er en
precompiler til C :)

---

Kim Hansen <k-tahf.qvxh@oek.dk> writes:

> leeloo@phreaker.net (Kent Friis) writes:
>
>> Den Mon, 17 Jun 2002 15:51:27 +0200 skrev Bertel Lund Hansen:
>> >C++ har OOP. Det har C ikke. De problemer der løses elegant med
>> >OOP, er besværlige uden.
>>
>> Det kan skam godt lade sig gøre at skrive OO-programmer i C. Der er
>> endda noget der gør det!
>
> Hvis man vil se et eksempel på det så prøv at skrive et simpel Gnome
> eller gtk+ program, de har et C bibliotek der er fuldstændigt
> objektorienteret. Det er absolut en times tid værd at skrive et hello
> world program for at se at OOP også virker fint i alm. C.

Og samtidig lære hvorfor der er så langt at foretrække at have
eksplicit understøtelse for OOP i sproget

---

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Kim Hansen <k-tahf.qvxh@oek.dk> writes:
>
> > leeloo@phreaker.net (Kent Friis) writes:
> >
> >> Den Mon, 17 Jun 2002 15:51:27 +0200 skrev Bertel Lund Hansen:
> >> >C++ har OOP. Det har C ikke. De problemer der løses elegant med
> >> >OOP, er besværlige uden.
> >>
> >> Det kan skam godt lade sig gøre at skrive OO-programmer i C. Der er
> >> endda noget der gør det!
> >
> > Hvis man vil se et eksempel på det så prøv at skrive et simpel Gnome
> > eller gtk+ program, de har et C bibliotek der er fuldstændigt
> > objektorienteret. Det er absolut en times tid værd at skrive et hello
> > world program for at se at OOP også virker fint i alm. C.
>
> Og samtidig lære hvorfor der er så langt at foretrække at have
> eksplicit understøtelse for OOP i sproget

Ja, da jeg sad og legede med det tænkte jeg hele tiden i C++,
simpelthen fordi det var C++ det mindede om. Bortset fra at typefejl i
objekterne først bliver fanget i runtime...

Der kan ikke være tvivl om at GIU-kode bliver meget pænere med OOP.

Og hvis vi skal vende tilbage til kernesnak så ville filsystemer også
blive væsentligt nemmere at skrive med OOP i sproget, File og
Directory objekter der arver fra Inode, osv. Det ville ikke engang
være langsomere end den C-kode der er i Linux idag, for den er fyldt
med funktionspointere der bliver brugt til virtuelle funktioner i C.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

"bent petersen" <brugandre@bygikkelasselarsen.dk>

> hvad er forskellen på c og c++ ??

Måske

http://www.research.att.com/~bs/crc.pdf

kan hjælpe dig.

Venlig hilsen

Mogens Hansen

---

"bent petersen" <brugandre@bygikkelasselarsen.dk> wrote in message
news:3d0d8a24$0$80399$edfadb0f@dspool01.news.tele.dk...
> hvad er forskellen på c og c++ ??

C++ er Objekt-Orienteret. Hvilket vil sige at det nemmere at skrive
store programmer i C++. C har en bedre performance end C++.

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:aekq72$of0$1@sunsite.dk...
> C++ er Objekt-Orienteret. Hvilket vil sige at det nemmere at skrive
> store programmer i C++. C har en bedre performance end C++.

Oh, sikke en flaim-bait!!
C-programmører vil mene at man også kan programmere objektorienteret i C
C++-programmører vil mene at man ikke mister noget som helst performance i
C++.

Oh well, nu har jeg skrevet det - så nu har jeg jo overflødiggjort de
forudsagte svar


Bjarke

---

Den Mon, 17 Jun 2002 16:20:31 +0200 skrev Bjarke Dahl Ebert:
>"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
>news:aekq72$of0$1@sunsite.dk...
>> C++ er Objekt-Orienteret. Hvilket vil sige at det nemmere at skrive
>> store programmer i C++. C har en bedre performance end C++.
>
>Oh, sikke en flaim-bait!!
>C-programmører vil mene at man også kan programmere objektorienteret i C
>C++-programmører vil mene at man ikke mister noget som helst performance i
>C++.

Og jeg mener at objektorientering ikke gør det nemmere at skrive store
problemer.

Objektorienterede problemer bør løses objektorienteret, og
ikke-objektorienterede problemer bør IKKE forsøges løst
objektorienteret.

Man kan sammenlige det med at et skib kan fragte meget mere end en
lastbil. Men uanset hvor stor lasten er, vil jeg nødig forsøge at
transportere den ind midt i Sahara med skib.

Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.

---

In article <3d0df02d$0$237$edfadb0f@dspool01.news.tele.dk>,
"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote:

> "Daniel Blankensteiner" <db@traceroute.dk> wrote in message
> news:aekq72$of0$1@sunsite.dk...
> > C++ er Objekt-Orienteret. Hvilket vil sige at det nemmere at skrive
> > store programmer i C++. C har en bedre performance end C++.
>
> Oh, sikke en flaim-bait!!
> C-programmører vil mene at man også kan programmere objektorienteret i C
> C++-programmører vil mene at man ikke mister noget som helst performance i
> C++.
>
> Oh well, nu har jeg skrevet det - så nu har jeg jo overflødiggjort de
> forudsagte svar

___________________
/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed |
/ \ \ the trolls |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________

---

Povl H. Pedersen wrote:
> ___________________
> /| /| | |
> ||__|| | Please do |
> / O O\__ NOT |
> / \ feed |
> / \ \ the trolls |
> / _ \ \ ______________|
> / |\____\ \ ||
....

Cool. Den gemmer jeg lige til fremtidig reference, hvis det er i orden
med dig.?

--
Jakob Møbjerg Nielsen | "Five exclamation marks, the
jakob@dataloger.dk | sure sign of an insane mind."
| -- Terry Pratchett, Reaper Man

---

In article <aem3ae$h9k$1@sunsite.dk>,
Jakob Møbjerg Nielsen <jakob@dataloger.dk> wrote:

> Povl H. Pedersen wrote:
> > ___________________
> > /| /| | |
> > ||__|| | Please do |
> > / O O\__ NOT |
> > / \ feed |
> > / \ \ the trolls |
> > / _ \ \ ______________|
> > / |\____\ \ ||
> ...
>
> Cool. Den gemmer jeg lige til fremtidig reference, hvis det er i orden
> med dig.?

Har selv hentet den i en anden newsgroup hvor vi næsten alle har en
troll i killfilter

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:aekq72$of0$1@sunsite.dk...
> C har en bedre performance end C++.

Vås.

---

"Jonas Meyer Rasmussen" <meyer@remove.diku.this.dk> wrote in message
news:aekuhs$5m0$1@eising.k-net.dk...
> "Daniel Blankensteiner" <db@traceroute.dk> wrote in message
> news:aekq72$of0$1@sunsite.dk...
> > C har en bedre performance end C++.
>
> Vås.

Kom med noget bedre end det! Meget bedre!
Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og svaret
var at C++ var for langsomt.

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote

> Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og svaret
> var at C++ var for langsomt.

Hvor stor peformance forskel fortalte de dig at de havde målt på FreeBSD
skrevet i C og FreeBSD skrevet i C++ ?
Jeg tænker f.eks. på:
* hvor meget der kan eksekveres pr. tidsenhed. F.eks. context switch /sec
* hvor meget hukommelse der kræves for at løse samme opgave
* hvor mange fejl der samlet var i de 2 systemer
* hvor lang tid det havde taget at skrive de 2 systemer

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:ael25u$14hl$1@news.cybercity.dk...
> > Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> > folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og
svaret
> > var at C++ var for langsomt.
>
> Hvor stor peformance forskel fortalte de dig at de havde målt på
FreeBSD
> skrevet i C og FreeBSD skrevet i C++ ?

Hvorfor stiller du et spørgsmål, som du udemærket godt ved ikke kan
besvares?

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> writes:

> "Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
> news:ael25u$14hl$1@news.cybercity.dk...
> > > Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> > > folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og
> svaret
> > > var at C++ var for langsomt.
> >
> > Hvor stor peformance forskel fortalte de dig at de havde målt på
> FreeBSD
> > skrevet i C og FreeBSD skrevet i C++ ?
>
> Hvorfor stiller du et spørgsmål, som du udemærket godt ved ikke kan
> besvares?

Selvfølgelig kan det lade sig gøre at måle det. Du kan f.eks. bruge
LMbench (http://www.bitmover.com/lmbench/) til at lave den slags
målinger.

Hvorfor kommer du konstant med postulater uden at have nogen
argumenter/beviser?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote in message
news:x62vg8hln6r.fsf@tyr.diku.dk...
> > > Hvor stor peformance forskel fortalte de dig at de havde målt på
> > FreeBSD
> > > skrevet i C og FreeBSD skrevet i C++ ?
> >
> > Hvorfor stiller du et spørgsmål, som du udemærket godt ved ikke kan
> > besvares?
>
> Selvfølgelig kan det lade sig gøre at måle det. Du kan f.eks. bruge
> LMbench (http://www.bitmover.com/lmbench/) til at lave den slags
> målinger.

Eftersom der ikke findes FreeBSD skrevet i C++, kan du ikke måle det.

> Hvorfor kommer du konstant med postulater uden at have nogen
> argumenter/beviser?

Hvorfor kommer du kontant med med modsatte meninger uden at have nogen
argumenter/beviser?

Jeg har fortalt hvor jeg har fået fortalt at C er hurtigere end C++ fra.
Jeg kan ikke andet end at stole på disse mennesker og på min egen
logiske sans.

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote

> Jeg har fortalt hvor jeg har fået fortalt at C er hurtigere end C++ fra.

Ukritisk, som om det var en simpel, endegyldig sandhed.

> Jeg kan ikke andet end at stole på disse mennesker og på min egen
> logiske sans.

Hvorfor kan du ikke andet ?
Hvad forhindrer dig i at undersøge forholdene selv eller finde sporbare
referencer ?

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:aelj30$1rr0$2@news.cybercity.dk...
> Hvorfor kan du ikke andet ?
> Hvad forhindrer dig i at undersøge forholdene selv eller finde
sporbare
> referencer ?

At søge på google giver ikke et godt resultat. Forstået på den måde at
der findes tekster der siger C++ er hurtigere og du kan finde tekster
der siger at C er hurtigere. Så må man jo spørge nogle "experter".

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:aelfap$fmu$1@sunsite.dk...
> Jeg har fortalt hvor jeg har fået fortalt at C er hurtigere end C++ fra.
> Jeg kan ikke andet end at stole på disse mennesker og på min egen
> logiske sans.

Hvis du læser Mogens Hansen's indlæg om quicksort performance, siger din
logiske sans dig stadig at C er hurtigere end C++?

Nej, forhåbentlig, så gør indlægget det klart at man ikke kan komme med et
sådant
postulat - Problemet er mere nuanceret, og man kan derfor aldrig sige at det
ene sprog er hurtigere
end det andet generelt...

mvh
Jonas

---

"Kim Hansen" <k-tahf.qvxh@oek.dk> wrote in message
news:x62vg8hln6r.fsf@tyr.diku.dk...
> Hvorfor kommer du konstant med postulater uden at have nogen
> argumenter/beviser?

Desuden så kan vi alle jo kun udtale os om hvad vi har hørt eller læst.
Jeg har hørt fra hvad jeg synes er en pålidelig kilde at C er hurtigere,
hvilket nok har noget at gøre med at C++ er OO. Personligt bruger jeg
selv C++, så hvis det viser sig at begge er lige hurtige, så er det da
bare et plus for mig.

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote

> > > Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> > > folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og
> svaret
> > > var at C++ var for langsomt.
> >
> > Hvor stor peformance forskel fortalte de dig at de havde målt på
> FreeBSD
> > skrevet i C og FreeBSD skrevet i C++ ?
>
> Hvorfor stiller du et spørgsmål, som du udemærket godt ved ikke kan
> besvares?

For at påvise, at den argumentation som du bruger, ikke er andet end en
anekdote.

Et simpelt, konkret, sporbart eksempel, hvor C++ er hurtigere end C er
sortering af unsigned integer med sorteringsalgoritmen i deres standard
biblioteker:

<code>
#include <algorithm>
#include <cstdlib>
#include <iostream>
#include <iomanip>
#include <vector>
#include <windows.h>

int c_compare(const void* arg1, const void* arg2)
{
return (*(unsigned*) arg1) - (*(unsigned*) arg2);
}

int main()
{
using namespace std;;

vector<unsigned>::size_type MAX = 8*1024*1024;
vector<unsigned> orig(MAX);

// initialize
for(vector<unsigned>::size_type i = 0; MAX != i; ++i) {
orig[i] = i;
}
random_shuffle(orig.begin(), orig.end());
vector<unsigned> c_work(MAX);
vector<unsigned> cpp_work(MAX);

for(vector<unsigned>::size_type i = 1; MAX / 1024 != i; i *= 2) {
// copy entire containers to eliminate
// CPU cache effects
c_work =
cpp_work = orig;
//copy(orig.begin(), orig.end(), work.begin());
vector<unsigned>::size_type to_sort = i*1024;

// MS-Windows specific performance measurement
LARGE_INTEGER start, c_stop, cpp_stop;
QueryPerformanceCounter(&start);

// C style sort
qsort(&c_work[0], to_sort, sizeof(unsigned), c_compare);
QueryPerformanceCounter(&c_stop);

// C++ style sort
sort(&cpp_work[0], &cpp_work[to_sort]);
QueryPerformanceCounter(&cpp_stop);

// Performance calculation
DWORD c_dur = (start.HighPart == c_stop.HighPart ?
c_stop.LowPart - start.LowPart :
start.LowPart - c_stop.LowPart);
DWORD cpp_dur = (c_stop.HighPart == cpp_stop.HighPart ?
cpp_stop.LowPart - c_stop.LowPart :
c_stop.LowPart - cpp_stop.LowPart);
cout << "size: " << setw(4) << i << " k - "
"C / C++ ratio: " << (100*c_dur) / cpp_dur << " %" << endl;
}
}
</code>

Som oversat med Microsoft Visual C++ .NET, på en 700 MHz Pentium III giver:
size: 1 k - C / C++ ratio: 123 %
size: 2 k - C / C++ ratio: 133 %
size: 4 k - C / C++ ratio: 133 %
size: 8 k - C / C++ ratio: 129 %
size: 16 k - C / C++ ratio: 138 %
size: 32 k - C / C++ ratio: 140 %
size: 64 k - C / C++ ratio: 142 %
size: 128 k - C / C++ ratio: 147 %
size: 256 k - C / C++ ratio: 147 %
size: 512 k - C / C++ ratio: 145 %
size: 1024 k - C / C++ ratio: 142 %
size: 2048 k - C / C++ ratio: 146 %
size: 4096 k - C / C++ ratio: 147 %

Det interessante er ikke eet konkret tilfælde hvor det C++ er hurtigere end
C, men at forstå hvilke mekanismer, der gør at det er naturligt at det er
hurtigere.
I dette tilfælde er det i høj grad "inline", der gør en forskel. Generisk
programmering fjerner behovet for typecasts.
Gennem forståelsen kan man foretage mere kvalificerede design valg og
vurderinger.

Eksemplet giver absolut heller _ikke_ basis for unuancerede konklusioner som
"C++ har en bedre performance en C".

Et andet eksempel på en undersøgelse af forskellige performance aspekter
mellem forskellige sprog er rapporten "An empirical comparison of C, C++,
Java, Perl, Python, Rexx and Tcl", Lutz Prechelt
(http://www.ipd.uka.de/EIR/otherwork/jccpprt_computer2000.pdf).

Hvis man er interesseret i at forstå hvad forskellige konstruktioner i C++
koster og hvorfor, så er "Technical Report on C++ Performance (DRAFT)"
(http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/n1355.pdf) sikkert en
glimrende kilde. Det er 138 sider seriøst arbejde.

En anden udemærket, men lidt gammel, kilde til forståelse, er bogen
Inside the C++ Object Model
Stanley B. Lippman
ISBN 0-201-83454-5

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> skrev i en meddelelse
news:ael25u$14hl$1@news.cybercity.dk...
>
> "Daniel Blankensteiner" <db@traceroute.dk> wrote
[klip]
> Hvor stor peformance forskel fortalte de dig at de havde målt på FreeBSD
> skrevet i C og FreeBSD skrevet i C++ ?
> Jeg tænker f.eks. på:
> * hvor meget der kan eksekveres pr. tidsenhed. F.eks. context switch
/sec
> * hvor meget hukommelse der kræves for at løse samme opgave
> * hvor mange fejl der samlet var i de 2 systemer
> * hvor lang tid det havde taget at skrive de 2 systemer

Apropos forskellige mål for performance i programmeringssprog, så afholdes
der årligt en konkurrence hvor det forsøges afgjort hvilke sprog der er
hurtige.

Der udstikkes en opgave og hvert hold har 72 timer til at programmere en
løsning i hvilket sprog de nu har mest lyst til at bruge. Holdene bliver
bedømt efter hvor godt løsningen fungerer og hvor hurtigt den afvikles.

Det er ofte funktionsprogrammeringssprog der vinder, men måske man skal
være forsigtig med at konkludere noget vildt, da konkurrencen afholdes
i et miljø med en overvægt af funktions-programmører; afsløres af
konkurrencens titel.

Det år jeg henviser til er det endda en rigtig gammel udgave af ML
(Meta Language) som vinder suverænt.

http://www.progsoc.uts.edu.au/~jhonan/func.html

Hilsen Anders

---

Anders Borum wrote:
> Apropos forskellige mål for performance i
> programmeringssprog, så afholdes der årligt en
> konkurrence hvor det forsøges afgjort hvilke sprog der er
> hurtige.
>
> Der udstikkes en opgave og hvert hold har 72 timer til at
> programmere en løsning i hvilket sprog de nu har mest
> lyst til at bruge. Holdene bliver bedømt efter hvor godt
> løsningen fungerer og hvor hurtigt den afvikles.
>
> Det er ofte funktionsprogrammeringssprog der vinder, men
> måske man skal være forsigtig med at konkludere noget
> vildt, da konkurrencen afholdes i et miljø med en
> overvægt af funktions-programmører; afsløres af
> konkurrencens titel.

Man skal bestemt heller ikke undervurdere programørenes
dygtighed. Et godt eksempel er vinderne af
Third Annual ICFP Programming Contest.
Jeg gætter på, at de ville kunne lave effektive programmer
i hvad som helst.

http://www.cis.upenn.edu/~sumii/icfp/

Opgaven gik ud på at implementere et lille PostScript-lignende sprog,
men beregnet på raytracing.

Dag 1: Parser færdig. Fortolker påbegyndt.
Dag 2: Færdiggjorde al beregningsmatematikken.
(Inklusive valgfrie features, indlagt for at afgøre en uafgjort)
Påviste bug hos opgavestilleren.
Dag 3: Optimering.
Dag 4: Udfra fortolkeren generes en oversætter ved hjælp
af teknikker fra partiel evaluering.
Aflevering.

Ret imponenerende.

--
Jens Axel Søgaard

"Then we slept. Yes, throughout the contest, we did sleep enough as usual in our homes."

---

Daniel Blankensteiner wrote:
> Kom med noget bedre end det! Meget bedre!
> Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og svaret
> var at C++ var for langsomt.

Det er ikke så sort på hvidt.

Enkelte C++ features kan give runtime-overhead, du er ikke tvunget til
at bruge de features som du ikke bruger.

- Morten.

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:ael06n$f51$1@sunsite.dk...
> "Jonas Meyer Rasmussen" <meyer@remove.diku.this.dk> wrote in message
> news:aekuhs$5m0$1@eising.k-net.dk...
> > "Daniel Blankensteiner" <db@traceroute.dk> wrote in message
> > news:aekq72$of0$1@sunsite.dk...
> > > C har en bedre performance end C++.
> >
> > Vås.
>
> Kom med noget bedre end det! Meget bedre!

mjae, mit argument var ca. ligeså detaljeret som dit.

> Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og svaret
> var at C++ var for langsomt.

Det er stadig noget vås. I og med at C er et subset af C++(stort set, med
nogle få undtagelser),
så vil ethvert C program kunne oversættes som et C++ program og opnå samme
ydelse.

Så kan man så bagefter overveje om man vil anvende nogen af de smarte _og_
effektive
værktøjer, som der findes i C++, men ikke i C...

---

"Jonas Meyer Rasmussen" <meyer@remove.diku.this.dk> wrote in message
news:ael5ur$kss$1@eising.k-net.dk...
> Det er stadig noget vås. I og med at C er et subset af C++(stort set,
med
> nogle få undtagelser),
> så vil ethvert C program kunne oversættes som et C++ program og opnå
samme
> ydelse.
>
> Så kan man så bagefter overveje om man vil anvende nogen af de smarte
_og_
> effektive
> værktøjer, som der findes i C++, men ikke i C...

Jamen hvorfor bruge C++ fremfor C, hvis det ikke er for at benytte
værktøjer som class's o.s.v...

mvh
db

---

"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
news:ael6kr$e44$1@sunsite.dk...
> Jamen hvorfor bruge C++ fremfor C, hvis det ikke er for at benytte
> værktøjer som class's o.s.v...

Du har ret, men pointen skulle blot illustrere hvorfor udsagnet "C er
hurtigere en C++",
aldrig kan være sandt.

---

Daniel Blankensteiner wrote:
> "Jonas Meyer Rasmussen" <meyer@remove.diku.this.dk> wrote in message
> news:aekuhs$5m0$1@eising.k-net.dk...
>
>>"Daniel Blankensteiner" <db@traceroute.dk> wrote in message
>>news:aekq72$of0$1@sunsite.dk...
>>
>>>C har en bedre performance end C++.
>>
>>Vås.
>
>
> Kom med noget bedre end det! Meget bedre!
> Jeg skrev engang til FreeBSD (som jo er kendt for sin performance)
> folkene og spurgte hvorfor de ikke omprogrammet kernen i C++, og svaret
> var at C++ var for langsomt.

Man kan argumentere begge veje. C++ programmering kan give anledning til
mange funktionskald, og mange allokeringer på stakken. På den anden side
giver C++ bedre mulighed for optimering, til gengæld. Et meget
instruktivt eksempel er bsort() fra standard librariet og den
tilsvarende algoritme fra STL. Sidstnævnte er (lidt) hurtigere, da
comparison-funktionen kan inlines i STL udgaven (via. funktion objects),
mens det ikke er muligt i C-udgaven.

--
mvh. Esben
home.worldonline.dk/~mesben

---

Linux var på et tidspunkt skrevet så den kunne oversættes i både C og
C++, og skiftede endda til g++ som default compiler. De skiftede dog
hurtigt tilbage, men ikke fordi g++ genererede for langsom kode, den
var bare dengang alt for buggy (det var tilbage i 1.* tiden).

Når de FreeBSD folk siger at C++ "er langsomt" skyldes det
sandsynligvis ikke andet end fordomme, der i bedste fald bygger på
anekdotisk evidens. Den slags C programmører der interesserer sig for
kernels har sjældent den store interesse for, eller viden om,
programmeringssprog generelt.

I princippet bør portabel C++ generere hurtigere kode fordi

1) typesystemet er en anelse stærke, så lidt flere optimeringer er
mulige, og

2) mange ting er indbygget i sproget (og standard biblioteket), som
compileren derved kan optimere langt bedre end hvis de skulle
simuleres i C.

I praksis vil det samme program (altså hvor man ikke bruger specielle
features fra C eller C++) normalt køre med samme hastighed, eller
marginalt hurtigere i C. Det skyldes at sproget er simplere og derfor
lettere for programmører at implementere optimeringer, og brugt i
vigtige benchmarks, så relativt flere ressourcer bliver brugt på at
finde på optimeringer. Når forskellen ikke er større skyldes det at C
og C++ normalt deler backend, så det er kun de (for C mindre vigtige)
optimeringer i front-enden der bliver påvirket.

I praksis vil C++ programmer der bruger C++ fasciliteter ofte være
langsommere end ækvivalente C programmer. Det skyldes at det er let
at introducere nye abstraktioner i C++, hvilket tilskynder
programmørerne til at gøre det, og disse abstraktioner har ofte har en
pris.

---

In article <rjelf4v8ch.fsf@zuse.dina.kvl.dk>,
Per Abrahamsen <abraham@dina.kvl.dk> wrote:


> I princippet bør portabel C++ generere hurtigere kode fordi
>
> 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
> mulige, og

Dette er forkert. De manglende typecheck i C gør dette hurtigere.
Derudover er der problemerne med virtual tables som der skal slås op i
såfremt man over overskrevet en nedarvet metode. Disse lookups er hvad
der i gamle dage gjorde C++ langsomt.

> 2) mange ting er indbygget i sproget (og standard biblioteket), som
> compileren derved kan optimere langt bedre end hvis de skulle
> simuleres i C.

Hvad mener du ? Såfremt flere standardlibs er håndoptimerede har du ret.
Ellers ikke.

> I praksis vil C++ programmer der bruger C++ fasciliteter ofte være
> langsommere end ækvivalente C programmer. Det skyldes at det er let
> at introducere nye abstraktioner i C++, hvilket tilskynder
> programmørerne til at gøre det, og disse abstraktioner har ofte har en
> pris.

korrekt.

---

"Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
>
> > I princippet bør portabel C++ generere hurtigere kode fordi
> >
> > 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
> > mulige, og
>
> Dette er forkert. De manglende typecheck i C gør dette hurtigere.

Kan du give et eksempel hvor det er tilfældet - gerne med en konkret måling
der påviser det ?

> Derudover er der problemerne med virtual tables som der skal slås op i
> såfremt man over overskrevet en nedarvet metode. Disse lookups er hvad
> der i gamle dage gjorde C++ langsomt.

Det udsagn må vist høre hjemme i kategorien "temmeligt unuanceret".

Det er ikke fordi at man overskriver en metode, at funktions kaldet (typisk)
sker gennem den virtuelle funktions tabel (vtbl).
Det er fordi funktionen er virtuel - uanset om den er overskrevet eller ej.
Sådan har det altid været, og vil formodentligt forblive sådan.
Dertil kommer naturligvis, at det generelt er en dårlig idee at overskrive
ikke virtuelle metoder - så det er ikke helt forkert hvad du sagde.

Hvis C++ compileren med _sikkerhed_ kan afgøre objektets dynamiske type,
_må_ den gerne lave et ikke virtuelt kald eller inline funktionen, selvom
den er virtuel. F.eks.
class foo
{
public:
virtual void bar(void);
};

void bar(void)
{
foo f;
f.bar(); // _can_ be dispatched non-virtual or inlined
}

Virtuelle kald er _lidt_ langsommere end ikke virtuelle kald, og en del
langsommere end inlinede funktions kald.
Det er alt sammen meget naturligt, hvis man tænker over det.
Se eventuelt de referencer jeg tidligere har givet i denne tråd for konkrete
målinger.

Gør virtuelle kald så C++ programmer langsomme ?
Nej, ikke hvis de er brugt rigtigt.

Hvis man bruger virtuelle metoder fordi man har _brug_ for run-time
polymorphy, så er en typisk implementering (eet opslag med et fast index i
en fast tabel, efterfulgt af et indirekte funktionskald) den hurtigste måde
at gøre det på.

Hvis man _ikke_ har _brug_ for run-time polymorphy, men anvender virtuelle
metoder alligevel, så har man naturligvis et overhead, i den forstand at man
betaler for noget som man ikke har glæde af.

Venlig hilsen

Mogens Hansen

---

In article <3d1054d3$1@lxcs1.manbw.dk>,
"Mogens Hansen" <mogens_h@dk-online.dk> wrote:

> "Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> > Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> >
> >
> > > I princippet bør portabel C++ generere hurtigere kode fordi
> > >
> > > 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
> > > mulige, og
> >
> > Dette er forkert. De manglende typecheck i C gør dette hurtigere.
>
> Kan du give et eksempel hvor det er tilfældet - gerne med en konkret måling
> der påviser det ?

Hvis du laver noget i stil med:

MyObject o = (MyObject) someObject;
o.etellerandet();

så laves der her et opslag idet metoden skal findes inden den kaldes.
Der sker altså et runtime typecheck, og dette koster performance.

Dette er også eksemplet på, at alle funktionskald prinicpielt render
gennem virt tabeller.

C++ er normalt kun er langsommere såfremt der er rigtigt mange kald til
metoder, fremfor kald til pæn C lignende kode.

---

[ Povl H. Pedersen ]

[ snip ]

> Hvis du laver noget i stil med:
>
> MyObject o = (MyObject) someObject;
> o.etellerandet();
>
> så laves der her et opslag idet metoden skal findes inden den
> kaldes.


Nei:

[ SPARC asm ]

main:
..LLFB3:
!#PROLOGUE# 0
save %sp, -120, %sp
..LLCFI2:
!#PROLOGUE# 1
add %fp, -20, %o0
call _ZN3foo3barEv, 0
nop

[ /SPARC asm ]

som tilsvarer

int
main()
{
foo f;
f.bar();
}


Det spiller _ingen_ rolle om bar er virtuell eller ej.


> Der sker altså et runtime typecheck, og dette koster performance.


_Hvor_ tar du dette ifra? _Hvilket_ runtime typecheck? (Hint: i
eksempelet over er det _statisk_ opplagt hvilken funksjon skal kalles,
_uansett_ om etellerandet er virtuell eller ej. For extra credit:
hvorfor er det slik?).


> Dette er også eksemplet på, at alle funktionskald prinicpielt render
> gennem virt tabeller.


Huh?


> C++ er normalt kun er langsommere såfremt der er rigtigt mange kald
> til metoder, fremfor kald til pæn C lignende kode.


_Slutt_ med dette.

For det første er det ekstremt dustete å snakke om hastigheten til
_språk_, da selve formuleringen ikke gir mening. Man kan sammenligne
hastigheten til _implementasjoner_ av språk, ikke hastigheten til
språk som sådanne.

For det andre vil kall på:

* non-virtual member functions
* static member functions

være _nøyaktig_ like raske som kall på "vanlige" C funksjoner, med
mindre implementasjonen er _hjerneskadet_. I noen tilfeller vil også
kall på _virtuelle_ funksjoner kunne skje uten ekstra oppslag i en
virtuell tabell (den meste vanlige teknikken idag). Eksempelet ditt
illustrerer dette meget godt.

Kall på virtuelle funksjoner der det ikke er opplagt compile-time
hvilken funksjon skal kalles skjer via ett tabelloppslag, men _det_ er
på _ingen_ måte tregere enn den tilsvarende løsningen realisert i C på
alle implementasjoner jeg kjenner til.





ivr
--
C++: "an octopus made by nailing extra legs onto a dog"
            -- Steve Taylor, 1998

---

"Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote:
>
> > "Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> > > Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> > >
> > >
> > > > I princippet bør portabel C++ generere hurtigere kode fordi
> > > >
> > > > 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
> > > > mulige, og
> > >
> > > Dette er forkert. De manglende typecheck i C gør dette hurtigere.
> >
> > Kan du give et eksempel hvor det er tilfældet - gerne med en konkret
måling
> > der påviser det ?
>
> Hvis du laver noget i stil med:
>
> MyObject o = (MyObject) someObject;

En lidt knudret måde at oprette et objekt på - men lad os ikke lægge for
stor vægt på det i denne sammenhængen.

> o.etellerandet();
>
> så laves der her et opslag idet metoden skal findes inden den kaldes.
> Der sker altså et runtime typecheck, og dette koster performance.
>

Nej, det er absolut ikke rigtigt generelt.
På baggrund af det eksempel du viser, kan man slet ikke sige hvor der sker.

Hvis funktionen "MyObject:::etellerandet" er en lille inline funktion, og
compileren er bare nogenlunde, vil der slet ikke blive foretaget et
funktionskald.
Hvis funktionen "MyObject:::etellerandet" er en _ikke_ virtuel metode, vil
der typisk blive lavet et direkte funktionskald, som er eksakt lige så
hurtigt som en C funktion "foo(MyObject*)".
Hvis funktionen "MyObject:::etellerandet" er en virtuel metode, skal der
typisk laves et opslag i den virtuelle funktions tabel, hvorefter der vil
blive lavet et indirekte funktionskald. Performance vil svare til at kalde
en C funktion "foo(MyObject*)" via en peger til funktionen.

Hvilken sammenhæng har eksemplet med "De manglende typecheck i C gør dette
hurtigere" ?

> Dette er også eksemplet på, at alle funktionskald prinicpielt render
> gennem virt tabeller.

Nej, det er _absolut_ _fuldstændigt_ misforstået.
Hvorfra har du overhovedet fået den idee ?

> C++ er normalt kun er langsommere såfremt der er rigtigt mange kald til
> metoder, fremfor kald til pæn C lignende kode.

Nej, det er absolut forkert.
Prøv selv at måle det, eller kig på de målinger som jeg allerede har henvist
til som andre har lavet.

Venlig hilsen

Mogens Hansen

---

In article <aeqe19$rk7$1@news.cybercity.dk>,
"Mogens Hansen" <mogens_h@dk-online.dk> wrote:

> "Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> > "Mogens Hansen" <mogens_h@dk-online.dk> wrote:
> >
> > > "Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> > > > Per Abrahamsen <abraham@dina.kvl.dk> wrote:
> > > >
> > > >
> > > > > I princippet bør portabel C++ generere hurtigere kode fordi
> > > > >
> > > > > 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
> > > > > mulige, og
> > > >
> > > > Dette er forkert. De manglende typecheck i C gør dette hurtigere.
> > >
> > > Kan du give et eksempel hvor det er tilfældet - gerne med en konkret
> måling
> > > der påviser det ?
> >
> > Hvis du laver noget i stil med:
> >
> > MyObject o = (MyObject) someObject;
>
> En lidt knudret måde at oprette et objekt på - men lad os ikke lægge for
> stor vægt på det i denne sammenhængen.
>
> > o.etellerandet();
> >
> > så laves der her et opslag idet metoden skal findes inden den kaldes.
> > Der sker altså et runtime typecheck, og dette koster performance.
> >
>
> Nej, det er absolut ikke rigtigt generelt.
> På baggrund af det eksempel du viser, kan man slet ikke sige hvor der sker.
>
> Hvis funktionen "MyObject:::etellerandet" er en lille inline funktion, og
> compileren er bare nogenlunde, vil der slet ikke blive foretaget et
> funktionskald.
> Hvis funktionen "MyObject:::etellerandet" er en _ikke_ virtuel metode, vil
> der typisk blive lavet et direkte funktionskald, som er eksakt lige så
> hurtigt som en C funktion "foo(MyObject*)".
> Hvis funktionen "MyObject:::etellerandet" er en virtuel metode, skal der
> typisk laves et opslag i den virtuelle funktions tabel, hvorefter der vil
> blive lavet et indirekte funktionskald. Performance vil svare til at kalde
> en C funktion "foo(MyObject*)" via en peger til funktionen.
>
> Hvilken sammenhæng har eksemplet med "De manglende typecheck i C gør dette
> hurtigere" ?

Du kender ikke nødvendigvis typen af someObject, som kunne være en void
* der castes. Altså er det nødvendigt i runtime at lave et typecheck i
C++. Det var ihvertfald min tanke. Jeg mener at have set runtime errors
(i modsætning til crashes) på forkerte typer. men det kan være jeg tager
fejl. Har ikke kodet ret meget i C++ de seneste år.

>> > Dette er også eksemplet på, at alle funktionskald prinicpielt render
> > gennem virt tabeller.
>
> Nej, det er _absolut_ _fuldstændigt_ misforstået.
> Hvorfra har du overhovedet fået den idee ?

Jeg checked Stoustrups bog, og kan se du har ret. Jeg tænkte på et af de
sprog hvor alle funtioner var virtuelle.

> > C++ er normalt kun er langsommere såfremt der er rigtigt mange kald til
> > metoder, fremfor kald til pæn C lignende kode.
>
> Nej, det er absolut forkert.
> Prøv selv at måle det, eller kig på de målinger som jeg allerede har henvist
> til som andre har lavet.

Enig, medmindre det er en virtuel funktion,

---

[ Povl H. Pedersen ]

[ snip ]

> > > Hvis du laver noget i stil med:
> > >
> > > MyObject o = (MyObject) someObject;

[ snip ]

> > Hvilken sammenhæng har eksemplet med "De manglende typecheck i C
> > gør dette hurtigere" ?
>
> Du kender ikke nødvendigvis typen af someObject, som kunne være en
> void * der castes.


For det første er slike typecasts ikke tillatt.

For det andre, selv om slike casts hadde vært tillatt, kunne man
fremdeles ha avgjort compile-time _hvilken_ funksjon skulle kalles
etter C++ sine regler. I eksempelet ditt trenger man _ingen_ runtime
typesjekktester.

(hint1: hva er forskjellen mellom å kalle en metode via en peker, en
referanse og et objekt? hint2: hva er "slicing"?)


> Altså er det nødvendigt i runtime at lave et typecheck i C++.


Nei, ikke i dette tilfellet.


> Det var ihvertfald min tanke. Jeg mener at have set runtime errors
> (i modsætning til crashes) på forkerte typer. men det kan være jeg
> tager fejl. Har ikke kodet ret meget i C++ de seneste år.


Man _kan_ tvinge runtime typesjekk i C++ (fx. vha. dynamic_cast). Men
det er en _lang_ vei derfra til konklusjonen din.

[ snip ]


> > > C++ er normalt kun er langsommere såfremt der er rigtigt mange
> > > kald til metoder, fremfor kald til pæn C lignende kode.
> >
> > Nej, det er absolut forkert. Prøv selv at måle det, eller kig på
> > de målinger som jeg allerede har henvist til som andre har lavet.
>
> Enig, medmindre det er en virtuel funktion,


Nei, FCOL. Vær så snill, les litt om hvordan virtuelle funksjoner
fungerer, og prøv å finne ut hvordan _tilsvarende_ kode i C og C++ vil
bli oversatt til det laget som måtte finnes på nivået under.





ivr
--
C++: "an octopus made by nailing extra legs onto a dog"
            -- Steve Taylor, 1998

---

"Povl H. Pedersen" <nospam@home.terminal.dk> wrote
> "Mogens Hansen" <mogens_h@dk-online.dk> wrote:
>
> > Hvilken sammenhæng har eksemplet med "De manglende typecheck i C gør
dette
> > hurtigere" ?
>
> Du kender ikke nødvendigvis typen af someObject,

Enig.
Det er bestemt ikke tydeligt hvad kode gør - hvis det overhovedet er lovlig
kode.

> ...som kunne være en void
> * der castes. Altså er det nødvendigt i runtime at lave et typecheck i
> C++.

Nej.
Der kan ikke laves noget runtime typecheck på void *.
Kun dynamic_cast (som ikke har noget tilsvarende i C-style cast) giver
anledning til en runtime bestemmelse af typen.
Alle andre cast (static_cast, const_cast, reinterpret_cast og C-style cast)
beregnes på compiletime, hvis de kan lade sig gøre.

Jeg kan dog stadig ikke se hvilken sammenhæng de mente at "De manglende
typecheck i C gør dette hurtigere".
Måske mener du det ikke mere, og i så fald skal jeg nok lade være med at
trampe mere rundt i det.

> Det var ihvertfald min tanke. Jeg mener at have set runtime errors
> (i modsætning til crashes) på forkerte typer. men det kan være jeg tager
> fejl.

Jeg ved ikke lige hvor du vil hen.
Men ja, der findes mange fejlbehæftede programmer.

> Har ikke kodet ret meget i C++ de seneste år.

Ok.

Venlig hilsen

Mogens Hansen

---

Hejsa.

"Povl H. Pedersen" <nospam@home.terminal.dk> wrote in message
news:nospam-2097DC.18315219062002@news.cybercity.dk...
[klip]
> Hvis du laver noget i stil med:
>
> MyObject o = (MyObject) someObject;
> o.etellerandet();
>
> så laves der her et opslag idet metoden skal findes inden den kaldes.
> Der sker altså et runtime typecheck, og dette koster performance.
>
> Dette er også eksemplet på, at alle funktionskald prinicpielt render
> gennem virt tabeller.

Som Mogens og Igor siger, så er det ikke et eksempel på dette.

Der bliver ikke slået op i tabellen. For at få oversætteren til finde den
korrekte funktion, til at kalde, ved kald til en virtual funktion, så _skal_
den kaldes igennem enten en reference eller en pointer.

Følgende program skulle gerne illustrere det.


mvh Jonas


#include <iostream>

using namespace std;

struct A
{
virtual int foo(){ return 0; }
};

struct B : public A
{
virtual int foo(){return 1;}
};

int main( )
{
B enb;
A ena = (A)enb;
A* ato = &enb;
A& atre = enb;
cout << ena.foo() << endl;
cout << ato->foo() << endl;
cout << atre.foo() << endl;
}

Mvh Jonas

---

"Povl H. Pedersen" <nospam@home.terminal.dk> writes:

> In article <rjelf4v8ch.fsf@zuse.dina.kvl.dk>,
> Per Abrahamsen <abraham@dina.kvl.dk> wrote:
>
>
>> I princippet bør portabel C++ generere hurtigere kode fordi
>>
>> 1) typesystemet er en anelse stærke, så lidt flere optimeringer er
>> mulige, og
>
> Dette er forkert. De manglende typecheck i C gør dette hurtigere.

Det er en stærkt kontroversiel påstand at bedre statisk typecheck (som
er hvad jeg taler om) skulle gøre programmerne langsommere,
konventionel visdom siger det modsatte.

> Derudover er der problemerne med virtual tables som der skal slås op i
> såfremt man over overskrevet en nedarvet metode. Disse lookups er hvad
> der i gamle dage gjorde C++ langsomt.

Hvis programmøren _overfødigt_ erklærer funktioner virtuelle vil koden
blive langsommere. Men hvis programmøren kun erklærer funktioner
virtuelle hvor der er brug for det, vil man i C kode enten skulle
emulere et OO design med funktionspointere, eller lave et
funktionsorienteret design med store switch statements. I begge
tilfælde vil C++ kunne give lige så god, eller bedre kode (for
løsningen med switch-statements er det dog arkitekturafhængigt).

>> 2) mange ting er indbygget i sproget (og standard biblioteket), som
>> compileren derved kan optimere langt bedre end hvis de skulle
>> simuleres i C.
>
> Hvad mener du ? Såfremt flere standardlibs er håndoptimerede har du ret.
> Ellers ikke.

Mange standard funktioner i GCC er indbyggede i compileren, hvilket er
endnu bedre end "håndoptimeret". Det betyder at compileren kan
generere kode der er bedre end en generel håndoptimeret rutine, da
compileren ved præcis hvor funktionen bliver brugt.

---

In article <3d0d8a24$0$80399$edfadb0f@dspool01.news.tele.dk>,
"bent petersen" <brugandre@bygikkelasselarsen.dk> wrote:

> hvad er forskellen på c og c++ ??

C er Objective C uden objekterne. Et godt programmeringssprog, som
normalt også også kan compiles med en C++ compiler

C++ er en ikke helt så ren og pæn måde som Objective C til at
implementere objektorienteret programmering ovenpå C.

C++ er en fremragende compiler til at compile C kode. Giver bedre
fejlmeldinger, og man kan tillade sig er declarere sine variable nede i
koden hvor de benyttes.

Hvis du er newbie der skal lære et af dem, så lær noget objektorienteret
til at started med (Objective C eller C++). Når du skal implementere
dine metoder, så anvender du alligevel god gammeldaws C.

---

Povl H. Pedersen <nospam@home.terminal.dk> skrev:

> C++ er en fremragende compiler til at compile C kode.

Nej, en C++-oversætter kan ikke oversætte al korrekt C-kode. Men det
er muligt at man ofte også får en C-oversætter ved anskaffelse af en
C++-oversætter.

> Giver bedre
> fejlmeldinger,

Hvordan det?

> og man kan tillade sig er declarere sine variable nede i
> koden hvor de benyttes.

Det gælder da både C og C++.

---

Byrial Jensen <bjensen@nospam.dk> writes:

> > og man kan tillade sig er declarere sine variable nede i
> > koden hvor de benyttes.
>
> Det gælder da både C og C++.

Må man i C99 erklære variable midt i en blok? Fx sådan:

int
main ()
{
printf ("hej, verden\n");

int x = 1000;

printf ("%d kys og kram", x);

return 0;
}

---

Soeren Sandmann <sandmann@daimi.au.dk> skrev:
> Må man i C99 erklære variable midt i en blok? Fx sådan:
>
> int
> main ()
> {
> printf ("hej, verden\n");
>
> int x = 1000;
>
> printf ("%d kys og kram", x);
>
> return 0;
> }

Ja.

---

"Povl H. Pedersen" <nospam@home.terminal.dk> writes:

> C++ er en ikke helt så ren og pæn måde som Objective C til at
> implementere objektorienteret programmering ovenpå C.

Det er en meget subjektiv vurdering. Objective C er Smalltaks
objektmodel overført temmelig direkte til C, hvor OOP i C++ er mere en
naturlig udvidelse af struct begrebet.

Jeg finder at C++'s løsning giver et mere homogent sprog, men hvis man
mener at OOP absolut skal være som i Smalltalk er Objective C
selvfølgelig "renere".

---

Den Mon, 17 Jun 2002 23:15:51 +0200 skrev Povl H. Pedersen:
>In article <3d0d8a24$0$80399$edfadb0f@dspool01.news.tele.dk>,
> "bent petersen" <brugandre@bygikkelasselarsen.dk> wrote:
>
>> hvad er forskellen på c og c++ ??
>
>Hvis du er newbie der skal lære et af dem, så lær noget objektorienteret
>til at started med (Objective C eller C++). Når du skal implementere
>dine metoder, så anvender du alligevel god gammeldaws C.

Hvor meget C anvender man reelt? Ja +, -, osv. er det samme, men
standard libraries er da vidt forskellige. Fx. mellem C's char*, strcpy,
strcmp,... og C++'s string.

Mvh
Kent
--
Which one is faster - Lotus Notes or Lotus Esprit?

---

Jeg er vis meget "newbie".
c og c++ det er vist den moderen og datteren :)

Hvis jeg vil prøve c++ skal det så være visual c++ eller?
hviske programmer (alle) skal jeg så skaffe for at kunne lave programmer?

Mvh
Bent

"bent petersen" <brugandre@bygikkelasselarsen.dk> skrev i en meddelelse
news:3d0d8a24$0$80399$edfadb0f@dspool01.news.tele.dk...
> hvad er forskellen på c og c++ ??
>
> Mvh
> BHP
>
>

---

"bent petersen" <brugandre@bygikkelasselarsen.dk> wrote

> Hvis jeg vil prøve c++ skal det så være visual c++ eller?

C++ er et programmeringssprog.
Visual C++ er et udviklingsmiljø til MS-Windows, som kan bruges til at lave
C++ programmer med.

> hviske programmer (alle) skal jeg så skaffe for at kunne lave programmer?

Hvilken platform kører du ?

Venlig hilsen

Mogens Hansen