Ny på GCC, diverse fågor...

[mri]

Warning angående attribute packed i gcc om man jobbar på Arm ellerr dylik processor som bara läser sina datatyper från alignade addresser: attribute packed sätter också alignment till 1 byte för strukturen.
Mitt råd är att nogrannt läsa dokumentationen för dessa attribut annars kan det bli överraskningar.

[Zeela]

Vad är det med switch som är crap jämfört med pascals Case?

[Icecap]

I Pascal kan man (om jag minns rätt) för en Case 1-7, alltså motsvarighet till alla värden mellan (och inklusiva) de två värden, 1, 2, 3, 4, 5, 6 & 7.
Detta går ju i C också, det blir bara lite mer skrivning.

[Zeela]

Jo, men det har ju egentligen inget med Case att göra. Det är ju en annan feature, nämligen Set och språkets hantering av såna.

[Icecap]

Jag hakar på lite, trådkapar helt enkelt.

Använder GCC med Eclipse till RX-processorn. Jag enabler C99.
Det har varit en del småsaker, en av dom är just packningen av variabelstrukturer - men den del har jag löst.

Programmet jag har gjort fungerar bra - om jag inte slår på optimering. Det är testat och har kört stabilt genom ett bra tag.

Men aktiverar jag optimeringen (likgiltigt om det är för hastighet eller kodstorlek) blir det en hel del problem med att få saker och ting att fungera.

Jag minns att ha sett att optimeringen i GCC "ibland" har en del utmaningar för sig och att det helt enkelt fungerar uselt.

Jag har inte problem med minnesplatsen, programmet använder 9% av tillgängligt programminne men det är ju bara detta projekt. Finns det något känd man kan göra för att optimeringen faktisk kan fungera eller är det bara en framtida feature?

[SvenW]

Debbuggning fungerar inte alltid med optimering och det har sina naturliga orsaker.
Hur det är specifikt för med RX-processorn vet jag inget om.

Mina erfarenheter begränsas till Intel Pc, ARM och AVR.
Vissa konstiga saker har kanske skett någon gång, men jag minns inga större bekymmer
annat än att icke-optimerad kod blivit för stor eller för långsam.

[mri]

Slår man på optimering i gcc får man se till att skriva koden korrekt enligt standarden. Fullösningar som andra kompilatorer (visual c t.ex) sväljer kan ge buggar i gcc. Visst kan gcc ha buggar också men generellt är optimeringen aggresiv och tar alla tillfällen att trixa om c standarden öppnar upp för sådant.

[baron3d]

Fungerar med -O1, från och med -O2 händer en massa.
Har själv för vana att använda -Wall, så att man får varningar vid minsta konstighet.

[Marta]

Nya nybörjarproblem när jag skall byta från Pascal till GCC.

Skall ha en länkad lista, men fastnar i moment22... Strunta i om det är något struntfel, det är principen för forwarddeklarerade types som är det viktiga.

I Pascal blir det
type
DataPtr:^Data;
Data: record
Back,
Forw:DataPtr;
SomeDataTypes....
end;

I GCC försökte jag

typedef struct {
Data* Back,
Forw;
SomeDataTypes
}Data;

Men det tar den inte för Data är odefinierat. Hur definierar jag en pekare till en ännu inte definierad datatyp? Längden är ju känd så det borde vara lika möjligt i C som det är i Pascal.

[baron3d]

typedef struct Data Data;

struct {
Data* Back,
Forw;
SomeDataTypes
} Data;

[Marta]

'Data' redeclared as different kind of symbol'...

För tydlighets skull, det är GCC och inte G++ jag använder om det nu har betydelse.

[Findecanor]

Jag ser två fel:
1. Du måste deklarera typen "Data" innan du kan använda den. Alltså "typedef struct Data Data" gör "Data" till ett typ-alias för "struct Data". Detta måste göras före "struct Data { ... }" som definierar typen "struct Data".
Innan du har deklarerat typen "Data" så förstår kompilatorn inte vad en pekare till det är, men den förstår alltid vad en pekare till en struct är för något.
2. Du måste skriva '*' före varje pekares namn i strukturen: "Data *Back, *Forw". (Inte helt självklar syntax, jag vet ...)

Alternativt skulle du kunna skriva:

Kod: Markera allt

typedef struct Data {
   struct Data *Back, *Forw; /* OBS: "struct Data", inte "Data" */
   SomeDataType whatever;
} Data;

[ie]

Ett exempel på hur det ser ut i min kod:

Kod: Markera allt

typedef struct sender_queue_t SENDER_QUEUE;
struct sender_queue_t
{
	uint8_t *sender;
	SENDER_QUEUE *next;
};
static SENDER_QUEUE *sender = NULL;

[Findecanor]

@ie: Din användning av stora, små bokstäver och ändelsen "_t" är ganska okonventionell.
Vanligare är att endast värdetyper har namn som slutar med "_t" just för att visa att de är typer, att struktur-typer är i "camel case" ("SenderQueue") och att endast macron (vilket inkluderar konstanter) är i endast versaler.

[Marta]

Det blev alternativet som Findecanor visat. gcc accepterar det och pekarna tycks fungera. Däremot är jag fortfarande alldeles yr när det gäller vad som deklareras med de olika placeringarna av typnamnet före och efter {....} Är väl jag som är för gammal...

Nu till nästa tillkortakommande hos C vs Pascal. Programmet som skall porteras har en hel del var-deklarerade pekare. Hur deklareras en pekare till en pekare och hur görs dereference både för att komma åt det den till slut pekar på och att peka om denna pekare så den nya adressen följer med tillbaka?

T.ex. i Pascal: procedure UpdateData( var DataPtr; Data, Length);

Denna procedur skall då placera in Data i en länkad lista och beroende på Length så kan det hända att DataPtr ändras och den nya skall följa med tillbaka. Vissa procedurer har två sådana pekare som kan ändras, så att använda return är inte lösningen.