---

Hej NG

Jeg har nedenstående 2 filer som giver følgende compileringsfejl:

Array.obj : error LNK2001: unresolved external symbol "public: __thiscall
person::person(int,int)" (??0person@@QAE@HH@Z)
Debug/Array.exe : fatal error LNK1120: 1 unresolved externals

Nogen der ved hvor min fejl er?

************************

Min Array.cpp fil
-----------------------------
#include "Array.h"
#include <iostream>
using namespace std;

void main(void)
{
person person(123, 122);
person.print();
}

Min Array.h fil
-----------------------------
#ifndef Array_H
#define Array_H

#include <string>
#include <iostream>
using namespace std;

class person
{
private:
int price;
int age;
public:
person(int p, int a);
void print();
};

void person::print(void)
{
cout<<price<<age<<endl;
}
#endif

---

FrI wrote:

> Min Array.cpp fil
> -----------------------------
> #include "Array.h"
> #include <iostream>
> using namespace std;
>
> void main(void)
> {
> person person(123, 122);
> person.print();
> }
>
> Min Array.h fil
> -----------------------------
> #ifndef Array_H
> #define Array_H
>
> #include <string>
> #include <iostream>
> using namespace std;
>
> class person
> {
> private:
> int price;
> int age;
> public:
> person(int p, int a);
> void print();
> };
>
> void person::print(void)
> {
> cout<<price<<age<<endl;
> }
> #endif

Uden at være den store C++-ekspert, kan jeg se, at der mangler en definition
for constructoren. Det er nødvendigt, når den bruger parametre.

Mvh.
--
_ __ _ __
| | __ | | | __
| |__ | _|| |__| | _|
|_| |__ |_| |___| http://www.fepe.dk

---

FrI wrote:
> Array.obj : error LNK2001: unresolved external symbol "public: __thiscall
> person::person(int,int)" (??0person@@QAE@HH@Z)
> Debug/Array.exe : fatal error LNK1120: 1 unresolved externals
>
> Nogen der ved hvor min fejl er?
Du har ikke defineret person::person(int,int)

> Min Array.h fil
> -----------------------------
> #ifndef Array_H
> #define Array_H
>
> #include <string>
> #include <iostream>
> using namespace std;

Der er ingen grund til at inkluderer <string> når den ikke bruges.
Du bør _aldrig_ have "using namespace std;" i en headerfil.

> void person::print(void)
> {
> cout<<price<<age<<endl;
> }

Hvorfor har du denne definition i din headerfil i stedet for i en cpp-fil?

Ivan Johansen

---

Ivan Johansen wrote:

>> #include <string>
>> #include <iostream>
>> using namespace std;
>
>
> Du bør _aldrig_ have "using namespace std;" i en headerfil.
>
Ja, lad os starte en lille "krig" om namespace's.
Som gammel C-programør har jeg svært ved at se noget fornuftigt formål
med namespace, og endnu mindre med at alle standard definitioner skal
puttes i et namespace. Jeg synes derfor at det give _meget_ mening at
putte en "using namespace std;" i en header-fil, så man er fri for at
bekymre sig mere om det.

/b

---

On Sun, 07 Sep 2003 13:49:13 +0200 Bertel Brander wrote:

>>> #include <string>
>>> #include <iostream>
>>> using namespace std;
>>
>>
>> Du bør _aldrig_ have "using namespace std;" i en headerfil.
>>
> Ja, lad os starte en lille "krig" om namespace's.
> Som gammel C-programør har jeg svært ved at se noget fornuftigt formål
> med namespace,
> ...

Har du aldrig som C-programmør været ude for at, du ikke kunne linke, da
du havde brugt to forskellige stykker kode, der brugte det samme navn
for en variabel/funktion?

--
Vil du gerne kunne afspille de CDere du køber?

http://www.digitalforbruger.dk/

---

Anders Bo Rasmussen wrote:

