---

Hej C++ nørder

Jeg har næsten fået mine templates til at virke i et program.
Jeg definerer klassen i en headerfil nogenlunde sådan her:

template <class E>
class Foo{
private:
int privat;
public:
void get();
};

extern Foo<MyType> Bar;

Og implementerer den i en .cc fil:
// implementation af klassen Foo
Foo<MyType> Bar;

der oversættes seperat, men inkluderer header filen.
Samme headerfil inkluderes så i de filer der ønsker at bruge
template klassen.
Der oversættes fint, men linkeren vil ikke finde metoderne i klassen, i
dette eksempel vil den brokke sig over manglende reference til Bar.get()
nm viser også at den .cc fil der implementerer template klassen også kun
har en reference til Bar, ikke metoderne.

Hvordan kan det være og løses?

Håber I forstår hvad jeg mener, på forhånd tak,

Kasper

---

On Wed, 17 Dec 2003 19:33:51 +0100, Kasper Laudrup wrote:

> Samme headerfil inkluderes så i de filer der ønsker at bruge
> template klassen.
> Der oversættes fint, men linkeren vil ikke finde metoderne i klassen

Hvilken compiler drejer det sig om? Jeg har indtryk af, at kun
oversætteren Comeau C/C++ kan håndtere separat kompilering af
templates (for templates, der er erklæret med "export"-keyword'et). For
andre compilere, er du desværre nødt til at have
template-implementationen i headeren, foruden interface'et.

Se også
http://www.sslug.dk/emailarkiv/prog/2003_11/msg00021

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Det drejer sig om gcc 3.2.3

Det er ikke export, som så vidt jeg har forstået ikke er ordentligt
understøttet af nogen compilere, med templates eller ej, men extern.

Det jeg synes er mystisk er, at implementeringen og ærkleringen ligger i
samme fil, så alt tyder på at det bliver oversat, men den eksporterer
åbenbart ikke metoderne, kun klassen.

Så både implementationen og interfacet er i samme fil, og externt
refereret i en header-fil.

Hvis jeg fjerner den externe erklæring i headerfilen, brokker linkeren sig
over at den heller ikke kan finde klassen.

Men, tak, yderligere hjælp modtages med stor glæde.

On Wed, 17 Dec 2003 20:04:23 +0100, Troels Arvin wrote:
> Hvilken compiler drejer det sig om? Jeg har indtryk af, at kun
> oversætteren Comeau C/C++ kan håndtere separat kompilering af
> templates (for templates, der er erklæret med "export"-keyword'et). For
> andre compilere, er du desværre nødt til at have
> template-implementationen i headeren, foruden interface'et.
>
> Se også
> http://www.sslug.dk/emailarkiv/prog/2003_11/msg00021

---

"Troels Arvin" <troels@arvin.dk> wrote in message
news:pan.2003.12.17.19.04.23.419029@arvin.dk...
> On Wed, 17 Dec 2003 19:33:51 +0100, Kasper Laudrup wrote:
>
> > Samme headerfil inkluderes så i de filer der ønsker at bruge
> > template klassen.
> > Der oversættes fint, men linkeren vil ikke finde metoderne i klassen
>
> Hvilken compiler drejer det sig om? Jeg har indtryk af, at kun
> oversætteren Comeau C/C++ kan håndtere separat kompilering af
> templates (for templates, der er erklæret med "export"-keyword'et). For
> andre compilere, er du desværre nødt til at have
> template-implementationen i headeren, foruden interface'et.

Er det rigtigt?
Min forståelse af det, er at export blot udsætter instatieringen til
link stadiet, og at definitionen stadig skal eksistere
ved oversættelse af alle compilation units(dvs ligge i en header).

Hvis, så gør begrænser det export's anvendelighed - Og det forklarer
måske hvorfor at der er så få compilere der har implementeret det?

mvh Jonas

---

"Jonas Meyer" <a@b.c> wrote in message news:brs0o4$q3$1@munin.diku.dk...
>
> "Troels Arvin" <troels@arvin.dk> wrote in message
> news:pan.2003.12.17.19.04.23.419029@arvin.dk...
> > On Wed, 17 Dec 2003 19:33:51 +0100, Kasper Laudrup wrote:
> >
> > > Samme headerfil inkluderes så i de filer der ønsker at bruge
> > > template klassen.
> > > Der oversættes fint, men linkeren vil ikke finde metoderne i klassen
> >
> > Hvilken compiler drejer det sig om? Jeg har indtryk af, at kun
> > oversætteren Comeau C/C++ kan håndtere separat kompilering af
> > templates (for templates, der er erklæret med "export"-keyword'et). For
> > andre compilere, er du desværre nødt til at have
> > template-implementationen i headeren, foruden interface'et.
>
> Er det rigtigt?
Ja, sørme.
http://www.comeaucomputing.com/4.0/docs/userman/export.html

Jeg må have hørt forkert.

---

"Kasper Laudrup" <laudrup@_Fjern_Dette_linuxfan.dk> wrote in message
news:pan.2003.12.17.18.33.50.764130@_Fjern_Dette_linuxfan.dk...
> Hej C++ nørder
>
> Jeg har næsten fået mine templates til at virke i et program.
> Jeg definerer klassen i en headerfil nogenlunde sådan her:
>
> template <class E>
> class Foo{
> private:
> int privat;
> public:
> void get();
> };
>
> extern Foo<MyType> Bar;
>
> Og implementerer den i en .cc fil:
> // implementation af klassen Foo
> Foo<MyType> Bar;
>
> der oversættes seperat, men inkluderer header filen.
> Samme headerfil inkluderes så i de filer der ønsker at bruge
> template klassen.
> Der oversættes fint, men linkeren vil ikke finde metoderne i klassen, i
> dette eksempel vil den brokke sig over manglende reference til Bar.get()
> nm viser også at den .cc fil der implementerer template klassen også kun
> har en reference til Bar, ikke metoderne.
>
> Hvordan kan det være og løses?

Løsningen er nok desværre at lave implementationen i header filen.
Jeg har aldrig forsøgt at lave en "extern" med en specificeret type, men da
det ikke fungerer gælder det sikkert som det generelt gør, at compileren
ikke laver koden. Det er i hvert fald tilfældet for templates der blot
forsøges delt op i header og implementationsfiler. Compileren laver kun
koden for de typer som templaten instansieres med, og da din kode her ikke
instantierer templaten, bliver der ikke lavet noget kode.
"export" keyword'et hjælper på dette, men man skal være opmærksom på at det
ikke fjerner compiler afhængigheden så linkeren pludselig kan lave koden.
Ved at bruge export kan du dele dine filer op i headers og implementation
som andet kode, men til gengæld gør du det sværere for dit IDE eller make at
afgøre om noget skal compiles, da alle filer der instantierer en given
template stadig skal recompiles hvis noget i din cc fil ændres. Men da de
sandsynligvis kun #include'er headerfilen, kan make ikke se at noget er
ændret.
Personligt foretrækker jeg at lave implementationen i headeren.

Kristian

---

> ændret.
> Personligt foretrækker jeg at lave implementationen i headeren.
>
> Kristian
>

Hørt. På denne facon sparer man også sine fingre for unødig møje
med indtastning af template erklæringer for hver funktion i cpp filen
(hint: her kan man nøjes med at taste det en enkelt gang oven over
klassen i .hpp filen).


mvh Jacob

---

"Kasper Laudrup" <laudrup@_Fjern_Dette_linuxfan.dk> wrote:

[8<8<8<]
> Der oversættes fint, men linkeren vil ikke finde metoderne i klassen, i
> dette eksempel vil den brokke sig over manglende reference til Bar.get()

Hvor er Foo<E>::get implementeret ?
Hvor bruger du Foo<MyType>::get (og er implementering includeret i den fil
der bruger den) ?

Du skal være opmærksom på at med mindre du bruger explicit template
instantiering (hvilket man som ofte ikke gør) vil Foo<MyType>::get kun blive
instantieret (lagt ud som assembler kode) hvis den faktisk bliver brugt.

> Hvordan kan det være og løses?

Den nemmeste måde at løse problemet er at have Foo<E>::get implementeret i
samme fil som klasse erklæringen - altså i header filen.


Venlig hilsen

Mogens Hansen

---

Problemet er så, at jeg får "multiply defined" i linker fasen. Det kan jeg
sagtens forstå hvorfor, men har svært ved at overskue hvordan jeg skal
løse det.

De gode råd (som jeg takker for) om at bruge #ifdef osv. i
headerfiler hjælper ikke rigtigt, da det er i link fasen problemet opstår.
Enten er min klasse undefined eller også er den multiply defined.

Det smarteste ved templates burde da være at man kunne definere en klasse
eller funktion i en fil og så bruge den flere steder, ellers ryger ideen
med templates vel lidt?

>
> Den nemmeste måde at løse problemet er at have Foo<E>::get implementeret i
> samme fil som klasse erklæringen - altså i header filen.

---

"Kasper Laudrup" <laudrup@_Fjern_Dette_linuxfan.dk> wrote :

> Problemet er så, at jeg får "multiply defined" i linker fasen. Det kan jeg
> sagtens forstå hvorfor, men har svært ved at overskue hvordan jeg skal
> løse det.

Jeg kan ikke forstå hvorfor du får "multiple defined" når du linker.
Kig eventuelt på det komplette eksempel jeg postede andetsteds i denne tråd.

Kan du vise det mindst mulige eksempel hvor du har problemet ?
Hvilken compiler bruger du ?

[8<8<8<]
> Det smarteste ved templates burde da være at man kunne definere en klasse
> eller funktion i en fil og så bruge den flere steder,

Det lyder ikke umiddelbart som en template - det lyder mere som en normal
klasse eller funktioner.

Templates spiller en rolle, når den bruges med flere forskellige typer -
antallet af steder er den bruges er underordnet.

> ellers ryger ideen
> med templates vel lidt?

Problemet er formodentlig at hvis du ikke viser noget kode der giver
problemer, er det svært præcist at forstå hvorfor det giver problemer.

Venlig hilsen

Mogens Hansen

---

Du skal lave dine metoder inline i .h filen. Ellers kan linkeren ikke
finde en implementation af templaten med den "rigtige" template type.
Enkelte compilere kan finde ud af noget med et "export" eller lignende
keyword, men det er vistnok ikke standard C++...

template <class FooType> class Foo
{
   public:
      inline Foo()
      {
         return;
      }
};

---

On Thu, 18 Dec 2003 02:11:08 -0800, Nicolai Hansen wrote:

> Enkelte compilere kan finde ud af noget med et "export" eller lignende
> keyword, men det er vistnok ikke standard C++...

Jeg tror, at du roder rundt i _de facto_ standard og formel standard.

"export" er skam med i den formelle C++-standard. I hvertfald nævnes
den uden forbehold i Stroustrup-bogen.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

Troels Arvin <troels@arvin.dk> writes:

> On Thu, 18 Dec 2003 02:11:08 -0800, Nicolai Hansen wrote:
>
>> Enkelte compilere kan finde ud af noget med et "export" eller lignende
>> keyword, men det er vistnok ikke standard C++...
>
> Jeg tror, at du roder rundt i _de facto_ standard og formel standard.
>
> "export" er skam med i den formelle C++-standard. I hvertfald nævnes
> den uden forbehold i Stroustrup-bogen.

Men er det med i næste standard?

Jeg tror EDG's erfaringer tyder på at det ikke bør være med. Det var
1) absurd svært at implementere, og 2) gav ikke hurtigere kompilering,
som er hvad folk normalt håber på at få ud af at bruge det.

GCC folkene arbejder ikke på det. Jeg ved ikke om Borland og
Microsoft har planer om at understøtte export.

Er der egentlig andre end de fire der arbejder seriøst med udvikling
af C++ front-ends?

---

"Per Abrahamsen" <abraham@dina.kvl.dk> wrote:
> Troels Arvin <troels@arvin.dk> writes:

[8<8<8<]
> > "export" er skam med i den formelle C++-standard. I hvertfald nævnes
> > den uden forbehold i Stroustrup-bogen.
>
> Men er det med i næste standard?

Det vil jeg bestemt forvente.
Som jeg har forstået det, så argumenterede Microsoft ved Herb Sutter, for at
det skulle fjernes fra næste C++ Standard ved standardiseringsmødet i Oxford
i april.
Hans papir kan findes blandt de øvrige C++ Standard kommite papirer. James
Kanze har udtryk at han følte sig fejl-citeret i det papir.
Det vandt ikke genklang, og export forbliver i standarden.

>
> Jeg tror EDG's erfaringer tyder på at det ikke bør være med.

Det er ikke EDG's udlægning.
Jeg har hørt Daveed Vandevoorde, der hos EDG har i det væsentlige har
implementeret export, fortælle om hvor svært det var. Han korrigerede Herb
Sutter, da Herb Sutter udlagde erfaringerne på samme måde som du siger.
Det var svært, men jeg forstod at han mente at der var en tendens til at
overdrive hvor svært og unyttigt det var.

> Det var
> 1) absurd svært at implementere, og

Svært, men muligt.

> 2) gav ikke hurtigere kompilering,
> som er hvad folk normalt håber på at få ud af at bruge det.

