|
|
|
|
Strumenti |
08-07-2014, 11:04 | #21 | |||
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Quote:
Quote:
Quote:
Quando viene raggiunta la } che termina il main lo Standard corrente *garantisce* che il valore ritornato sia 0. Altro che meno portabile, 0 è il valore di ritorno portabile per eccellenza. Sempre per lo Standard, 0 e EXIT_SUCCESS sono inoltre del tutto equivalenti nel segnalare "successful completion". Da notare che il valore di EXIT_SUCCESS è implementation defined, e quindi potrebbe essere diverso dal convenzionale 0 (anche se non ho mai incontrato un'implementazione così). Se così fosse, lo 0 ritornato automaticamente o equivalentemente tramite "return 0;" o "exit(0)" resterebbe tra i due il valore *noto* e garantito per tutti a prescindere. E' anche per questo motivo che tutti lo usano, che vari lint lo hanno sempre riconosciuto e si aspettano di vederlo pena sollevare warnings, etc. "return 0;" è tanto nello Standard quanto ovunque, dallo stesso K&R seconda edizione al King al Van Der Linden a tutti gli altri buoni autori. Le uniche discussioni degna di nota che riguardano ugualmente 0 e EXIT_SUCCESS sono quelle sui freestanding environment, dove quello che accade al termine dei programmi non è standardizzato: il (mancato) senso nel ritornare in automatico un valore in un ambiente dove main non è magari supposto ritorni alcunchè oppure dove non è previsto ritorni del tutto, le questioni di unreachable code e via dicendo. Ma questo è un problema delle specifiche ANSI che sono da sempre incomplete quando non decisamente fatte male, spesso più d'intralcio che chiarificatrici. In C89 invece la situazione è diversa - main senza un return con un valore (compatibile con il tipo ritornato da main) ritorna uno stato indefinito all'ambiente chiamante. Nel caso di un return e dell'equivalente exit(), 0 e EXIT_SUCCESS sono ancora una volta garantite come assolutamente equivalenti per segnalare successo (e come prima, con zero che è universalmente noto e accettato mentre l'altro resta dipendente dall'implmentazione). Prima ancora, mi scoccio d'arrivarci che penso basti così. Non che m'aspettassi qualcosa di diverso da come t'eri presentato. Ma vabbè, almeno le prime pagine dello Standard prima di buttarsi a farsi ganzi in giro, i "mesi di trattazione" e trollate varie sugli altri linguaggi annesse... Ultima modifica di van9 : 08-07-2014 alle 13:46. |
|||
08-07-2014, 13:42 | #22 | |
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Quote:
|
|
08-07-2014, 13:55 | #23 |
Senior Member
Iscritto dal: Dec 2006
Messaggi: 3808
|
@van9 stai sbagliando, sia in relazione al problema sia in relazione allo standard, questo è tutto quello che posso dire .
|
08-07-2014, 14:23 | #24 |
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Si. Se poi vuoi spendere qualcosa compra "C Programming: A Modern Approach" di King (2a edizione), è per principianti e così dettagliato che contiene praticamente tutto quello a cui accennavo (per tanti altri libri - Deitel compreso - non è così).
|
08-07-2014, 18:34 | #25 | |||
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Quote:
a e b sono due array di tipo array-of-T, con T := int. In "a = b", viene formata una nuova espressione per via del fatto che b decade (salvo eccezioni) a puntatore. La trasformazione che genera la nuova espressione è una certa t: t :: array-of-T -> pointer-to-Tprende la b di "int b[20]" e genera un puntatore che sostituiamo idealmente alla b in "a = b". Un altro esempio di possibile trasformazione è: t' :: array-of-T -> pointer-to-array-of-Tovvero quella che verrebbe applicata se nel programma ci fosse "a = &b". b in tutto questo, è e resta di tipo array-of-T. Dopo di che, assegnare due array è illegale. Non si può assegnare un tipo pointer-to-T ad un tipo array-of-T. Un lvalue di tipo array-of-T è per definizione non modificabile. Il tuo programma non compila per via di quanto esposto sopra. I puntatori costanti c'entrano meno di nulla. Se pensi di non poter assegnare ad a perché questo è un "puntatore costante" ti sbagli e non hai capito bene come funziona il C. 'Ste quattro cazzate è quanto genera confusione da decenni. Ogni volta che qualche faina per abbreviare parla di "equivalenza" e robe simili, non aiuta nessuno. Due cose sono equivalenti se e solo se le puoi sempre e comunque sostituire una all'altra. Arrays e pointers sono entità diverse e non equivalenti. Nomi di arrays e constant pointers sono entità diverse e non equivalenti. I buoni libri tipo il King e le note di Steve Summit (curatore delle faq di comp.lang.c) non entrano così nel dettaglio che manco ce n'è bisogno, ma nemmeno affermano il falso come in "(Il nome di) un array è un puntatore costante al primo elemento". Usano una via di mezzo con anche spiegazioni del tipo """il nome di una variabile array è usata come un "puntatore costante", salvo ad esempio il caso che venga passata come parametro""", con tanto di virgolettato che enfatizza l'analogia. Posto che si è chiarito già che il nome di un array non è un puntatore, che gli array e i puntatori non sono equivalenti/intercambiabili e via dicendo... diviene accettabile. Virgolettati, "quasi", "potrebbe" accompagnati da solide precisazioni sono (in my book) molto diversi dal tuo "in soldoni". Personalmente sono contrario ad analogie e similitudini se non accompagnate dai sacrosanti "assiomi" del caso ("A non è B; ci sono comunque le circostanze a,b e c in cui B può comparire al posto di A" e via così). Quote:
Quote:
Efficace esposizione dell'aspetto didattico/sociale della faccenda; unita al lato formale che ho esposto sopra spero non ti lascino più dubbi al riguardo. Nota anche che tra i commenti lo stesso Burr di prima non si lamenta. Come vedi (e come già con il nostro OP) le spiegazioni alla "for most purposes it is" e "in soldoni" portano solo errori software, di comprensione e quel falso senso di sicurezza ("ho capito", "so come funziona") che poi alla fine genera danni e noie varie nel lungo termine. Ultima modifica di van9 : 08-07-2014 alle 19:06. |
|||
08-07-2014, 18:52 | #26 | ||
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Quote:
"""ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570""" http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf Quote:
Codice:
#include <inttypes.h> #include <wchar.h> int main(void) { uintmax_t i = UINTMAX_MAX; // this type always exists wprintf(L"The largest integer value is %020" PRIxMAX "\n", i); return 0; } |
||
08-07-2014, 20:25 | #27 | |
Member
Iscritto dal: Nov 2012
Messaggi: 126
|
Quote:
dimenticavo: se non sono la stessa cosa, e lo stai confermando tu adesso, è ovvio che non sono *mai* la stessa cosa come ho precisato io. Perché mi contesti quest'ultima quindi? Sono o non sono la stessa cosa? Ultima modifica di van9 : 08-07-2014 alle 20:34. |
|
Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 19:14.