/ Forside / Teknologi / Udvikling / C/C++ / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
C/C++
#NavnPoint
BertelBra.. 2425
pmbruun 695
Master_of.. 501
jdjespers.. 500
kyllekylle 500
Bech_bb 500
scootergr.. 300
gibson 300
molokyle 287
10  strarup 270
Header-fil problemer...
Fra : Torben Wridt


Dato : 10-05-01 07:57

Hej!!
Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.

Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000. Det er
et elektronik-modul som drives via en LPT-port og som indeholder 16 digitale
kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er så,
at signalerne fra printerporten "konverteres" til en IIC-bus.
Til at foretage den egentlige timing etc. af denne bus medleverer Velleman
bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har indtil
dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
"fremtidssikkert" at konvertere til C!!
Og så startede mine problemer....Har ikke før selv skrevet endsige
implementeret "fremmede" include-filer!

Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel" version
3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har jeg
smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis compilerens
opsætning mht. dirs)

Med kittet er der en hel del demo-software. Problemet er, at jeg ikke kan få
disse eksempler til at funke. Compileren fejl-melder, at den ikke kan finde
de funktionskald som er indeholdt i headerfilen.....

Æhhh......, hvad gør JEG forkert????

Håber ikke, at mit spørgsmål er alt for dumt. Bær over med mig...

Venligst Torben W.





 
 
Dansoft Denmark (10-05-2001)
Kommentar
Fra : Dansoft Denmark


Dato : 10-05-01 21:53



--

"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9dde6a$ss4$1@news.net.uni-c.dk...
> Hej!!
> Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.
>
> Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000. Det
er
> et elektronik-modul som drives via en LPT-port og som indeholder 16
digitale
> kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er
så,
> at signalerne fra printerporten "konverteres" til en IIC-bus.
> Til at foretage den egentlige timing etc. af denne bus medleverer Velleman
> bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har indtil
> dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
> "fremtidssikkert" at konvertere til C!!
> Og så startede mine problemer....Har ikke før selv skrevet endsige
> implementeret "fremmede" include-filer!
>
> Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel"
version
> 3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har jeg
> smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
> hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis compilerens
> opsætning mht. dirs)
>
> Med kittet er der en hel del demo-software. Problemet er, at jeg ikke kan

> disse eksempler til at funke. Compileren fejl-melder, at den ikke kan
finde
> de funktionskald som er indeholdt i headerfilen.....
>
> Æhhh......, hvad gør JEG forkert????
>
Hej
Har du husket at inkludere din header fil i I2C.C ved at skrive #include
<I2C.h> i starten af din C file?

Hilsen Torben

E-Mail: dansoft-denmark@dansoft-denmark

URL: http://www.dansoft-denmark.dk


Torben Wridt (14-05-2001)
Kommentar
Fra : Torben Wridt


Dato : 14-05-01 09:58


Dansoft Denmark <dansoft-denmark@dansoft-denmark.dk> skrev i en
nyhedsmeddelelse:e3DK6.321$qY.11272@news.get2net.dk...
>
>
> --
>
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9dde6a$ss4$1@news.net.uni-c.dk...
> > Hej!!
> > Er ny her i NG, og starter op med et sikkert noget "dumt" spørgsmål, hi.
> >
> > Har igennem flere år brugt et kit fra fa. Velleman som hedder K-8000.
Det
> er
> > et elektronik-modul som drives via en LPT-port og som indeholder 16
> digitale
> > kanaler, og et antal analoge AD'ere og ditto DA'ere. "Hemmeligheden" er
> så,
> > at signalerne fra printerporten "konverteres" til en IIC-bus.
> > Til at foretage den egentlige timing etc. af denne bus medleverer
Velleman
> > bl.a. en unit-fil til Pascal-folk, og en header-fil til C-folk. Har
indtil
> > dato brugt modulet i.forb. med Pascal-programmer, men fandt det mere
> > "fremtidssikkert" at konvertere til C!!
> > Og så startede mine problemer....Har ikke før selv skrevet endsige
> > implementeret "fremmede" include-filer!
> >
> > Den medfølgende "I2C.C" har jeg compilet med compilerens(en "gammel"
> version
> > 3) "library"-funktion. De derved generede I2C.lib og I2C-obj filer har
jeg
> > smidt ind i compilerens "library"-dir. Den medfølgende header-fil, som
> > hedder I2C.h er placeret i "header"-dir. (Matcher naturligvis
compilerens
> > opsætning mht. dirs)
> >
> > Med kittet er der en hel del demo-software. Problemet er, at jeg ikke
kan
> få
> > disse eksempler til at funke. Compileren fejl-melder, at den ikke kan
> finde
> > de funktionskald som er indeholdt i headerfilen.....
> >
> > Æhhh......, hvad gør JEG forkert????
> >
> Hej
> Har du husket at inkludere din header fil i I2C.C ved at skrive #include
> <I2C.h> i starten af din C file?
>
> Hilsen Torben
>
> E-Mail: dansoft-denmark@dansoft-denmark
>
> URL: http://www.dansoft-denmark.dk
>