Den konklusion forstod jeg at Daveed Vandevoorde ikke ville drage.
Der foreligger for begrænsede erfaringer til at kunne konkludere det.
Tilsvarende har jeg læst P.J. Plauger, som har implementeret Standard
Library med export, give udtryk for.
EDG første implementering var optimeret mod at være korrekt og ikke hurtig.

>
> GCC folkene arbejder ikke på det. Jeg ved ikke om Borland og
> Microsoft har planer om at understøtte export.

Jeg er ret sikker på at Borland har planer understøtte export.

>
> Er der egentlig andre end de fire der arbejder seriøst med udvikling
> af C++ front-ends?

Der må være andre også.
Hvad med Metrowerks ?
Desuden er der forskellige statiske analysatorer (a la PC Lint). Jeg kender
ihvertfald en fyr der er med til at lave front-end til sådan et produkt.

Borland arbejder ikke seriøst med udvikling af C++ front-ends mere (og det
er vel nogle år siden de sidst har rykket seriøst).
De har købt licens til EDG front-enden og vil bruge den fremover - den kører
i preview for tiden.
Dermed deler de front-end med bl.a. Comeau og Intel (som aktivt har disablet
export), og skulle derfor være i stand til at implementere export, ligesom
de nemt vil kunne understøtte C99.

