---

Hej,

Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
fulgt gruppen i et stykke tid, er det gået op for mig, at en del af
de meninger(fordomme) som jeg havde om C++, ser ud til at være for-
svundet i ISO C++ 98.

Derfor kunne jeg godt tænke mig noget input om følgende...

* Hvor godt dokumenteret er standard lib'et til C++
o Herunder er der gode frie steder om det.
* Hvor compliant er dette henover platforme (Gcc vs. kommercielle).
* Kan template's lægges i libs idag (Gcc specifik).
* Hvor meget "clasher" standard lib'et med C specifikke libs.
o eg. er det muligt at bruge poll(), select() etc. eller
skal der her bruges C++ specifikke ting. (og i den sam-
menhæng _kan_ der indsættes "hooks" til feks. wait oa.
asynkrone ting.)

Jeg har ca. 15 års erfaring med C, og en del erfaring i OO via andre sprog
(dog primært fortolkere (lisp og python), så i må _meget gerne være teknis-
ke

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Note: det er *meget* vigtigt for mig at det er portabelt, eg. det varede
meget længe inden jeg gik fra K&R til ANSI pgra. portabilitet.

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

Kim Petersen <kim@vindinggaard.dk> writes:

> Derfor kunne jeg godt tænke mig noget input om følgende...
>
> * Hvor godt dokumenteret er standard lib'et til C++

Tjah, det står i standarden og en masse bøger.

> o Herunder er der gode frie steder om det.

Sikkert, men jeg har ikke kigget.

> * Hvor compliant er dette henover platforme (Gcc vs. kommercielle).

De nyeste compilere fra GNU, Borland og Microsoft er tæt nok på
standarden til at normal kode er portabel. Microsoft er længst fra,
mest indirekte fordi deres compiler ikke er tæt nok på standarden til
at implementere hele biblioteket.

> * Kan template's lægges i libs idag (Gcc specifik).

Template instantieringer kan som de har kunne længe. Koden kan
generelt ikke. Jeg er heller ikke sikker på at det giver så meget
mening, templates er en compile time feature, ikke en link time
feature. Hvis man lægger dem i et bibliotek skal linkeren til at
kalde compileren.

> * Hvor meget "clasher" standard lib'et med C specifikke libs.
> o eg. er det muligt at bruge poll(), select() etc. eller
> skal der her bruges C++ specifikke ting. (og i den sam-
> menhæng _kan_ der indsættes "hooks" til feks. wait oa.
> asynkrone ting.)

Der er desværre ingen standariserede C++ specifikke features til OS
interfacet, så man er nødt til at bruge C interfacet. Det er der dog
generelt heller ingen problemer med.

---

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

> Kim Petersen <kim@vindinggaard.dk> writes:
>
> > Derfor kunne jeg godt tænke mig noget input om følgende...
> >
> > * Hvor godt dokumenteret er standard lib'et til C++
>
> Tjah, det står i standarden og en masse bøger.

Hmm, lad mig prøve at uddybe... Hvor mange forskellige måder kan stan-
darden udlægges på, eg. hvor specifik er den - og dermed kan forskellige
implementeringer virke forskelligt på trods af at være baseret på samme
beskrivelse...

Et rigtigt godt eksempel på en implementering af en standard som har været
et problem er f=open(path,O_APPEND); - hvornår bliver seek udført i det til-
fælde (lad være at svare austin-group har diskuteret dette længe - og det
_er_ implementerings specifik (indtil næste POSIX ).

>
> > o Herunder er der gode frie steder om det.
>
> Sikkert, men jeg har ikke kigget.

Ok

>
> > * Hvor compliant er dette henover platforme (Gcc vs. kommercielle).
>
> De nyeste compilere fra GNU, Borland og Microsoft er tæt nok på
> standarden til at normal kode er portabel. Microsoft er længst fra,
> mest indirekte fordi deres compiler ikke er tæt nok på standarden til
> at implementere hele biblioteket.

Findes der i den sammenhæng et subset af standarden, som kan betragtes som
værende de-facto så?

>
> > * Kan template's lægges i libs idag (Gcc specifik).
>
> Template instantieringer kan som de har kunne længe. Koden kan
> generelt ikke. Jeg er heller ikke sikker på at det giver så meget
> mening, templates er en compile time feature, ikke en link time
> feature. Hvis man lægger dem i et bibliotek skal linkeren til at
> kalde compileren.

Hmm, det gør vel compile time forbasket tung, hvis man benytter sig af
mange libs? Og lidt af et helvede at distribuere libs?

>
> > * Hvor meget "clasher" standard lib'et med C specifikke libs.
> > o eg. er det muligt at bruge poll(), select() etc. eller
> > skal der her bruges C++ specifikke ting. (og i den sam-
> > menhæng _kan_ der indsættes "hooks" til feks. wait oa.
> > asynkrone ting.)
>
> Der er desværre ingen standariserede C++ specifikke features til OS
> interfacet, så man er nødt til at bruge C interfacet. Det er der dog
> generelt heller ingen problemer med.

Hvad med threading (pthreads etc.), er der definitioner af hvordan std-
funktionerne håndterer dette? [eg. reentrant etc.]

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
news:rjpu71o3e2.fsf@ssv2.dina.kvl.dk...
> De nyeste compilere fra GNU, Borland og Microsoft er tæt nok på
> standarden til at normal kode er portabel. Microsoft er længst fra,
> mest indirekte fordi deres compiler ikke er tæt nok på standarden til
> at implementere hele biblioteket.

Passer det nu også?
Scott Meyers skriver ellers lige det modsatte, at det i MS' tilfælde er
compileren der er sej nok, men
problemet ligger i at den STL der følger med er en gammel gammel dikumware
version.
Og hvis det er det, så er det jo ikke noget problem, så kan man bare hente
en ny fra stlport.

Jonas

---

"Jonas Meyer Rasmussen" <meyerDO_REMOVE_THIS@diku.dk> wrote in message
news:9rv2nc$u9f$1@eising.k-net.dk...
>
> "Per Abrahamsen" <abraham@dina.kvl.dk> wrote in message
> news:rjpu71o3e2.fsf@ssv2.dina.kvl.dk...
> > De nyeste compilere fra GNU, Borland og Microsoft er tæt nok på
> > standarden til at normal kode er portabel. Microsoft er længst fra,
> > mest indirekte fordi deres compiler ikke er tæt nok på standarden til
> > at implementere hele biblioteket.
>
> Passer det nu også?
> Scott Meyers skriver ellers lige det modsatte, at det i MS' tilfælde er
> compileren der er sej nok, men
> problemet ligger i at den STL der følger med er en gammel gammel dikumware
> version.

Jeg oplever i hvertfald problemer med template implementeringen i såvel
Microsoft Visual C++ V6.0 og V7.0 Beta 2, i kode som ikke bruger Standard
Library overhovedet.

> Og hvis det er det, så er det jo ikke noget problem, så kan man bare hente
> en ny fra stlport.
>

Eller købe en opdatering fra Dinkumware.

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> wrote in message
news:9rv5ij$bcp$1@news.cybercity.dk...
> Jeg oplever i hvertfald problemer med template implementeringen i såvel
> Microsoft Visual C++ V6.0 og V7.0 Beta 2, i kode som ikke bruger Standard
> Library overhovedet.
Ja, nu du siger det så havde jeg også nogle problemer
Det var et lidt bizart tilfælde hvor en template funktion kaldte sig selv
rekursivt.. med et andet
template argument
> Eller købe en opdatering fra Dinkumware.
Jae, men det er jo den man får med 7'eren...

men nu vi er ved det, hvad er så fordelen ved den fra dinkumware i forhold
til stlport?

---

"Jonas Meyer Rasmussen" <meyerDO_REMOVE_THIS@diku.dk> wrote in message
news:9s20h1$3jv$1@eising.k-net.dk...
>
> men nu vi er ved det, hvad er så fordelen ved den fra dinkumware i forhold
> til stlport?

Det blev diskutteret på comp.lang.c++.moderated for nyligt.
Se
http://groups.google.com/groups?q=%22ISO+C%2B%2B+Standard+Compliance+Testing
+and+MSVC%2B%2B%22&hl=en&rnum=1&selm=f41d067f.0110250334.35518752%40posting.
google.com

Venlig hilsen

Mogens Hansen

---

Hej!

Det er rart at se saadan en informeret diskussion om C++ paa dansk.

Jeg ville lige tilfoeje at hvis en programmoer er interesseret i at
laere en moderne C++ stil vil det maaske vaere en god ide at kikke
paa: Koenig&Moo: Accelerated C++. Det er et forsoeg paa en systematisk
presentation af C++ uden at gaa omveje over C eller pre-standard C++.
Den er ogsaa dejlig velskrevet

- Bjarne
(http://www.research.att.com/~bs)

---

In <1yjigsmq.fsf@localhost.localdomain>, Kim Petersen wrote:

> Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
> fulgt gruppen i et stykke tid, er det gået op for mig, at en del af de
> meninger(fordomme) som jeg havde om C++, ser ud til at være for- svundet
> i ISO C++ 98.
Så er der da sket noget. Du er så stoppet ved Bjarnes 2 rev. (den lille
grå), og her var C++ ikke så omfattende som nu, men det var nu stadigt
godt

> * Hvor godt dokumenteret er standard lib'et til C++
> o Herunder er der gode frie steder om det.
Jeg kender ikke så meget til "frie" steder, men C++ ISO har jeg kodet til
I snart flere år (siden den ikke var ISO godkendt). Denne dokumentation er
bestemt ikke hygge læsning, men den hænger temlig godt sammen. Jeg kan
anbefale Bjarnes 3.

> * Hvor compliant er dette henover platforme (Gcc vs.
> kommercielle).
Tjaa, jeg har kodet på SUN platformen hvor SUN ejen (og ret dyre) compiler
var en smule bagud i forhold til Gcc. Det er ofte i template koden man
finder de væreste problemer ved flytning, og det er ofte library relateret
!

> * Kan template's lægges i libs idag (Gcc specifik).
Jeg ved ikke med Gcc 3.0, men 2.95.x kan tweekes til at gøre dette, men
deres "repo" kode er ikke held god endnu (det skulle kunne gøre det
automatisk. Jeg ser frem til at få tid til at lege mere med gcc 3.0.

> * Hvor meget "clasher" standard lib'et med C specifikke libs.
Øhh, jeg er ikke sikker på hvad du mener, men de to sameksisterer fint nu
om dage.

> o eg. er det muligt at bruge poll(), select() etc. eller
> skal der her bruges C++ specifikke ting. (og i den
> sam- menhæng _kan_ der indsættes "hooks" til feks.
> wait oa. asynkrone ting.)
Du kan FRIT bruge C og C++ i en stor pærevælding, det virker --- bare du
holder hovedet koldt

> Jeg har ca. 15 års erfaring med C, og en del erfaring i OO via andre
> sprog (dog primært fortolkere (lisp og python), så i må _meget gerne
> være teknis- ke
Python er udemærket, men C++ er lavet til store systemer og til at forme
OO struktur i, med runtime check og alting, samtidigt med at du har
styrken fra C. Hvis du kan lide OO modellen, men vil blive ved med at have
styrken fra C er dette helt klart et klogt skift. Dog vil jeg sige,
invister lidt tid i projektet, C++ lære man ikke på en dag

/BL

---

"Bo Lorentsen" <bl@lue.dk> writes:

> In <1yjigsmq.fsf@localhost.localdomain>, Kim Petersen wrote:
>
> > Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
> > fulgt gruppen i et stykke tid, er det gået op for mig, at en del af de
> > meninger(fordomme) som jeg havde om C++, ser ud til at være for- svundet
> > i ISO C++ 98.
> Så er der da sket noget. Du er så stoppet ved Bjarnes 2 rev. (den lille
> grå), og her var C++ ikke så omfattende som nu, men det var nu stadigt
> godt

Exactly - den grå er ret flosset [inklusive i øvrigt Ellis+Stroustrups Anno-
tated C++ Ref. man.]

>
> > * Hvor godt dokumenteret er standard lib'et til C++
> > o Herunder er der gode frie steder om det.
> Jeg kender ikke så meget til "frie" steder, men C++ ISO har jeg kodet til
> I snart flere år (siden den ikke var ISO godkendt). Denne dokumentation er
> bestemt ikke hygge læsning, men den hænger temlig godt sammen. Jeg kan
> anbefale Bjarnes 3.

Jeg vil se om budget holder _Men_ er 3'eren tilstrækkeligt? Eg. K&R
er en udemærket reference - men elendig manual...

>
> > * Hvor compliant er dette henover platforme (Gcc vs.
> > kommercielle).
> Tjaa, jeg har kodet på SUN platformen hvor SUN ejen (og ret dyre) compiler
> var en smule bagud i forhold til Gcc. Det er ofte i template koden man
> finder de væreste problemer ved flytning, og det er ofte library relateret
> !
>
> > * Kan template's lægges i libs idag (Gcc specifik).
> Jeg ved ikke med Gcc 3.0, men 2.95.x kan tweekes til at gøre dette, men
> deres "repo" kode er ikke held god endnu (det skulle kunne gøre det
> automatisk. Jeg ser frem til at få tid til at lege mere med gcc 3.0.

Glad, for jeg synes det må være en essentiel ting at have templates med i
biblioteker - uanset om dette så måtte medføre et ekstra pseudocompileret
lag eller ej.

>
> > o eg. er det muligt at bruge poll(), select() etc. eller
> > skal der her bruges C++ specifikke ting. (og i den
> > sam- menhæng _kan_ der indsættes "hooks" til feks.
> > wait oa. asynkrone ting.)
> Du kan FRIT bruge C og C++ i en stor pærevælding, det virker --- bare du
> holder hovedet koldt

Jeg tror jeg her kom til at tænke lidt for meget i store frameworks, et
eksempel på dårlig implementering er faktisk en jeg er stødt på i Python,
her er gtk/glib implementeret _uden_ mulighed for at du kan indsætte fx.
process waits i det's mainloop. [selvom det underliggende gtk/glib lib kan].

>
> > Jeg har ca. 15 års erfaring med C, og en del erfaring i OO via andre
> > sprog (dog primært fortolkere (lisp og python), så i må _meget gerne
> > være tekniske
> Python er udemærket, men C++ er lavet til store systemer og til at forme
> OO struktur i, med runtime check og alting, samtidigt med at du har
> styrken fra C. Hvis du kan lide OO modellen, men vil blive ved med at have
> styrken fra C er dette helt klart et klogt skift. Dog vil jeg sige,
> invister lidt tid i projektet, C++ lære man ikke på en dag

Hehe, det havde jeg såmen heller ikke regnet med, du kan lære at håndtere
et sprog på 1-2 dage - men at være hjemmevant/proficient kræver tid _megen_
tid

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

> > > * Kan template's lægges i libs idag (Gcc specifik).
> > Jeg ved ikke med Gcc 3.0, men 2.95.x kan tweekes til at gøre dette, men
> > deres "repo" kode er ikke held god endnu (det skulle kunne gøre det
> > automatisk. Jeg ser frem til at få tid til at lege mere med gcc 3.0.
>
> Glad, for jeg synes det må være en essentiel ting at have templates med i
> biblioteker - uanset om dette så måtte medføre et ekstra pseudocompileret
> lag eller ej.

Det overrasker mig meget at høre at gcc kan gøre dette - er der nogen, der
ved hvordan det fungerer?
Ideén med templates er jo netop at koden ikke er skrevet endnu - eller i
hvert fald, de rigtige kald er ikke sat ind. For mig at se må der opstå et
problem i at kompilere et template library uden instansiering da denne kode
kun er halvt færdig. I hvert fald kan den da ikke optimeres særligt
effektivt.

Kristian

---

In <3be2dab4$0$363$edfadb0f@dspool01.news.tele.dk>, Kristian Dupont
Knudsen wrote:

>> Glad, for jeg synes det må være en essentiel ting at have templates med
>> i biblioteker - uanset om dette så måtte medføre et ekstra
>> pseudocompileret lag eller ej.
>
> Det overrasker mig meget at høre at gcc kan gøre dette - er der nogen,
> der ved hvordan det fungerer?
> Ideén med templates er jo netop at koden ikke er skrevet endnu - eller i
> hvert fald, de rigtige kald er ikke sat ind. For mig at se må der opstå
> et problem i at kompilere et template library uden instansiering da
> denne kode kun er halvt færdig. I hvert fald kan den da ikke optimeres
> særligt effektivt.
I gcc kan man styre om templates bliver "implicit" eller "explicit"
instancieret. Dette gør at man kan styrre hvor de bliver instancieret, og
hvor de blot bliver refereret.
Dette er dog ganske compiler nær, og skal gøres forskælligt for hver
compiler.

/BL

---

In <hesdhzae.fsf@localhost.localdomain>, Kim Petersen wrote:

> Exactly - den grå er ret flosset [inklusive i øvrigt Ellis+Stroustrups
> Anno- tated C++ Ref. man.]
Det er også gode bøger

> Jeg vil se om budget holder _Men_ er 3'eren tilstrækkeligt? Eg. K&R
> er en udemærket reference - men elendig manual...
Jeg bruger Bjarnes bog ganske meget, jeg har dog fået fat i "Jusuttis" som
også lyder ganske fint, og har fået god omtale.

> Glad, for jeg synes det må være en essentiel ting at have templates med
> i biblioteker - uanset om dette så måtte medføre et ekstra
> pseudocompileret lag eller ej.
Jeg er enig. Templates er som nogle anmærker en compile time ting, men det
gør ikke noget om vi kan ligge noget i libs da C++ programmer ellers bliver
ganske "bloat". Jeg har dog ikke set noget jeg har været helt tilfreds med
endnu

> Hehe, det havde jeg såmen heller ikke regnet med, du kan lære at
> håndtere et sprog på 1-2 dage - men at være hjemmevant/proficient kræver
> tid _megen_ tid
Hmm, det jeg bare ville udtrykke er at C++ ikke bare er C med classer. Det
er der desværre alt for mange der tror, og det ser ud derefter, og de får
ikke det udbytte at C++ som de måtte ønske.

/BL

---

"Kim Petersen" <kim@vindinggaard.dk> wrote in message
news:1yjigsmq.fsf@localhost.localdomain...

> Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
> fulgt gruppen i et stykke tid, er det gået op for mig, at en del af
> de meninger(fordomme) som jeg havde om C++, ser ud til at være for-
> svundet i ISO C++ 98.

Hvilke fordomme har du ?

>
> Derfor kunne jeg godt tænke mig noget input om følgende...
>
> * Hvor godt dokumenteret er standard lib'et til C++

Vældigt godt.
Hvis du mener referencer, så er følgende bøger gode eksempler (rækkefølgen
er tilfældig):

Generic Programming and the STL: Using and Extending the C++ Standard
Template Library
Matthew H. Austern
ISBN: 0-201-30956-4

C++ Standard Library, The: A Tutorial and Reference
Nicolai M. Josuttis
ISBN: 0-201-37926-0

STL Tutorial and Reference Guide: C++ Programming with the Standard Template
Library
David R. Musser, Gillmer J. Derge and Atul Saini
ISBN: 0-201-37923-6

Standard C++ IOStreams and Locales
Angelika Langer and Klaus Kreft
ISBN 0-201-18395-1

The C++ Standard Template Library
P. J. Plauger, Alexander A. Stepanov, Meng Lee, David R. Musser
ISBN: 0134376331

Alle disse bøger er skrevet af anerkendte top-eksperter, som kender Standard
Library meget indgående fra deres daglige arbejde. Det er ikke bare noget
det har læst og genfortalt - det er vigtigt.

Naturligvis er den ultimative reference C++ Standarden (ISO/IEC 14882), som
kan købes for $18. Den er god som reference, men den er ikke god at lære
fra.

Desuden er der dokumentation med til compilerne.

Hvis du mener brugen (som egentlig er mere væsentlig), så findes der også
mange gode bøger.

To der ikke er til at komme uden om er:

The C++ Programming Language, Special Edition
Bjarne Stroustrup
ISB 0-201-70073-5

Accelerated C++
Andrew Koenig, Barbara Moo
ISBN 0-201-70353-X

Men også mange andre. Se f.eks. www.accu.org

> o Herunder er der gode frie steder om det.

Dinkumware (personerne er P.J. Plauger og Pete Becker)
http://www.dinkum.com

Idet jeg antager at du er professionel udvikler, mener jeg at det er mere
vigtigt at kvaliteten er høj end at prisen er lav. Tiden og intellektuel
kapacitet er de væsentligste begrænserninger, når man skal lære nyt.
Det hjælper ikke noget at købe bogen. Det hjælper at læse den.

> * Hvor compliant er dette henover platforme (Gcc vs.
kommercielle).

Jeg oplever til hverdag ikke de store problemer.
Kode kan som regel nemt flyttes mellem
gcc 2.96
Borland C++Builder V5
Intel C++ V5.0
EDG baserede compilere

Jeg oplever en del problemer med C++ implementeringen i Microsoft Visual C++
V6.0. Primært i forbindelse med implementeringen af templates men også lidt
i Standard Library (der kan iøvrigt købes en ny og mere complaint
implementering fra Dinkumware).

Det er absolut muligt i praksis at skrive portabel kode (også med Microsoft
Visual C++).

> * Hvor meget "clasher" standard lib'et med C specifikke libs.
> o eg. er det muligt at bruge poll(), select() etc. eller
> skal der her bruges C++ specifikke ting. (og i den sam-
> menhæng _kan_ der indsættes "hooks" til feks. wait oa.
> asynkrone ting.)
>

Det bør ikke give problemer - og gør det heller ikke i praksis.
Alle funktioner og klasser i Standard Library ligger i "namespace std", hvor
andre ikke har lov til at lægge noget. Det forhindrer uheldige sammenfald i
navne.
Der er dog ikke nogen grund til _kun_ at bruge Standard Library.
Ofte er det hensigtsmæssigt i C++ at bruge klassebiblioteker der indkapsler
operativsystem specifikke funktioner.
Et eksempel på et sådant bibliotek, som er tilgængeligt på mange platforme
og mange compilere er ACE (http://siesta.cs.wustl.edu/~schmidt/).
Det øger portabiliteten, fjerner mange muligheder for fejl og implementerer
en række design patterns som er nyttige til netværks- og multitrådet
programmering.
Der findes også mange andre åbne, portable biblioteker til specielle formål
(f.eks. regulære udtryk, matrice beregninger etc.).

Venlig hilsen

Mogens Hansen

---

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

> "Kim Petersen" <kim@vindinggaard.dk> wrote in message
> news:1yjigsmq.fsf@localhost.localdomain...
>
> > Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
> > fulgt gruppen i et stykke tid, er det gået op for mig, at en del af
> > de meninger(fordomme) som jeg havde om C++, ser ud til at være for-
> > svundet i ISO C++ 98.
>
> Hvilke fordomme har du ?

1 For lidt standardiseret (har ændret sig).
2 For mange faciliteter er "svagt" implementeret (templates igen ændret).
3 OO er ikke egnet til compilerede sprog [her har jeg stadig problemer].
4 For mange forskellige måder at gøre det samme på - hører egentligt
under #1 - mit oprindelige problem var med string implementeringer.
5 Casting problematikker, her har jeg specifikt manglet en mulighed for
at kunne putte forskellige objekter som ikke er typerelaterede i en
container.

plus en del andre som jeg sikkert kommer på mens jeg tilegner mig ISO 98

>
> >
> > Derfor kunne jeg godt tænke mig noget input om følgende...
> >
> > * Hvor godt dokumenteret er standard lib'et til C++
>
> Vældigt godt.
> Hvis du mener referencer, så er følgende bøger gode eksempler (rækkefølgen
> er tilfældig):

Tak for dem, vil se på dem, næste gang jeg er i Århus og kan se dem [jeg
køber _aldrig_ IT bøger uden at have fået et "feel" for dem først ]

> Naturligvis er den ultimative reference C++ Standarden (ISO/IEC 14882), som
> kan købes for $18. Den er god som reference, men den er ikke god at lære
> fra.

Se den vil jeg se om ikke jeg kan få fat i. ISO dokumenterne er som du
siger trælse at lære efter - men geniale som reference og som input til
fejl/feature problematikker.

>
> Desuden er der dokumentation med til compilerne.
>
> Hvis du mener brugen (som egentlig er mere væsentlig), så findes der også
> mange gode bøger.
>
> To der ikke er til at komme uden om er:
>
> The C++ Programming Language, Special Edition
> Bjarne Stroustrup
> ISB 0-201-70073-5

Ser ikke ud som om jeg kommer uden om den [selv om jeg har v.2].
>
> Dinkumware (personerne er P.J. Plauger og Pete Becker)
> http://www.dinkum.com

Hmm, Plauger skriver han ikke jævnligt i Dr.Dobbs? I så tilfælde er han
en god reference

> Der er dog ikke nogen grund til _kun_ at bruge Standard Library.
> Ofte er det hensigtsmæssigt i C++ at bruge klassebiblioteker der indkapsler
> operativsystem specifikke funktioner.

Kan du give et estimat af hvor gode sådanne er? Her mener jeg specifikt med
hensyn til tab i performance og funktionalitet.

> Et eksempel på et sådant bibliotek, som er tilgængeligt på mange platforme
> og mange compilere er ACE (http://siesta.cs.wustl.edu/~schmidt/).

ACE er højt på min "læse"-liste, der var en PDF af en af bøgerne - selvom
jeg hader at læse online - kan det vel gøres.

> Det øger portabiliteten, fjerner mange muligheder for fejl og implementerer
> en række design patterns som er nyttige til netværks- og multitrådet
> programmering.
> Der findes også mange andre åbne, portable biblioteker til specielle formål
> (f.eks. regulære udtryk, matrice beregninger etc.).

Tak for det gode svar Mogens - der er meget at kigge på, men det regnede
jeg nu også med. Det væsentlige for mig var hvor portabelt tingene var,
der er stadigt ting som jeg vil skrive i C - men der er også nogle større
projekter hvor jeg har manglet noget OO i C [udover de elementer man selv
kunne simulere i C].

--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

"Kim Petersen" <kim@vindinggaard.dk> wrote in message
news:y9lpggv6.fsf@localhost.localdomain...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> >
> > Hvilke fordomme har du ?
>
> 1 For lidt standardiseret (har ændret sig).

ja, det har ændret sig

> 2 For mange faciliteter er "svagt" implementeret (templates igen ændret).

Hvis man bruger gode, moderne compilere er der ikke meget tilbage af de
problemer.

> 3 OO er ikke egnet til compilerede sprog [her har jeg stadig problemer].

Mener du statisk typede sprog i forhold til dynamisk typede sprog.

> 4 For mange forskellige måder at gøre det samme på - hører egentligt
> under #1 - mit oprindelige problem var med string implementeringer.

Det kender jeg godt - men det er snart en del år siden jeg sidst er stødt på
det, hvor der var forskellige implementeringer af string klassen, som man
forventede at den ville blive.
Desuden er der fortsat problemer med at forskellige sub-systemer har
proprietære string typer - f.eks. MFC, CORBA, VCL, COM, KDE, databaser. Men
man har altid type problemer, når man skal interface sub-systemer.

> 5 Casting problematikker, her har jeg specifikt manglet en mulighed for
> at kunne putte forskellige objekter som ikke er typerelaterede i en
> container.
>

Det lyder umiddelbart som pkt. 3, med statisk typede sprog i forhold til
dynamisk typede.
Jeg kender ikke særligt meget til dynamisk typede sprog. Jeg er meget glad
for det statiske typecheck.
Faktisk kan man lave mange gode ting ved at programmere typesystemet i C++,
og foretage en masse eksekvering på compiletidspunktet, så det endelige
program bliver meget performance optimeret (men det er nok en anden
historie).

Jeg kan ikke huske at jeg har oplevet det problem - måske har jeg ikke været
klar over at jeg har haft det.
Hvis jeg fik behov for at putte forskellige ikke relaterede typer i en
container, ville se om Any typen fra Boost (www.boost.org -
http://www.boost.org/libs/any/index.html) ville kunne bruges. Den kan rumme
alle type - så vidt jeg ved.
Boost er i det hele taget et glimrende sted.

>
> Tak for dem, vil se på dem, næste gang jeg er i Århus og kan se dem [jeg
> køber _aldrig_ IT bøger uden at have fået et "feel" for dem først ]
>

Du kan sagtens nøjes med een af dem. Kig på anmeldelserne på www.accu.org.
Personligt bruger Musser & Saini - den udkom først, og jeg brugte Atul
Saini's kommercielle STL implementering tilbage i 1995.
Jeg er sikker på at de andre også er gode.

> > Naturligvis er den ultimative reference C++ Standarden (ISO/IEC 14882),
som
> > kan købes for $18. Den er god som reference, men den er ikke god at lære
> > fra.
>

Den kan købes her:
http://webstore.ansi.org/AnsiDocStore/shopper_lookup.asp

> >
> > The C++ Programming Language, Special Edition
> > Bjarne Stroustrup
> > ISB 0-201-70073-5
>
> Ser ikke ud som om jeg kommer uden om den [selv om jeg har v.2].

Første og anden udgave har kun af historisk interesse.
Special Edition og Third Edition (i optryk efter foråret 2000) er identiske,
hvad angår indhold.

>
> Hmm, Plauger skriver han ikke jævnligt i Dr.Dobbs? I så tilfælde er han
> en god reference

Sikkert - men også i "Embedded Systems" og "C/C++ Users Journal".
Han ved meget om implementering af Standard Library.

>
> Kan du give et estimat af hvor gode sådanne er? Her mener jeg specifikt
med
> hensyn til tab i performance og funktionalitet.

ACE er lavet med enormt fokus på performance.
Jeg ville kræve _målinger_ før jeg bliver bekymret over performance.
Måske findes der nogle mål for det Doug Schmidts hjemmeside.
Jeg har set nogle målinger
(http://www.orbexpress.com/technical/rt_diicoe/release.html), der
sammenligner netværks performance mellem rå TCP/IP kommunikation og CORBA
(bl.a. TAO som er bygget ovenpå ACE).

Venlig hilsen

Mogens Hansen

---

"Mogens Hansen" <mogens_h@dk-online.dk> writes:
>
> > 3 OO er ikke egnet til compilerede sprog [her har jeg stadig problemer].
>
> Mener du statisk typede sprog i forhold til dynamisk typede sprog.

Ja.

> Desuden er der fortsat problemer med at forskellige sub-systemer har
> proprietære string typer - f.eks. MFC, CORBA, VCL, COM, KDE, databaser. Men
> man har altid type problemer, når man skal interface sub-systemer.

Selvfølgeligt, men man burde dog forvente, at disse subsystemer i så tilfælde
lægger et layer imellem, som gør dette transparent. Specielt hvis de distan-
cerer sig fra en standard.

>
> > 5 Casting problematikker, her har jeg specifikt manglet en mulighed for
> > at kunne putte forskellige objekter som ikke er typerelaterede i en
> > container.
> >
>
> Det lyder umiddelbart som pkt. 3, med statisk typede sprog i forhold til
> dynamisk typede.

Ikke helt - der kan være gode grunde til dette. Mit problem ligger i at
det i C++ er muligt at caste "nedad" i et objekthieraki - men ikke muligt
at caste "opad" på en typesikker måde. Og ja, man burde jo i så tilfælde
skrive en baseclass som disse alle er nedarvet fra - men det er ikke altid
muligt/hensigtsmæssigt - godt eksempel er at så skulle jeg til at skrive
en egen stringclass i denne base. Jeg kan selvfølgelig "wrappe" dem, men
dette er heller ikke efter min mening hensigtsmæssigt, idet jeg så bare
ville have 2 sideløbende hierakier. Hvis du kan følge mig....

I mange af de tilfælde hvor dette hidtil har været nødvendigt, er det muligt
at bruge templates istedet. Derfor også mine spørgsmål vedr. templatesystem-
ets portabilitet og libraryegnethed.

Hvis jeg hurtigt skulle komme op med et eksempel - ville jeg nok vælge DOM
systemet i XML - her er det et træ som består af mange objekter - som du
ville blive nødt til at caste "opad" for at kunne få fat i den funktiona-
litet som det enkelte element har.

> Jeg kan ikke huske at jeg har oplevet det problem - måske har jeg ikke været
> klar over at jeg har haft det.
> Hvis jeg fik behov for at putte forskellige ikke relaterede typer i en
> container, ville se om Any typen fra Boost (www.boost.org -
> http://www.boost.org/libs/any/index.html) ville kunne bruges. Den kan rumme
> alle type - så vidt jeg ved.
> Boost er i det hele taget et glimrende sted.

Jeg vil kigge på Boost også - i det hele taget har du været en ren guldgrube
i gode links og referencer, tak for det


--
Mvh. Kim Petersen /| Tlf: +4575831551 |\ Jomfru Ingefreds Vej 18
Software Engineer / | Fax: (none atm.) | \ 7100 Vejle
LSS / | Email: kim@vindinggaard.dk | \ DK - Danmark

---

> Ikke helt - der kan være gode grunde til dette. Mit problem ligger i at
> det i C++ er muligt at caste "nedad" i et objekthieraki - men ikke muligt
> at caste "opad" på en typesikker måde. Og ja, man burde jo i så tilfælde
> skrive en baseclass som disse alle er nedarvet fra - men det er ikke altid
> muligt/hensigtsmæssigt - godt eksempel er at så skulle jeg til at skrive
> en egen stringclass i denne base. Jeg kan selvfølgelig "wrappe" dem, men
> dette er heller ikke efter min mening hensigtsmæssigt, idet jeg så bare
> ville have 2 sideløbende hierakier. Hvis du kan følge mig....

Jeg er ikke helt med. Hvorfor kan det ikke gøres sådan?:

class Base: public std::string{};

Ellers hvis base skal nedarve fra en anden klasse A (og du helst vil undgå
multibel nedarvning):

class Base : public A{
std::string s;
public:
std::string& getString(){return s;}
};

---

"Kim Petersen" <kim@vindinggaard.dk> wrote in message
news:d730hkyf.fsf@localhost.localdomain...
> "Mogens Hansen" <mogens_h@dk-online.dk> writes:

> > > 5 Casting problematikker, her har jeg specifikt manglet en mulighed
for
> > > at kunne putte forskellige objekter som ikke er typerelaterede i en
> > > container.
> > >
> >
> > Det lyder umiddelbart som pkt. 3, med statisk typede sprog i forhold til
> > dynamisk typede.
>
> Ikke helt - der kan være gode grunde til dette. Mit problem ligger i at
> det i C++ er muligt at caste "nedad" i et objekthieraki - men ikke muligt
> at caste "opad" på en typesikker måde.

Jeg tror ikke at vi er helt enige om hvad der er op og ned på et
arve-hieraki.
Ikke at det gør det store, jeg mener at jeg forstår hvad du skriver - men
terminologi er alligevel vigtigt.

Når man caster opad (upcast), går man fra en afledt klasse til en base
klasse.
Når man caster nedad (downcast), går man fra en base klasse til en afledt.
Se f.eks. "The C++ Programming Language, Special Edition" side 408, for
samme forklaring.

Det _er_ muligt at caste på en typesikker måde i C++.
Det hedder "dynamic_cast" (se f.eks. samme bog, samme side og der omkring).
Den kan også bruges til cross-casting i hierakier med multiple arv.
Det kræver at man har mindst een virtuel metode - f.eks. destructoren. Men
det har man typisk når man arbejder med run-time polymophy (i modsætning til
compile-time polymorphy eller static polymorphy).

Generelt er det at foretrække at bruge C++ cast
static_cast
const_cast
dynamic_cast
reinterpret_cast
frem for C cast (i C++ programmer)

> Og ja, man burde jo i så tilfælde
> skrive en baseclass som disse alle er nedarvet fra - men det er ikke altid
> muligt/hensigtsmæssigt - godt eksempel er at så skulle jeg til at skrive
> en egen stringclass i denne base. Jeg kan selvfølgelig "wrappe" dem, men
> dette er heller ikke efter min mening hensigtsmæssigt, idet jeg så bare
> ville have 2 sideløbende hierakier. Hvis du kan følge mig....
>

Ikke helt. Kan du give et lille eksempel gerne med kode ?

> I mange af de tilfælde hvor dette hidtil har været nødvendigt, er det
muligt
> at bruge templates istedet.

I mange tilfælde drejer det som om hvorvidt man har med statisk polymorphy
(f.eks. implementeret med templates) i forhold til dynamisk polymorphy
(f.eks. implementeret med virtuelle metoder) at gøre.
Altså tidspunkter (compile-time/run-time) hvor man har brug for dynamikken.

Se bogen
Multi-Paradigm DESIGN for C++
James O. Coplien
ISBN 0-201-82467-1
for en virkelig god beskrivelse af en række væsentlige design aspekter.
Det er _ikke_ en læse let bog. Den skal sikkert læses mere end een gang. Jeg
gik lidt sur i den efter de første kapitler. Lagde den væk og læste den igen
og læste bagefter hans phd afhandling om samme emne. Den er virkelig god
(advarsel: man bliver ikke mere begejstret for f.eks. Java af at læse den!).
Det er typisk for Coplien, at når har skriver en bog har samtiden svært ved
at forstå den - der går typisk 6-7 år før man er i stand til at forstå det.
Tiden kan kortes lidt ned ved hårdt arbejde.
Coplien var i øvrigt den første person, der fik adgang til C++ compileren (C
with classes) udenfor Bjarne Stroustrup's gruppe.

Se også (men bagefter)
Moden C++ Design
Andrei Alexandrescu
ISBN 0-201-70431-5
og
Generative Programming
Krzysztof Czarnecki, Ulrich W. Eisenecker
ISBN 0-201-30977-7

>
> Hvis jeg hurtigt skulle komme op med et eksempel - ville jeg nok vælge DOM
> systemet i XML - her er det et træ som består af mange objekter - som du
> ville blive nødt til at caste "opad" for at kunne få fat i den funktiona-
> litet som det enkelte element har.
>

Jeg ved ikke særligt meget om DOM.
Hvis jeg ikke skulle bruge et tredieparts bibliotek (f.eks. Xerces
http://xml.apache.org/xerces-c/index.html), ville jeg implementere det ved
en kombination af de to design patterns Composite og Visitor.

Composite til at modelere dokumentet, som forskellige typer indeholdt i en
træstruktur.
Visitor til at traversere træet, når det er blevet skabt, for at bruge
information i dokumentet.

Se bogen
Design Patterns, Elements of Reusable Object-Oriented Software
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
ISBN 0-201-63361-2
ofte kaldet GoF (Gang of Four).
Eller søg på nettet - der er masser.


Venlig hilsen

Mogens Hansen

---

In <y9lpggv6.fsf@localhost.localdomain>, Kim Petersen wrote:

> 5 Casting problematikker, her har jeg specifikt manglet en mulighed for
> at kunne putte forskellige objekter som ikke er typerelaterede i en
> container.
Du kunne jo bruge en "variant" teknik. Som er en typesafe pointer type,
ganske sjov teknik

/BL

---

"Kim Petersen" <kim@vindinggaard.dk> wrote in message
news:1yjigsmq.fsf@localhost.localdomain...

> Nu er det måske på tide at få sig et nyt "look" på C++, efter at have
> fulgt gruppen i et stykke tid, er det gået op for mig, at en del af
> de meninger(fordomme) som jeg havde om C++, ser ud til at være for-
> svundet i ISO C++ 98.

Hvilke fordomme har du ?

>
> Derfor kunne jeg godt tænke mig noget input om følgende...
>
> * Hvor godt dokumenteret er standard lib'et til C++

Vældigt godt.
Hvis du mener referencer, så er følgende bøger gode eksempler (rækkefølgen
er tilfældig):

Generic Programming and the STL: Using and Extending the C++ Standard
Template Library
Matthew H. Austern
ISBN: 0-201-30956-4

C++ Standard Library, The: A Tutorial and Reference
Nicolai M. Josuttis
ISBN: 0-201-37926-0

STL Tutorial and Reference Guide: C++ Programming with the Standard Template
Library
David R. Musser, Gillmer J. Derge and Atul Saini
ISBN: 0-201-37923-6

Standard C++ IOStreams and Locales
Angelika Langer and Klaus Kreft
ISBN 0-201-18395-1

The C++ Standard Template Library
P. J. Plauger, Alexander A. Stepanov, Meng Lee, David R. Musser
ISBN: 0134376331

Alle disse bøger er skrevet af anerkendte top-eksperter, som kender Standard
Library meget indgående fra deres daglige arbejde. Det er ikke bare noget
det har læst og genfortalt - det er vigtigt.

Naturligvis er den ultimative reference C++ Standarden (ISO/IEC 14882), som
kan købes for $18. Den er god som reference, men den er ikke god at lære
fra.

Desuden er der dokumentation med til compilerne.

Hvis du mener brugen (som egentlig er mere væsentlig), så findes der også
mange gode bøger.

To der ikke er til at komme uden om er:

The C++ Programming Language, Special Edition
Bjarne Stroustrup
ISB 0-201-70073-5

Accelerated C++
Andrew Koenig, Barbara Moo
ISBN 0-201-70353-X

Men også mange andre. Se f.eks. www.accu.org

> o Herunder er der gode frie steder om det.

Dinkumware (personerne er P.J. Plauger og Pete Becker)
http://www.dinkum.com

Idet jeg antager at du er professionel udvikler, mener jeg at det er mere
vigtigt at kvaliteten er høj end at prisen er lav. Tiden og intellektuel
kapacitet er de væsentligste begrænserninger, når man skal lære nyt.
Det hjælper ikke noget at købe bogen. Det hjælper at læse den.

> * Hvor compliant er dette henover platforme (Gcc vs.
kommercielle).

Jeg oplever til hverdag ikke de store problemer.
Kode kan som regel nemt flyttes mellem
gcc 2.96
Borland C++Builder V5
Intel C++ V5.0
EDG baserede compilere

Jeg oplever en del problemer med C++ implementeringen i Microsoft Visual C++
V6.0. Primært i forbindelse med implementeringen af templates men også lidt
i Standard Library (der kan iøvrigt købes en ny og mere complaint
implementering fra Dinkumware).

Det er absolut muligt i praksis at skrive portabel kode (også med Microsoft
Visual C++).

> * Hvor meget "clasher" standard lib'et med C specifikke libs.
> o eg. er det muligt at bruge poll(), select() etc. eller
> skal der her bruges C++ specifikke ting. (og i den sam-
> menhæng _kan_ der indsættes "hooks" til feks. wait oa.
> asynkrone ting.)
>

Det bør ikke give problemer - og gør det heller ikke i praksis.
Alle funktioner og klasser i Standard Library ligger i "namespace std", hvor
andre ikke har lov til at lægge noget. Det forhindrer uheldige sammenfald i
navne.
Der er dog ikke nogen grund til _kun_ at bruge Standard Library.
Ofte er det hensigtsmæssigt i C++ at bruge klassebiblioteker der indkapsler
operativsystem specifikke funktioner.
Et eksempel på et sådant bibliotek, som er tilgængeligt på mange platforme
og mange compilere er ACE (http://siesta.cs.wustl.edu/~schmidt/).
Det øger portabiliteten, fjerner mange muligheder for fejl og implementerer
en række design patterns som er nyttige til netværks- og multitrådet
programmering.
Der findes også mange andre åbne, portable biblioteker til specielle formål
(f.eks. regulære udtryk, matrice beregninger etc.).

Venlig hilsen

Mogens Hansen

---

Kim Petersen <kim@vindinggaard.dk> writes:

> Hmm, lad mig prøve at uddybe... Hvor mange forskellige måder kan stan-
> darden udlægges på, eg. hvor specifik er den - og dermed kan forskellige
> implementeringer virke forskelligt på trods af at være baseret på samme
> beskrivelse...

Jeg vil antage at der er masser af ting der er udefineret eller
implementation defineret ligesom i C standarden. Om ikke andet
indeholder den hele C89 standard biblioteket, så de ting der er
udefinerede eller implementation definerede der, er det også i C++
standarden.

Men jeg har ikke oplevet problemer ved portering af kode der skyldes
en for løs definition af standardbiblioteket. De problemer der opstår
skyldes normalt at enten så tillod den compiler jeg brugte noget
ulovlig kode, eller også er der fejl i den compiler jeg porterer til.

> Findes der i den sammenhæng et subset af standarden, som kan betragtes som
> værende de-facto så?

Ja, det hedder Visual C++ (minus extensions)

Det er nok den af de "store" navne der er længst bagude.

> Og lidt af et helvede at distribuere libs?

Næh, templates skal bare ligge i headers. Så det er ikke værre end at
distribuere C biblioteker.

> Hmm, det gør vel compile time forbasket tung, hvis man benytter sig af
> mange libs?

Ja, C++ headerfiler har en tendens til at blive meget store.

> Hvad med threading (pthreads etc.), er der definitioner af hvordan std-
> funktionerne håndterer dette? [eg. reentrant etc.]

Theading indgår ikke i standarden. Den nyeste GNU version skulle være
"thread safe", og jeg vil antage Microsoft og Borland også er det,
givet at threading er populært for MS Windows platformen.

Men det er ikke et punkt hvor jeg kan tale fra erfaring.

---

"Jonas Meyer Rasmussen" <meyerDO_REMOVE_THIS@diku.dk> writes:

> Scott Meyers skriver ellers lige det modsatte, at det i MS' tilfælde
> er compileren der er sej nok, men problemet ligger i at den STL der
> følger med er en gammel gammel dikumware version.

Tjah, jeg har ikke haft problemer med biblioteket, men deres compiler
crasher ("intenal error") hvis jeg kommer til at kigge skævt på den.

---

Jeg tror der er en misforståelse her...

GCC kan _ikke_ compilere templates, heller ikke med -frepo. Det
problem -frepo løser er et andet, nemlig flere instantieringer af den
samme type.

Eksempel:

Fil a.cc indeholder

vector<double> foo;

Fil b.cc indeholder

vector<double> bar;

Når compileren ser vector<double> i fil a.cc vil den instantiere vector
tempalten med double og lægge det i fil a.o. Det samme vil ske når
compileren oversætter b.cc. Når linkeren så skal link a.o og b.o
sammen, vil vi få en "duplicate definition" fordi vector<double> er
defineret i begge object filer.

Med "-frepo" vil compileren når den oversætter "a.cc" først kikke i et
"repository" for at se om den allerede har en instantiering af
"vector<double>". I så fald vil den ikke gøre mere. Ellers vil den
instantiere den, og placere den i repositoriet. Når den så oversætter
"b.cc" vil den kunne bruge den version.

På den måde er der kun en version af en bestemt template
instantiering, og vi slipper for "duplicate definitions". Denne
løsning kaldes "Sun modellen" af GCC udviklerne.

Men tilsyneladende er der noget galt med den, for de er ved at gå bort
fra den til fordel for noget de kalder "Borland modellen". I den vil
vector<double> blive compiler placeret i begge filer, men mærket på en
bestempt måde der tillader linkeren at se bort fra dupletter og tage
den første den bedste definition den støder på.

Jeg plejede at bruge -frepo fordi det var hurtigere, men jeg kunne kun
få det til at virke på Sun og med GCC 3.0 kan jeg slet ikke få det til
at virke mere.

---

In <rj3d3vden8.fsf@ssv2.dina.kvl.dk>, Per Abrahamsen wrote:

> Jeg tror der er en misforståelse her...
Det er vist mig der roder lidt sammen på libs. og instanciering.

> På den måde er der kun en version af en bestemt template instantiering,
> og vi slipper for "duplicate definitions". Denne løsning kaldes "Sun
> modellen" af GCC udviklerne.
Jeg har kodet op mod SUN CC i noget tid, og det må havde gået mig til
hovedet. Jeg kan desuden fortælle at SUN CC's template repository ikke virker
ordenligt og ofte laver fejl, som gør at man skal recompilerer alt. Det
vil vi gerne undgå i gcc

> Men tilsyneladende er der noget galt med den, for de er ved at gå bort
> fra den til fordel for noget de kalder "Borland modellen"....
Kan du henvise til noget online skriv om dette eller er det noget du har
læst en gcc dev. listen ? Jeg har set gcc's gennerelle template skriv,
men jeg har ikke haft en fornæmmelse af den fremtidige udvikling på dette
felt.

> Jeg plejede at bruge -frepo fordi det var hurtigere, men jeg kunne kun
> få det til at virke på Sun og med GCC 3.0 kan jeg slet ikke få det til
> at virke mere.
Det er trist at høre, så er der KUN borland modellen tilbage, men hvad --
bare den så virker, så mine C++ programmer ikke bliver så store. Jeg er
så ked af at C folk driller mig

Men tak for det klare udredning, den trængte jeg til

/BL

---

"Bo Lorentsen" <bl@lue.dk> wrote in message
news:pan.2001.11.04.23.42.54.409.1062@lue.dk...

>
> Kan du henvise til noget online skriv om dette eller er det noget du har
> læst en gcc dev. listen ? Jeg har set gcc's gennerelle template skriv,
> men jeg har ikke haft en fornæmmelse af den fremtidige udvikling på dette
> felt.
>

Måske
http://www.edg.com/docs/edg_cpp.pdf , kapitel 1.11
kan hjælpe, selvom det ikke er specifikt for GCC med derimod for EDG

> Det er trist at høre, så er der KUN borland modellen tilbage, men hvad --
> bare den så virker, så mine C++ programmer ikke bliver så store. Jeg er
> så ked af at C folk driller mig

Instantierings modellen gør _ikke_ programmerne større - kun compileringen
langsommere (hvilket også er trist).
Linkeren sorterer de dubletter fra. Det er faktisk et krav i C++ Standarden
et en funtion kun findes på een adresse.

Venlig hilsen

Mogens Hansen

---

In <3be68168$1@lxcs1.manbw.dk>, Mogens Hansen wrote:

> Måske
> http://www.edg.com/docs/edg_cpp.pdf , kapitel 1.11 kan hjælpe, selvom
> det ikke er specifikt for GCC med derimod for EDG
Tak, omend det ikke ligner en gcc road map

> Instantierings modellen gør _ikke_ programmerne større - kun
> compileringen langsommere (hvilket også er trist). Linkeren sorterer de
> dubletter fra. Det er faktisk et krav i C++ Standarden et en funtion kun
> findes på een adresse.
Det var også det jeg forventede, men alt den inlining gør ting MEGET
store, og det gør mig lidt trist når jeg ved hvor små og "sexet" C++
programmer var i gamle dage (pre. template C++)

Jeg har lavet en fuld C++ wrapper "hello, world" under windows (Ok, win 16
men aligevel), på under 15 k, statisk linket, hvor C versionen fyldte
omkring 8K. Det var tider !

Man kunne stoppe med at bruge templates, men det er de bare for lækre til


/BL

---

"Bo Lorentsen" <bl@lue.dk> wrote in message
news:pan.2001.11.06.17.09.41.702.3150@lue.dk...
> In <3be68168$1@lxcs1.manbw.dk>, Mogens Hansen wrote:

>
> > Instantierings modellen gør _ikke_ programmerne større - kun
> > compileringen langsommere (hvilket også er trist). Linkeren sorterer de
> > dubletter fra. Det er faktisk et krav i C++ Standarden et en funtion kun
> > findes på een adresse.
> Det var også det jeg forventede, men alt den inlining gør ting MEGET
> store, og det gør mig lidt trist når jeg ved hvor små og "sexet" C++
> programmer var i gamle dage (pre. template C++)

inline og template's er orthogonale.
inlined funktioner behøver ikke at have noget med templates at gøre.
templates behøver ikke at have noget med inline at gøre.
inline og templates kan kombineres og bruges sammen.

Det er lidt en myte, og unuanceret at sige at såvel templates og inline gør
programmerne større.

Der er 2 ting, der gør at inlinede funktioner _både_ kan gøre programmet
mindre _og_ hurtigere:

1.
Hvis en funktion er lille, kræver det færre instruktioner at udføre arbejdet
end at sætte kaldestakken op og pille den ned igen.
Et eksempel på dette er vector<T>::begin.
Et hurtigt forsøg på min maskine, viser at et inlinet eksekvering fylder 6
bytes, hvor det fylder 13 bytes at sætte kaldestakken op, foretage kaldet og
nedlægge kaldestakken igen. Altså mere end dobbelt så meget plads. Hertil
kommer så naturligvis udførelsen af funktionen.

2.
Det at funktionen er inlinet giver compilerens optimizer mulighed for at
lave optimeringer, som den typisk ellers vil afstå fra.
F.eks. hvis en funktion bliver kaldt med et argument, som er en compile-time
konstant kan dele af funktionen helt blive undladt.
Et ekstremt eksempel er:

void foo(int i)
{
if(i < 0) {
// do a lot of computation
}
}

void bar(void)
{
foo(7);
}

Det er en teknik jeg med succes har benyttet i embeddede systemer med
begrænsede resourcer.

Store inline funktioner kan gøre programmet større, men specielt på moderne
processorer hvor udnyttelsen af cache på CPUen kan det spille en væsentlig
performance forskel.

Med hensyn til templates og store programmer (code-bloat), så er der også
her en del myte dannelse.
Jeg har selv bidraget med noget af myte dannelsen.

Templates instantierer af natur netop de funktioner, der er brug for. Hvis
man skriver kode, der instantierer flere funktioner end man har brug for,
bliver programmet naturligvis større end man har brug.

Man skal være meget nuaceret om hvad man mener, der gør programmerne for
store.
Det typisk eksempel på code-bloat er at containere indeholdende pointere til
forskellige typer, kan dele koden.
F.eks. vil std::vector<int*> og std::vector<std::string*> på assemblerniveau
typisk være identiske. Alligevel kan man nemt komme ud for at såvel
std::vector<int*>::push_back og std::vector<string*>::push_back findes i det
endelige program.

Den simple løsning er at Standard Library implementeringen indeholder en
template specialisering for pegere:
templat <class T> clas vector<T*>;
Dette er bl.a. beskrevet på side 342 i Bjarne Stroustrups bog "The C++
Programming Language, Special Edition".

En mere avanceret løsning som Microsoft Visual C++ understøtter (ved
passende opsætning af compiler og linker options) er at linkeren beregner en
checksum for assembler instruktionerne (opcodes) for samtlige funktioner.
Hvis 2 eller flere funktioner har samme checksum, er det muligvis samme
assembler instruktionssekvens. Herefter laver linkeren en nærmere analyse af
hvorvidt funktionerne faktisk er identiske, og slår dem sammen hvis det er
tilfældet.
Det gør at også std::vector<std::string*> og std::vector<int> (_ikke_ int*)
kan dele funktioner, idet såvel std::string* og int er 32 bit størrelser (på
x86 arkitekturen) med samme copy og assignment semantik.
Det er rimeligt smart.

For år tilbage var der problemer med template instantiering.
Bl.a. instantierede såvel Microsoft Visual C++ og Borland C++ _alle_
funktioner i en template klasse - uanset om de bliver brugt eller ej. Dette
har _aldrig_ været meningen med templates. En compiler har end ikke lov til
at forsøge at compilere ikke virtuelle funktioner, der ikke bliver brugt.
Det er væsentligt at skelne mellem egenskaber, der stammer fra ikke optimale
implementeringer og egenskaber der er fundamentale ved f.eks. templates.

I januar 1997 offentliggjorde jeg artikelen "How to Reduce Code Bloat From
STL Containers" i det meget ansete, men desværre nu lukkede, tidskrift "C++
Report".
På baggrund af min interesse for at kunne skrive programmer med høj
performance og tilbagemelding fra artiklen har jeg fulgt med i emnet gennem
lang tid.

>
> Jeg har lavet en fuld C++ wrapper "hello, world" under windows (Ok, win 16
> men aligevel), på under 15 k, statisk linket, hvor C versionen fyldte
> omkring 8K. Det var tider !
>

Jeg tror ikke at stigningen i programstørrelse skyldes templates og
inlining.
En væsentlig del af stigningen i programstørrelse skyldes run-time library
med bl.a. opstartskode, kode til oprettelse og nedlæggelse af globale
objekter etc.

Se
http://www.microsoft.com/msj/defaulttop.asp?page=/msj/archive/s569.htm
for en udemærket beskrivelse.
Her viser Matt Pietrek hvordan man kan skrive et lille program, med
anvendelse af en reduceret men ofte tilstrækkelig opstartskode, der fylder
ca. 5kbyte på Win32.

Hvis du tager I/O stream klasserne er disse blevet udvidet, med f.eks.
håndtering af locale, i forhold til det oprindelige I/O stream bibliotek.
Den funktionalitet fylder naturligvis noget. Jeg har siddet ved siden af
Dietmar Kuhl, der fortalte hvordan man kunne lave nogle optimeringer, i
forhold til en "simpel" og typisk implementering af locales, så størrelsen
af programmet bliver afhængigt af hvilke dele af locale man bruger. Igen er
det væsentligt at skelne mellem ikke optimale implementeringer og hvad der
er fundament for at overholde C++ Standardens krav.

Desuden sælges Dinkumware varianter af Standard Library, som ikke
implementerer fuld funktionalitet, men til gengæld er mindre. Ikke at jeg
vil anbefale at bruge det. Men hvis man har _meget_ behov er det en
mulighed.

Run-time type information (RTTI) og exception-håndtering fylder noget, men
påvirker ikke nødvendigvis eksekveringshastigheden.

> Man kunne stoppe med at bruge templates, men det er de bare for lækre til
>

Det er der vist sjældent grund til.

Venlig hilsen

Mogens Hansen

---

In <9s9k6e$tua$2@news.cybercity.dk>, Mogens Hansen wrote:

> inline og template's er orthogonale.
> inlined funktioner behøver ikke at have noget med templates at gøre.
> templates behøver ikke at have noget med inline at gøre. inline og
> templates kan kombineres og bruges sammen.
Først mange tak for din grundige gennemgang !

Jeg ved godt at inline og templates ikke hænger direkte sammen, men når
man kikker i div. header filer (SGI STL), finder man den ene kæmpe
funktion efter den anden, som er inline.

Jeg tror dit forslag om at bruge template specialicerings tricket, ikke er
helt værst. Men som udgangs punkt ville det være godt hvis ens compiler
gjorde arbejdet, hvilke jo er natruligt for en C++ programmør

> Det er lidt en myte, og unuanceret at sige at såvel templates og inline
> gør programmerne større.
Du har ret, jeg vil vælge mine ord med større omhu næste gang .-)

/BL

---

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

> Kode kan som regel nemt flyttes mellem
> gcc 2.96

Øh, han spurgte til C++ standard bibliioteket. GCC 2.96 er slet ikke
med på den vogn, han skal have fat i GCC 3.0 (der så har sine egne
problemer).

---

Sikke en kort tråd.
>
> > Kode kan som regel nemt flyttes mellem
> > gcc 2.96
>
> Øh, han spurgte til C++ standard bibliioteket. GCC 2.96 er slet ikke
> med på den vogn, han skal have fat i GCC 3.0 (der så har sine egne
> problemer).

---

"Bo Lorentsen" <bl@lue.dk> writes:

> I gcc kan man styre om templates bliver "implicit" eller "explicit"
> instancieret. Dette gør at man kan styrre hvor de bliver instancieret, og
> hvor de blot bliver refereret.
> Dette er dog ganske compiler nær, og skal gøres forskælligt for hver
> compiler.

Man kan altid lave en eksplicit template instantiering, det ser sådan
her ud.

template class add_submodule<Vegetation>;

Her er add_submodule en template og Vegetation en klasse den bliver
instantieret med.

Jeg bruger kun den feature for at omgås bugs i Borland C++ 5.0, men
jeg kan forestille mig det er praktisk for at placere template
instantieringer i libraries. F.eks. vil de give god mening at have
complex<double> instantieret i standard biblioteket.

---

"Bo Lorentsen" <bl@lue.dk> writes:

> Jeg er enig. Templates er som nogle anmærker en compile time ting, men det
> gør ikke noget om vi kan ligge noget i libs da C++ programmer ellers bliver
> ganske "bloat".

En teknik Stroustrup anbefaler er at bruge templates til at give et
typesikkert interface til noget type-usikkert generel kode (der
f.eks. operererer på void*).

---

"Bo Lorentsen" <bl@lue.dk> writes:

> Kan du henvise til noget online skriv om dette eller er det noget du har
> læst en gcc dev. listen ?

Det er fra gcc dev. listen som du har gættet.

Men der står en del om det i GCC manualen.