Mange tak for dit hurtige svar!
Jeps, jeg har included I2C-headerfilen i I2C.c inden denne blev compilet.
Se evt. mit indlæg til en anden der har svaret!

Mange tak!

Mvh Torben.



Richard Flamsholt (11-05-2001)
Kommentar
Fra : Richard Flamsholt


Dato : 11-05-01 00:23

"Torben Wridt" <oz6tw@qsl.net> skrev:
>Compileren fejl-melder, at den ikke kan finde
>de funktionskald som er indeholdt i headerfilen.....

Der kan være utallige årsager, så derfor:
Hvad fejl-melder compileren helt præcis?

--
Richard Flamsholt
richard@flamsholt.dk - www.richard.flamsholt.dk

Torben Wridt (14-05-2001)
Kommentar
Fra : Torben Wridt


Dato : 14-05-01 10:04


Richard Flamsholt <richard@flamsholt.dk> skrev i en
nyhedsmeddelelse:bi8mftsf8o5fs2asiv1t6o4v9lglb8t0kv@sunsite.auc.dk...
> "Torben Wridt" <oz6tw@qsl.net> skrev:
> >Compileren fejl-melder, at den ikke kan finde
> >de funktionskald som er indeholdt i headerfilen.....
>
> Der kan være utallige årsager, så derfor:
> Hvad fejl-melder compileren helt præcis?
>
> --
> Richard Flamsholt
> richard@flamsholt.dk - www.richard.flamsholt.dk

Hej, og tak for din ulejlighed med at svare!
Et eksempel:
Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
Når jeg forsøger at compile fås følgende fejl-melding:
"*linker error: Undefined symbol _SelectI2CprinterPort in module ........"
(Bemærk den tilførte underscore)
Jeg benytter en Turbo C++ version 3, gammel, men normal OK.

Øh....., leder det dig ind på noget spor?

Mvh, en snart noget gråhåret, ))




Mogens Hansen (14-05-2001)
Kommentar
Fra : Mogens Hansen


Dato : 14-05-01 19:47

Hej Torben,
"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9do74s$eu4$1@news.net.uni-c.dk...
> Et eksempel:
> Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
> Når jeg forsøger at compile fås følgende fejl-melding:
> "*linker error: Undefined symbol _SelectI2CprinterPort in module ........"
> (Bemærk den tilførte underscore)
> Jeg benytter en Turbo C++ version 3, gammel, men normal OK.

Det er DOS ?

>
> Øh....., leder det dig ind på noget spor?

Du skal bruge 2 ting:
1. En headerfil - den har du allerede
2. En implementering - C-fil, OBJ-fil eller LIB-fil.

Compileren (linkeren) har svært ved at finde implementeringen.

Du har, at dømme efter dit oprindelige inlæg, en "i2c.c" fil, som indeholder
implementeringen.
Det at du lægger OBJ-filen eller LIB-filen i compilerens library bibliotek
gør _ikke_ at compileren kan finde dem.
Du skal includere dem i dit projekt. Det nemmeste er formodentlig at
includere source-filen "i2c.c" filen i dit projekt, så burde der være en
chance for at compileren og linkeren klare resten.

Inkluderer du headerfilen i en C eller en C++ fil ? (Det _kan_ spille en
rolle for hvilket navn linkeren leder efter - afhængigt af hvordan
headerfilen er lavet)

Venlig hilsen

Mogens Hansen



Torben Wridt (15-05-2001)
Kommentar
Fra : Torben Wridt


Dato : 15-05-01 08:47


Mogens Hansen <mogens_h@dk-online.dk> skrev i en
nyhedsmeddelelse:9dpali$2ur$1@news.cybercity.dk...
> Hej Torben,
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9do74s$eu4$1@news.net.uni-c.dk...
> > Et eksempel:
> > Et funktionskald fra header-filen kunne være "SelectI2CprinterPort"
> > Når jeg forsøger at compile fås følgende fejl-melding:
> > "*linker error: Undefined symbol _SelectI2CprinterPort in module
........."
> > (Bemærk den tilførte underscore)
> > Jeg benytter en Turbo C++ version 3, gammel, men normal OK.
>
> Det er DOS ?
>
> >
> > Øh....., leder det dig ind på noget spor?
>
> Du skal bruge 2 ting:
> 1. En headerfil - den har du allerede
> 2. En implementering - C-fil, OBJ-fil eller LIB-fil.
>
Jeps! som du har bemærket er implementeringen i en i2c.c-fil.


