/ 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
Scope problemer med ukendt struct pointer
Fra : Martin Tilsted


Dato : 30-10-03 23:45

I mit C program har jeg det foelgende:

struct a {
   void (*Func_a)(struct b *Data);
};

struct b {
   void (*Func_b)(struct a *Data);
};

Altsaa to structs der hver indeholder en funtions pointer til en
funktion der tager en pointer til en struct af den modsatte type.

Problemet er bare at min compiler(gcc 2.95) brokker sig med en

`struct b' declared inside parameter list its scope is only this
definition or declaration, which is probably not what you want.

Og det har den jo ret i, men hvad goer man saa hvis man gerne vil have
det til at virke?

I foelge gcc manualen saa gaelder at

---- Cut fra gcc manual ----
Users often think it is a bug when GCC reports an error for code like this:

int foo (struct mumble *);

struct mumble { ... };

int foo (struct mumble *x)
{ ... }


This code really is erroneous, because the scope of struct mumble in the
prototype is limited to the argument list containing it. It does not
refer to the struct mumble defined with file scope immediately
below--they are two unrelated types with similar names in different scopes.

But in the definition of foo, the file-scope type is used because that
is available to be inherited. Thus, the definition and the prototype do
not match, and you get an error.

This behavior may seem silly, but it's what the ISO standard specifies.
It is easy enough for you to make your code work by moving the
definition of struct mumble above the prototype. It's not worth being
incompatible with ISO C just to avoid an error for the example shown above.
---- Cut slut ----

Men naar begge af afhaenige af hinanden nytter det jo ikke at bytte dem
om, saa hvad goer man i stedet hvis man gerne vil skrive gyldigt C?

Alternativt: Hvis det ikke kan lade sig goere er der saa nogle der
kender en switch til gcc saa den ikke kommer med den warning. Koden vil
jo virke i praksis da alle pointerne er lige store.

Og nej at kode det i c++ i stedet er desvaere ikke en loesning.

Martin Tilsted.


 
 
Kent Friis (30-10-2003)
Kommentar
Fra : Kent Friis


Dato : 30-10-03 23:11

Den Thu, 30 Oct 2003 22:45:29 +0000 skrev Martin Tilsted:
>I mit C program har jeg det foelgende:
>
>struct a {
>   void (*Func_a)(struct b *Data);
>};
>
>struct b {
>   void (*Func_b)(struct a *Data);
>};
>
>
>This behavior may seem silly, but it's what the ISO standard specifies.
>It is easy enough for you to make your code work by moving the
>definition of struct mumble above the prototype. It's not worth being
>incompatible with ISO C just to avoid an error for the example shown above.
>
>Men naar begge af afhaenige af hinanden nytter det jo ikke at bytte dem
>om, saa hvad goer man i stedet hvis man gerne vil skrive gyldigt C?

Så skriver du gyldig C i stedet for.

>Alternativt: Hvis det ikke kan lade sig goere er der saa nogle der
>kender en switch til gcc saa den ikke kommer med den warning.

Nej, gcc har ikke en switch til "ignorer fejl i koden".

> Koden vil jo virke i praksis da alle pointerne er lige store.

Men pointere virker ikke ens, selvom de er lige store:

#include <stdio.h>
#include <stdlib.h>

int main() {
void * v;
   char * c;
   int * i;
   
   v=malloc(10);
   c=(char *) v;
   i=(int *) v;
   
   printf("1: c=0x%p i=0x%p\n",c,i);
   
   c++;
   i++;
   
   printf("2: c=0x%p i=0x%p\n",c,i);
   
   return 0;
}

programmet giver:
1: c=0x0x8049700 i=0x0x8049700
2: c=0x0x8049701 i=0x0x8049704

c og i bliver begge initialiseret til at pege på samme adresse, og
adressen udskrives, så vi kan se at de er ens. Derefter bliver de
begge talt en op, og adressen udskrives igen. Nu er de ikke ens længere.

Der er stor forskel på pointere.

Løsningen på dit problem er til gengæld ret simpelt - du skal blot
erklære dine structs inden du bruger dem (du kan nøjes med b, men
for symmetriens skyld ville jeg nok vælge at erklære begge):

struct a;
struct b;

Mvh
Kent
--
"Intelligence is the ability to avoid doing work, yet get the work done"
- Linus Torvalds

Martin Tilsted (31-10-2003)
Kommentar
Fra : Martin Tilsted


Dato : 31-10-03 02:17

> Nej, gcc har ikke en switch til "ignorer fejl i koden".

Teknisk set er det vel ikke en fejl, man introducere bare en struct som
ikke kan tilgaas. Gcc vil gerne compile det, den giver bare warning om
den ubrulige struct.

> Løsningen på dit problem er til gengæld ret simpelt - du skal blot
> erklære dine structs inden du bruger dem (du kan nøjes med b, men
> for symmetriens skyld ville jeg nok vælge at erklære begge):
>
> struct a;
> struct b;
>
> Mvh
> Kent

Se det var en glimrende loesning. Tak for det.

Martin Tilsted


Kent Friis (31-10-2003)
Kommentar
Fra : Kent Friis


Dato : 31-10-03 20:40

Den Fri, 31 Oct 2003 01:16:58 +0000 skrev Martin Tilsted:
>> Nej, gcc har ikke en switch til "ignorer fejl i koden".
>
>Teknisk set er det vel ikke en fejl, man introducere bare en struct som
>ikke kan tilgaas. Gcc vil gerne compile det, den giver bare warning om
>den ubrulige struct.

Jo, det er en fejl.

Fejl deles typisk i to kategorier, syntaksfejl og logiske fejl. Syntax-
fejl vil compileren give som error, logiske fejl kan compileren derimod
ikke finde, men nogen gange finder den noget der ligner, og det giver
så warnings.

I dette tilfælde er der altså tale om en logisk fejl, og compileren
siger da også "jeg tror ikke du mente det du skriver her".

Et andet eksempel er if(x=y), som typisk vil give en warning, fordi
der kan være tale om en logisk fejl, og man rent faktisk mente
if(x==y) - men if(x=y) er ikke syntax-mæssigt forkert, og compileren
ved ikke hvad man egentlig mente, så derfor er det en warning.

Mvh
Kent
--
Demokrati er lige som den 29. februar - begge dele forekommer
en gang hver fjerde år.

Søg
Reklame
Statistik
Spørgsmål : 177459
Tips : 31964
Nyheder : 719565
Indlæg : 6408186
Brugere : 218881

Månedens bedste
Årets bedste
Sidste års bedste