Venlig hilsen

Mogens Hansen

---

Per Abrahamsen <abraham@dina.kvl.dk> wrote in message news:<rjoeu6xect.fsf@sheridan.dina.kvl.dk>...
> Troels Arvin <troels@arvin.dk> writes:
>
> > On Thu, 18 Dec 2003 02:11:08 -0800, Nicolai Hansen wrote:
> >
> >> Enkelte compilere kan finde ud af noget med et "export" eller lignende
> >> keyword, men det er vistnok ikke standard C++...
> >
> > Jeg tror, at du roder rundt i _de facto_ standard og formel standard.
> >
> > "export" er skam med i den formelle C++-standard. I hvertfald nævnes
> > den uden forbehold i Stroustrup-bogen.
>
> Men er det med i næste standard?
>

Der var et forslag til at lave "export" "optional" i den naeste
standard. Det loeb paa haard modstand i kommiteen og da det kom til en
afstemning var resultated 80/20 for at vedholde "export" or ikke at
diskutere dette emne igen.

---

Virkede som et ganske godt bud, men det virker desværre heller ikke. Jeg
får stadig fejl om at linkeren ikke kan finde metoderne selvom de er
inline. Betyder inline i øvrigt ikke, at funktionskroppen kopieres derhen
hvor den skal bruges, ligesom en makro?