> Compileren (linkeren) har svært ved at finde implementeringen.
>
> Du har, at dømme efter dit oprindelige inlæg, en "i2c.c" fil, som
indeholder
> implementeringen.
> Det at du lægger OBJ-filen eller LIB-filen i compilerens library bibliotek
> gør _ikke_ at compileren kan finde dem.
> Du skal includere dem i dit projekt. Det nemmeste er formodentlig at
> includere source-filen "i2c.c" filen i dit projekt, så burde der være en
> chance for at compileren og linkeren klare resten.
>
Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
problemer(det burde jeg vel have omtalt, hm).
Men det betyder vel også, at min compilede exe-fil bliver større end
nødvendigt?!
(i2c.h-filen indeholder egentlig kun definitions og prototyping).


> Inkluderer du headerfilen i en C eller en C++ fil ? (Det _kan_ spille en
> rolle for hvilket navn linkeren leder efter - afhængigt af hvordan
> headerfilen er lavet)
>
Det foregår altsammen i C.

> Venlig hilsen
>
> Mogens Hansen
>

Kære Mogens Hansen!!
Du skal have tak for dit konstruktive indlæg. Det blev jeg meget glad for.
Som du nok aner, er jeg ikke særlig gammel
hvad angår C-sproget. Har benyttet Pascal indtil for ca. 1 år siden, hi.

Mangen venlige hilsner!
Torben W.




Mogens Hansen (15-05-2001)
Kommentar
Fra : Mogens Hansen


Dato : 15-05-01 10:27

Hej Torben
"Torben Wridt" <oz6tw@qsl.net> wrote in message
news:9dqn0f$re4$1@news.net.uni-c.dk...
> >
> Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
> problemer(det burde jeg vel have omtalt, hm).
> Men det betyder vel også, at min compilede exe-fil bliver større end
> nødvendigt?!

Den bliver større - men ikke større end _nødvendigt_ (altså under
forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
du efter alt at dømme).
Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.

Venlig hilsen

Mogens Hansen



Torben Wridt (15-05-2001)
Kommentar
Fra : Torben Wridt


Dato : 15-05-01 10:34


Mogens Hansen <mogens_h@dk-online.dk> skrev i en
nyhedsmeddelelse:3b00f652$1@lxcs1.manbw.dk...
> Hej Torben
> "Torben Wridt" <oz6tw@qsl.net> wrote in message
> news:9dqn0f$re4$1@news.net.uni-c.dk...
> > >
> > Klart nok!! Hvis jeg includer i2c.c filen i mit projekt er der ingen
> > problemer(det burde jeg vel have omtalt, hm).
> > Men det betyder vel også, at min compilede exe-fil bliver større end
> > nødvendigt?!
>
> Den bliver større - men ikke større end _nødvendigt_ (altså under
> forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
> du efter alt at dømme).
> Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.
>
> Venlig hilsen
>
> Mogens Hansen
>

OK!! Mange tak for dine klare ord!!! Herligt når nettet bliver brugt på
denne måde!
Mange venlige hilsner, Torben Wridt, Middelfart.




Byrial Jensen (19-05-2001)
Kommentar
Fra : Byrial Jensen


Dato : 19-05-01 08:53

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>Den bliver større - men ikke større end _nødvendigt_ (altså under
>forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det har
>du efter alt at dømme).
>Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det samme.

Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
nøjes med at medlinke de funktioner som rent faktisk bruges fra en
LIB-fil.

Mogens Hansen (19-05-2001)
Kommentar
Fra : Mogens Hansen


Dato : 19-05-01 17:18

Hej Byrial,
"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:slrn9gc92u.kv.bjensen@ask.ask...
> Mogens Hansen <mogens_h@dk-online.dk> skrev:
> >Den bliver større - men ikke større end _nødvendigt_ (altså under
> >forudsætning af at du har brug for funktionaliteten i "i2c.c" - og det
har
> >du efter alt at dømme).
> >Og ikke større end hvis du bruger LIB- eller OBJ-filer - det er det
samme.
>
> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
> LIB-fil.

Det er _ikke_ nødvendigvis rigtigt hvad du siger.
Der er en lille grund til at sige tværtimod - ikke mindst på den i denne
tråd omtalte platform (MS-DOS og Turbo C++ V3.0).
Hvor meget og hvor lidt der kommer med fra en LIB-fil er platforms
afhængigt - det er ikke defineret i sprogstandarden.

Der er _ikke_ noget krav om at alle funktioner i en source-fil linkes med,
hvis de ikke bliver refereret.
Se f.eks. compiler option /Gy (Enable Function-Level Linking) i Micrsoft
Visual C++ (fra V5 og fremefter, så vidt jeg husker).
Selv ikke-kaldte virtuelle funktioner behøves ikke at blive linket med,
selvom de egentlig bliver refereret fra den virtuelle funktionstabel (på en
typisk implementation). Få compilere/linkere har dog implementeret denne
optimering (Sybase Watcom C++ 10.0 gjorde, og det er så vidt jeg er
orienteret ved gcc at implementere det).

