Problem med struct og char-array i C

[etse]

Først legger jeg trykk på at dette er C og ikke C++.

Jeg har nå prøvd å lage meg et lite spill, og kommet til delen hvor jeg skal lagre high-scoren fra spillet i en fil; dette har jeg fått til å funke fint med å la navnet være en integer. Jeg prøvde nå å gå over til å la navnet være en string (character array), men får noen feilmeldinger jeg ikke helt vet hva jeg skal gjøre med.

 

Jeg vet det er lett å bruke pointere, men grunnet lagring av structen til fil er det på mange måter lettere å ikke bruke pointer; men si ifra om dette er helt nødvendig.

 

Koden finner dere her:

http://pastebin.com/m41bec6da

 

Denne består av 3 filer, Object.C, Object.H og Main.C

 

Object.C = Linje 1-29

Object.H = Linje 30-51

Main.C = Linje 52 - slutten

 

Feilen jeg får er

main.c:10: error: incompatible types in assignment

 

Og den mener da linjen:

object->player = player;

 

Jeg kan ikke helt se, hvorfor dette ikke er lov, når både player og object->player begge deler er satt til å være char-array med 12 ledige plasser. Noen som har mulighet til å forklare?

[GeirGrusom]

Vel, du har rotet litt med rekkefølgen på ting her, du definerer CreateObject (som du forøvrig burde kikke over én gang til) to ganger i headeren din, du definerer også object_t før du definerer object,

DestoryObject har ingen funksjonskropp, AddScore returnerer ingen verdi, og du kaller AddScore med første parameter list når AddScore bare tar imot to parameter.

 

Du kan heller ikke sette verdien i et array lik verdien i et annet array, du må bruke strcpy eller eventuelt strncpy.

Endret 16. november 2008 av GeirGrusom

[etse]

Vel, du har rotet litt med rekkefølgen på ting her, du definerer CreateObject (som du forøvrig burde kikke over én gang til) to ganger i headeren din, du definerer også object_t før du definerer object,

DestoryObject har ingen funksjonskropp, AddScore returnerer ingen verdi, og du kaller AddScore med første parameter list når AddScore bare tar imot to parameter.

 

Du kan heller ikke sette verdien i et array lik verdien i et annet array, du må bruke strcpy eller eventuelt strncpy.

nle en del rot i den koden etter klipping og liming for å få vekk alt uvesentelige.

 

her er den ordnet opp

http://pastebin.com/m256729fd

 

men strcpy, takk; skal se om det ordnet problemet.

 

Endret koden til følgende:

http://pastebin.com/m67a024e8

 

får nå:

3 [main] Breakout 5364 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION

455 [main] Breakout 5364 open_stackdumpfile: Dumping stack trace to Breakout.exe.stackdump

Endret 16. november 2008 av etse

[GeirGrusom]

Du har byttet om rekkefølgen på parameterne i strcpy.

Det skal være strcpy(object->player, player).

[etse]

Takk for hjelpen Fikk alt til å virke nå.

[GeirGrusom]

Du burde virkelig kikke over CreateObject funksjonen din, den er helt sprø, faktisk kunne den vært et bidrag til WTF.

[etse]

Du burde virkelig kikke over CreateObject funksjonen din, den er helt sprø, faktisk kunne den vært et bidrag til WTF.

For å være ærlig ser jeg ikke helt hva som er galt med den? Den allokerer minne til en ny struct og returnerer minneadressen til denne?

 

eller ser jeg kjører samme if-testen 2 ganger, men utenom det virker den jo riktig?

Endret 16. november 2008 av etse

[GeirGrusom]

Den virker ja, men mesteparten av koden gjør absolutt ingenting.

Du sjekker om malloc returnerer null, og hvis den gjør det så returnerer funksjonen null? hva er poenget? kan du ikke bare returnere det malloc gjør?

og enda verre er det at du bruker goto, dette er noe som du ALDRI må gjøre.

Endret 16. november 2008 av GeirGrusom

[zotbar1234]

(...) og enda verre er det at du bruker goto, dette er noe som du ALDRI må gjøre.

 

"Structured programming with go to statements", D. Knuth, 1974.

[krigun]

(...) og enda verre er det at du bruker goto, dette er noe som du ALDRI må gjøre.

 

"Structured programming with go to statements", D. Knuth, 1974.

 

Tror det GeirGrusom mener er at det er veldig få som bruker goto idag. Det har vært lange diskusjoner om hvorvidt bruk av goto er bra/dårlig, men deil bruk kan nok føre til endel "spaghettikode", og enkelte språk har t.o.m. goto <linjenummer>; trenger vel ikke stor forklaring på hvorfor ikke dette funker så bra i lengden.

[GeirGrusom]

(...) og enda verre er det at du bruker goto, dette er noe som du ALDRI må gjøre.

 

"Structured programming with go to statements", D. Knuth, 1974.

 

Goto fører til rotete og sølete kode, fordi en ikke kan se umiddelbart hvor en goto egentlig fører programmet.

goto er en uting, og jeg kan ikke tenke meg et eneste tilfellet der det er nødvendig å bruke.

 

Jeg har ikke brukt goto siden jeg satt med Visual Basic 6.0 (hvor det måtte brukes for error handling)

 

Goto er ansett som såpass grisete at dersom du viser fram kode med goto på et jobbintervju, så kan det alene faktisk føre til at du ikke får jobben.

Du bør isåfall ha en ganske forbanna god grunn for å bruke goto.

[zotbar1234]

Tror det GeirGrusom mener er at det er veldig få som bruker goto idag. Det har vært lange diskusjoner om hvorvidt bruk av goto er bra/dårlig, men deil bruk kan nok føre til endel "spaghettikode", og enkelte språk har t.o.m. goto <linjenummer>; trenger vel ikke stor forklaring på hvorfor ikke dette funker så bra i lengden.

 

goto i C er i praksis den eneste muligheten å simulere try-finally (la oss se bort fra setjmp()/longjmp() som er den *egentlige* veien til try-finally):

 

void
foo()
{
T1 *resource1 = something();
T2 *resource2 = something_else();
// ...

if ( <some condition> )
	goto cleanup;

// ...

if ( <some other condition> )
	goto cleanup;

// something useful

cleanup:
release(resource1);
release(resource2);
// ...
}

 

... og selv om OP sitt innlegg overhodet ikke trengte goto, lignet forslaget hans på denne modellen. Man har dessverre få andre verktøy tilgjengelig. Ja, vi leser alle xkcd. Artikkelen til Knuth inneholder en rekke interessante tilfeller der goto er nyttig.

[zotbar1234]

goto er en uting, og jeg kan ikke tenke meg et eneste tilfellet der det er nødvendig å bruke.

 

Fanatisme er en uting. Hvis du ikke kan tenke deg et eneste tilfelle der goto gjør sin nytte, er jo artikkelen til Knuth et godt utgangspunkt.

 

Goto er ansett som såpass grisete at dersom du viser fram kode med goto på et jobbintervju, så kan det alene faktisk føre til at du ikke får jobben.

 

Dersom jeg ikke får jobb *utelukkende* fordi jeg har brukt goto (heller enn at den ble brukt f.eks. feil), så tviler jeg på om jeg vil ha slike kolleger.

[krigun]

goto i C er i praksis den eneste muligheten å simulere try-finally (la oss se bort fra setjmp()/longjmp() som er den *egentlige* veien til try-finally):

 

Infinite discussion loop detected. aborting.

[GeirGrusom]

Vanligvis er goto en indikasjon på at koden er strukturert feil.

Jeg har aldri møtt på et sted der jeg har tenkt "Oi! her hadde det vært kjekt med goto!"

[etse]

Vanligvis er goto en indikasjon på at koden er strukturert feil.

Jeg har aldri møtt på et sted der jeg har tenkt "Oi! her hadde det vært kjekt med goto!"

Jeg vet koden min kanskje kan får pris for å være spaghetti-kode. Men driver og prøver å ordne opp i strukteren nå. Videre føler jeg at i flere av bøkene jeg har om C-programmering så er goto brukt for mye error-handling, hvis meningen er at hver "error" skal behandles på samme måte.

 

Så har egentlig lagt til meg den (u)vanen at hver gang jeg gjør noe som kan gå galt, så tar jeg å sjekker om det gikk bra, og hvis ikke tar jeg goto error. Og lager er prosedyre for behandling av errors i slutten av koden. Følger man f.eks. denne metoden ser jeg ikke hvorfor det skal være så mye mer rotere enn noe annet.

 

Jeg har og lagt merke til at fåreleseren vår på universitet også bruker mye goto, jeg skal ikke gå ut å si at han er er av de beste til å kode, for jeg vet ingenting om hvor god han er. Men jeg føler at han burde ha kompetanse nok til å ikke ha brukt goto, om det var en så stor u-ting som det skulle virke som. Det er vel mer en smaks-sak om man bruker goto eller ikke. Men kan se for meg at om man bruker det veldig mye, og ikke bare til spesielle ting, så kan du enda med en forvirrende kode, som sender deg opp, ned og gjerne opp igjen.

[Kagee]

Jeg mener foreleseren min sa noe om at han ville ha strøket en dårlig eksamen om man i tillegg brukte goto. Men det kommer vel ann på foreleseren.

Endret 20. november 2008 av Kagee

[GeirGrusom]

Jeg gidder aldri dra i C forelesningene så jeg aner ikke hva foreleseren har å si om saken.

[etse]

Jeg mener foreleseren min sa noe om at han ville ha strøket en dårlig eksamen om man i tillegg brukte goto. Men det kommer vel ann på foreleseren.

Det kommer vel helt ann på hvordan du bruker den. Lager du noe kode lignende dette tror jeg ikke folk er glade:

switch(var)
{
 case 1:
	  goto something1;
	  break;
 case 2:
	  goto something2;
	  break;
 case 3:
	  goto something3;
	  break;
}

something1:
 // Do something
something2:
 // Do something
something3:
 // Do something

 

Men kode lignende dette er ikke så uoversiktlig:

// Do something
if(SomeError)
goto error;

// Do some more
if(SomeError)
goto error;

error:
// General handling for errors

 

Forskjellen her er at i det første tilfellet brukes koden til å styre elementer i funksjonen hvor du ellers f.eks. skulle bare laget funksjoner og kallt på de forskjellige funksjonene (et eksempel) i det forskjellige casene. Mens i det andre tilfellet har man en felles-ting som skal gjøres, hvis et tilfelle oppstår en av mange plasser. Det kan selvfølgelig gjøres på flere måter; men ser ikke helt hvorfor det skal være så veldig galt å bruke goto i slike tilfeller. Det gjør ting oversiktlig og enkelt.

[LostOblivion]

Det eneste goto i dag kan brukes til i C og fortsatt være fornuftig er å bryte ut av nestede looper. Dette kan også, og burde, unngås ved å skrive om koden. F eks:

int gives_error(int a, int b);

int main()
{
int i, j;

for (i = 0; i < 10; i++)
	for (j = i; j < 10; j++)
		if (gives_error(i, j))
			goto was_error;
return 0;
was_error:
printf("Found error\n");
return 1;
}

...

Jeg har aldri brukt goto i C da...