Problemet er, at hvis jeg har implementationen i headerfilen og inkluderer
den i de filer hvor jeg vil bruge min template-klasse får jeg (af gode
grunde) multiply defined, eller noget i den retning.

Så spørgsmålet kan måske begrænses til:
Hvordan laver jeg nemmest en template klasse og bruger den i flere .cc
filer? (Det burde da kunne lade sig gøre)

På forhånd tak!

On Thu, 18 Dec 2003 02:11:08 -0800, Nicolai Hansen wrote:

> Du skal lave dine metoder inline i .h filen. Ellers kan linkeren ikke
> finde en implementation af templaten med den "rigtige" template type.
> Enkelte compilere kan finde ud af noget med et "export" eller lignende
> keyword, men det er vistnok ikke standard C++...
>
> template <class FooType> class Foo
> {
>    public:
>       inline Foo()
>       {
>          return;
>       }
> };

---

> Problemet er, at hvis jeg har implementationen i headerfilen og inkluderer
> den i de filer hvor jeg vil bruge min template-klasse får jeg (af gode
> grunde) multiply defined, eller noget i den retning.

Du skal ikke inkludere den i "de filer hvor jeg vil bruge min
template-klasse" - du skal inkludere den i "de filer hvor jeg skal
bruge den og den ikke er inkluderet i forvejen".

Lad os sige at vi har et linked list template kaldet List<ListType> i
list.h. Vi har så en "vej" klasse som indeholder en List<Bil> *biler;
og et par nedarvede klasser "motorvej" og "markvej". Disse indeholder
udover en liste af biler hhv en List<Lastbil> *lastBiler og en
List<Trakoterer> *traktorer.
I disse to klasser skal "list.h" _ikke_ inkluderes da den er
inkluderet i den klasse de nedarver fra (vej.h).

Du kan også vælge (da ovenstående nogle gange ikke er muligt), at
skrive class List<ListType>; lige efter dine includes i header filen.
Og så inkludere list.h i din .cpp fil (i så fald skal list.h _ikke_
inkluderes i din .h fil til klassen).

Håber det hjælper dig.

---

Nicolai Hansen wrote:
> Du skal ikke inkludere den i "de filer hvor jeg vil bruge min
> template-klasse" - du skal inkludere den i "de filer hvor jeg skal
> bruge den og den ikke er inkluderet i forvejen".

Det er også brugbart at bruge
#ifndef _DINFIL_HPP
#define _DINFIL_HPP