De typiske "simple" LIB implementering som jeg har set, virker på den måde
at hvis een funktion i en compilation unit bliver _alle_ funktionerne i den
compilation unit medtaget. For at opnå den effekt som du snakker om, gør
run-time library implementeringerne typisk det at de laver een compilation
unit pr. funktion (f.eks. een for "strcpy", een for "strcmp" etc.).
Det er således ikke en egenskab ved compiler/linker, men partitioneringen af
library implementationen.

Det som jeg har set, er at linkeren tager et givent kode-segment med, hvis
een funktion er refereret i den. Compileren kan så vælge at lægge hver
funktion i en given compilation unit i separate kode-segmenter (f.eks.
"Enable Function-Level Linking" optionen). Herved bliver linkeren i stand
til at kun linke netop de funktioner, der faktiske bliver refereret, med.
Dette er uafhængigt af om linkeren linker en LIB-fil eller en OBJ-fil med.

Med hensyn til den i denne tråd omtalte platform - MS-DOS - vil compilerene
typisk lægge _alle_ funktioner i en given compilation unit i samme
kode-segment, fordi det giver mulighed for at lave "near call" i stedet for
"far call", hvilket performancemæssigt er at foretrække.
Jeg er derfor rimelig sikker på at det er rigtigt når jeg sagde "Og ikke
større end hvis du bruger LIB- eller OBJ-filer - det er det samme".
Jeg har _ikke_ installeret min gode gamle Borland C++ V3.1 (som er det
nærmeste jeg har) for at verificere det.
Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed som
du kan _forestille_ dig ?

Det betyder _ikke_ at anvendelsen af LIB-filer og source-filer (og
OBJ-filer) er _fuldstændig_ ækvivalent.
Jeg har f.eks. set at hvis en source-fil indeholder et global objekt, som
ikke bliver refereret (ved navn) fra andre steder, vil det objekt blive
linket med, hvis man angiver OBJ-filen til linkeren, men objektet vil _ikke_
blive linket med, hvis det ligger i en LIB-fil.

Venlig hilsen

Mogens Hansen























Byrial Jensen (20-05-2001)
Kommentar
Fra : Byrial Jensen


Dato : 20-05-01 07:44

Mogens Hansen <mogens_h@dk-online.dk> skrev:
>Hej Byrial,
>"Byrial Jensen" <bjensen@nospam.dk> wrote in message
>>
>> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
>> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
>> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
>> LIB-fil.
>
>Det er _ikke_ nødvendigvis rigtigt hvad du siger.
>[...]
>Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed som
>du kan _forestille_ dig ?

Hej Mogens,

Jeg er helt enig i alle de betragtninger som jeg har klippet væk
ovenfor. Prøv at læse mit første indlæg igen: Jeg skrev netop at
det er en /mulighed/ at en linker kan nøjes med at udvælge enkelte
funktioner fra bibliotek. Jeg har ingen viden om hvordan den
oprindelige spørgers programmeringværtøjer er lavet med hensyn til
dette.

Mogens Hansen (20-05-2001)
Kommentar
Fra : Mogens Hansen


Dato : 20-05-01 08:53

Hej Byrial,

"Byrial Jensen" <bjensen@nospam.dk> wrote in message
news:slrn9gepl1.lk.bjensen@ask.ask...
> Mogens Hansen <mogens_h@dk-online.dk> skrev:
> >Hej Byrial,
> >"Byrial Jensen" <bjensen@nospam.dk> wrote in message
> >>
> >> Den bliver måske større end hvis han bruger LIB-filer, hvis han ikke
> >> bruger alle funktionerne i i2c.c, og hvis den linker han bruger, kan
> >> nøjes med at medlinke de funktioner som rent faktisk bruges fra en
> >> LIB-fil.
> >
> >Det er _ikke_ nødvendigvis rigtigt hvad du siger.
> >[...]
> >Har du _konkret_ _viden_ om at det er forkert - eller er det en mulighed
som
> >du kan _forestille_ dig ?
>
> Hej Mogens,
>
> Jeg er helt enig i alle de betragtninger som jeg har klippet væk
> ovenfor. Prøv at læse mit første indlæg igen: Jeg skrev netop at
> det er en /mulighed/ at en linker kan nøjes med at udvælge enkelte
> funktioner fra bibliotek. Jeg har ingen viden om hvordan den

Jeg læste (og læser fortsat) dit indlæg således at der er et performance
argument (program størrelse) for at bruge LIB-filer i stedet for
source-filen direkte, hvilket jeg ikke mener særligt ofte (afhængig af
platform) er tilfældet.

Venlig hilsen

Mogens Hansen



Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408847
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste