Varför införa ytterligare en felkälla, makron kan ge de mest konstiga felen so dessutom är synnerligen svåra att hitta.
Dessutom får man på sin höjd en varning om man skriver samma #define på ett annat ställe.
Använder man const och enum, så blir det kompileringsfel i stället, vilket är betydligt bättre än en varning som försvinner i textmängden.
Men visst i småprojekt med någon enstaka källkodsfil och några hundra rader typ, så kan det ju vara ok, möjligtvis.
Har man ett stort projekt, så skall makron och defines vara bannlysta. (stora projekt tenderar till att bli tillräckligt o-överskådliga ändå, utan att blanda in men massa makron och defines som rör om grytan ytterligare.
Vi själva undviker makron, dock har vi en del defines, men de håller vi på att jobba bort, och ersätter med enums och const.
Dock är vårt projekt lite större än de vanliga.
Förstår inte vad som är "invalid expression" i C
Re: Förstår inte vad som är "invalid expression" i C
Det är intressant att #defines ska undvikas - då nära nog ALLA .H-filer som definierar pinnar osv. i µC består nästan uteslutande av #define's.
Men att skapa en macro för att t.ex. höja-och-sänka en strobe eller liknande är för mig bara lathet och ska undvikas. Då är det bättre att skapa en inline-funktion som gör detta.
Själv definierar jag många #define för t.ex. de 4 debug/Whatever LED (LED_Green, LED_Yellow, LED_Red, LED_Blue) som finns på styrkortet, vilken hastighet µC'n ska köra osv.
Finns det en konstant som man använder många ställen definierar jag den just ett enda ställe för att alla instanser refererar till den och ja, då kan en konstant vara bättre ur felmeddelande-hänseende. Men hur gör man om det är en specifik portpinne då?
Jag använder #define för att slå på/av funktioner i hårdvaran (USE_RS232_A, USE_RS232_B, USE_RS485, USE_CMT0, USE_HOCO50MHZ osv.)
Men jag håller med om att man ska tänka en del innan man kastar runt #define's och man ska ha några klara regler för var och hur man tillåter sig att använda #define.
Jag har t.ex. färdiga standard-filer för t.ex. RS232-kommunikation och då jag använder interruptstyrd buffring behöver jag att definiera storleken på en buffer. Det sker via #define och när den filen tas in kollar kompilern om rätt #define finns och använder den, i annat fall finns en default #define som sätter en minimal bufferstorlek.
Men att skapa en macro för att t.ex. höja-och-sänka en strobe eller liknande är för mig bara lathet och ska undvikas. Då är det bättre att skapa en inline-funktion som gör detta.
Själv definierar jag många #define för t.ex. de 4 debug/Whatever LED (LED_Green, LED_Yellow, LED_Red, LED_Blue) som finns på styrkortet, vilken hastighet µC'n ska köra osv.
Finns det en konstant som man använder många ställen definierar jag den just ett enda ställe för att alla instanser refererar till den och ja, då kan en konstant vara bättre ur felmeddelande-hänseende. Men hur gör man om det är en specifik portpinne då?
Jag använder #define för att slå på/av funktioner i hårdvaran (USE_RS232_A, USE_RS232_B, USE_RS485, USE_CMT0, USE_HOCO50MHZ osv.)
Men jag håller med om att man ska tänka en del innan man kastar runt #define's och man ska ha några klara regler för var och hur man tillåter sig att använda #define.
Jag har t.ex. färdiga standard-filer för t.ex. RS232-kommunikation och då jag använder interruptstyrd buffring behöver jag att definiera storleken på en buffer. Det sker via #define och när den filen tas in kollar kompilern om rätt #define finns och använder den, i annat fall finns en default #define som sätter en minimal bufferstorlek.
Re: Förstår inte vad som är "invalid expression" i C
Naturligtvis har #define sin plats, vid till exempel villkorlig kompilering, då är #define oumbärligt.
Gällande det där med portpinnar osv, i uChips includefiler så är alla portar, register, flaggor, bitar mm antingen enumrerade eller structade konstanter, det existerar inga defines i dem för detta, enbart för att villkora processortyp.
Gällande det där med portpinnar osv, i uChips includefiler så är alla portar, register, flaggor, bitar mm antingen enumrerade eller structade konstanter, det existerar inga defines i dem för detta, enbart för att villkora processortyp.