...kodestump

#endif

Så er der nogen, der har bildt mig ind at preprocessoren ikke hiver
samme fil ind to gange, når man i en hjerneblødning inkluderer samme
fil to gange.

---

Jacob Andresen <jacob@halsskovgade.dk> wrote in message news:<3fe2ae93$0$27443$edfadb0f@dread16.news.tele.dk>...
> Nicolai Hansen wrote:
> > Du skal ikke inkludere den i "de filer hvor jeg vil bruge min
> > template-klasse" - du skal inkludere den i "de filer hvor jeg skal
> > bruge den og den ikke er inkluderet i forvejen".
>
> Det er også brugbart at bruge
> #ifndef _DINFIL_HPP
> #define _DINFIL_HPP
>
> ..kodestump
>
> #endif
>
> Så er der nogen, der har bildt mig ind at preprocessoren ikke hiver
> samme fil ind to gange, når man i en hjerneblødning inkluderer samme
> fil to gange.

Det er rigtigt nok. MSVC++ gør det her helt automatisk. Tænkte ikke
lige over det da jeg altid sletter dem

---

"Kasper Laudrup" <laudrup@_Fjern_Dette_linuxfan.dk> wrote in message
news:pan.2003.12.18.16.49.34.290173@_Fjern_Dette_linuxfan.dk...
> Virkede som et ganske godt bud, men det virker desværre heller ikke. Jeg
> får stadig fejl om at linkeren ikke kan finde metoderne selvom de er
> inline. Betyder inline i øvrigt ikke, at funktionskroppen kopieres derhen
> hvor den skal bruges, ligesom en makro?

Delvis.
inline er et hint til compileren om at den gerne må sætte kode direkte ind
på kalde-stedet, og dermed undgå faktisk at udgøre et kald på assembler
niveau.
Compileren må gerne undlade at lave funktionen som inline, ligesom den gerne
må inline funktioner man ikke har markeret som inline.

inline adskiller sig fra makroer ved at overholde alle regler for
funktioner, som f.eks. typer, scoping og evaluering af parametre.

>
> Problemet er, at hvis jeg har implementationen i headerfilen og inkluderer
> den i de filer hvor jeg vil bruge min template-klasse får jeg (af gode
> grunde) multiply defined, eller noget i den retning.

Det burde du ikke få, hvis det er en template klasse.
Hvordan ser din kode ud (mindst mulige eksempel der giver problemet) ?

>
> Så spørgsmålet kan måske begrænses til:
> Hvordan laver jeg nemmest en template klasse og bruger den i flere .cc
> filer? (Det burde da kunne lade sig gøre)

<foo.h>
#ifndef GUARD_FOO_H
#define GUARD_FOO_H

#include <iostream>
#include <typeinfo>

template <typename T>
class foo
{
public:
void func() const;
};

template <typename T>
void foo<T>::func() const
{
std::cout << "foo<" << typeid(T).name() << ">::func() called" <<
std::endl;
}

#endif // #ifndef GUARD_FOO_H
<foo.h/>



<bar.h>
#ifndef GUARD_BAR_H
#define GUARD_BAR_H

void bar();

#endif //#ifndef GUARD_BAR_H
<bar.h/>



<bar.cpp>
#include "bar.h"
#include "foo.h"

void bar()
{
foo<int> fi;
foo<double> fd;

fi.func();
fd.func();
}
<bar.cpp/>



<main.cpp>
#include "foo.h"
#include "bar.h"

int main(int argc, char* argv[])
{
foo<int> fi;
fi.func();
bar();
}
<main.cpp/>

Hjælper det dig ?


Venlig hilsen

Mogens Hansen

---

"Nicolai Hansen" <nic@aub.dk> wrote in message
news:<d96764ff.0312180211.4bf6732a@posting.google.com>...
> Du skal lave dine metoder inline i .h filen.

Det er ligegyldigt om funktionen er inline eller ej - blot den ligger i
header filen.

[8<8<8<]
> Enkelte compilere kan finde ud af noget med et "export" eller lignende
> keyword, men det er vistnok ikke standard C++...

Jo, det er en del af Standard C++.
Der er blot ikke ret mange compilere der understøtter det - Comeau er vist
den eneste, og i hvertfald den første.

>
> template <class FooType> class Foo
> {
> public:
> inline Foo()

Det inline er overflødigt.
Hvis funktionen er defineret i klasse erklæringen er den inline.
Hvis den er defineret uden for klasse erklæringen skal man skrive inline,
hvis man vil have at det er en inline funktion.

Venlig hilsen

Mogens Hansen