---

Det maa naesten vaere en rekort for en enkelt C++-fejlbesked.

Undefined first referenced
symbol in file
__rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allocator<c
har> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,__rws
td::__ident<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,
std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::less<
std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::alloc
ator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::it
erator __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::allo
cator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,__rwstd::__ident<std::basic_string<char,std::char_traits<char>,std::allocator<c
har> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std
::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std
::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >
> >::erase(__rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::
allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<ch
ar> >,__rwstd::__ident<std::basic_string<char,std::char_traits<char>,std::allocat
or<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char
> > > >::iterator,__rwstd::__rb_tree<std::basic_string<char,std::char_traits<char
>,std::allocator<char> >,std::basic_string<char,std::char_traits<char>,std::alloc
ator<char> >,__rwstd::__ident<std::basic_string<char,std::char_traits<char>,std::
allocator<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<ch
ar> > >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<ch
ar> > >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocat
or<char> > > >::iterator) ../../../lib/Solaris/libeps.so
void __rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::alloca
tor<char> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> >,
__rwstd::__ident<std::basic_string<char,std::char_traits<char>,std::allocator<cha
r> >,std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::
less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,std::
allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >
>::__deallocate_buffers() ../../../lib/Solaris/libeps.so
ld: fatal: Symbol referencing errors. No output written to ../../../bin/Solaris/e
ps_server

---

Martin Moller Pedersen wrote:

> Det maa naesten vaere en rekort for en enkelt C++-fejlbesked.

Jeg har set en der var tre-fire gange så lang Jeg håber, at den
nye standard gør et-eller-andet ved det problem.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahp78t$bat$1@sunsite.dk...
> Jeg har set en der var tre-fire gange så lang Jeg håber, at den
> nye standard gør et-eller-andet ved det problem.
Hvad skulle den gøre? Er det ikke op til implementationen hvordan
der rapporteres om fejl?

Der findes ihvertfald et godt værktøj til at klare den slags:
http://www.bdsoft.com/tools/stlfilt.html

mvh Jonas

---

Jonas Meyer Rasmussen wrote:

> "Claus Rasmussen" <clr@cc-consult.dk> wrote in message
>
>> Jeg har set en der var tre-fire gange så lang Jeg håber, at den
>> nye standard gør et-eller-andet ved det problem.
>
> Hvad skulle den gøre? ...

Jeg ved ikke... måske nogle hårdere typedef's:

hard_typedef basic_string<en-masse-fnadder> string;

Et andet problem er, at man efterhånden har fået malet sig op i en
krog med hensyn til templates. 'extern' keywordet er dels usandsyn-
ligt svært at implementere (der findes én kompiler, der accepterer
det) og dels giver det ikke det, folk regner med.

Det bliver ret svært at indføre noget seperat kompilering af tem-
plates som kunne begrænse størrelsen af fejlmeddelelserne en del.


> Er det ikke op til implementationen hvordan
> der rapporteres om fejl?

Jo, men når "implementationen" er en C linker har man et problem.
En C++ linker kunne gøre noget smartere.


> Der findes ihvertfald et godt værktøj til at klare den slags:
> http://www.bdsoft.com/tools/stlfilt.html

Jeg har læst om den, og den har fået gode anmeldelser. Men et
eller andet sted er det lidt af en falliterklæring EMM.

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote in message
news:ahrrv0$3ib$1@sunsite.dk...

> Et andet problem er, at man efterhånden har fået malet sig op i en
> krog med hensyn til templates. 'extern' keywordet er dels usandsyn-
> ligt svært at implementere (der findes én kompiler, der accepterer
> det) og dels giver det ikke det, folk regner med.

Ja!
Jeg tror aldrig man får fede templates i C++. Semantikken af templates er
direkte imod separat kompilering. Hvis man har separat kompilering af
templates, skal man i hvert fald have en usandsynligt smart linker - ja,
faktisk må hele compileren (pånær parseren) hellere være indbygget i
linkeren, for hvordan skulle man ellers instantiere templates?

> > Der findes ihvertfald et godt værktøj til at klare den slags:
> > http://www.bdsoft.com/tools/stlfilt.html
>
> Jeg har læst om den, og den har fået gode anmeldelser. Men et
> eller andet sted er det lidt af en falliterklæring EMM.

Yep. Det er ligesom med Boost (www.boost.org). De gør sig vældige
anstrengelser for at implementere nogle af de ting C++ mangler. Så de laver
lige et "Boost-sprog" oven på C++.

Jeg vil sgu ikke have alskens værktøjer til at reparere C++ med - jeg vil
have et sprog der virker på forhånd.
C++ kommer *aldrig* til at blive fedt. Det hænger så meget fast i
bagudkompatibilitetskrav (som du siger: de har malet sig op i en krog), at
man ikke kan rette de grundlæggende fejl.

Mvh.
Bjarke "Python" Ebert

---

Bjarke Dahl Ebert wrote:

> Yep. Det er ligesom med Boost (www.boost.org). De gør sig vældige
> anstrengelser for at implementere nogle af de ting C++ mangler. Så de
> laver lige et "Boost-sprog" oven på C++.

Helt enig. Boost bygger mange steder på helt tilfældige sideeffekter som
aldrig var tiltænkt den brug som Boost gør af dem (men boost er immervæk
/fedt/ !).


> Jeg vil sgu ikke have alskens værktøjer til at reparere C++ med - jeg vil
> have et sprog der virker på forhånd.

Nemlig.

Templates /er/ fedt. C++ har et kanon-library som der ikke er noget andet
sprog, der kan måle sig med. Men den måde, templates er implementeret på
i C++, giver nogle temmeligt ubehagelige sideeffekter. Samtidigt er den
nuværende template definition i C++ langt fra tilstrækkelig - som boost
netop demonstrer.


> C++ kommer *aldrig* til at blive fedt. Det hænger så meget fast i
> bagudkompatibilitetskrav (som du siger: de har malet sig op i en krog), at
> man ikke kan rette de grundlæggende fejl.

EMM skulle de droppe bagudkompabiliteten. Eller lave et helt nyt sprog,
der var nogenlunde lig med C++ - C.


> Bjarke "Python" Ebert
^^^^^^
Ja, det /har/ vi bemærket

-Claus

---

"Claus Rasmussen" <clr@cc-consult.dk> wrote

[]
> 'extern' keywordet er dels usandsyn-
> ligt svært at implementere (der findes én kompiler, der accepterer
> det) og dels giver det ikke det, folk regner med.

Det hedder "export" - ikke "extern".

> Det bliver ret svært at indføre noget seperat kompilering af tem-
> plates som kunne begrænse størrelsen af fejlmeddelelserne en del.

Det er mit klare indtryk, at der kan gøres meget for både at minimere
kompileringstider, forbedre fejlmeldinger, forbedre muligheden for at browse
i koden, og optimere programmerne globalt hvis der bliver puttet
tilstrækkelige resourcer i at implementere det.
IBM Visual Age V4 og senere er et interessant eksempel på dette.
Todd L. Veldhuizen beskriver i dokumentet "Five compilation models for C++
templates" (http://osl.iu.edu/~tveldhui/) nogle spændende tanker om hvad der
kan gøres.

[snip]
> Jo, men når "implementationen" er en C linker har man et problem.
> En C++ linker kunne gøre noget smartere.

Som det tidligere er bemærket i denne tråd, er der jo åbenlyst tale om en
C++ linker - eller ville fejlmeldingen være mindre læsbar.

[snip]
> Jeg har læst om den, og den har fået gode anmeldelser. Men et
> eller andet sted er det lidt af en falliterklæring EMM.

Er demangling af funktionsnavne i fejlmeddelelser så også en falliterklæring
?
Enhver hjælp, der kan føre til at man finder fejlen hurtigere må da være et
fremskridt.

Venlig hilsen

Mogens Hansen

---

"Martin Moller Pedersen" <tusk@daimi.au.dk> wrote in message
news:aho8aj$t7c$1@news.net.uni-c.dk...
> Det maa naesten vaere en rekort for en enkelt C++-fejlbesked.

Haha . Det må jeg sgu nok sige.

> Undefined first referenced
> symbol in file
>
__rwstd::__rb_tree<std::basic_string<char,std::char_traits<char>,std::alloca
tor<c
> har> >,std::basic_string<char,std::char_traits<char>,std::allocator<char>
>,__rws
[...]

Jeg kan specielt godt lide at linkeren forsøger at stille det op i en fin
tabel med indentering.

NU må man da fatte, at en C-linker ikke længere er relevant som back-end
maskineri til en C++-compiler.

De må sgu også snart se at få fingeren ud, hvis de mener noget med det-der
separat kompilering af template-kode. ("extern template <class T> class
Foo;")

Bjarke

---

"Bjarke Dahl Ebert" <bebert@worldonline.dk> wrote

[snip]
> NU må man da fatte, at en C-linker ikke længere er relevant som back-end
> maskineri til en C++-compiler.

Fejlmeldingerne er et "quality of implementation" spørgsmål, og der er klart
behov en dekryptering af fejlmeddelelsen, så man nemmere kan se at det er
__rb_tree<string, less>::iterator __rb_tree<string,
less>::erase(__rb_tree<string, less>::iterator,__rb_tree<string,
less>::iterator)
og
void __rb_tree<string, less>::__deallocate_buffers()
der mangler (og gerne også at det formodentlig stammer fra noget
"std::set<std::string>" eller "std::multiset<std::string>").

Der er intet til hinder for at gøre det med traditionel linker teknologi -
noget lignende gøres allerede, som Jonas Meyer Rasmussen har påpeget.

Det er dog ikke "blot" en C-linker, der typisk bruges til at linke C++
programmer med.
Du kan se af fejlmeldingen, at den allerede har foretaget demangling af
navnene - hvilket er specifikt for C++.
Linkeren vil også ofte have til opgave at eliminere duplikere template
instantieringer.
Men linkeren kan også langt mere avancerede opgaver. Der er f.eks. linkere
som foretager den egentlige generering af assembler instruktioner. Linkeren
har overblik over det samlede program, og kan dermed lave optimeringer på
tværs af compilation units, og bl.a. inline funktioner, der ikke er erklæret
"inline".

Teknologier hvor C++ implementeringen har bedre overblik over hele projektet
er naturligvis både spændende og nyttig, men ikke en forudsætning for at
give bedre fejlmeldinger.

> De må sgu også snart se at få fingeren ud, hvis de mener noget med det-der
> separat kompilering af template-kode. ("extern template <class T> class
> Foo;")

Du mener formodentlig "export" - i stedet for "extern" ?
Hvordan skulle separat kompilering i sig selv hjælpe fejlmeldingen i
forbindelse med "undefined symbols" ?
(Bemærk dog at jeg ikke har nævneværdig erfaring med "export" - få
mennesker i verden har - selv om jeg den sidste måned har haft en compiler
der understøtter "export")

Venlig hilsen

Mogens Hansen

---

"Bjarke Dahl Ebert" <bebert@worldonline.dk> writes:

> NU må man da fatte, at en C-linker ikke længere er relevant som back-end
> maskineri til en C++-compiler.

Det er tydeligvis en C++ linker, ellers havde fejlbeskedet ikke været
nær så læselig .

Det har egentlig heller ikke så meget med linkeren at gøre, compileren
kunne have givet en lignende besked (typisk når den ikke kan finde en
passende overloaded funktion).