---

Hey.. Er der stor forskel på C & C++ og hvilket bør man vælge som
nybegynder?

Mvh
Michael

---

"Michael Andreasen" <maskinen2000@hotmail.com> wrote in message news:ao7b89$ief$1@sunsite.dk...
> Hey.. Er der stor forskel på C & C++ og hvilket bør man vælge som
> nybegynder?

Ja, der er stor forskel. C++ er vel nærmest en udvidelse og opdatering af C. Der er
ikke noget i vejen for at starte med C++. Begge dele er sikkert noglelunde lige svært
at lære. Det kommer an på hvad du skal bruge det til. Jeg vil anbefale at du sætter dig
mere ind i forskellen på C og C++ (og måske andre sprog som VB, Java og C#) før du
bestemmer dig, så du kan træffe et kvalificeret valg.

---

> Ja, der er stor forskel. C++ er vel nærmest en udvidelse og opdatering af
C.

Ikke bare "vel nærmest", men i allerhøjeste grad. :) Bjarne Stoustrups mål
var en ajourføring af C, der gjorde det muligt at reflektere centrale OOP
paradigmer direkte i sproget (C++ hed oprindeligt "C with classes"). Der er
så kommet et par ekstra syntaktiske forbedringer til, men det var
"OOP-enablement" der var den drivende kraft.

Med venlig hilsen,
/\/\\ads Orbesen Troest

---

Mads Orbesen Troest wrote:
> Ikke bare "vel nærmest", men i allerhøjeste grad. :) Bjarne Stoustrups mål
> var en ajourføring af C, der gjorde det muligt at reflektere centrale OOP
> paradigmer direkte i sproget (C++ hed oprindeligt "C with classes"). Der
> er så kommet et par ekstra syntaktiske forbedringer til, men det var
> "OOP-enablement" der var den drivende kraft.

ok.. tak til alle 3 for svaret.. Jeg tror bare jeg prøver at kaste mig ud i
noget c++ begynder bøger eller websites hvis jeg kan finde nogle gode
tutorials.

--
Mvh
Michael

---

Michael Andreasen wrote:
> ok.. tak til alle 3 for svaret.. Jeg tror bare jeg prøver at kaste mig ud
> i noget c++ begynder bøger eller websites hvis jeg kan finde nogle gode
> tutorials.

Jeg har vel også forstået det korrekt, hvis jeg tror jeg ikke behøver andet
end en teksteditor (f.eks. nano/pico) og en compiler g++ ??

Eller findes der nogle gode editors til KDE?

Takker
Michael Andreasen

---

> Jeg har vel også forstået det korrekt, hvis jeg tror jeg ikke behøver
andet
> end en teksteditor (f.eks. nano/pico) og en compiler g++ ??

Joeh, det er da en start. :) Du kommer nok også til at stifte bekendtskab
med "gdb" (det synes at være linux du kører) når du skal debugge og "make"
når engang du skal til at lave større projekter (hvis du ikke bruger et mere
fancy IDE - der findes vist noget på Sourceforge, men jeg har aldrig selv
stiftet bekendtskab med det). Men til at komme igang med er en simpel editor
fint nok; og på *nix systemer er gcc og g++ stort set altid installeret, og
så er det bare at gå igang. :)

#include <iostream>
int main() {
cout << "Jamen, ER det ikke fanTAStiskt, Johan?!" << endl;
}

> Eller findes der nogle gode editors til KDE?

Somme vil nok sige (x)emacs (der har glimrende programmerings "modes" med
syntax highlighting, debugger interface, etc.), og andre vil sige at dertil
er livet for kort, og pludselig har man en flamende ikke-C(++) relateret
tråd her... ;)

/\/\\

---

> #include <iostream>
> int main() {
> cout << "Jamen, ER det ikke fanTAStiskt, Johan?!" << endl;
> }

Æh, flot; der skal (med mindre det er iostream.h der includes) også lige stå
"using namespace std;" før main, eller også skal der stå std::cout og
std::endl - det lille Hello World mesterværk klarede jeg jo glimrende... ;)

/\/\\

---

Mads Orbesen Troest wrote:
> Æh, flot; der skal (med mindre det er iostream.h der includes) også lige
> stå "using namespace std;" før main, eller også skal der stå std::cout og

:o] Tak for eksemplet.. Har allerede fået det op og køre med g++ Det gik jo
forbavsende nemt..

Tak til alle... Iøvrigt glæder jeg mig til at deltage her i gruppen - det
lader til der er en god stemning hvis jeg ser bort fra de hentydninger der
er til flamekrige og relionskrige m.m.

Mvh
Michael

---

Michael Andreasen skrev:

>lader til der er en god stemning hvis jeg ser bort fra de hentydninger der
>er til flamekrige og relionskrige m.m.

Det er kun hentydninger. Der har været flere eksempler på
tværgående diskussioner uden at det saglige grundlag er gået
fløjten.

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

---

Mads Orbesen Troest wrote:
> Æh, flot; der skal (med mindre det er iostream.h der includes) også lige stå
> "using namespace std;" før main, eller også skal der stå std::cout og
> std::endl - det lille Hello World mesterværk klarede jeg jo glimrende... ;)

Og da der ikke er noget der hedder iostream.h, skal der enten stå "using
namespace std;" eller "std::cout".

Ivan Johansen

---

> Og da der ikke er noget der hedder iostream.h, skal der enten stå "using
> namespace std;" eller "std::cout".

Det er korrekt at "iostream.h" er gammeldags og slet at opfordre til. De
fleste compilere understøtter det (fordi iostreams var vidt implementerede
før namespaces var, og for at bevare bagudkompatibiliteten). Når man
includer iostream.h introduceres det samtidig i namespacet; hvilket på en
compiler der ikke understøtter namespaces bare vil sige, at det er
tilgængeligt uden videre, og på en nyere compiler mappes det (using
std::cout, etc.), så man ligeledes her kan anvende medlemmerne uden
namespace-kvalifikation.

Men, du har ret, det er ikke standard og generelt ikke en vane man bør
tillægge sig. Jeg har benyttet det nogle gange i kode der skulle være
portabelt mellem forskellige compilere, hvoraf nogen havde namespaces og
andre ikke. Jeg er dog siden gået over til at løse dette problem med sort
makro magi samt ved at undgå "using namespace" (der i det hele taget let kan
overdrives), og i stedet for at qualifye direkte med "std::" placere end
compilerSTD makro foran, som mapper til "std::" på namespace compilere og
som er tom på gamle compilere. Jeg har så på de gamle compilere include
filer, der mapper fx "<iostream>" til "<iostream.h>". (Hvor STLport har
kunnet anvendes sørger den automatisk for dette.)

/\/\\

---

On Fri, 11 Oct 2002 23:00:03 +0200, Michael Andreasen wrote:

> Eller findes der nogle gode editors til KDE?
>
Hvis det er en IDE, du tænker på, kan du kikke på KDevelop. Måden
den er bygget op på, mener lidt om Borland Builder.

Hvis du vil snuse lidt til Gnome, findes der også her et godt bud på en
IDE. Hent Anjuta fra http://anjuta.sourceforce.net

Og så er det ellers bare med at komme igang

--
Hilsen/Sincerely
Michael Rasmussen

"C makes it easy to shoot yourself in the foot; C++ makes it harder,
but when you do, it blows away your whole leg." - Bjarne Stroustrup
-------------------------------------------------------------------
Fjern NOSPAM fra min adresse, for at sende mig en mail

---

