delfin Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Jeg har akkurat blitt tvunget over på C++ i forbindelse med skolen, og har tidligere erfaring fra java, C# og litt ymse. Problemet mitt med c++ er at jeg sannsynligvis har misset et eller annet vesentlig angående strukturering av programmer, for jeg kommer stadig vekk bort i gjensidige avhengigheter, f.eks som under: app.cpp: hovedprogrammet, skal ha tilgang til metoder i fourier.h, samt structene derfra. fourier.h: inneholder structs for diverse, pluss noen metoder. Skal ha tilgang til structs fra image.h. Ikke en klasse (kanskje triks å lage klasse?). Skal behandle et "image" image.h: klasse som inneholder et bilde, med en pixel-struct. Må kunne se structene til fourier. så problemet mitt her, er da at jeg får et salig rot av dependencies. Jeg må inkludere fourier.h i image.cpp f.eks, for å få tilgang til structs fra fourier.h. Er dette virkelig nødvendig? I C# er det så greit, da sier jeg bare at den bruker den og den fila, men her må jeg inkludere kildekoden. Samtidig må jeg inkludere image.h i fourier.cpp for å se structene for bildet mitt, og da blir det jo krøll. Hvordan i all verden er riktig måte å løse dette i C++? Er ikke helt inne i tankegangen her enda... Beklager dårlig formulering, men jeg håper dere forstår problemet. Lenke til kommentar
Cotul Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Vel, først vil jeg si at structs er vel egentlig en uting i c++ som kun henger igjen for kompatibilitet med C. Er vel bedre å bruke klasser, men antar det er en skole oppgave som spesifiserer bruk av structs så nok om det. Hvis jeg leser deg rett så må du bare inkludere fourier.h i image.h. Da skal du ha tilgang til innholdet i image.cpp siden du der inkluderer image.h. Jeg har forstått det sånn at du skal alltid inkludere filer i header filene (.h) og at i .cpp fila skal du bare inkludere tilhørende .h fil. Gjelder selvsagt ikke for main fila. Håper du forsto no av det jeg skrev nå. Og jeg håper at jeg svarte på noe av spørsmålet ditt. Lenke til kommentar
delfin Skrevet 26. februar 2008 Forfatter Del Skrevet 26. februar 2008 Takk for at du svarer, men jeg tror dessverre ikke vi tenker på samme problemet. Jeg inkluderer kun .h-filen, men såvidt jeg kan se er en av tingene man må definere i .h filen structs. Problemet er at jeg i tillegg til å måtte inkludere fourier.h i image (for å få structen som hører til fourier..) også må inkludere image.h i fourier (for å få structen for et bilde (uchar r,g,b)) .. og da blir det jo selvsagt krøll, siden de inkluderer hverandre, så hver gang jeg inkluderer f.eks image.h, inkluderer jeg også fourier.h, som igjen inkluderer image.h etc... Lenke til kommentar
TitanKvad Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 (endret) Takk for at du svarer, men jeg tror dessverre ikke vi tenker på samme problemet. Jeg inkluderer kun .h-filen, men såvidt jeg kan se er en av tingene man må definere i .h filen structs. Problemet er at jeg i tillegg til å måtte inkludere fourier.h i image (for å få structen som hører til fourier..) også må inkludere image.h i fourier (for å få structen for et bilde (uchar r,g,b)) .. og da blir det jo selvsagt krøll, siden de inkluderer hverandre, så hver gang jeg inkluderer f.eks image.h, inkluderer jeg også fourier.h, som igjen inkluderer image.h etc... Tja. Så om jeg har forstått deg riktig her så vil du i kodefilen at den henter inn strukturen fra fourier.h, som da trenger en struktur fra image.h? Dette hørtes litt for enkelt ut så jeg har gjerne misforstått... Da må det vel være like enkelt som å inkludere dem i den rekkefølgen du trenger i kildefilen som tar dem i bruk istedenfor å gjøre inkluderingen i header-filen? Med mindre du kryssrefererer mellom strukturene da, hvor i så fall løsningen bør være å forhåndsdefinere den ene før slik at den under kompileringen skjønner at det ikke er en udeklarert variabel. I header-filen kan man vel egentlig putte hva som helst. Det er vel bare hva folk foretrekker å bruke dem til og standarder folk følger som er grenser. Har du lekt deg med #ifdef og #endif for å få hver av dem til å kun inkluderes én gang da? Jeg skjønner bare ikke helt hvorfor du trenger å inkludere en header-fil i en header-fil som igjen trenger å inkludere den forrige. Om ikke dette løste problemet ditt kunne en grov forklaring av problemstillingen med kode gjort det en smule enklere. EDIT: Ahaha. Stopp en halv. Nå fikk jeg med meg noe jeg overså i posten din. "Jeg må inkludere fourier.h i image.cpp f.eks, for å få tilgang til structs fra fourier.h. Er dette virkelig nødvendig? I C# er det så greit, da sier jeg bare at den bruker den og den fila, men her må jeg inkludere kildekoden. Samtidig må jeg inkludere image.h i fourier.cpp for å se structene for bildet mitt, og da blir det jo krøll." Nei det blir vel ikke krøll? Om du inkluderer en header-fil i en kildefil og en annen i en annen så må man vel også huske på at hver av kildefilene kompileres for seg og så lenkes sammen til utførbar etterpå. Det bør vel gå helt fint å inkludere fourier.h i image.cpp og image.h i fourier.cpp. Om jeg ikke misforstår helt her. Endret 26. februar 2008 av TitanKvad Lenke til kommentar
GeirGrusom Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Vel, først vil jeg si at structs er vel egentlig en uting i c++ som kun henger igjen for kompatibilitet med C. Er vel bedre å bruke klasser, men antar det er en skole oppgave som spesifiserer bruk av structs så nok om det. Det er ingen reell forskjell på struct og class(bortsett fra at private er standard i class, public i struct) i C++. teknisk sett spiller det ingen rolle hvilken man bruker, men man har som regel primitive objekter i strukturer, og avanserte i klasser. Og grunnen er, som du sier, fordi C++ skal støtte å kompilere C programmer, men det er ingen regel mot å bruke det, fordi det blir nok ikke droppet så lenge C++ skal støtte C. Ofte pleier ihvertfall jeg å lage en felles include fil som inkluderer alle andre .h filer, da er det bare rekkefølgen i den som spiller noen rolle, og man trenger ikke tenke på hvilken som inkluderer hva. Lenke til kommentar
TitanKvad Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Ofte pleier ihvertfall jeg å lage en felles include fil som inkluderer alle andre .h filer, da er det bare rekkefølgen i den som spiller noen rolle, og man trenger ikke tenke på hvilken som inkluderer hva. Sikkert et greit tips å gi ja. Syns mye av det der rundt objekter og header-filer blir mye som "hvorfor gjøre det enkelt når du kan gjøre det dritkomplisert". Jeg for min del gjør stortsett alt i én kildefil som har seksjoner skrevet direkte i header-filer så jeg slipper det hodeverket. Men gjerne ikke å anbefale om man jobber med mer enn hobby-utvikling. Lenke til kommentar
GeirGrusom Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Hehe, jeg tror jeg foretrekker å strukturere koden skikkelig Eksempel fra spillmotor som jeg jobber litt med: (dllmain.h) Klikk for å se/fjerne innholdet nedenfor #pragma once #define WIN32_LEAN_AND_MEAN #include <vector> #include <stack> #include "../DeepSpace/Common.h" #ifdef DO_ENGINE_IMPORT #undef export #define export __declspec(dllimport) #else #undef export #define export __declspec(dllexport) #endif // Foreward decleration of squirrels virtual machine handle datatype struct SQVM; typedef SQVM* HSQUIRRELVM; #include <windows.h> namespace Ds3 { namespace Graphics { #include "model.h" #include "BaseTexture.h" #include "GraphicsRenderer.h" namespace MeshBuilders { #include "meshbuilders.h" } } namespace Audio { #include "audiosystem.h" } #include "engine.h" } #include "squirrel.h" extern "C" { #include "scripting.h" } Her skriver jeg bare #include "dllmain.h" i alle kodefilene. Lenke til kommentar
Cotul Skrevet 26. februar 2008 Del Skrevet 26. februar 2008 Vel, først vil jeg si at structs er vel egentlig en uting i c++ som kun henger igjen for kompatibilitet med C. Er vel bedre å bruke klasser, men antar det er en skole oppgave som spesifiserer bruk av structs så nok om det. Det er ingen reell forskjell på struct og class(bortsett fra at private er standard i class, public i struct) i C++. teknisk sett spiller det ingen rolle hvilken man bruker, men man har som regel primitive objekter i strukturer, og avanserte i klasser. Og grunnen er, som du sier, fordi C++ skal støtte å kompilere C programmer, men det er ingen regel mot å bruke det, fordi det blir nok ikke droppet så lenge C++ skal støtte C. Joda, men har fått høre at vi helst skal unngå å bruke struct og heller gå for egne klasser. For enklere å lære seg å tenke klasse orientert, eller noe sånt. Hvertfall noe sånt læreren sa når jeg brukte struct i en oppgave på skolen. Lenke til kommentar
OldMan Skrevet 2. mars 2008 Del Skrevet 2. mars 2008 Hvis du bruker Visual studio kan det hjelpe å skrive: #pragma once øverst i alle .h filene dine, da kan du includere dem overalt uten å få trøbbel. Ellers er er det greit å bruke følgende i alle.h filene: #ifndef _Navnpåhfil_h_ #define _Navnpåhfil_h_ Innhold i h fil her #endif // _Navnpåhfil_h_ Lenke til kommentar
delfin Skrevet 5. mars 2008 Forfatter Del Skrevet 5. mars 2008 Hvis du bruker Visual studio kan det hjelpe å skrive: #pragma once øverst i alle .h filene dine, da kan du includere dem overalt uten å få trøbbel. Ellers er er det greit å bruke følgende i alle.h filene: #ifndef _Navnpåhfil_h_ #define _Navnpåhfil_h_ Innhold i h fil her #endif // _Navnpåhfil_h_ Jeg trodde #pragma once var en erstatning for #ifndef? Må si dette lille scriptespråket til c++ gjør det hele mer komplisert enn nødvendig, men det er jo greit... Jeg har forresten fått det til nå, problemet var circular dependencies, og jeg løste det ved å flytte alt som trengte å vite om begge structene til den ene klassen (fourier), men i etterpåklokskapens lys burde jeg nok laget en fellesklasse for de to, f.eks "complexImage" eller noe... gjort er gjort, og det var bare en oppgave på skolen som nå er godkjent, men takk for hjelpen Lenke til kommentar
GeirGrusom Skrevet 5. mars 2008 Del Skrevet 5. mars 2008 #pragma once sier bare at precompileren kun skal inkludere filen én gang. Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå