Bitfält i C

[Abra Hana]

>sodjan

>Den där "teorin" är något du själv har hittat på! Ingen har sagt så här.
(Om jag tolkar din meningsbyggnad rätt...)

om du menar :
> "olika kompilatorn bestämmer olika hur bitarna ska läggas in"

Det var min uppfattning av din teori
" >det är upp till kompilatorn hur bitarna ska läggas ut."

ber om ursäkt för det om jag tolkade det fel .

om du menar

>Det finnas ett bestämt kompilerings algoritm som alla C kompilatorer måste följa ( beroende på plattform ) för att räkna storleken på en structure beroende av dess data medlemmar

då teorin är mitt , och speglar enbart min gissning , och inget annat .

----------------------------------------------------------------------------------
>Och att använda en Microsoft produkt för att bevisa en standard !?
Kreativt men lite vågat, skulle jag säga

Trots att jag är anhängare till vissa av microsoft produkt inklusivt deras visual C/C++ kompilator , skulle aldrig komma mig i tanke att påstå att deras kompilator följer C Standard till fullo . Det där har du själv hittat på .
jag bara , med faset i handen skrev att det måste finnas en kompilerings algoritm som alla kompilatorer måste följa för att räkna storleken på en strukture .

-------------------------------------------------------


->Icecap skrev

Om det är M$ Visual C++ du menar är du ganska fel ute, den har inte ett bra rykte och den dominerar definitivt inte heller.....

--------------------------------------------------------

Att påstå att M$ visual C++ är kass när det gäller att utveckla applikationer som körs i deras plattform windows , är lika med att påstå att Microchips kompilator MCC är helt kass när det gäller att utveckla program som ska programmeras i PIC:ar .

Du kan åtminstone nämna en kompilator som är bättre än M$ visual c++ och som används för att utveckla windows program ! . och på vilket sätt är den bättre än M$ visual C++ .

*

[sodjan]

> skulle aldrig komma mig i tanke att påstå att deras kompilator följer C Standard till fullo

Nu gällde det ju bara allokeringen av bit fält, inte *hela* C-standarden...

> att det måste finnas en kompilerings algoritm som alla kompilatorer måste följa för att räkna storleken på en strukture

Vilket (så vitt jag förstår) inte gör för en structure med BIT-FÄLT !
Det är alltså upp till varje kompilator att bestämma det...

[Icecap]

Abra Hana: När påstod jag att den är kass? Det får vara din tolkning och det får DU stå för!

De programmeringsforum jag skrivar på är ytterst skeptiska till vissa av M$ lösningar vilket gör att den inte är dominerande (som DU påstår), inom visuella utvecklingsverktyg finns det Borland C Builder t.ex., Delphi och lite andra där det finns en hel del funktioner osv. att hitta på nätet.

Bättre i användervänlighet alltså, själva kodgenereringen ska jag inte uttala mig om, det är nog ganska lika om nu inte M$ använder dessa "specialrutiner" som det har varit så mycket tjafs om och som jag inte vill sia om.

[TomasL]

Tjafset har väl främst handlat om att MS utnytjar div "odokumenterade" APIer mm, som konkurenterna inte har "tillgång" till.

[Abra Hana]

>Iceap

Kass och kass , jag skulle ha skrivit annat ord än kass ..........

Jag instämmer med dig när det gäller visuella utvecklingsverktyg .
Borland C Builder är betydligt bättre än visual c++ med sitt MFC .


>TomasL

finns det nån länk till "Citat från K&R, svenska upplagan" . ?

[TomasL]

>finns det nån länk till "Citat från K&R, svenska upplagan" . ?

Inte vad jag vet, å andra sidan kostar den inte så mycket, 368:- Ink frakt.
Då inkluderar den också bok nr 2 "Programmeringsspråket C - Lösningarna"

ISBN 0130282774

[speakman]

Jag vet en sak som definitivt inte är bra med VC++ 6.0, och det är när detta meddelande börjar dyka upp:
fatal error C1001: INTERNAL COMPILER ERROR

Sedan är det tji helvete att få den att kompilera på rätt vis...

Microsoft har "accepterat" det som en bugg sedan länge, men någon fix finns inte.
Och inte finns källkoden tillgänglig för egen felsökning heller...

Lösningen blev att köra Dev-C++ IDE och mingw32-kompilatorn. Funkar klockrent.

Mvh
speakman

[JJ]

C-standarden pekar ut att vissa saker är implementationsberoende, dvs två kompilatorer kan göra vissa saker olika samtidigt som båda följer standarden. Andra saker är "ej definierade".

Vill man vara säker på att ens kod fungerar för olika kompilatiorer så får man se till att hålla sig till portabla konstruktioner.

[ajo]

Skulle tro att det är upp till kompilatorn att bestämma hur dom ska placeras. Jag tror på teorin att den inte vill lägga samma bitfield över flera bytes. Kompilatorn är antagligen inte "smart" nog att förstå hur bitarna skall pusslas ihop för att ta upp så lite plats som möjligt men samtidigt inte överlappa. Koden nedan ger sizeof 3 och är samma, fast i annan ordning så kompilatorn får det lättare?

Kod: Markera allt

struct Time 
{ 
   unsigned char 
               b0 : 5, 
               b3 : 1, 
               b4 : 1, 
               b5 : 1, 
               b1 : 5, 
               b2 : 5, 
               b6 : 1; 
}; 

[gille]

ajo:
Ett exempel:

Kod: Markera allt

struct apa {
 int a;
 int b;
};

I standarden för C är det definerat att addressen för a är lägre än b. Man får alltså inte flytta om hur man vill.