"Michael Rasmussen" <mir@datanom.net> wrote in message
news:pan.2002.10.11.22.42.31.714648.26522@datanom.net...

> Hvis det er en IDE, du tænker på, kan du kikke på KDevelop. Måden
> den er bygget op på, mener lidt om Borland Builder.

Jeg syntes at KDevelop minder mere om Visual C++ (før .NET) end Borland
C++Builder.
Hvis man vil prøve noget, der ligner C++Builder under Linux må det være
Borland Kylix 3.
Den kan hentes i en OpenEdition fra www.borland.com

Venlig hilsen

Mogens Hansen

---

Mads Orbesen Troest <mads@troest.NEVERMORE.dk> skrev:
>> Ja, der er stor forskel. C++ er vel nærmest en udvidelse og
>> opdatering af C.
>
> Ikke bare "vel nærmest", men i allerhøjeste grad.

Bemærk at det /var/ C++, men det /er/ det ikke længere for C har
udviklet sig siden den version som C++ er bygget over.

Ethvert korrekt C-program efter C-standarden fra 1989 er med ganske
få undtagelser også et korrekt C++-program. Men det samme gælder
ikke for korrekte C-programmer efter C-standarden fra 1999.

---

Michael Andreasen wrote:
> Hey.. Er der stor forskel på C & C++ og hvilket bør man vælge som
> nybegynder?

Ja, der er stor forskel. Teknisk set er C++ en overbygning på C, men de
teknikker der anvendes i de to sprog er meget forskellige. I praksis er
det derfor to vidt forskellige sprog.

Jeg vil anbefale at man som begynder starter med C++, da det er på et
højere niveau og derfor nemmere at forstå. Jeg mener at det er nemmere
at lære C når man kan C++ end omvendt.

Efter min mening er C i dag dog kun relevant til små embedede systemer,
men der er andre der mener noget andet.

Ivan Johansen

---

> Efter min mening er C i dag dog kun relevant til små embedede systemer,
> men der er andre der mener noget andet.


Kan du ikke hurtigt forklare hvad et embeded system er? (jeg er nowice og
ikke uenig)

--
Mvh
Anders Lund
Anders@zaimGED.dk
Fjern geden fra min signatur!

---

"Anders Lund" <Anders@zaimGED.dk> wrote in message news:3da73e5f$0$72286$edfadb0f@dspool01.news.tele.dk...
> > Efter min mening er C i dag dog kun relevant til små embedede systemer,
> > men der er andre der mener noget andet.
> Kan du ikke hurtigt forklare hvad et embeded system er? (jeg er nowice og
> ikke uenig)

Det sad jeg også og tænkte på.. men jeg var for doven til at spørge google eller her.

---

> Kan du ikke hurtigt forklare hvad et embeded system er? (jeg er nowice og
> ikke uenig)

Din lokale hæveautomat, for eksempel. ;)

Typisk specialiserede systemer, der kører i en hardwaremæssigt begrænset -
men til gengæld veldefineret (fx realtidssystemer med garanterede
svartider) - kontekst.

/\/\\ads Orbesen Troest

---

Anders Lund wrote:
> Kan du ikke hurtigt forklare hvad et embeded system er? (jeg er nowice og
> ikke uenig)

Et embedet system er et lille system med processor, ram, osv, der er
indlejret i et apparat og ikke opfattes som en computer. Som eksempler
kan jeg nævne telefoner, mobiltelefoner, fjernsyn, video, ovn, alarmer,
osv.

Til sådanne små processorer har man ofte kun assembler og en C compiler
til rådighed. Til små systemer hvor man f.eks. kun har 16 kB EEPROM
(hukommelse til programmet) til rådighed, er det ofte nødvendigt at
presse processor og hukommelse til det yderste.

Ivan Johansen

---

On Fri, 11 Oct 2002 22:25:59 +0200, Ivan Johansen <NG@Padowan.dk>
wrote:

>Efter min mening er C i dag dog kun relevant til små embedede systemer,
>men der er andre der mener noget andet.
Tjaa, hvis en mobiltelefoner falder inden for kategorien "små embedede
systemer". Det vil jeg nu ikke mene, meeen det er vel en individuel
bedømmelse. C++ ville ikke kunne bruges til at lave protokolstakken i
en mobil med, da dette ville kræve en uforholdsmæssig kraftigt CPU til
at udføre det. I gamle dage lå skellet imellem at lave tingene i C og
i Assembler. I dag er det rykket et skridt opad til at være valget
imellem C++/Java og C. Men som tiden går vil man jo kunne få
kraftigere og kraftigere CPU'er til embeddede systemer (som ikke
bruger særligt meget strøm!!!), så man kan gå fuld og helt over til
C++/Java. Man slipper dog ikke for Assembler og C i en lille del af
systemet.

Jeg arbejder selv i et selskab som udvikler SW til GSM/GPRS/EDGE
mobiltelefoner, her bruger vi udelukkende C. CPU'erne er ARM7/9 hvilke
er 32-bit RISC CPU'er. I en alm. GSM/GPRS terminal (som f.eks. Nokia
3410) sidder en ARM7 (32,5MHz) og en ADI 2181 DSP (65 MHz). Et sådan
system har mellem 8-16MByte FLASH Prom (program hukommelse) og
1-4Mbyte RAM.

Jeg ville helt klart vælge C først, da dette kan lære en noget om den
"simple" struktur i programmering, og derefter gå videre til et sprog
med OOP, enten C++ eller Java af en eller anden art.

/Thomas

---

Thomas Lykkeberg skrev:

>Jeg ville helt klart vælge C først, da dette kan lære en noget om den
>"simple" struktur i programmering, og derefter gå videre til et sprog
>med OOP, enten C++ eller Java af en eller anden art.

Jeg vil råde til at man lærer OOP som udgangspunkt. Den
programmeringsmåde kan spare en for et hav af problemer som er
ligegyldige for slutløsningen.

Men i en vis forstand kan det være lige meget. Når man når et
vist niveau, skal man kunne begge dele.

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

---

Thomas Lykkeberg wrote:
> Tjaa, hvis en mobiltelefoner falder inden for kategorien "små embedede
> systemer". Det vil jeg nu ikke mene, meeen det er vel en individuel
> bedømmelse.
Okay, en mobiltelefon er nok et stort embedet system. Hvis der er en C++
compiler til rådighed vil jeg til enhver tid foretrække den frem for C.

> C++ ville ikke kunne bruges til at lave protokolstakken i
> en mobil med, da dette ville kræve en uforholdsmæssig kraftigt CPU til
> at udføre det.
Hvorfor det? C++ er designet til at være lige så hurtig som C, hvilket
stort set er opfyldt. Nogen gange er programmer skrevet i C++ endda
hurtigere end hvis de var skrevet i C. Der er ikke nogen der siger at du
absolut skal bruge virtuelle funktioner og exceptions fordi du bruger C++.

> Jeg ville helt klart vælge C først, da dette kan lære en noget om den
> "simple" struktur i programmering, og derefter gå videre til et sprog
> med OOP, enten C++ eller Java af en eller anden art.

Min erfaring er at når man starter med C lærer man at bruge masser af
makroer og casts. Det er meget svært at vænne sig af med når man skifter
til C++. Desuden synes jeg ikke at der er noget simpelt i C. Hvis man
skulle lære noget andet først ville jeg anbefale Pascal/Delphi. Sprogene
Pascal og C++ har nemlig vidt forskellig syntaks, så man kommer ikke til
at blande dem sammen. C og C++ er derimod meget nemme at blande sammen.

