Embedded systems programmers worldwide earn failing grades in C

[legacy]

• 

dead

[cdimauro]

• 

Già. E il C è un linguaggio abbastanza piccolo a livello di caratteristiche.

Ovviamente noi italiani siamo gli ultimi in classifica...

[TheKaneB]

• 

Cani -_-

[TheKaneB]

• 

Sul K&R c'è scritta sta cosa

Io l'ho usata per scrivere stringhe che contenevano andate a capo \n, in modo da rendere più leggibile la cosa:

Codice: [Seleziona]

const char *esempio = "Questa stringa prima o poi\n"
                      "andrà a capo.";


[Z80Fan]

• 

Come caratteristiche sì, però ha delle cosine nascoste (e poco usate) che quando le vedi dici "wtf?!"

Più che altro, la roba che spesso frega è l 'undefined behaviour, la specifica ne é piena; praticamente quasi ogni volta che c'è da decidere un piccolo punto poco chiaro, lo buttano nel bidone del u.b. e pace fatta.

Ben poi i programmatori che devono stare attenti, peggio ancora é proprio quando pensi "beh, ma è OVVIO che funziona così, non é logico diversamente" che appare il tranello. Vai ben poi te a trovarlo...

[TheKaneB]

• 

Come caratteristiche sì, però ha delle cosine nascoste (e poco usate) che quando le vedi dici "wtf?!"

Più che altro, la roba che spesso frega è l 'undefined behaviour, la specifica ne é piena; praticamente quasi ogni volta che c'è da decidere un piccolo punto poco chiaro, lo buttano nel bidone del u.b. e pace fatta.

Ben poi i programmatori che devono stare attenti, peggio ancora é proprio quando pensi "beh, ma è OVVIO che funziona così, non é logico diversamente" che appare il tranello. Vai ben poi te a trovarlo...

yep, questo problema ce l'ha anche il C++ purtroppo, e ho provato sulla mia pelle la rogna di aggirare i vari comportamenti undefined facendo test incrociati con 2 compiler diversi (GCC vs MSVC), specialmente riguardo le enum (che per MSVC fanno anche da namespace, mentre per GCC no) e i template (che su GCC hanno/avevano diverse limitazioni per i template ricorsivi).

[TheKaneB]

• 

Ho appena fatto i due test per curiosità e in entrambi (C e C++ embedded) ho dato 7 risposte corrette su 10.

Tra gli errori che ho fatto, una domanda chiedeva quali costrutti erano validi, di cui 2 facevano pena stilisticamente e io per istinto ho risposto quello "best practice" anche se erano tutti validi.
Un altro errore riguardava il reinterpret_cast (avevo risposto che per quella situazione serviva lo static_cast) e un altro errore riguardava una roba che è "undefined" ma per esperienza so che GCC si comporta in un certo modo (quindi credevo che fosse parte dello standard).

Interessante il commento di un tizio riguardo questi test:

Gentlemen, gentlemen... Let's just sum this whole discussion up simply with what I saw this time and so many times before in my 25 years of programming C for embedded and non-embedded applications, and elsewhere in life. The test was designed by a company wanting to sell us THEIR training, to show us how much we needed said training, and how little we remembered about the trivia associated with programming in C/C++. As such, the test did not address REAL knowledge and practice issues, but nuance and inuendo questions about code no self-respecting experienced professional embedded software developer would write. Sadly, Mr. Barr is missing the experience to see through this and published an article embellishing the results of the Netrino sales test. I do think Mr. Barr owes the profession an apology.

Devo dire che un po' ha ragione, perchè in effetti tutti i dubbi che ho avuto li avrei risolti in 30 secondi con il manuale di C o C++ sotto braccio (quando sviluppavo a basso livello avevo sempre il manuale con me, per non sbagliare sulle cose contorte), ma per onestà verso il quiz ho risposto per quello che ricordavo.

Se volete fare il test e postare le vostre impressioni, la registrazione al sito è gratuita ma per un cazzo di bug non ti fa cambiare la password, quindi fate la registrazione, fate il login provvisorio e fate subito il test

