Giddion Skrevet 22. november 2006 Del Skrevet 22. november 2006 (endret) Jeg bruker va_arg for å ta imot variabler av ulikt antall og typer (dohh), men så kommer jeg da til punktet jeg skal bruke disse, så finnes det en metode for å validere at eks.. en int ikke er en peker. Jeg ser for meg 3 muligheter. 1) Jeg vet at C++ RTTI kan gjøre jobben, men det vil jeg helst slippe å skru på. 2) Hva med å validert variablene før de ble "omgjort" til va_arg, men da må jeg gjøre ting litt mer komplisert, og det vil jeg da helst slippe. (jeg tror dette er den beste) 3) Hva med å lage en egen RTTI datastring (1 char pr type) som kjapt kan valideres ved en binær sammenligning, men det kan bli litt komplisert ettersom jeg håper å få inkludert dynamisk installering av nye variabel typer. Hvorfor bruker jeg va_arg. Vel jeg trenger en felles interface, og denne interfacen brukes til å generere run-time genererte objekter så vel som linker-time objekter , og disse skal kunne kalles på både fra skript og C++. Hvis det er andre forslag så kom med de. Takker for alle svar. Endret 22. november 2006 av Giddion Lenke til kommentar
einaros Skrevet 22. november 2006 Del Skrevet 22. november 2006 Bruk av varargs er så godt som alltid en dårlig idé. Generelt sett er det langt bedre å bruke en kombinasjon av overloading og templates. Dersom du er fullstendig avhengig av variabelt antall parameter run-time, faller det riktignok i grus. Kan du gi et eksempel på interfacet ditt, og hvorfor du mener det må være som det er? En ting jeg kan si umiddelbart, er at du ikke vil være i stand til å få valideringen så god som du kanskje ønsker, samme hvilken teknikk du bruker. Lenke til kommentar
Giddion Skrevet 22. november 2006 Forfatter Del Skrevet 22. november 2006 Bruk av varargs er så godt som alltid en dårlig idé. Generelt sett er det langt bedre å bruke en kombinasjon av overloading og templates. Dersom du er fullstendig avhengig av variabelt antall parameter run-time, faller det riktignok i grus. 7335621[/snapback] Jeg er dessverre avhengig av et variabelt antall variabler, ellers så hadde jeg vært helt enig i bruken av templates og overload. Kan du gi et eksempel på interfacet ditt, og hvorfor du mener det må være som det er? 7335621[/snapback] Vel jeg skal lage en slags klasser (kalt Entity) disse kan ha funksjoner (som egentlig holder til hos entityinstance) og variabler. Disse klassene skal også kunne lages og defineres i run-time via skript. Når disse defineres laget en slags mal (kalt entityinstance) denne malen inneholder en funksjon som skal mota og behandle argumentene og utefra det lage en Entity utefra den typen entityinstance som blir kalt på. Disse klassene blir styrt og organisert fra klassen CEntityManager. Denne klassen skal/eller bør ha en felles interface (her er det jeg føler jeg må bruke va_arg) mot alle Constructor funksjonene til de ulike entityinstance. Den funksjonen jeg trenger va_arg til er da (denne ligger hos CEntityManager) CEntity* CreateEntity(Y_UINT uiEntityTypeID,...) //... er da variabler til de ulike Constructor funksjonene. Håper dette gjorde det litt klarere En ting jeg kan si umiddelbart, er at du ikke vil være i stand til å få valideringen så god som du kanskje ønsker, samme hvilken teknikk du bruker. 7335621[/snapback] Hmm mulig jeg forklarte meg dårlig, jeg trenger ikke stål kontroll på alt, hvis en raring konverterer et tilfeldig tall til en peker og gir den videre så skal han alltids få hele programmet til å klikke, men dette er bare mulig å gjøre i den hardkodede delen. I skript delen så er det full kontroll helt til variablene skal over til den hardkodede delen av programmet. Jeg kan jo bruke [dynamic_cast] i debug kompileringen for å finne slike feil dvs med c++ RTTI, eller vil ikke det fungere? Jeg har tenkt litt til og jeg har enda en metode. Denne metoden bruker skriptets tabel variabel (som i LUA og gm), dette er en slags vector, men med variabel ID for hvert av elementene. Denne metoden er dessverre med på å skape et stort kaos av skille mellom skript delen og hardkodete delen noe som jeg overhode ikke liker. Takker for svar Lenke til kommentar
einaros Skrevet 23. november 2006 Del Skrevet 23. november 2006 Hrm, jeg mente jeg hadde krysset av på "Følg dette emnet", for å gi svar så fort som mulig .. men det virker det ikke som jeg har klart. Lenke til kommentar
einaros Skrevet 23. november 2006 Del Skrevet 23. november 2006 Jeg kan jo bruke [dynamic_cast] i debug kompileringen for å finne slike feil dvs med c++ RTTI, eller vil ikke det fungere? Problemet er at RTTI, og spesifikt typeid-operatoren, ikke kan ta i mot en vilkårlig minneadresse og si hva slags type variabel som befinner seg der. Jeg går ut i fra at det var hva du egentlig ville hatt. Det koker nok ned til at hvis du vil/må bruke varargs, blir nødt til å finne deg i litt usikkerhet. Hvis klienten, enten det er et script eller annet program, sender en identifikator på ønsket objekt til deg, må du bortimot ta det for god fisk at parametrene stemmer over ens med signaturen til objektets ctor. Lenke til kommentar
Giddion Skrevet 23. november 2006 Forfatter Del Skrevet 23. november 2006 Jeg kan jo bruke [dynamic_cast] i debug kompileringen for å finne slike feil dvs med c++ RTTI, eller vil ikke det fungere? Problemet er at RTTI, og spesifikt typeid-operatoren, ikke kan ta i mot en vilkårlig minneadresse og si hva slags type variabel som befinner seg der. Jeg går ut i fra at det var hva du egentlig ville hatt. 7344293[/snapback] Vel hvis jeg kan validere at det de sender er riktig så funker det også. Men det skal jeg alltids få til Det koker nok ned til at hvis du vil/må bruke varargs, blir nødt til å finne deg i litt usikkerhet. Hvis klienten, enten det er et script eller annet program, sender en identifikator på ønsket objekt til deg, må du bortimot ta det for god fisk at parametrene stemmer over ens med signaturen til objektets ctor. 7344293[/snapback] stemmer... det var det jeg fryktet.. jaja takk for hjelpen. Jeg tror nok jeg lager en charstring som vil fungere som en mal for hvilke data som kan bli mottat, og en som fungere som en indikator for hva som blir sendt. Takk for svaren 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å