[C++] Var aanpassen in andere unit

[Verwijderd]

Kan ik een variabele (een int of een string) aanroepen/bewerken vanuit een andere unit dan waar die gedeclareerd is?

In unit A heb ik een stringA gedeclareerd, en in unit B voer ik iets uit waardoor ik de string in unit A wil veranderen.

Kan dit, en hoe?

Ik kan niet zomaar in unit B zeggen: stingA = "blabla";

[ Voor 0% gewijzigd door Verwijderd op 09-09-2002 10:14 . Reden: iets duidelijker ]

[Janoz]

ja.

[whoami]

Het kan....
Ik denk dat je eens op het keyword extern moet gaan zoeken ....

_{Niet happen als ik verkeerd ben ofzo, C++ is al een tijd geleden...}

[Pooh]

unit?

iets serieuzer:
Tipje: Ga eens een boek lezen. Kost je €20 voor het lidmaatschap van de bibiliotheek, of €80 als je d'r een koopt, maar daar leer je veel meer van.

[whoami]

[quote]Poohbear schreef op 09 september 2002 @ 10:17:
unit?



C++ Builder..... Erfenis (niet echt het goede woord) van Delphi en de VCL.

[Pooh]

whoami schreef op 09 september 2002 @ 10:20:
[...]
C++ Builder..... Erfenis (niet echt het goede woord) van Delphi en de VCL.

En het is? Gewoon een class? Een zelfstandig gecompiled geheel? Een zelfstandig gelinkt geheel?

[whoami]

Een unit in CPP Builder is imho een cpp-file met bijhorende header. Het kan dus een class zijn...
* whoami weet de juiste C++ term er niet meer van.
* whoami is brak vandaag.

[Creepy]

Een unit is één geheel (in C(++) is de combo .h en .c ongeveer hetzelfde).
Een unit kan natuurlijk wel weer gebruik maken van andere units.

In Pascal kan dat op source nivo zijn (unitnaam.pas) en in Delphi (=Object Pascal)is het ook mogelijk om een gecompileerde unit uit te wisselen (unit.dcu DCU= Delphi Compiled Unit).

Overigens is de naam UNIT geen overerving van Delphi en de VCL maar van de taal Pascal zelf. Het hoofdbestand (waarin het programma daadwerkelijk start.. zie dit als het bestand waarin in C de functie main() zit) begint met het keyword program of library. Elke andere file die word geinclude (uses in Pascal) begint altijd met het keyword unit.

edit: Wat de topicstarter lijkt te willen kan in Pascal (en dus ook Delphi) op de volgende manier)

test.dpr:

code:

Program test

uses globals;

begin
        writeln(globalstring);
     globalstring:='Aangepast';
      writeln(globalstring);
end;

globals.pas

code:

unit globals;

interface

var globalstring: string;

implementation

var localunitstring: string; // deze is niet in een andere unit te gebruiken.

end.

[whoami]

Creepy schreef op 09 september 2002 @ 11:03:

Overigens is de naam UNIT geen overerving van Delphi en de VCL maar van de taal Pascal zelf. Het hoofdbestand (waarin het programma daadwerkelijk start.. zie dit als het bestand waarin in C de functie main() zit) begint met het keyword program of library. Elke andere file die word geinclude (uses in Pascal) begint altijd met het keyword unit.

Mjah....
Ik wou gewoon maar zeggen dat Delphi ( OO Pascal) en C++ Builder dezelfde VCL gebruiken. C++ Builder gebruikt dus die VCL die in OOPascal geschreven is, vandaar dat die dingen in C Builder ook units heten.

[Creepy]

Is in C++ Builder dan ook de source van de VCL op te vragen zoals in Delphi?? In delphi met ctrl op een Tiets o.i.d klikken en de desbetreffende unit komt op in je code editor. Of wordt met C++ Builder ook de Delphi compiler meegelevert?

[Verwijderd]

--------=[ UNIT 1 ]=----------------------------------------------
hallo.h:

C++:

int global_hallo_var;
#include "hallo.cpp" // niet echt van toepassing....

--------=[ UNIT 2 ]=----------------------------------------------
doei.h:

C++:

int global_doei_func();
#include "doei.cpp"

doei.cpp:

C++:

void global_doei_func()
{
  global_hallo_var = 5;
}

--------=[ UNIT MAIN ]=----------------------------------------------
main.cpp:

C++:

#include <stdio.h>
#include "hallo.h"
#include "doei.h"
void main()
{
  global_doei_func();
  printf("%i\n", global_hallo_var);
}

Moet duidelijk genoeg zijn lijkt mij.
Oftwel het kan gewoon. (Moet wel een globaal gedefineerde variable zijn natuurlijk)

[Verwijderd]

*Kuch*

C++:

extern int global_hallo_var; // extern vergeten
// #include "hallo.cpp" // Dit is echt XXX en nergens voor nodig

Sorry hoor, maar dit lijkt echt nergens op; vooral dat constant includen van .cpp files, terwijl je de .h files niet include in de .cpp files.

[Verwijderd]

Verwijderd schreef op 09 september 2002 @ 12:06:
*Kuch*

C++:

extern int global_hallo_var; // extern vergeten
// #include "hallo.cpp" // Dit is echt XXX en nergens voor nodig

Sorry hoor, maar dit lijkt echt nergens op; vooral dat constant includen van .cpp files, terwijl je de .h files niet include in de .cpp files.

Je kan gaan schreeuwen dat het nergens op lijkt, maar het werkt perfect. Het enige wat de preprocessor doet is op de plek van een include de geinclude file toevoegen, al is het een .bmp file. Je bent helemaal vrij in hoe je het doet. Ik in C/C++ doe het op deze wijze. Die extern is echt niet nodig om zo maar een variable aan te spreken.

die #include "hallo.cpp" heb ik er enkel bijgezet omdat hier boven over een 'unit' werd gesproken als een paar van .h/.cpp.

[curry684]

Je kan gaan schreeuwen dat het nergens op lijkt, maar het werkt perfect. Het enige wat de preprocessor doet is op de plek van een include de geinclude file toevoegen, al is het een .bmp file. Je bent helemaal vrij in hoe je het doet. Ik in C/C++ doe het op deze wijze.

En vervolgens compileer je zeker met gcc -o myfile.exe doei.h hallo.h?

Ik kan me niet voorstellen dat je ooit een project van meer dan 1 cpp-file hebt gemaakt als je deze techniek hanteert, je verdrinkt namelijk binnen de kortste keren in de 'Function body already defined' errors.

En voor de originele poster: in BCB zit in het File menu de optie 'Include Unit' of zoiets, als je nu terwijl je in Unit 1 zit dat doet met Unit 2 kun je vervolgens (binnen access rights natuurlijk) alles in Unit 2 vermeubelen.

[ Voor 0% gewijzigd door curry684 op 09-09-2002 12:46 . Reden: Typo ]

[Verwijderd]

gcc main.cpp -o main
en tada, het werkt. Het mag misschien niet de standaard zijn (wat die ook moge zijn). Maar het werkt en er zit een duidelijke structuur in.
Je hebt een header file waar alle declaraties en definities in staan, deze header file include de implementatie uit een cpp file. Meer onzin heb ik echt niet nodig om een beetje structuur in mijn project te krijgen. En geloof mij, deze techniek is heel goed toe te passen met meerdere cpp-files.

Maar leg eens uit waarom het fout zou zijn. En wat voor techniek jij toepast...
Misschien kan ik er wat van leren, aangezien je daar zelf wel van overtuigd lijkt.

[Verwijderd]

Verwijderd schreef op 09 september 2002 @ 12:38:
Die extern is echt niet nodig om zo maar een variable aan te spreken.

Als je in een header een variabele declareert (dus geen constante) en je include die header vervolgens in meerdere .cpp files, dan heb je een dik probleem als die variabele niet extern gedeclareerd is: elke file ("unit") zal een eigen versie van die variabele aanmaken (dat is geen probleem bij een const).

Maw. dat vergeten van "extern" gaat zolang goed als je de .h maar in één .cpp include.

[ Voor 0% gewijzigd door Verwijderd op 09-09-2002 13:00 . Reden: declaratie vs. definitie ]

[.oisyn]

Verwijderd schreef op 09 september 2002 @ 12:38:
[...]

Het enige wat de preprocessor doet is op de plek van een include de geinclude file toevoegen, al is het een .bmp file.

uhm ja, ga jij maar eens een bmp file includen en dan zien hoe je compiler klaagt over parse errors

Die extern is echt niet nodig om zo maar een variable aan te spreken

en probeer dan maar eens 1 variabele aan te spreken vanuit 2 source files... dat lukt je gewoon niet zonder extern (omdat ze dan in beide sourcefiles gedefinieerd worden, en dan krijg je dus duplicate symbols tijdens het linken)

[Verwijderd]

ok dat is duidelijk, maar ik zal eigenlijk nooit een .h vanuit meer dan één .cpp (of andere .h) includen, dan vind ik dat mijn structuur niet meer klopt.

[Verwijderd]

Verwijderd schreef op 09 september 2002 @ 13:00:
ok dat is duidelijk, maar ik zal eigenlijk nooit een .h vanuit meer dan één .cpp (of andere .h) includen, dan vind ik dat mijn structuur niet meer klopt.

Sorry hoor maar waarvoor heb je dan nog headers nodig . Headers zijn er per definitie om meerdere cpp files gebruik te laten maken van de interface gedifinieerd in de .h. Overigens doen ze ook meestal nog een #IF !DEFINED blabla.h boven in een header waardoor jouw code misschien nog werkend is te krijgen.

[Verwijderd]

.oisyn schreef op 09 september 2002 @ 12:58:
uhm ja, ga jij maar eens een bmp file includen en dan zien hoe je compiler klaagt over parse errors

Om maar even duidelijk te maken dat er geen standaard is en dit bijvoorbeeld ook kan:

hallo.txt:

C++:

"hallo"

main.cpp:

C++:

int main(int, char **)
{
  printf("%s\n",
  #include "hallo.txt"
  );

[Pooh]

Verwijderd schreef op 09 september 2002 @ 13:00:
ok dat is duidelijk, maar ik zal eigenlijk nooit een .h vanuit meer dan één .cpp (of andere .h) includen, dan vind ik dat mijn structuur niet meer klopt.

Waar denk je dat header-files voor bedoeld zijn?

[LordLarry]

je hoort geen cpp files te includen in je h. Dat hoort juist andersom.

aap.h

code:

extern int a;

aap.cpp

code:

#include "aap.h"

int a = 0;

main.cpp

code:

#include "aap.h"

main{
  a = 6;
}

[Verwijderd]

[quote]Poohbear schreef op 09 september 2002 @ 13:06:
Waar denk je dat header-files voor bedoeld zijn?
[...]
Om een duidelijk onderscheid te kunnen maken tussen declaraties/definities en implementaties.

[Verwijderd]

LordLarry schreef op 09 september 2002 @ 13:07:
je hoort geen cpp files te includen in je h. Dat hoort juist andersom.

aap.h

code:

extern int a;

aap.cpp

code:

#include "aap.h"

int a = 0;

main.cpp

code:

#include "aap.h"

main{
  a = 6;
}

Dit snap ik dus niet, hoe kan je dan een functie aanroepen die in aap.cpp staat??
Die is dan onbekend.

[Verwijderd]

Verwijderd schreef op 09 september 2002 @ 12:53:
Je hebt een header file waar alle declaraties en definities in staan, deze header file include de implementatie uit een cpp file.

Juist ja. Je include dus de implementatie van je functies in je header. Op het moment dat je die header vervolgens weer in verschillende .cpp files include, include je dus ook de implementatie van je functies in die verschillende .cpp files. Deze implementaties zullen dan ook in elke object file gecompileerd worden, en op het moment daat je gaat linken zit je met een heleboel koppieen van die implementaties en dus met "duplicate symbols".

Maar leg eens uit waarom het fout zou zijn. En wat voor techniek jij toepast...

Voor uitleg zie boven. Het werkt het beste als je alleen declaraties opneemt in de .h files en die .h files vervolgens include in .cpp files:

C++:

/* blah.h */
extern int status;
const char* status_msg();

C++:

/* blah.cpp */
#include "blah.h"
int status= 0;

static const char* MESSAGES[]= { "Ok", "Offline" };

const char* status_msg()
{
   return MESSAGES[status];
}

C++:

/* main.cpp */
#include <iostream>
#include "blah.h"

int main()
{
    std::cout << status_msg() << std::endl;
    return status;
}

[Verwijderd]

Hoe weet main.cpp in godsnaam waar hij status_msg vandaan wil halen, die link is er toch niet ?? Naar mijn idee 'zweeft' blah.cpp buiten het project.
Mijn source structuur levert een soort grote boom diagram die zich in één keer laat compileren. dmv: g++ main.cpp -o main
Het levert gewoon een grote source-tree op, en dat vind ik veel makkelijker en logischer werken. Het mag er dan niet voor bedoeld zijn.. maar het werkt en is netjes.

[Verwijderd]

unteraarsch>> main.cpp weet niet waar hij status_msg() vandaan moet halen, en de compiler ook niet Wat de compiler wel weet, is dat er ergens in de source files een functie met de signatuur const char* status_msg(void) moet zijn. Deze signatuur wordt door de compiler opgenomen in de object file. Vervolgens verbindt de linker de object files door de signaturen die de compiler geplaatst heeft te vervangen door het adres van de functie, die hij in een andere object file gevonden heeft.

Wat jij aan het doen bent is de productieregels voor je object files proberen op te nemen in die files zelf. Omdat dit vroeger of later altijd fout gaat, heeft men het fenomeen makefiles bedacht.

[Janoz]

Laat het netjes maar weg ..

main.cpp weet precies waar ie status_msg moet weghalen omdat deze in de header staat gedefinieerd. Een cpp source heeft eigenlijk weinig te maken met de rest van de onderdelen. Dit zijn juist de .h en de .o file. Als je een fatsoenlijke makefile zou gebruiken, dan zou het compileren ook een stuk sneller gaan omdat ie niet alles bij langs moet gaan (die hele source tree van je) maar alleen de veranderde cpp files + het linken.

[LordLarry]

Verwijderd schreef op 09 september 2002 @ 13:14:
[...]

Dit snap ik dus niet, hoe kan je dan een functie aanroepen die in aap.cpp staat??
Die is dan onbekend.

erm, weet je zeker dat jij c kan programmeren?

aap.h

code:

extern int a;

void Test();

aap.cpp

code:

#include "aap.h"

int a = 0;

void Test(){
  // Do Something
}

[MSalters]

Verwijderd schreef op 09 september 2002 @ 13:06:
[...]
Om maar even duidelijk te maken dat er geen standaard is en dit bijvoorbeeld ook kan:

hallo.txt:

C++:

"hallo"

main.cpp:

C++:

int main(int, char **)
{
  printf("%s\n",
  #include "hallo.txt"
  );

Er is een standaard voor en die zegt dat je compiler daar precies niets mee hoeft te doen. Dat' ie er wel wat mee doet is geluk/toeval/makkelijkste implementatie.

Er zijn compilers waar je headers in een H/HPP directory moet zetten, ipv een .h/.hpp extensie te geven. Als die geen TXT directory supporten zou het niet hoeven te werken, sterker nog zo'n compiler mag gewoon crashen.

[Creepy]

Verwijderd schreef op 09 september 2002 @ 13:14:
[...]

Juist ja. Je include dus de implementatie van je functies in je header. Op het moment dat je die header vervolgens weer in verschillende .cpp files include, include je dus ook de implementatie van je functies in die verschillende .cpp files. [...]

En dat is dus ook meteen de reden dat er geen "header" files in Pascal zijn. In Pascal heeft een unit een interface deel (de .h file in C/C++), en een implementation deel (de .c/.cpp file).

Unteraarsch: Tuurlijk kan je elke file includen die je wilt, de preprocessor plempt gewoon domweg die file op de plek van de #include neer. Maar als je met header files werkt, kijk dan ff naar de uitleg van Mietje en LordLarry. Dit heeft echt voordelen, zeker met betrekking tot seperaat compileren (en dus ook het gebruik van Makefile).

[curry684]

http://davidrobins.net/code/cpp/EFnet_cpp_faq_compile.html

[Verwijderd]

Creepy schreef op 09 september 2002 @ 15:40:
[...]

En dat is dus ook meteen de reden dat er geen "header" files in Pascal zijn. In Pascal heeft een unit een interface deel (de .h file in C/C++), en een implementation deel (de .c/.cpp file).

Unteraarsch: Tuurlijk kan je elke file includen die je wilt, de preprocessor plempt gewoon domweg die file op de plek van de #include neer. Maar als je met header files werkt, kijk dan ff naar de uitleg van Mietje en LordLarry. Dit heeft echt voordelen, zeker met betrekking tot seperaat compileren (en dus ook het gebruik van Makefile).

True. Ik begrijp jullie verbazing over het feit dat ik een .cpp include vanuit mijn .h. Is uiteindelijk waneer je met libraries gaat werken ook niet erg handig. Maar het idee om alle cpp via een make-file mee te geven vind ik omslachtig. Welke techniek mij dan makkelijker lijkt is om het ongeveer zo te doen. (Indien men uitgaat van source):

C++:

#include "header1.h"
#include "header2.h"
#include "header3.h"

#include "impl1.cpp"
#include "impl2.cpp"
#include "impl3.cpp"

void main ()
{
   whatever();
}

Zo ben je minder afhankelijk van je makefile en kan je alles wat je gebruikt vanuit je source regelen. Dat vind ik een stuk overzichtelijker.

[Creepy]

Eén van de grote voordelen van een Makefile is seperaat compileren!
Dat betekent dus dat alleen de verandere files opnieuw worden gecompileerd en NIET (zoals in jou geval!) ALLE files elke keer opnieuw compilen.

Als je een flink project hebt levert dit enorme tijdwinst op. 1 file aanpassen betekent dat alleen die file, plus alle afhankelijke files opnieuw worden gecompileerd. Bij jou 1 file aanpassen betekent altijd dat alle files worden gecompileerd. Als het een flink produkt betreft waarvan de compile tijd op enkele minuten ligt scheelt dit enorm (laat staan een project wat uren compileren in beslag neemt)

De verbazing (in elk geval die van mij) is omdat ik dus WEL gebruik maak van makefiles (en dus seperaat compileren!), en ik dus ook alleen maar .h files include aangezien daar de interface's staan gedefinieerd.

Jou "techniek" lijkt misschien makkelijk, maar als je eenmaal een groot project hebt zal je er snel van afstappen, puur en alleen vanwege de compile tijd alleen.

[ Voor 0% gewijzigd door Creepy op 10-09-2002 12:41 . Reden: typo ]

[MSalters]

Om een idee te geven wat separate compilatie je oplevert: een project waar ik aan werkte kostte 2 dagen om te bouwen, maar elke afzonderlijke .c compileerde binnen een minuut.

[Pooh]

MSalters schreef op 10 september 2002 @ 13:04:
Om een idee te geven wat separate compilatie je oplevert: een project waar ik aan werkte kostte 2 dagen om te bouwen, maar elke afzonderlijke .c compileerde binnen een minuut.

Tsja. Dat zegt niet zo heel veel. Ten eerste: hoe snel is je processor? Ten tweede: wat duurde zo lang om te bouwen? (Ik heb wel eens 2 dagen gewerkt aan een algoritme van een paar regels).
Maar verder heb je gelijk natuurlijk.

[.oisyn]

Poohbear schreef op 10 september 2002 @ 13:21:
[...]


Tsja. Dat zegt niet zo heel veel. Ten eerste: hoe snel is je processor? Ten tweede: wat duurde zo lang om te bouwen? (Ik heb wel eens 2 dagen gewerkt aan een algoritme van een paar regels).
Maar verder heb je gelijk natuurlijk.

MSalters bedoelt bouwen als in to build, compileren dus
hoe snel je processor is doet er niet veel toe: als je hele project compileren 2 dagen duurt wil je echt niet alles steeds opnieuw doen. En nee, naar de winkel stappen om een snellere cpu te kopen is _geen_ oplossing

[Pooh]

.oisyn schreef op 10 september 2002 @ 17:26:

[...]


MSalters bedoelt bouwen als in to build, compileren dus
hoe snel je processor is doet er niet veel toe: als je hele project compileren 2 dagen duurt wil je echt niet alles steeds opnieuw doen. En nee, naar de winkel stappen om een snellere cpu te kopen is _geen_ oplossing

* PoohBear heeft zijn dag niet vandaag... begrijp mensen elke keer weer verkeerd...

[MSalters]

.oisyn schreef op 10 september 2002 @ 17:26:
[...]

MSalters bedoelt bouwen als in to build, compileren dus
hoe snel je processor is doet er niet veel toe: als je hele project compileren 2 dagen duurt wil je echt niet alles steeds opnieuw doen. En nee, naar de winkel stappen om een snellere cpu te kopen is _geen_ oplossing

Precies. En de bouwmachine was al een dedicated Sun server met meer processoren dan in al mijn PCs bij elkaar, dus daar zit inderdaad ook geen winst.
(Het project was overigens een backbone telefooncentrale, zoals o.a. de KPN gebruikt. 15MLOC, commentaar niet meegerekend)

[Verwijderd]

Tis nog mooier om geen globale variabelen te gebruiken.... (en ja.. soms moet je wel...)

[curry684]

Verwijderd schreef op 12 september 2002 @ 04:24:
Tis nog mooier om geen globale variabelen te gebruiken.... (en ja.. soms moet je wel...)

Worst case scenario is 1 globale variabele: een class waarin de 'semiglobals' zitten. Over het algemeen noem je die dan 'Application' of een afgeleide

[.oisyn]

Verwijderd schreef op 12 september 2002 @ 04:24:
Tis nog mooier om geen globale variabelen te gebruiken.... (en ja.. soms moet je wel...)

als je gebruik maakt van namespaces maakt dat dus weer geen enkele *** uit

[Verwijderd]

.oisyn schreef op 12 september 2002 @ 16:35:

[...]


als je gebruik maakt van namespaces maakt dat dus weer geen enkele *** uit

Ligt er aan of threadsafe wil zijn of niet...

[.oisyn]

vicz: Ligt er aan of threadsafe wil zijn of niet...

Dat heeft niets te maken met het feit of je globale variabelen gebruikt of niet. Je kunt net zo goed niet thread-safe zijn als je er objecten van maakt en die objecten over meerdere threads gebruikt. Het is gewoon een kwestie van mutual exclusion, wat je ook bij globale variabelen kunt doen.

[curry684]

Niks mis met een global mutex... verdomd handig zelfs als je multiprocess DLL's aan het schrijven bent (ik doel hier op bijv. een systemhook-DLL).

[Verwijderd]

Sterker nog, heel vaak zal je bij een functionele scheiding van je sources je mutexes wel globaal MOETEN definieren, aangezien deze in de implementatie files van de verschillende threads gebruikt moeten worden (bv. gina)

[curry684]

Verwijderd schreef op 13 september 2002 @ 18:19:
Sterker nog, heel vaak zal je bij een functionele scheiding van je sources je mutexes wel globaal MOETEN definieren, aangezien deze in de implementatie files van de verschillende threads gebruikt moeten worden (bv. gina)

Moeten is wel een heel sterk woord... de nette lieve vriendelijke implementatie hiervoor is om gewoon een named mutex te gebruiken, en dan ben je meteen van het gezeik met globals af. Daarom prefereerde ik het woord 'handig'