[TheKaneB]

• 

Ad ogni modo qualsiasi progetto embedded/mission critical seleziona sempre un subset di un linguaggio ed applica dei coding convention e style molto rigorosi. Padroneggiare un linguaggio quindi serve molto relativamente (ed avrebbe senso solo se il linguaggio è davvero semplice)

Sul K&R c'è scritta sta cosa

Ah..
Io il C l'ho imparato altrove, il K&R l'ho solo consultato (lo trovo irritante per studiarci programmazione in modo serio)

yep.

Ah, un'altra cosa che mi ha lasciato interdetto, ma ho risposto correttamente, era una domanda sull'Exception Handling nel quiz C++ Embedded.
Che io sappia, in molti progetti embedded (per esempio PIC o AVR, compreso Arduino) il runtime C++ è parecchio ridotto per occupare meno memoria e una delle caratteristiche che spesso saltano è proprio questa. Spesso vengono zappate via anche le funzioni virtuali.

[Z80Fan]

• 

@TheKaneB:
Già, capita anche a me e il gioco che sviluppo: io su Linux/gcc , il mio amico/collaboratore su Windows /vc++, e abbiamo penato molto sopratutto con gli enum (gcc aveva già enum class da c++11), e altre cosucce non supportate dall'uno o dall'altro.

Ora sono sul cellulare, quando arrivo a casa provo anche io il test.

[TheKaneB]

• 

Ah..
Io il C l'ho imparato altrove, il K&R l'ho solo consultato (lo trovo irritante per studiarci un linguaggio di programmazione in modo serio)

Io inizialmente l'ho imparato dal K&R, ho fatto un paio di cosine sul Linux Kernel (ero ancora un niubbo), poi ho iniziato a lavorare e mi hanno bastonato come un cane e mi hanno insegnato a programmare correttamente in C con uno "stile a oggetti" moderno (K&R invoglia lo spaghetti-code e l'uso selvaggio di macro, tricks e cast selvaggi)

[TheKaneB]

• 

Non conosco i dettagli implementativi, ma con il C++ su Arduino, se abilitassero l'exception handling non avresti più spazio in Ram. Lo spazio su flash è poi veramente ridotto. Un helloworld che blinka un LED occupa un centinaio di bytes se non ricordo male.

[Z80Fan]

• 

Non conosco i dettagli implementativi, ma con il C++ su Arduino, se abilitassero l'exception handling non avresti più spazio in Ram. Lo spazio su flash è poi veramente ridotto. Un helloworld che blinka un LED occupa un centinaio di bytes se non ricordo male.

Beh, c'è da dire che le librerie Arduino sono dei mattoni allucinanti.
C'era un progetto che le ha riscritte per renderle più leggere, ma non ricordo il nome.

Un'implementazione dell'exception handling in realtà si può far tale da usare pochissimo spazio dati, con però un costo lato codice/costanti. Avevo indagato un po' di tempo fa sulla faccenda; non ve la descrivo perché sono via cellulare, però poi ne si può discutere se interessa. (metti che ci viene fuori un thread come quello sulle vtable. )

[TheKaneB]

• 

@Z80Fan: sicuramente sarebbe interessante approfondire la questione, anche perchè l'exception handling è una funzione comoda che consente di scrivere codice più sicuro senza dilungarsi troppo con if innestati e relativi codici di controllo.

[TheKaneB]

• 

Se il C è usatissimo in embedded un motivo c'è
Comunque negli ultimi anni le cose sono molto cambiate dato che nell'embedded si trova un hardware più spinto

E' vero, ma è anche molto più comodo e sicuro scrivere in C++, specialmente se il firmware da sviluppare si vuole rendere un pelino più facile da mantenere e portare in futuro su altre piattaforme. Con tutti i suoi difetti, il C++ resta comunque un linguaggio ad oggetti molto versatile (forse "troppo" versatile).

[TheKaneB]

• 

Appunto! con le exceptions si fa molta meno fatica a seguire il flusso di programma
Tutto ciò che devia dal flusso principale spara un'eccezione e vive tranquillo. Molto più elegante e sicuro