> On Sun, 07 Sep 2003 13:49:13 +0200 Bertel Brander wrote:
>
>
>>>>#include <string>
>>>>#include <iostream>
>>>>using namespace std;
>>>
>>>
>>>Du bør _aldrig_ have "using namespace std;" i en headerfil.
>>>
>>
>>Ja, lad os starte en lille "krig" om namespace's.
>>Som gammel C-programør har jeg svært ved at se noget fornuftigt formål
>>med namespace,
>>...
>
>
> Har du aldrig som C-programmør været ude for at, du ikke kunne linke, da
> du havde brugt to forskellige stykker kode, der brugte det samme navn
> for en variabel/funktion?
>
I fornuftigt designet kode: Nej.

/b

---

Bertel Brander skrev:

>> Har du aldrig som C-programmør været ude for at, du ikke kunne linke, da
>> du havde brugt to forskellige stykker kode, der brugte det samme navn
>> for en variabel/funktion?

>I fornuftigt designet kode: Nej.

Har du været med til at lave kode på titusindvis af linjer hvor
man inkluderer mange moduler fra forskellige kilder?

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

---

Bertel Lund Hansen wrote:

> Bertel Brander skrev:
>
>
>>>Har du aldrig som C-programmør været ude for at, du ikke kunne linke, da
>>>du havde brugt to forskellige stykker kode, der brugte det samme navn
>>>for en variabel/funktion?
>
>
>>I fornuftigt designet kode: Nej.
>
>
> Har du været med til at lave kode på titusindvis af linjer hvor
> man inkluderer mange moduler fra forskellige kilder?
>
Jeg har lavet kode til mobil telefoner i 10+ år (mest i C), ofte med
større mængder kode fra forskellige kilder, og har ikke haft problermer.

/b

---

"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:3f5b27f4$0$13270$edfadb0f@dread15.news.tele.dk...
> I fornuftigt designet kode: Nej.

Nu hænder det jo relativt ofte (i hvert fald for mig), at man inkluderer
header filer /
linker med libs man ikke selv har forfattet, og der er det rart med
namespaces.

Det ville også have været rart, hvis Win32 API'et på en eller anden måde
udkom i en ordenlig
wrappet version, så man undgik makroer og kunne undgå at eks. PlaySound var
definet til hhv. PlaySoundA/PlaySoundW og istedet var lagt i to forskellige
namespaces, eller
blot var overloadet. Jeg har mere end een gang været sidet relativt længe og
undret mig over
at den ikke kunne finde PlaySoundA i min lyd-wrapper.

- Michael Rasmussen

---

Michael Rasmussen wrote:
> "Bertel Brander" <bertel@post4.tele.dk> wrote in message
> news:3f5b27f4$0$13270$edfadb0f@dread15.news.tele.dk...
>
>>I fornuftigt designet kode: Nej.
>
>
> Nu hænder det jo relativt ofte (i hvert fald for mig), at man inkluderer
> header filer /
> linker med libs man ikke selv har forfattet, og der er det rart med
> namespaces.
Hvis man inkluderer c++ kode vil man normalt (hvis det er ordentlig
designet) oftest kun have brug for at inkludere en (eller nogle få)
klasser, så det eneste man ville kunne få problemer med er type navnet
på denne klasse.
Hvis man inkluderer C kode bør/vil man normalt lave en wrapper
klasse.
>
> Det ville også have været rart, hvis Win32 API'et på en eller anden måde
> udkom i en ordenlig
> wrappet version, så man undgik makroer og kunne undgå at eks. PlaySound var
> definet til hhv. PlaySoundA/PlaySoundW og istedet var lagt i to forskellige
> namespaces, eller
> blot var overloadet. Jeg har mere end een gang været sidet relativt længe og
> undret mig over
> at den ikke kunne finde PlaySoundA i min lyd-wrapper.
>
MFC og wxwindows er eksempler på wrappere om Win32 API'et, ingen af
disse bruger namespace.

/b

---

Bertel Brander wrote:
> Hvis man inkluderer c++ kode vil man normalt (hvis det er ordentlig
> designet) oftest kun have brug for at inkludere en (eller nogle få)
> klasser, så det eneste man ville kunne få problemer med er type navnet
> på denne klasse.

