Go Down

Topic: problema atoi() (Read 9838 times) previous topic - next topic

gpb01


Attento!
non puoi scrivere commenti nel #define

devi spezzare le righe

--> http://arduino.cc/en/Reference/Define


Scusa Paolo, ma nel link riportato non mi sembra si dica che le #define non possano essere seguite da commenti ... nei "Tip" si indica solo che :

1. La #define NON deve essere conclusa con il ";" come invece va normalmente fatto con le altre istruzioni
2. La #define NON deve contenere il segno di "=" per l'assegnazione di un valore

... dove vedi che NON deve contenere commenti ???  Io li ho sempre usati senza alcun problema ... ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

PaoloP

Ho ricontrollato la cosa e in effetti i commenti vengono eliminati prima di passare il codice al pre-processore.
Comunque in caso di bug il testo potrebbe essere accodato al define. Vedi ad esempio il bug dell'IDe quando, in alcuni casi si usa il /* */ su più righe.
Quindi diciamo che non è un obbligo ma una buona prassi.  :smiley-mr-green:

leo72

Anch'io ero della convinzione che i commenti cozzassero in fase di compilazione. Tant'è che non più di un paio di giorni fa un utente aveva un problema simile e togliendo i commenti dal #define aveva risolto i suoi guai.

gpb01


Ho ricontrollato la cosa e in effetti i commenti vengono eliminati prima di passare il codice al pre-processore.
...


... che sarebbe il corretto comportamento secondo le specifiche C99 (http://www.open-std.org/JTC1/sc22/wg14/www/docs/n1124.pdf) ;)

Ad esempio, GNU C, seguendo dette specifiche, converte i commenti in uno spazio prima di processare il codice (http://gcc.gnu.org/onlinedocs/gcc-2.95.3/cpp_1.html al punto 1.1) ...

... in ogni caso buono a sapere che, con l'IDE di Arduino, questo potrebbe a volte creare problemi.

Grazie,

Guglielmo
Search is Your friend ... or I am Your enemy !

leo72

Però c'è da dire anche che noi stiamo usando avr-gcc, non gcc. E non è detto che tutto quello che è supportato da gcc lo sia anche su avr-gcc e nello stesso modo.

gpb01


Però c'è da dire anche che noi stiamo usando avr-gcc, non gcc. E non è detto che tutto quello che è supportato da gcc lo sia anche su avr-gcc e nello stesso modo.


Si, si, ovvio Leo, difatti concludevo dicendo che era buono a sapersi che con avr-gcc ci possono essere problemi (anche se, almeno dalla 1.xx, sembrerebbe che i commenti // vengano correttamente gestiti. Non so quelli /*  */) ;)

Guglielmo

Search is Your friend ... or I am Your enemy !

leo72


Si, si, ovvio Leo, difatti concludevo dicendo che era buono a sapersi che con avr-gcc ci possono essere problemi (anche se, almeno dalla 1.xx, sembrerebbe che i commenti // vengano correttamente gestiti. Non so quelli /*  */) ;)

Giorni fa mi pare che qualcuno (lesto, forse?) si fosse lamentato del fatto che aveva scoperto che alcuni commenti erano gestiti male.
Non ritrovo la discussione, però...

lestofante

no, non ero io ma ricordo qualcosa sul fatto di commentare le include con /**/ venisse ignorato o qualcosa di simile.

Per quanto riguarda le define, io credo che semplicemente il pre-compilatore se ne "sbatta" del commento e copi TUTTO quello dopo il nome delle define al suo posto...
quidi per esepio
Code: [Select]

esegui(DEFINE);

diventa
Code: [Select]

esegui(15 //numero di led);


Quote
che sarebbe il corretto comportamento secondo le specifiche C99

credo che avr-gcc usa il C90 con un pizzico di fantasia (cerca -std=):

http://ccrma.stanford.edu/planetccrma/man/man1/avr-gcc.1.html
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

Maurotec

In avr-gcc ci sono tutti gli standard di gcc, solo che tramite IDE arduino non è possibile passare argomenti al compilatore e quindi bisogna convivere con gli argomenti preparati dal team. Questa è il prezzp da pagare per la semplicità e l'affidabilità di Arduino IDE.

Io non mai usato commenti nelle define, forse perchè un tempo il C si incasinava, poi con arduino non mi sono neanche chiesto se potevo usare i commenti sulla stessa riga, me ne sono andato per come ero abbituato.

In ogni caso e sempre una buona abitudine perchè quella volta che passi ad ANSI C sicuramente vengono fuori i problemi.

Ciao.

gpb01

#24
Mar 27, 2013, 07:19 am Last Edit: Mar 27, 2013, 07:27 am by gpb01 Reason: 1

...
In ogni caso e sempre una buona abitudine perchè quella volta che passi ad ANSI C sicuramente vengono fuori i problemi.
...


Bé, in realtà sembrerebbe che le specifiche ANSI C originali non si occupavano proprio di cosa fa il pre-processore (http://eli-project.sourceforge.net/c_html/c.html#s4 vd. Section 4), diversamente dalle specifiche C90 e poi C99 ... ;)

Guglielmo
Search is Your friend ... or I am Your enemy !

PaoloP

Quindi non mettete commenti nei #define e vivete felici.  :smiley-mr-green:

lestofante



...
In ogni caso e sempre una buona abitudine perchè quella volta che passi ad ANSI C sicuramente vengono fuori i problemi.
...


Bé, in realtà sembrerebbe che le specifiche ANSI C originali non si occupavano proprio di cosa fa il pre-processore


e quindi ognuno fa come più gli piace
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

leo72


Quindi non mettete commenti nei #define e vivete felici.  :smiley-mr-green:

+1
Mai messi. Sempre prima.

gpb01


+1
Mai messi. Sempre prima.


-1
Sempre messi (... fin dai tempi di LabWindows, ANSI C di National Instruments ... anni '90 ... chi se lo ricorda ?) e mai avuti problemi ...  :smiley-mr-green: :smiley-mr-green: :smiley-mr-green:

Guglielmo
Search is Your friend ... or I am Your enemy !

PaoloP

@Guglielmo
Il giorno che Arduino darà problemi "strani", ricordati del tuo post.  ]:D ]:D

Go Up