Ivan Johansen

---

On Sat, 12 Oct 2002 11:39:05 +0200, Ivan Johansen <NG@Padowan.dk>
wrote:

>Okay, en mobiltelefon er nok et stort embedet system. Hvis der er en C++
>compiler til rådighed vil jeg til enhver tid foretrække den frem for C.
Jeg har kun et ord: Protabilitet.

>Hvorfor det? C++ er designet til at være lige så hurtig som C, hvilket
>stort set er opfyldt. Nogen gange er programmer skrevet i C++ endda
>hurtigere end hvis de var skrevet i C. Der er ikke nogen der siger at du
>absolut skal bruge virtuelle funktioner og exceptions fordi du bruger C++.
Nej, selvfølgelig ville jeg heller ikke bruge disse funktionaliteter,
men et ord igen: Portabilitet.

Jeg er da også godt klar over at "C" kode kompileret med en C++
kompiler må give næsten det samme "output", sådan rent
hastighedsmæssigt. Men en ting skal være sagt, det er næsten umuligt
at skrive 100000+ liner kode, til en GSM/GPRS protokol stak, som skal
kunne kompileres på 10 forskellige C++ kompilere. Det snakkes der jo
om i stor stil her i gruppen. Tingene har vist sig at være noget
nemmere hvis man holder sig til "årgang 1989 C". Det har ihvertfald
været konklusionen der hvor jeg arbejder. Men jeg vil da gerne
overraskes.

Jeg har meget svært ved at se fordelene i at bruge C++ til at lave
protokol stakken i en mobil med. Kan du iøvrigt forklare mig hvorfor
man også tilrådes på det kraftigste at bruge C, når man eks. vis laver
WDM/NT drivere til PC platformen?

C++ egner sig (efter min mening) kun til projekter som ikke kræver den
store realtids afhængighed. Men igen, hvis man blot koder C, med en
C++ kompiler, hvad er gevinsten så? Jeg vil til hver en tid mene at
det er at skyde gråspurve med kanonkugler.

Mht. vedligeholdelse, ja så må jeg give dig ret, så er C++ meget
overlegen, hvis det da er kodet med henblik på dette.

/Thomas

---

Thomas Lykkeberg <thomasDOTlykkeberg@privatDOTdk> skrev:
>
> Jeg er da også godt klar over at "C" kode kompileret med en C++
> kompiler må give næsten det samme "output", sådan rent
> hastighedsmæssigt. Men en ting skal være sagt, det er næsten umuligt
> at skrive 100000+ liner kode, til en GSM/GPRS protokol stak, som skal
> kunne kompileres på 10 forskellige C++ kompilere. Det snakkes der jo
> om i stor stil her i gruppen. Tingene har vist sig at være noget
> nemmere hvis man holder sig til "årgang 1989 C". Det har ihvertfald
> været konklusionen der hvor jeg arbejder. Men jeg vil da gerne
> overraskes.

Med gcc behøver man ikke at holde sig til C89. Gcc kan oversætte
til mange af de CPU'er som bruges i embeddede systemer. Jeg har
selv brugt gcc til ARM på min forrige arbejdsplads. Det var godt
nok ikke til C++-kode, men til C99 fordi vi havde brug for at kunne
initialisere unions med andre elementer end det første hvilket man
ikke kan gøre i C89. Men C++ oversat med gcc til embeddede systemer
burde ikke være noget problem.

---

Thomas Lykkeberg wrote:
> Nej, selvfølgelig ville jeg heller ikke bruge disse funktionaliteter,
> men et ord igen: Portabilitet.
Godt ord. Men C++ skulle også gerne være portabelt.

> Jeg er da også godt klar over at "C" kode kompileret med en C++
> kompiler må give næsten det samme "output", sådan rent
> hastighedsmæssigt. Men en ting skal være sagt, det er næsten umuligt
> at skrive 100000+ liner kode, til en GSM/GPRS protokol stak, som skal
> kunne kompileres på 10 forskellige C++ kompilere.
Det er nok rigtigt. Men andre dele mener jeg med fordel kan skrives i
C++. Det er ikke alle systemer der skal kompileres med 10 forskellige
kompilere.

> Det snakkes der jo
> om i stor stil her i gruppen. Tingene har vist sig at være noget
> nemmere hvis man holder sig til "årgang 1989 C". Det har ihvertfald
> været konklusionen der hvor jeg arbejder. Men jeg vil da gerne
> overraskes.
Det har du desværre ret i. Problemet er at der mangler ordentlige C++
kompilere.


> Jeg har meget svært ved at se fordelene i at bruge C++ til at lave
> protokol stakken i en mobil med.
Det er ikke sikkert at der er en fordel i C++ der. Det skal jeg ikke
kunne sige. Jeg snakker systemer generelt, hvor jeg vil foretrække C++
frem for C. Men ofte er der ikke nogen ordentlig C++ compiler til rådighed.

> Kan du iøvrigt forklare mig hvorfor
> man også tilrådes på det kraftigste at bruge C, når man eks. vis laver
> WDM/NT drivere til PC platformen?
Jeg kender ikke noget til Windows drivere og jeg har aldrig hørt nogen
tilråde det. Men en driver skal jo alligevel have et C interface, så jeg
tror ikke at der er nogen stor fordel i at bruge C++ her.


> C++ egner sig (efter min mening) kun til projekter som ikke kræver den
> store realtids afhængighed. Men igen, hvis man blot koder C, med en
> C++ kompiler, hvad er gevinsten så? Jeg vil til hver en tid mene at
> det er at skyde gråspurve med kanonkugler.
Jeg mener ikke at man skal kode C med en C++ compiler. Med C++ kan man
lave inline funktioner og templates, hvilket betyder at man undgår en
masse makroer og casts. Desuden kan man programmere objektorienteret med
inkapsling af data.


> Mht. vedligeholdelse, ja så må jeg give dig ret, så er C++ meget
> overlegen, hvis det da er kodet med henblik på dette.
Så er vi da enig i noget.

Ivan Johansen

---

"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
news:tp7gquo2qotc5al42c0sfgb15g1uerh404@4ax.com...
> On Sat, 12 Oct 2002 11:39:05 +0200, Ivan Johansen <NG@Padowan.dk>
> wrote:

[8<8<8<]
> Jeg har kun et ord: Protabilitet.

Var det ikke dig, der i et tidligere indlæg i denne tråd skrev:
"C++ ville ikke kunne bruges til at lave protokolstakken i en mobil med, da
dette ville kræve en uforholdsmæssig kraftigt CPU til at udføre det." ?

Argumentet var performance.

[8<8<8<]
> >Der er ikke nogen der siger at du
> >absolut skal bruge virtuelle funktioner og exceptions fordi du bruger
C++.
> Nej, selvfølgelig ville jeg heller ikke bruge disse funktionaliteter,
> men et ord igen: Portabilitet.


Hvilke C++ compilere har du oplevet problemer med implementering af
virtuelle funktioner ?
Jeg har meget svært ved at forestille mig nogen overhovedet. Den vil i givet
fald været helt fundamental defekt.

Hvilke konkrete problemer har du oplevet med portabiliteten af exceptions ?
Det er mange år siden jeg sidst så en C++ compiler, der ikke understøttede
exceptions.
Jeg kan muligvis forestille mig variende performance karakteristik, og
varierende implementering af exception specifikationer.

> Jeg er da også godt klar over at "C" kode kompileret med en C++
> kompiler må give næsten det samme "output", sådan rent
> hastighedsmæssigt.

"Rigtig" C++ kode kan i visse tilfælde være hurtigere end til tilsvarende C
kode.
Det typiske eksempel er sortering af et array af integers. Eksemplet er
simpelt, men holder i den virkelige verden til store opgaver.

Templates er en effektiv måde til at have fleksibilitet i koden på
compile-time, uden at det giver overhead på run-time.

Jeg har selv skrevet et C++ GUI bibliotek, der giver abstraktion mindst
svarende til MFC, og praktisk taget samme performance som tilsvarende C
program. En af de store fordele i forhold til anvendelse af det C baserede
Win32 API er langt bedre typesikkerhed. Biblioteket bliver iøvrigt oversat
med mere end een compiler.

> Men en ting skal være sagt, det er næsten umuligt
> at skrive 100000+ liner kode, til en GSM/GPRS protokol stak, som skal
> kunne kompileres på 10 forskellige C++ kompilere.

Hvorfor skulle det være sværere med en protokol stak end med en CORBA
implementering, der kan oversættes med mange compilere ?

Prøv at kigge på ACE/TAO
(http://www.cs.wustl.edu/~schmidt/ACE-versions-i.html og
http://tao.doc.wustl.edu/scoreboard/).

Det er et stort C++ system med langt over 1.000.000 linier kode, som bliver
oversat med en masse forskellige compilere (fra helt uafhængige kilder -
ikke kun gcc) til en masse forskellige platforme.

ACE/TAO har brugt C++ til real-time systemer gennem de sidste godt 10 år -
altså på et tidspunkt hvor compilerne var mindre ensartede end de er i dag.

> Det snakkes der jo
> om i stor stil her i gruppen. Tingene har vist sig at være noget
> nemmere hvis man holder sig til "årgang 1989 C". Det har ihvertfald
> været konklusionen der hvor jeg arbejder. Men jeg vil da gerne
> overraskes.

Jeg tror godt på at der er færre compatiblitets problemer ved at anvende
C89 - men i det valg er der absolut også indgået kompromisser.

[8<8<8<]
> Kan du iøvrigt forklare mig hvorfor
> man også tilrådes på det kraftigste at bruge C, når man eks. vis laver
> WDM/NT drivere til PC platformen?

En del af forklaringen er så afgjort myte, i stil med hvad jeg opfatter at
du også formidler i denne tråd.
I Windows 2000 er visse drivere, så vidt jeg har forstået, skrevet med
anvendelse C++.

>
> C++ egner sig (efter min mening) kun til projekter som ikke kræver den
> store realtids afhængighed.

Hvilken praktisk erfaring er din mening funderet i ?

Jeg har selv gennem de sidste mere end 10 år anvendt C++ til flere embedede
systemer, som havde absolut hårde real-time krav og relativt små
processorer.
Det er systemer med langt over 100000 linier source kode, der skulle
oversætte med 2-3 forskellige compilere.

> Men igen, hvis man blot koder C, med en
> C++ kompiler, hvad er gevinsten så? Jeg vil til hver en tid mene at
> det er at skyde gråspurve med kanonkugler.

Det kan så afgjort lade sig gøre, og det har så afgjort ikke være C-stil
kode oversat med en håndfuld C++ compilere.

Venlig hilsen

Mogens Hansen

---

"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
news:02nfqu4pmqlk6cru0r81p57v3g8ln3jq00@4ax.com...

[8<8<8<]
> C++ ville ikke kunne bruges til at lave protokolstakken i
> en mobil med, da dette ville kræve en uforholdsmæssig kraftigt CPU til
> at udføre det.

Den bliver du nok lige nødt til at forklare lidt nærmere.
Hvilke egenskaber ved protokolstakke gør at man fornuftigt kan lave det i C
og ikke i C++ pga. performance ?
Hvilke egenskaber ved C++ gør at det er mindre egnet til at lave
protokolstakke end C ?
Det lyder for mig som en god, gammel myte.


Venlig hilsen

Mogens Hansen

---

On Sat, 12 Oct 2002 17:13:46 +0200, "Mogens Hansen"
<mogens_h@dk-online.dk> wrote:

>Den bliver du nok lige nødt til at forklare lidt nærmere.
>Hvilke egenskaber ved protokolstakke gør at man fornuftigt kan lave det i C
>og ikke i C++ pga. performance ?
Jeg havde opfattelsen af at C++ har et "runtime" system som fylder en
hel del (derfor EC++ Embedded C++), men kun hvis man bruger de
features som har brug for "runtime" systemet selvfølgelig. Det er her
jeg ikke kan forstå hvad man skal med C++ hvis man ikke bruger dets
features??

>Hvilke egenskaber ved C++ gør at det er mindre egnet til at lave
>protokolstakke end C ?
>Det lyder for mig som en god, gammel myte.
Det kan også godt være at det er en myte, men hvis jeg kigger på vores
underleverandører af dele til protokol stakken, i en GSM/GPRS telefon,
ja så hedder firmaerne TTPCom og Intel. De bruger under udvikligens
første fase en GCC compiler til den specifikke CPU der skal bruges.
Næste punkt er så for dem at optimerer GCC compileren til CPU'en.
Dette er nødvendigt da det ofte er en udvidet/customised version af
eks. vis ARM7, ARM9 eller StrongARM. Mht deres support for C++
compilerer er der ingen, desværre.

Jeg vil godt give dig ret i, at hvis man forsøger at lave
objektorienteret kode med en C kompiler, ja så kan det umuligt blive
lige så effektivt som med en rigtig C++ kompiler. Men hvis man ikke
laver det objekt orienteret?

---

Thomas Lykkeberg skrev:

>Jeg havde opfattelsen af at C++ har et "runtime" system som fylder en
>hel del (derfor EC++ Embedded C++), men kun hvis man bruger de
>features som har brug for "runtime" systemet selvfølgelig. Det er her
>jeg ikke kan forstå hvad man skal med C++ hvis man ikke bruger dets
>features??

Man kan jo nøjes med at bruge de features der kun spiller en
rolle ved oversættelsen. Hvis man f.eks. definerer en
templatefunktion, så vil oversætteren selv danne de nødvendige
færdige funktioner hvor man ellers selv skulle have skrevet hver
enkelt. I det færdige program kan man ikke se forskel (skrevet
uden konkret viden om en sammenligning mellem de to måder).

Og så er der jo hele håndteringen af strings som alene er skiftet
fra C til C++ værd. Og man kan jo også godt lave sig en vector
uden i øvrigt at lave sit program OO.

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

---

On Sun, 13 Oct 2002 11:25:09 +0200, Bertel Lund Hansen
<nospam@lundhansen.dk> wrote:

>Man kan jo nøjes med at bruge de features der kun spiller en
>rolle ved oversættelsen. Hvis man f.eks. definerer en
>templatefunktion, så vil oversætteren selv danne de nødvendige
>færdige funktioner hvor man ellers selv skulle have skrevet hver
>enkelt. I det færdige program kan man ikke se forskel (skrevet
>uden konkret viden om en sammenligning mellem de to måder).
>
>Og så er der jo hele håndteringen af strings som alene er skiftet
>fra C til C++ værd. Og man kan jo også godt lave sig en vector
>uden i øvrigt at lave sit program OO.
Prøv iøvrigt at læse denne artikler fra Embedded.com. Den er godt nok
fra 97, men der arbejdes på EC++ stadigvæk.

http://www.embedded.com/97/feat9712.htm

/Thomas

---

Thomas Lykkeberg wrote:
> On Sat, 12 Oct 2002 17:13:46 +0200, "Mogens Hansen"
> <mogens_h@dk-online.dk> wrote:
> Jeg havde opfattelsen af at C++ har et "runtime" system som fylder en
> hel del (derfor EC++ Embedded C++), men kun hvis man bruger de
> features som har brug for "runtime" systemet selvfølgelig. Det er her
> jeg ikke kan forstå hvad man skal med C++ hvis man ikke bruger dets
> features??

Hvorfor tror du det? Fordi man bruger en C++ compiler behøver man jo
ikke bruge alle features i C++. Hvis man har et krav om at programmet
skal være hurtigt eller fylde lidt skal man selvfølgelig tænke sig om.
Det samme gælder når man programmerer i C.

Det er nok rigtigt at visse dele fylder meget. Jeg kan f.eks. forestille
mig at håndering af exceptions og streams fylder en del. Men så kan man
bare lade være med at bruge de dele. Der er utroligt mange ting i C++
som ikke fylder mere. Jeg har også erfaring med at sprintf() i C fylder
temmeligt meget og derfor skal ungås.

Ivan Johansen

---

"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
news:eddiqucl5d3443pqm76gvrqfhkclflqlr3@4ax.com...
> On Sat, 12 Oct 2002 17:13:46 +0200, "Mogens Hansen"
> <mogens_h@dk-online.dk> wrote:
>
> >Den bliver du nok lige nødt til at forklare lidt nærmere.
> >Hvilke egenskaber ved protokolstakke gør at man fornuftigt kan lave det i
C
> >og ikke i C++ pga. performance ?
> Jeg havde opfattelsen af at C++ har et "runtime" system som fylder en
> hel del (derfor EC++ Embedded C++), men kun hvis man bruger de
> features som har brug for "runtime" systemet selvfølgelig. Det er her
> jeg ikke kan forstå hvad man skal med C++ hvis man ikke bruger dets
> features??

Opfattelsen af at der er et "runtime" system som fylder en hel del, er (som
jeg også opfatter at du antyder) vag. Det er vanskelligt at kommentere på
det.

Jeg er meget i tvivl om hvad der egentlig var målet med EC++ - altså hvis
interesse prøvede de at varetage tilbage i 1995-97 ?
Personligt tror jeg i høj grad det var leverandørerne af compilere til
specielle processorer der blev tilgodeset, og i mindre grad brugerne i de
compilere.
Hvis man læser den artikel som du henviser til
(http://www.embedded.com/97/feat9712.htm), vil man se at der mange steder
tales om _leverandørens_ problemer, f.eks. med at skrive compilerne hurtigt
nok i forhold til hvad kunderne ønsker. Hvis man kan få kunderne til at
_ønske_ en mindre del af sproget, kan det taget noget af presset fra
leverandøren.

Hvis man kigger på dele af hvad der er pillet ud af C++ for at få EC++, vil
man se at det bestemt ikke alene er begrundet i run-time performance
(eksekveringshastighed og kodestørrelse).

F.eks.
* Namespace er udeladt.
Der er absolut _intet_ run-time overhead ved namespace. Der er alene tale om
kompleksitet for compiler leverandørerne, og givetvis _lidt_ lavere
dårligere oversættelseshastigheder som følge af mere kompiliceret navne
lookup.

* New-style cast er udeladt.
Der er absolut _intet_ run-time overhead ved new-style cast, i forhold til
C-style cast.

* Template er udeladt.
Det finder jeg _dybt_ uansvarligt i relation til embeddede systemer.
Min erfaring er at hvis man skal skrive ekstremt effektiv, men fleksibel
(compile-time polymorph) kode er templates vejen frem i C++. Det tillader at
en masse bliver bundet på oversættelses-tidspunktet, og en masse bliver
inlinet med deraf følgende mulighed for høj performance. Det er stort set
modsat klasse-hierakier og virtuelle metoder. Jeg vil næsten gå så langt som
at sige at jeg vil hellere undvære virtuelle metoder end templates, hvis der
skal skrives højeffektiv kode. Jeg vil dog nødigt undvære nogen af dem,
fordi tilsammen er det kraftigere end summen.
Bemærk i denne sammenhæng af templates formodentligt er kompliceret at
implementere for compiler leverandørerne.

* RTTI.
Tja, der er et vist overhead, men en god linker vil kunne fjerne meget af
det som faktisk ikke bliver anvendt.

* Exception håndtering.
Det fylder noget, men det er muligt at implementere så det kun koster
eksekveringstid, når der faktisk smides en exception - hvilket bør være
relativt sjældent.
Fejlhåndteringskode fylder, og hvis man tager de tal som P.J.Plauger angiver
i artiklen, fyldet et EC++ uden exception håndtering fylder 3/8 af et fuldt
C++ program med exception håndtering. Det står dog langt fra klart for mig
at han i programmet uden exception håndtering har erstattet det med en anden
form for fejlhåndtering - f.eks. fejlkoder der bliver håndteret korrekt på
alle niveauer.

Det er rigtigt at IO biblioteket voksede i forbindelse med
standardiseringsarbejdet. En væsentlig grund var tilføjelsen af locale.
Det er dog muligt at implementere en lang række optimeringer il IO
biblioteket så det bliver effektivt både med hensyn eksekveringshastighed og
kodestørrelse. Også her ligger arbejdet hos leverandøren - hvilket er
rimeligt fordi det så gavner flest. (Se "Technical Report on C++
Performance - DRAFT" for detaljer).

Generelt har jeg ikke ondt af compiler leverandører - uanset hvor svært
deres arbejde måtte være; de bliver betalt for det. Det er naturligvis et
problem, hvis de ikke kan levere robuste produkter.
ETC++ gør ikke hele billedet enklere - det er blot et tydeligt tegn på at
der internt i EC++ gruppen ikke er enighed om hvad der er nødvendigt.

Jeg tror mere på uddannelse og velunderbygget forståelse af hvad forskellige
features i C++ koster, er en mere konstruktiv vej at gå.
Hvis man er interesseret i at vide hvad forskellige features i C++ sproget
og biblioteket koster er rapport "Technical Report on C++ Performance -
DRAFT" glimrende læsning

Forholdende omkring C og C++ performance har tidligere været i denne gruppe.
Se f.eks. tråden "c eller C++" fra midt i juni i år - brug google.

>
> >Hvilke egenskaber ved C++ gør at det er mindre egnet til at lave
> >protokolstakke end C ?
> >Det lyder for mig som en god, gammel myte.
> Det kan også godt være at det er en myte, men hvis jeg kigger på vores
> underleverandører af dele til protokol stakken, i en GSM/GPRS telefon,
> ja så hedder firmaerne TTPCom og Intel. De bruger under udvikligens
> første fase en GCC compiler til den specifikke CPU der skal bruges.
> Næste punkt er så for dem at optimerer GCC compileren til CPU'en.
> Dette er nødvendigt da det ofte er en udvidet/customised version af
> eks. vis ARM7, ARM9 eller StrongARM. Mht deres support for C++
> compilerer er der ingen, desværre.

Bemærk at jeg ikke har anfægtet det fornuftige i jeres konkrete valg af C.
Der findes naturligvis gode grunde til at bruge C.
Et par stykker kunne være:
* Der findes en C compiler, men ikke en C++ compiler
* Der arbejdes under en kontrakt, der kræver at der bruges C
* Det marked man arbejder i er baseret på C
* Organisationen er tilpasset brugen af C
Der er utvivlsomt andre gode grunde.

Når det er sagt, forstår jeg ikke hvorfor det skulle være meget sværere at
tilpasse en C++ compiler end en C compiler til en speciel processor.
Hvis der er tale om særlige optimeringer og speciel kodegenerering f.eks.
fordi processoren har flere interne registre, så bør det alene burde være en
ændring i compiler back-enden - altså temmeligt uafhængigt af
programmeringssproget.
Hvis der er tale om at der skal tilføjes særlige keywords for f.eks. at
kunne tilgå særlige registre, lyder det som det samme arbejde der skal lavet
i front-enden i en C eller en C++ compiler.

Jeg forstår heller ikke hvorfor det skulle være utroligt svært at lave en
C++ compiler i forhold til at lave en C compiler. Det forekommer at være
rimeligt at basere en compiler til en høj specialiseret processor på en
allerede eksisterende front-end (f.eks. EDG eller gcc - begge meget udbredte
til det embeddede marked). Dermed skal man slet ikke skrive parseren, men
"kun" kode genereringsdelen.

Helt konkret:
Hvis der anvendes speciel udgave af gcc, hvad er så grunden til at C++
frontenden ikke kunne anvendes hvis man ønskede det ?

> Jeg vil godt give dig ret i, at hvis man forsøger at lave
> objektorienteret kode med en C kompiler, ja så kan det umuligt blive
> lige så effektivt som med en rigtig C++ kompiler.

Har jeg sagt det ?

> Men hvis man ikke
> laver det objekt orienteret?

Der er tilfælde, hvor typisk C++ kodestil giver mere effektiv eksekvering
end tilsvarende typisk C kodestil.
Årsagen skal typisk findes i anvendelsen af templates og inlining af
funktioner.
Det typiske eksempel er sortering af et array af integer, hvilket absolut
ikke har noget med objekt orientring at gøre.
Jeg har målt at C stil bruger 23%-47% mere tid end C++ stil. (Målt på en 700
MHz Pentium, oversat med Visual C++ .NET). Samtidig var C++ programmet
simplere og sikrere at skrive. (Se den tidligere nævnte tråd for komplet
kode og måleresultater).


Venlig hilsen

Mogens Hansen

---

On Wed, 16 Oct 2002 23:28:06 +0200, "Mogens Hansen"
<mogens_h@dk-online.dk> wrote:

>Jeg forstår heller ikke hvorfor det skulle være utroligt svært at lave en
>C++ compiler i forhold til at lave en C compiler. Det forekommer at være
>rimeligt at basere en compiler til en høj specialiseret processor på en
>allerede eksisterende front-end (f.eks. EDG eller gcc - begge meget udbredte
>til det embeddede marked). Dermed skal man slet ikke skrive parseren, men
>"kun" kode genereringsdelen.

Hej Mogens

Phuuu, det var en lang smørre. Jeg vil ikke mene at problemet ligger i
at lave selve C++ compileren, men derimod i forbindelse med en
ordentlig high-level-language debugger. Jeg har ikke nogen ide om det,
men hvis man spøger Intel (en af vores underleverandører), siger de at
det skam ikke er en nem sag at lave en brugbar C++ debugger på
rekordtid. Du skal jo huske at vi får CPU'en længe før den kommer i
masse produktion, hvilket jo betyder at Intel ikke en gang er færdige
med at lave første test version (Beta versionen) af compileren.

Det er rigtigt at de basserer deres compiler på GCC, men findes der en
JTAG debugger med C++ support for den? Vi kan skam sagtens få en C++
compiler til deres produkter, men som sagt før ligger problemet i at
der ikke findes en brugbar C++ debugger, før vi er færdige med
projektet. Jeg håber at dette vil ændre sig i fremtiden.

/Thomas

---

"Thomas Lykkeberg" <thomasDOTlykkeberg@privatDOTdk> wrote in message
news:5tmtqug2g8a334q0sd63sfurqr5t7ldvj2@4ax.com...

[8<8<8<]
> Det er rigtigt at de basserer deres compiler på GCC, men findes der en
> JTAG debugger med C++ support for den?

Lauterbach har support for at debugge C++ programmer på source-niveau til en
lang række ARM7/9 varianter (http://www.lauterbach.com/bdm.html#_2) med en
række forskellige C++ compilere (http://www.lauterbach.com/clist.html#ARM)
herunder gcc baserede.
Se http://www.lauterbach.com generelt.
Om det konkret vil kunne bruges i jeres sammenhæng og vil virke
tilfredsstillende ved jeg naturligvis ikke.

Mine kollegaer anvender Lauterback BDM debuggere i forbindelse med en EDG
baseret C++ compiler, til embedded udvikling af ikke trivielle systemer med
hårde real-time krav.
Der anvendes mange C++ features, som vil kunne slå en typisk C debugger ud
af kurs. F.eks. templates, der i denne sammenhæng udemærker sig ved at een
linie source-kode mapper til mange kode-adresser - afhængigt af template
argument typerne.
Jeg har ikke hørt andet end at det er en god og fuldt ud acceptabel
kombination. Naturligvis ikke fuldstændigt perfekt og fejlfrit - men hvad er
det ?
Da jeg var involveret i de projekter, brugte vi en anden debugger, som efter
sigende er noget dårligere men brugbar. Den blev brugt til bl.a. at udvikle
distribuerede, embedded systemer, hvor flere noder blev debugget samtidigt.


Venlig hilsen

Mogens Hansen

---

Thomas Lykkeberg <thomasDOTlykkeberg@privatDOTdk> writes:

> On Sat, 12 Oct 2002 11:39:05 +0200, Ivan Johansen <NG@Padowan.dk>
> wrote:
>
>>Okay, en mobiltelefon er nok et stort embedet system. Hvis der er en C++
>>compiler til rådighed vil jeg til enhver tid foretrække den frem for C.
> Jeg har kun et ord: Protabilitet.

C++ har vel efterhånden tæt på samme portabilitet. GCC er nok det
mest udbredte system til embedded, og den understøtter begge sprog.

> Kan du iøvrigt forklare mig hvorfor
> man også tilrådes på det kraftigste at bruge C, når man eks. vis laver
> WDM/NT drivere til PC platformen?

Mit gæt: C ABI'en er mere stabil, så binære moduler der der skal
linkes sammen (f.eks. kerne og driver) vil også fungere når de er
oversat med forskellige compilere.

Det er ret vigtigt for et consumer OS, men mindre vigtigt for
embedded, hvor brugeren ikke op opgradere dele af systemet alene.

> C++ egner sig (efter min mening) kun til projekter som ikke kræver den
> store realtids afhængighed.

Man kan i nogen situationer vinde hastighed ved at bruge virtuelle
funktioner i stedet for switches, og man kan bruge compile-time
features som overloadede funktioner og (med omhu) templates uden at
det påvirker hastigheden negativt. Desuden får man et bedre
typesystem, og en række andre "gratis" features som f.eks. mere
specifikke former for casts.

Problemet kommer npår nogen prøver at skrive Java eller Smalltalk i
C++, og gør al ting virtuelt, uanset om det er nødvendigt eller ej.

---

Per Abrahamsen wrote:
> C++ har vel efterhånden tæt på samme portabilitet. GCC er nok det
> mest udbredte system til embedded, og den understøtter begge sprog.

Så vidt jeg ved har Comeau Computing også en del ports af deres C++
compiler til embeddede systemer.

Ivan Johansen

---

Ivan Johansen <NG@Padowan.dk> writes:

> Det har du desværre ret i. Problemet er at der mangler ordentlige C++
> kompilere.

Er det stadig tilfældet?

GCC kvalificerer efterhånden som "en ordentlig C++ compiler", og
findes til det meste (og er fri).

EDG har nok den bedste front-end, og er basis for de fleste compilere,
med Intel og Comaou som de to mest kendte.

Borland har et godt rygte, omend den nok efterhånden er blevet
ovehalet af de to andre.

Microsoft er blevet meget bedre, men er stadig det svageste led. Med
de C++ folk de har hyret tror jeg faktisk på at det bliver løst i
næste version, og de så vil være helt i toppen.

Er der andre? Jeg tror efterhånden at det eneste problem er folk der
insisterer på at bruge ældre compilere, eller Microsoft. Og den
sidste gruppe er snart klar.

---

Per Abrahamsen wrote:
> Ivan Johansen <NG@Padowan.dk> writes:
>>Det har du desværre ret i. Problemet er at der mangler ordentlige C++
>>kompilere.
> Er det stadig tilfældet?

Jeg ved det faktisk ikke. Mit indtryk er at der stadig mangler C++
kompilere til mange mindre processorer, men at det går stille og roligt
fremad. Jeg mener endda at man nu kan få en C++ kompiler til ADSP2181.
Men jeg har stadig ikke set nogen til 8051 kompatible processorer.

> Borland har et godt rygte, omend den nok efterhånden er blevet
> ovehalet af de to andre.
Borland arbejder vist også på en kompiler til mobile platforme.

Ivan Johansen

---

On Sun, 13 Oct 2002 12:37:08 +0200, Ivan Johansen <NG@Padowan.dk>
wrote:

>Jeg mener endda at man nu kan få en C++ kompiler til ADSP2181.
Ja, så er verden da brudt sammen. Hvad skulle man dog bruge en C++
compiler til, på en 16-bit DSP, med 32KWord hukommelse? Nu må
galskaben da snart stoppe

/Thomas

---

Thomas Lykkeberg wrote:
> Ja, så er verden da brudt sammen. Hvad skulle man dog bruge en C++
> compiler til, på en 16-bit DSP, med 32KWord hukommelse? Nu må
> galskaben da snart stoppe

Ja, det undrer også mig, men ifølge denne pressemeddelelse fra Analog
Devices er det lige det DSP udviklere har gået og manglet:
http://www.analog.com/pressrelease/prdisplay/0,1115,157,00.html

Ivan Johansen

---

Thomas Lykkeberg <thomasDOTlykkeberg@privatDOTdk> writes:

> Jeg havde opfattelsen af at C++ har et "runtime" system som fylder en
> hel del (derfor EC++ Embedded C++), men kun hvis man bruger de
> features som har brug for "runtime" systemet selvfølgelig. Det er her
> jeg ikke kan forstå hvad man skal med C++ hvis man ikke bruger dets
> features??

C++'s minimale runtime fylder mere end C's minimale runtime, men hører
stadig til blandt de små.

Her tæller jeg ikke standard-bibliotekerne med, det er en uafhængig
beslutning hvor store dele af dem man ønsker at trække ind. Jeg kan
f.eks. sagtens forestille min at nogen embedded applikationer vil
undgå iostream og stdio.

---

Thomas Lykkeberg <thomasDOTlykkeberg@privatDOTdk> writes:

> Prøv iøvrigt at læse denne artikler fra Embedded.com. Den er godt nok
> fra 97, men der arbejdes på EC++ stadigvæk.

Lidt fjollet. Embedded C++ var faktisk bare et C++ subset som svarede
til hvad der var rimeligt portabelt i '97. GCC fik hurtigt et
"Embedded C++" flag, men alt hvad det betød var at visse features blev
disabled. Lidt ligesom -ansi. GCC genererede hverken mere effektiv
eller kompakt kode af den grund, og det har jeg heller ikke hørt om
andre compilere der gør.

Embedded C++ var en forståelig fejltagelse i sin tid, og en
anakronisme i dag.

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Opfattelsen af at der er et "runtime" system som fylder en hel del, er (som
> jeg også opfatter at du antyder) vag. Det er vanskelligt at kommentere på
> det.

Men man kan sætte tal på det. GCC's C runtime er samlet i libgcc, og
fylder ca. 32kB.

alpha% size libgcc_s.so.1
text data bss dec hex filename
30823 2060 148 33031 8107 libgcc_s.so.1

Dertil kommer et standard bibliotek der følger med operativsystemet.

GCC's C++ runtime er ligeledes delt op i standard biblioteket, samt en
del der er nødvendig support for rene sprogfasciliteter. Den sidste
del ligger i et seperat bibliotek, for brug for folk der ikke bryder
sig om at linke med standard biblioteket.

Den fylder ca. 44 kB, så man altså mere end fordobler sit runtime
behov. Jeg ved dog ikke om alt det nedenstående altid linkes med.
Hvis f.eks. demangleren kan undværes når man ned på 20 kB. Stadig en
anseelig forøgelse.

% size libsupc++.a
text data bss dec hex filename
36 0 0 36 24 del_op.o (ex libsupc++.a)
36 0 0 36 24 del_opnt.o (ex libsupc++.a)
24 0 0 24 18 del_opv.o (ex libsupc++.a)
24 0 0 24 18 del_opvnt.o (ex libsupc++.a)
472 112 16388 16972 424c eh_alloc.o (ex libsupc++.a)
200 164 0 364 16c eh_aux_runtime.o (ex libsupc++.a)
272 56 0 328 148 eh_catch.o (ex libsupc++.a)
383 60 0 443 1bb eh_exception.o (ex libsupc++.a)
592 208 12 812 32c eh_globals.o (ex libsupc++.a)
2656 324 0 2980 ba4 eh_personality.o (ex libsupc++.a)
256 224 0 480 1e0 eh_terminate.o (ex libsupc++.a)
300 112 0 412 19c eh_throw.o (ex libsupc++.a)
40 0 0 40 28 eh_type.o (ex libsupc++.a)
242 32 4 278 116 new_handler.o (ex libsupc++.a)
224 122 0 346 15a new_op.o (ex libsupc++.a)
188 109 0 297 129 new_opnt.o (ex libsupc++.a)
52 110 0 162 a2 new_opv.o (ex libsupc++.a)
16 0 0 16 10 new_opvnt.o (ex libsupc++.a)
88 56 0 144 90 pure.o (ex libsupc++.a)
4377 552 0 4929 1341 tinfo.o (ex libsupc++.a)
2061 1728 0 3789 ecd tinfo2.o (ex libsupc++.a)
1548 916 0 2464 9a0 vec.o (ex libsupc++.a)
22456 820 8 23284 5af4 cxa_demangle.o (ex libsupc++.a)
1392 0 0 1392 570 dyn-string.o (ex libsupc++.a)

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rju1jlih3n.fsf@zuse.dina.kvl.dk...

> Men man kan sætte tal på det.
[8<8<8<]

Det er een måde at gøre det op for een compiler på een platform.

Men hvis man skal snakke om hvad "runtime" systemet koster (som Thomas
Lykkeberg gjorde), må man definere hvad man forstår med runtime systemet.

Man kan f.eks. sige at det er størrelsen på runtime biblioteket. Men er det
en rimelig målestok ?

F.eks.:
Jeg antager at "printf" ligger i ligger i C runtime biblioteket.
Er det rimeligt at sige at "printf" er en del af runtime systemet ? Selv for
et C program, der ikke bruger printf ?

Hvis man kigger på C++ runtime bibliotekerne, som du listede op, vil jeg
gætte på at f.eks. "std::cout", "std::ostream& operator<<(std::ostream&,
int)" og "std::string" _ikke_ ligger i de filer.
Det skyldes at det i virkeligheden er templates som jeg vil tro bliver
instantieret af compileren når de bruges.
Det er åbenlyst af "std::vector<foo>" heller ikke ligger i filerne.

Er det rimeligt at sige at størrelsen af "std::vector<foo>" er en del af
runtime systemet ?

Hvis man f.eks. skal vurdere prisen for "std::vector<foo>" må det være i
sammenligning med et C program med tilsvarende funktionalitet - altså med en
implementering af arrays af foo med dynamisk størrelse.

Jeg syntes man bør sammenligne statisk linkede programmer, hvor linkeren
fornuftigt har fjernet det man ikke bruger.
Specielt i relation til embeddede systemer er det rimeligt at se på hvor
meget ROM og hvor meget RAM bruger et program med en given funktionalitet.
Det er rimeligt f.eks. også at se på hvor meget af det konstante data, der
vil blive lagt i ROM.

Jeg mener at man i runtime systemet f.eks. kan medtage:
* Startup kode
* Sprog support bibliotek - f.eks. til exceptions
* Compiler genereret runtime system, som f.eks. virtuelle tabeller, RTTI

Det er rimeligt at se på om en given feature koster noget uanset om man
bruger den eller ej.
Det er rimeligt at se på hvad en given feature koster i sammenligning med en
alternativ implementering.

Jeg mener også at det er rimeligt at kigge på om prisen er atypisk høj for
en given implementering, set såvel i forhold til en række andre
implementeringer som i forhold til hvad der er muligt at implementere.

Lige pludselig kommer der en række detaljer som man ikke kan se bort fra for
at få et nuanceret billede.
Et bud på et nuanceret billede findes i "Technical Report on C++
Performance" som jeg nævnte.


Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:

> Det er een måde at gøre det op for een compiler på een platform.

Jeps. Og med mindre du kan påvise at det er atypisk, så har vi et
fint bud på hvilken størrelsesorden vi snakker om. Altså ca. en
fordobling af et i forvejen minimalt pladsforbrug. Hvis vi havde
sammenlignet med f.eks. Lisp havde der været tale om nogle helt andre
tal.

> Jeg antager at "printf" ligger i ligger i C runtime biblioteket.
> Er det rimeligt at sige at "printf" er en del af runtime systemet ? Selv for
> et C program, der ikke bruger printf ?

C har et begreb der hedder en "unhosted" implementering af standarden,
hvor f.eks. printf ikke er med. Så formelt set definerer C standarden
to sprog, hosted og unhosted C.

GCC er kun en implementation af unhosted C, da den ikke inkluderer et
C bibliotek.

I den aktuelle sammenhæng (sammenligning af pladsforbrug for runtime
mellem sprog for embedded brug) er det runtime delen for unhosted C
der er interessant.

C++ har ikke en tilsvarende skelnen, men det kræver ikke den store
fantasi at finde en tilsvarende opdeling for det sprog, og faktisk har
de flinke GCC folk allerede gjort det. Sikkert fordi de har mange
kunder i embedded verdenen. Hvis du compiler med -lsupc++ i stedet
for -lc++ får du "unhosted C++".

> Er det rimeligt at sige at størrelsen af "std::vector<foo>" er en del af
> runtime systemet ?

Det er irrelevant, da jeg slet ikke medtog standardbiblioteket.

> Hvis man f.eks. skal vurdere prisen for "std::vector<foo>" må det være i
> sammenligning med et C program med tilsvarende funktionalitet - altså med en
> implementering af arrays af foo med dynamisk størrelse.

Nej, nu snakker du om størrelsen på den genererede kode
(kodedensitet), ikke på runtime systemet. Den størrelse er _også_
relevant, men et andet tal.

Groft forenklet:

pladsforbrug = runtime-system + kodedensitet * program

Jo større programmet er, jo mindre betyder størrelsen af runtime
systemet, og jo mere betyder kodedensiteten.

> Lige pludselig kommer der en række detaljer som man ikke kan se bort fra for
> at få et nuanceret billede.

Man kan aldrig se bort fra detaljerne hvis man vil have et nuanceret
billede, det er tæt på at være en tautologi.

Men det er først sent i processen at detaljerne er andet end støj.

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjr8ep3z77.fsf@zuse.dina.kvl.dk...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > Det er een måde at gøre det op for een compiler på een platform.
>
> Jeps. Og med mindre du kan påvise at det er atypisk, så har vi et
> fint bud på hvilken størrelsesorden vi snakker om.

Jeg har ingen grund at tro at det er atypisk - jeg har ikke noget præcist
billede af hvad jeg ville forvente.
Jeg vil dog forvente en vis variation.
F.eks. vil jeg forvente at størrelsen af support koden til
exceptionhåndtering afhænger en del af om der er brugt en kode baseret
løsning eller en tabel baseret løsning.

[8<8<8<]
> C++ har ikke en tilsvarende skelnen, men det kræver ikke den store
> fantasi at finde en tilsvarende opdeling for det sprog, og faktisk har
> de flinke GCC folk allerede gjort det. Sikkert fordi de har mange
> kunder i embedded verdenen. Hvis du compiler med -lsupc++ i stedet
> for -lc++ får du "unhosted C++".

C++ har en tilsvarende skelnen mellm "hosted" og "freestranding"
implementering (§1.4-7).

[8<8<8<]
> Det er irrelevant, da jeg slet ikke medtog standardbiblioteket.

Ja, det kan jeg se når jeg læser dit indlæg igennem een gang til.
Du skrev det høj og tydeligt, men jeg misforstod det.

Venlig hilsen

Mogens Hansen

---

> Hey.. Er der stor forskel på C & C++ og hvilket bør man vælge som
> nybegynder?

C++ har lidt ekstra "syntaktisk sukker" (som det ofte omtales) i forhold til
C, men kan ellers anvendes til klassisk procedural programming på samme vis.
Men der, hvor C++ jo især udmærker sig (og det var det, der var hele idéen
med C++), er ved dets understøttelse af klassiske objektorienterede
paradigmer direkte i sproget (klasser, nedarvning, etc.). Dermed ikke sagt
at man ikke kan programmere objektorienteret i C (eller hvilket som helst
andet proceduralt sprog), men der er store fordele ved at anvende et sprog,
der er specifikt designet til dette paradigme er, at ting som klasser og
nedarvning har direkte repræsentation og understøttelse i sproget.

Nu om dage er det objektorienterede paradigme så centralt inden for
udviklingsbrancen, at jeg klart vil anbefale dig at lære det fra
begyndelsen. Det vil sige at lære C++, men ikke bare som C med et par ekstra
syntaktiske finesser, men også lære om klasser, polymorfi og arv. (Mange
mener, at det først at lære at tænke proceduralt senere bliver en større
hæmsko for folk, når de skal til at lave objektorienteret udvikling.)

Med venlig hilsen,
/\/\\ads Orbesen Troest

---

Mads Orbesen Troest skrev:

>syntaktiske finesser, men også lære om klasser, polymorfi og arv. (Mange
>mener, at det først at lære at tænke proceduralt senere bliver en større
>hæmsko for folk, når de skal til at lave objektorienteret udvikling.)

Det omvendte er nu også rigtigt.

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