Det må være nogle meget små programmer du laver hvis de kun har nogle
enkelte klasser. Prøv f.eks. at kigge på Boost (http://boost.org). Jeg
vil gætte på at der er mindst 10.000 klasser og sikkert lige så mange
frie funktioner. Det bliver hurtigt svært at finde på et navn som ikke
er brugt i forvejen. Heldigvis ligger det hele i namespace boost.

> Hvis man inkluderer C kode bør/vil man normalt lave en wrapper
> klasse.
Hvorfor det? Det er da ingen grund til at lave en klasse til en funktion.


>> Det ville også have været rart, hvis Win32 API'et på en eller anden måde
>> udkom i en ordenlig
>> wrappet version
Jeg har også tit haft problemer med at Microsoft elsker makroer.

> MFC og wxwindows er eksempler på wrappere om Win32 API'et, ingen af
> disse bruger namespace.
Du mener forhåbentlig ikke at MFC er et godt designet bibliotek. Så vidt
jeg ved bruger MFC heller ikke templates, så det må vi også hellere lade
være med.


Jeg har været ude for at C kode skrevet af 3 forskellige personer brugte
de samme funktionsnavne. Løsningen blev at lave funktionerne static og
inkludere filerne i den fil hvor de blev brugt. Et namespace i C++ ville
være en langt mere elegant løsning.

Ivan Johansen

---

Dette svar er tænkt som et svar til alle indlæg om emnet siden mit
seneste indlæg.

Jeg mener ikke at man altid skal undlade at bruge namespace. Men
at man, når man vælger/ikke vælger at bruge namespace foretager man
et valg, som bør foretages på så kvalificeret grundlag som muligt.

Jeg er sikker på at der findes tilfælde hvor namespace er på sin plads,
men mener at det at påstå at man _aldrig_ må skrive "using namespace
std;" i en headerfil er lige så forket som at påstå at man _altid_
skal skrive det.

Specielt når det gælder std namespace'et mener jeg at der er god grund
til at inkludere det i sit globale namespace ved at bruge "using
namespace std;" da det definerer en del som bruges af det meste af ens
kode og som er tilgængelig for alle C++ platforme. For andre biblioteker
(f.ex Boost) er det mere tvivlsomt om man skal bruge en using i en
global headerfil, da de oftest kun bliver brugt af en mindre del af
programmet og ikke er tilgængelig altid.

Når man ser på alternativerne til "using namespace std;" er der (så vidt
jeg ved) kun to muligheder, at skrive:

std::cout << "Hello World";

eller:

using std::cout;
cout << "Hello World";

Ingen af disse er efter min ringe mening særlig attraktive.

/b

---

Bertel Brander wrote:
> Jeg mener ikke at man altid skal undlade at bruge namespace. Men
> at man, når man vælger/ikke vælger at bruge namespace foretager man
> et valg, som bør foretages på så kvalificeret grundlag som muligt.
Der er vi helt enige.


> Jeg er sikker på at der findes tilfælde hvor namespace er på sin plads,
> men mener at det at påstå at man _aldrig_ må skrive "using namespace
> std;" i en headerfil er lige så forket som at påstå at man _altid_
> skal skrive det.

Se More Exceptional C++ Item 40 for et godt eksempel på hvordan using
direktiv i headerfiler ødelægger andres kode.

> Specielt når det gælder std namespace'et mener jeg at der er god grund
> til at inkludere det i sit globale namespace ved at bruge "using
> namespace std;" da det definerer en del som bruges af det meste af ens
> kode og som er tilgængelig for alle C++ platforme.

Der er intet specielt ved namespace std. Det er ikke alle filer hvor jeg
bruger noget fra namespace std, så hvorfor skal jeg belemres med et
using direktiv fra en andens headerfil?

> std::cout << "Hello World";

Det er lige netop sådan jeg foretrækker det. Hvis du ikke kan lide det
må du gerne skrive "using namespace std;" i toppen af cpp-filen efter
alle includes, men aldrig i en headerfil jeg skal bruge.

Ivan Johansen

---

"Ivan Johansen" <NG3@padowan.dk> skrev:
>
> > std::cout << "Hello World";
>
> Det er lige netop sådan jeg foretrækker det.

Tsk, tsk. Her springer du over hvor gærdet er lavest. Du har godt nok
fortalt at cout kommer fra std (hvad det så end er i det givne scope),
men du vil da ikke lade det være op til Koenig lookup at gætte hvor <<
kommer fra? Du mener forhåbentlig:

::std:erator<<(::std::cout, "Hello world");

- Anders

---

Ivan Johansen wrote:

> Bertel Brander wrote:
>
>> Hvis man inkluderer c++ kode vil man normalt (hvis det er ordentlig
>> designet) oftest kun have brug for at inkludere en (eller nogle få)
>> klasser, så det eneste man ville kunne få problemer med er type navnet
>> på denne klasse.
>
>
> Det må være nogle meget små programmer du laver hvis de kun har nogle
> enkelte klasser. Prøv f.eks. at kigge på Boost (http://boost.org). Jeg
> vil gætte på at der er mindst 10.000 klasser og sikkert lige så mange
> frie funktioner. Det bliver hurtigt svært at finde på et navn som ikke
> er brugt i forvejen. Heldigvis ligger det hele i namespace boost.

Jeg håber ikke at man får smidt 10.000 klasser og lige så mange
funktioner i hovedet ved at inkludere en enkelt header-fil. Hvis
det er tilfældet vil jeg mene at det er en design fejl (i stil med
windows.h)

>
>> Hvis man inkluderer C kode bør/vil man normalt lave en wrapper
>> klasse.
>
>
>> MFC og wxwindows er eksempler på wrappere om Win32 API'et, ingen af
>> disse bruger namespace.
>
> Du mener forhåbentlig ikke at MFC er et godt designet bibliotek. Så vidt
> jeg ved bruger MFC heller ikke templates, så det må vi også hellere lade
> være med.
>

Jeg ved ikke om MFC er godt designet, jeg har ikke erfaring med ret
mange andre win32 api wrappere. På den anden side så bruger Bjarne selv
C++'s popularitet som argument for kvaliteten. Hvis det samme er
gældende for MFC kan det ikke være så dårligt. MFC er, så vidt jeg ved,
det mest brugte til at lave Windows applikationer.

/b

---

Bertel Brander wrote:
> Jeg håber ikke at man får smidt 10.000 klasser og lige så mange
> funktioner i hovedet ved at inkludere en enkelt header-fil. Hvis
> det er tilfældet vil jeg mene at det er en design fejl (i stil med
> windows.h)

Det kan godt være at du ikke får 10.000 klasser fra en enkelt headerfil,
men nu er det jo heller ikke unormalt at man inkluderer flere
headerfiler. Men jeg tror nu godt at man kan få op imod 1000 klasser med
ved at inkludere en header. Det er bestemt ikke dårligt design, men der
er ofte mange afhængigheder. Da det hele er templates ligger hele koden
i headerfiler. Men det er pakket pænt ind i adskillige namespaces.

> Jeg ved ikke om MFC er godt designet, jeg har ikke erfaring med ret
> mange andre win32 api wrappere. På den anden side så bruger Bjarne selv
> C++'s popularitet som argument for kvaliteten. Hvis det samme er
> gældende for MFC kan det ikke være så dårligt. MFC er, så vidt jeg ved,
> det mest brugte til at lave Windows applikationer.

Popularitet skyldes ikke altid kvalitet. Som det er blevet nævnt er MFC
gammelt og forældet. Det blev lavet længe før C++ blev standardiseret og
Microsoft har selv droppet MFC.

Ivan Johansen

---

Bertel Brander <bertel@post4.tele.dk> wrote in message

> Jeg ved ikke om MFC er godt designet, jeg har ikke erfaring med ret
> mange andre win32 api wrappere. På den anden side så bruger Bjarne selv
> C++'s popularitet som argument for kvaliteten.

Jeg tror aldrig at jeg har brugt C++ popularitet *ukvalifiseret* som
et argument. Det ville jo vaere latterligt. At mange bruger C++ viser
at det kan vaere nyttigt; at det blev saa populaert uden et
marketingsbuget en observation der kan bruges som del af et legitimt
argument.

> Hvis det samme er
> gældende for MFC kan det ikke være så dårligt. MFC er, så vidt jeg ved,
> det mest brugte til at lave Windows applikationer.

Men det er alligevel for daarligt.

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

---

Bjarne Stroustrup wrote:
> Bertel Brander <bertel@post4.tele.dk> wrote in message
>
>
>>Jeg ved ikke om MFC er godt designet, jeg har ikke erfaring med ret
>>mange andre win32 api wrappere. På den anden side så bruger Bjarne selv
>>C++'s popularitet som argument for kvaliteten.
>
>
> Jeg tror aldrig at jeg har brugt C++ popularitet *ukvalifiseret* som
> et argument. Det ville jo vaere latterligt. At mange bruger C++ viser
> at det kan vaere nyttigt; at det blev saa populaert uden et
> marketingsbuget en observation der kan bruges som del af et legitimt
> argument.

Du har helt ret, popularitet alene kan ikke bruges som målestok for
kvalitet. Det var ikke min intention at give intryk af at du skulle
have påstået det, hvis nogen har fået det indtryk, vil jeg hermed
beklage

Jeg skal for fremtiden være mere påpasselig med hvem jeg påstår
har sagt hvad.

/b

PS: Jeg kan ikke helt sige mig fri for at være en anelse beæret over
at Bjarne følger diskussion i denne NG.

---

"Bertel Brander" <bertel@post4.tele.dk> wrote

[8<8<8<]
> Hvis man inkluderer c++ kode vil man normalt (hvis det er ordentlig
> designet) oftest kun have brug for at inkludere en (eller nogle få)
> klasser, så det eneste man ville kunne få problemer med er type navnet
> på denne klasse.

Hvis den klasse man inkluderer bruger en anden klasse (eller funktion) i sin
implementering, risikerer man forsat navnesammefald når man linker, hvis man
andre har defineret en tilsvarende klasse (eller funktion).

[8<8<8<]
> MFC og wxwindows er eksempler på wrappere om Win32 API'et, ingen af
> disse bruger namespace.

Både MFC og wxWindows startede i 1992, hvor namespace ikke eksisterede i
C++.
Namespace blev diskuteret i 1991 i ANSI/ISO kommitteen, og det vedtaget at
det skulle med i C++ i 1993.
Derfor havde MFC og wxWindows ikke noget valg.

wxWindows navngiver alle sine klasser med prefix "wx".
At prefixe klasser var (og er for så vidt fortsat) et alternativ til
namespace.

MFC prefixer med klasserne med "C", og har vel nogenlunde med brute-force
sat sig på navne som CList.

Venlig hilsen

Mogens Hansen

---

"Bertel Brander" <bertel@post4.tele.dk> wrote in message
news:3f5b443b$0$54802$edfadb0f@dread11.news.tele.dk...
> Michael Rasmussen wrote:
> > "Bertel Brander" <bertel@post4.tele.dk> wrote in message
> > news:3f5b27f4$0$13270$edfadb0f@dread15.news.tele.dk...
> >
> >>I fornuftigt designet kode: Nej.
> >
> >
> > Nu hænder det jo relativt ofte (i hvert fald for mig), at man inkluderer
> > header filer /
> > linker med libs man ikke selv har forfattet, og der er det rart med
> > namespaces.
> Hvis man inkluderer c++ kode vil man normalt (hvis det er ordentlig
> designet) oftest kun have brug for at inkludere en (eller nogle få)
> klasser, så det eneste man ville kunne få problemer med er type navnet
> på denne klasse.
> Hvis man inkluderer C kode bør/vil man normalt lave en wrapper
> klasse.

Øh, de to wrappere du nævner nedenfor har de kun -få- klasser?
Hvis du mener det, tror jeg din definition af -få- afviger fra, hvad
gennemsnittet mener.

> > Det ville også have været rart, hvis Win32 API'et på en eller anden måde
> > udkom i en ordenlig
> > wrappet version, så man undgik makroer og kunne undgå at eks. PlaySound
var
> > definet til hhv. PlaySoundA/PlaySoundW og istedet var lagt i to
forskellige
> > namespaces, eller
> > blot var overloadet. Jeg har mere end een gang været sidet relativt
længe og
> > undret mig over
> > at den ikke kunne finde PlaySoundA i min lyd-wrapper.
> >
> MFC og wxwindows er eksempler på wrappere om Win32 API'et, ingen af
> disse bruger namespace.

Som de også bliver kritiseret for. MFC er mega gammelt, og formeligt på vej
ud, nu hvor de
har fået alt deres .net ståhej?
De har lavet et pænere alternativ med WTL, som netop _bruger_ namespaces.
wxwindows er også en gammel sag, og man kan da undre sig hvorfor de ikke
bruger namespaces - I praksis betyder det blot at de laver et prefix på wx
på
alle deres klasser osv.
I sidste ende er der eneste forskel vel, at hvis det var i et namespace,
kunne
du åbne det og undlade wx:: - det kan du ikke hvis du bruger prefix på
navnet.

mvh Jonas

---

"Michael Rasmussen" <michael@mediamobsters.com> wrote

[8<8<8<]
> Det ville også have været rart, hvis Win32 API'et på en eller anden måde
> udkom i en ordenlig
> wrappet version, så man undgik makroer og kunne undgå at eks. PlaySound
var
> definet til hhv. PlaySoundA/PlaySoundW og istedet var lagt i to
forskellige
> namespaces, eller
> blot var overloadet. Jeg har mere end een gang været sidet relativt længe
og
> undret mig over
> at den ikke kunne finde PlaySoundA i min lyd-wrapper.

Ja, der har jeg også ofte været. Det er helt ufatteligt at man skal have den
slags problemer!

Problemet er dog ikke namespace, men at Microsoft i ufattelig stor
udstrækning har benyttet sig af preprocessor makroer.
I C++ kunne samme funktionalitet langt bedre have været opnået med et par
inlinet funktioner og som du som du skriver funktions overload.

Venlig hilsen

Mogens Hansen

---

"Bertel Brander" <bertel@post4.tele.dk> wrote
> Ivan Johansen wrote:
>
> >> #include <string>
> >> #include <iostream>
> >> using namespace std;
> >
> >
> > Du bør _aldrig_ have "using namespace std;" i en headerfil.
> >
> Ja, lad os starte en lille "krig" om namespace's.
> Som gammel C-programør har jeg svært ved at se noget fornuftigt formål
> med namespace, og endnu mindre med at alle standard definitioner skal
> puttes i et namespace. Jeg synes derfor at det give _meget_ mening at
> putte en "using namespace std;" i en header-fil, så man er fri for at
> bekymre sig mere om det.

At skrive
using namespace std;
i en headerfil sætter stort set namespace mekanismen ud af kraft.

Det vil normalt blive betragtet som:
* Kode skrevet af en uerfaren C++ programmør
* En bevidst ondsindet handling
I begge tilfælde vil det være med til at man overvejer en ekstra gang inden
bruger kode fra en sådan kilde.

Et eksempel hvor det vil kunne give problemer er i forbindelse med brug af
Boost.
Boost Filesystem indeholder f.eks. klasser der er varianter af hvad man
finder i <fstream>.
De adskiller sig bl.a. ved at ligge i et andet namespace (og naturligvis
også noget funktionalitet).
Man løber en alvorlig risiko for at kode holder op med at virke.

Namespace findes af en god grund - nemlig at undgå navnesammenfald, når man
bruger kode fra mange steder i et program.
Tænk f.eks. på hvor mange date og LinkedList klasser, der gennem har
eksisteret i forskellige biblioteker.

Selv hvis man ikke bryder sig om namespaces, er det et faktum at de findes
og bruges i C++.
Det fører ikke noget godt med sig at prøve at undergrave det.

For mig svarer det lidt til, hvis man ikke bryder sig om indkapsling i
klasser så skriver
#define private public
#define protedted public
i sine header filer.
Så er man fri for at bekymre sig mere om indkapsling.


Venlig hilsen

Mogens Hansen

---

Bertel Brander wrote:
> Ja, lad os starte en lille "krig" om namespace's.
Så kører vi kanonerne i stilling.

> Som gammel C-programør har jeg svært ved at se noget fornuftigt formål
> med namespace,
Det er netop derfor at man skal starte med at lære C++ og derefter C og
ikke omvendt.

> og endnu mindre med at alle standard definitioner skal
> puttes i et namespace.
En af de mange fordele er at du kan have to implementationer af standard
library. Du kan f.eks. bruge STLport selv om compileren i forvejen har
et standard library, fordi STLport kan lægges i namespace _STL mens det
oprindelige ligger i namespace std.

> Jeg synes derfor at det give _meget_ mening at
> putte en "using namespace std;" i en header-fil, så man er fri for at
> bekymre sig mere om det.
Men den som bruger koden skal bekymre sig om det. Du er ikke alene i
verden og bør tænke på andre. Ham der skal bruge din headerfil vil
sikkert ikke have hele namespace systemet sat ud af kraft. En anden ting
er at det vil gøre en forskel hvilken rækkefølge du inkluderer
headerfiler. Det kan diskuteres om man bør bruge using direktiver i
cpp-filer, men man gør det _aldrig_ i headerfiler.

Som Mogens siger vil jeg også undgå kode skrevet af en der sætter hele
namespace systemet ud af kraft hvis jeg bruger hans kode.

Ivan Johansen

---

"Ivan Johansen" <NG3@padowan.dk> skrev:
>
> Som Mogens siger vil jeg også undgå kode skrevet af en der sætter hele
> namespace systemet ud af kraft hvis jeg bruger hans kode.

Naturligvis skal man lade være med at sætte en facilitet, som man har
brug for, ud af kraft.

Men hvis man nu ikke har brug for faciliten?

I min praksis forekommer navnesammenfald utroligt sjældent - to
tilfælde på seks år, og de viste sig begge at være kopier af den samme
kode. Begge navnesammenfald var nemme at håndtere, også uden
namespaces.

Namespaces løser et problem jeg ikke har. Jeg har ladet mig fortælle
at andre har problemer med navnesammenfald[1], og så er det da godt at
namespaces findes til at hjælpe dem; men det er ikke nogen grund til
at Bertel og jeg skal bære omkostningerne for noget vi ikke har gavn
af.

YAGNI.

mvh. Anders

[1] Men jeg har nu aldrig hørt nogen konkrete war stories.

---

Anders J. Munch wrote:
> I min praksis forekommer navnesammenfald utroligt sjældent - to
> tilfælde på seks år, og de viste sig begge at være kopier af den samme
> kode. Begge navnesammenfald var nemme at håndtere, også uden
> namespaces.
Jeg ser navnesammenfald meget ofte. Det er meget nemt at komme til at
bruge samme navn til en konstant eller enum som Borland allerede har
brugt i VCL. Heldigvis ligger VCL i adskillige namespaces hvilket løser
problemet.

> Namespaces løser et problem jeg ikke har. Jeg har ladet mig fortælle
> at andre har problemer med navnesammenfald[1], og så er det da godt at
> namespaces findes til at hjælpe dem; men det er ikke nogen grund til
> at Bertel og jeg skal bære omkostningerne for noget vi ikke har gavn
> af.
Det er ikke den der skriver koden der får problemer, det er den der
bruger den. Jeg kan selvfølgelig være ligeglad med din kode så længe jeg
ikke skal bruge den. Men hvis jeg skal tilgå noget kode du har skrevet
skal jeg inkludere din headerfil, hvilket betyder at jeg får
omkostningerne for noget du ikke har gavn af.

Se også More Exceptional C++ Item 40, hvor der blandt andet står:
"Namespace Rule #1: Never write using-directives in header files."

Ivan Johansen

---

"Ivan Johansen" <NG3@padowan.dk> skrev:
> Anders J. Munch wrote:
> > I min praksis forekommer navnesammenfald utroligt sjældent - to
> > tilfælde på seks år, og de viste sig begge at være kopier af den samme
> > kode. Begge navnesammenfald var nemme at håndtere, også uden
> > namespaces.
> Jeg ser navnesammenfald meget ofte. Det er meget nemt at komme til at
> bruge samme navn til en konstant eller enum som Borland allerede har
> brugt i VCL. Heldigvis ligger VCL i adskillige namespaces hvilket løser
> problemet.

Sjovt, jeg bruger også VCL, og det er aldrig sket for mig.

> Det er ikke den der skriver koden der får problemer, det er den der
> bruger den. Jeg kan selvfølgelig være ligeglad med din kode så længe jeg
> ikke skal bruge den. Men hvis jeg skal tilgå noget kode du har skrevet
> skal jeg inkludere din headerfil, hvilket betyder at jeg får
> omkostningerne for noget du ikke har gavn af.

s/min/Bertels/, jeg bruger "using namespace" i implementationsfiler
men ikke i headerfiler.

Hvad vigtigere er, ja, du kan være ligeglad med min kode. YAGNI. Den
dag du får brug for adgang til min kode, så finder vi en
løsning. Måske lægger jeg så mine egne funktioner og klasser i et
eller flere namespaces. Men det ville være dumt af mig at bruge tid på
det nu.

mvh. Anders

---

Anders J. Munch wrote:
> Hvad vigtigere er, ja, du kan være ligeglad med min kode. YAGNI. Den
> dag du får brug for adgang til min kode, så finder vi en
> løsning. Måske lægger jeg så mine egne funktioner og klasser i et
> eller flere namespaces. Men det ville være dumt af mig at bruge tid på
> det nu.

Det er aldrig spild at tid at skrive pænt opbygget kode. Men så længe du
ikke skriver "using namespace" i en header jeg skal bruger er jeg glad.

Ivan Johansen

---

Anders J. Munch wrote:

>
> Namespaces løser et problem jeg ikke har.

Jeg kan ikke være mere enig.

/b

---

Ivan Johansen <NG3@padowan.dk> writes:

> Du bør _aldrig_ have "using namespace std;" i en headerfil.

Hvis det er en del af en applikation hvor "using namespace std;" er
politik i implementationsfilerne, har jeg svært ved at se problemet.

Hvis det er en del af interfacet i et bibliotek med tredjepartsbrugere
er det selvfølgelig uhøfligt at tvinge dem til at sluge namespace std.

---

FrI wrote:
> Hej NG
>
> Jeg har nedenstående 2 filer som giver følgende compileringsfejl:
>
> Array.obj : error LNK2001: unresolved external symbol "public: __thiscall
> person::person(int,int)" (??0person@@QAE@HH@Z)
> Debug/Array.exe : fatal error LNK1120: 1 unresolved externals
>
> Nogen der ved hvor min fejl er?
>
> ************************
>
> Min Array.cpp fil
> -----------------------------
> #include "Array.h"
> #include <iostream>
> using namespace std;
>
> void main(void)
> {
> person person(123, 122);
> person.print();
> }
>
> Min Array.h fil
> -----------------------------
> #ifndef Array_H
> #define Array_H
>
> #include <string>
> #include <iostream>
> using namespace std;
>
> class person
> {
> private:
> int price;
> int age;
> public:
> person(int p, int a);
> void print();
> };
>
Du mangler en definition af person::person(int p, int a), f.ex:
person::person(int p, int a)
{
price = p;
age = a;
}

eller:

person::person(int p, int a) : price(p), age(a)
{

}

/b