Newsgroup: it.lavoro.informatica
Titolo: Fibonacci in cobol SAPIENTONI!!!!!!!

Iterative
 
Program-ID. Fibonacci-Sequence.
Data Division.
Working-Storage Section.
   01  FIBONACCI-PROCESSING.
     05  FIBONACCI-NUMBER  PIC 9(36)   VALUE 0.
     05  FIB-ONE           PIC 9(36)   VALUE 0.
     05  FIB-TWO           PIC 9(36)   VALUE 1.
   01  DESIRED-COUNT       PIC 9(4).
   01  FORMATTING.
     05  INTERM-RESULT     PIC Z(35)9.
     05  FORMATTED-RESULT  PIC X(36).
     05  FORMATTED-SPACE   PIC x(35).
Procedure Division.
   000-START-PROGRAM.
     Display "What place of the Fibonacci Sequence would you like 
(<173)? " with no advancing.
     Accept DESIRED-COUNT.
     If DESIRED-COUNT is less than 1
       Stop run.
     If DESIRED-COUNT is less than 2
       Move FIBONACCI-NUMBER to INTERM-RESULT
       Move INTERM-RESULT to FORMATTED-RESULT
       Unstring FORMATTED-RESULT delimited by all spaces into 
FORMATTED-SPACE,FORMATTED-RESULT
       Display FORMATTED-RESULT
       Stop run.
     Subtract 1 from DESIRED-COUNT.
     Move FIBONACCI-NUMBER to INTERM-RESULT.
     Move INTERM-RESULT to FORMATTED-RESULT.
     Unstring FORMATTED-RESULT delimited by all spaces into 
FORMATTED-SPACE,FORMATTED-RESULT.
     Display FORMATTED-RESULT.
     Perform 100-COMPUTE-FIBONACCI until DESIRED-COUNT = zero.
     Stop run.
   100-COMPUTE-FIBONACCI.
     Compute FIBONACCI-NUMBER = FIB-ONE + FIB-TWO.
     Move FIB-TWO to FIB-ONE.
     Move FIBONACCI-NUMBER to FIB-TWO.
     Subtract 1 from DESIRED-COUNT.
     Move FIBONACCI-NUMBER to INTERM-RESULT.
     Move INTERM-RESULT to FORMATTED-RESULT.
     Unstring FORMATTED-RESULT delimited by all spaces into 
FORMATTED-SPACE,FORMATTED-RESULT.
     Display FORMATTED-RESULT.
 
 
IDENTIFICATION DIVISION.
PROGRAM-ID. fibonacci-main.
 
DATA DIVISION.
WORKING-STORAGE SECTION.
01  num                                 PIC 9(6) COMP.
01  fib-num                             PIC 9(6) COMP.
 
PROCEDURE DIVISION.
     ACCEPT num
     CALL "fibonacci" USING CONTENT num RETURNING fib-num
     DISPLAY fib-num
     .
END PROGRAM fibonacci-main.
 
IDENTIFICATION DIVISION.
PROGRAM-ID. fibonacci RECURSIVE.
 
DATA DIVISION.
LOCAL-STORAGE SECTION.
01  1-before                            PIC 9(6) COMP.
01  2-before                            PIC 9(6) COMP.
 
LINKAGE SECTION.
01  num                                 PIC 9(6) COMP.
 
01  fib-num                             PIC 9(6) COMP BASED.
 
PROCEDURE DIVISION USING num RETURNING fib-num.
     ALLOCATE fib-num
     EVALUATE num
         WHEN 0
             MOVE 0 TO fib-num
         WHEN 1
             MOVE 1 TO fib-num
         WHEN OTHER
             SUBTRACT 1 FROM num
             CALL "fibonacci" USING CONTENT num RETURNING 1-before
             SUBTRACT 1 FROM num
             CALL "fibonacci" USING CONTENT num RETURNING 2-before
             ADD 1-before TO 2-before GIVING fib-num
     END-EVALUATE
     .
END PROGRAM fibonacci.
 
-- 
(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria, 
non è un disegno o un ricamo; non si può
fare con tanta eleganza, con tanta serenità e delicatezza, con tanta 
grazia e cortesia. La rivoluzione è un atto
di violenza, è l'azione implacabile di una classe che abbatte il potere 
di un'altra classe. (Mao Tze-tung)

 Iterative
 
ITERATIVE PARTE DA QUI BAMBOCCINI BELLI DEL NONNO

IL RECURSIVE PARTE DA QUI...BAMBOCCINI BELLI DEL NONNO

ORA LA QUESTIONE è ...MA SE NON CONOSCETE COSA CAZZO PARLATE A FARE?
 
LA DIFFERENZA TRA ME E VOI E' CHE VOI QUELLO CHE SO IO NON LO SAPETE E 
NON LO VOLETE IMPARARE, MENTRE IO OLTRE A QUELLO CHE CONOSCO SO TUTTO 
QUELLO CHE SAPETE VOI....E MOLTO ALTRO.
 
BAMBOCCINI PRESUNTUOSI!



 
Python: 
 
def fib(n):
    if n == 0:
        return 0
    elif n == 1:
        return 1
    else:
        return fib(n-1) + fib(n-2)
 
Muahuahuah
 
-- 


FRAGILE, FRAGILISSIMO ED ATTACCABILE...
comunque la questione non è quella è che qualcuno diceva che in cobol 
NON SI POTEVA FARE


 [...]
 
Minchia, in assembly veniva più corto!!!! ROTFL
 

 NON SI POTEVA FARE
 
Certo che si puo` fare. Si puo` andare anche in Cina a piedi, se e` per questo.


certamente se poi lo facevi in assembler lavorando solo sui registri 
veniva ancora piu corto...non si capiva un cazzo ma veniva cortissimo e 
lo leggeva solo chi lo aveva scrtitto.....
BAMBOCCIONI....NON SAPETE DI COSA STATE PARLANODO...mi fate perfinanco 
tenerezza!


On Saturday, 21 February 2015 17:47:01 UTC, Delta11  wrote:
 
[...]
 
"due to its declining popularity and the retirement of experienced COBOL programmers, programs are being migrated to new platforms, rewritten in modern languages or replaced with software packages. Most programming in COBOL is now purely to maintain existing applications." (pagina su "COBOL", Wikipedia)
 
Ma che peccato!!!

 lo leggeva solo chi lo aveva scrtitto.....
 
Perche` il codice COBOL che hai postato tu e` invece leggibilissimo, vero? :D


Ok, ho capito come mai anche nei post mischi le maiuscole con le 
minuscole così ad minchiam :-D
 


assembler ibm 360
 
For maximum compatibility, this program uses only the basic instruction 
set.
 
FIBONACC CSECT
          USING  FIBONACC,R12
SAVEAREA B      STM-SAVEAREA(R15)
          DC     17F'0'
          DC     CL8'FIBONACC'
STM      STM    R14,R12,12(R13)
          ST     R13,4(R15)
          ST     R15,8(R13)
          LR     R12,R15
*        ----   CODE
          LA     R1,0            f1=0
          LA     R2,1            f2=1
          LA     R4,1            i=1
          LA     R6,1
          LH     R7,N
LOOP     BXH    R4,R6,ENDLOOP   for i=2 to n
          LR     R3,R2
          AR     R3,R1           f3=f1+f2
          CVD    R4,P            i
          UNPK   Z,P
          MVC    C,Z
          OI     C+L'C-1,X'F0'
          MVC    WTOBUF+5(5),C+11
          CVD    R3,P            f3
          UNPK   Z,P
          MVC    C,Z
          OI     C+L'C-1,X'F0'
          MVC    WTOBUF+12(10),C+6
          WTO    MF=(E,WTOMSG)		
          LR     R1,R2           f1=f2
          LR     R2,R3           f2=f3
          B      LOOP            next i
ENDLOOP  EQU    *
*        ----   END CODE
RETURN   EQU    *
          LM     R14,R12,12(R13)
          XR     R15,R15
          BR     R14
*        ----   DATA
N        DC     H'46'           max i
P        DS     PL8
Z        DS     ZL16
C        DS     CL16
WTOMSG   DS     0F
          DC     H'80'
          DC     H'0'
WTOBUF   DC     CL80'fibo(12345)=1234567890 '
          YREGS
          END    FIBONACC



A parte l' immensità di codice da scrivere, riferendomi  ai compilatori 
sui vecchi maninframe non su quelli dei pc, il COBOL non ha la 
local-storage ma solo la working-storage (per chi viene dal C solo 
variabili globali)
Quindi  non avendo lo stack le procedure ricorsive sono impossibili a 
meno di simulare lo stack in qualche modo.
Poi so benissimo che i compilatori su pc (e forse su quache mainframe 
piu moderno) hanno aggiunto altre futeres tra cui lo stack ed i puntatori
 
#include<iostream>
using namespace std;
main(){
    int n, c, first = 0, second = 1, next;
    cout << "Enter the number of terms of Fibonacci series you want" << 
endl;
    cin >> n;
    cout << "First " << n << " terms of Fibonacci series are :- " << endl;
    for ( c = 0 ; c < n ; c++ ) {
       if ( c <= 1 )
          next = c;
       else {
          next = first + second;
          first = second;
          second = next;
       }
       cout << next << endl;
    }
    return 0;
}
 
 
 
questa è la versione C++
Ora, qual è la la piu leggibile ?
 
da
http://www.programmingsimplified.com/cpp/source-code/fibonacci-series
 
 
 
 
 

  [...]
 >
Visto? E' uscito la metà dell'altro, sempre pieno di maiuscole comunque.
Qui è più leggibile:
 
http://www.shanetarleton.com/windows-development/x86-assembly/
 
compreso di I/O verso l'utente.
 
E mo come la mettiamo?
 
 
 

 FRAGILE, FRAGILISSIMO ED ATTACCABILE...
 
E allora? Lo hai attaccato? Lo hai disintegrato? 
 
 
-- 

          return fib(n-1) + fib(n-2)
 
Anche se invece di 'fib' lo chiami 'pippo_e_paperino' si capisce AL VOLO 
che è l'algoritmo per Fibonacci.
 
In COBOLONE non si capisce manco se chiami tutto FIBONACCI. Cioè, lo 
intuisci... ma te devi da fidà :-)
 
Porello, il trollone s'è dato la zappa sui piedi da solo...

     int n, c, first = 0, second = 1, next;
 
Magari se usi la firma giusta per main() che e`
 
int main() { ...
 
;)

 ha scritto:

Ahahahahahahah GRANDE! :-D
 
 

 Ora, qual è la la piu leggibile ?
 
C++ FOR EVER!!!
 
 
 


va be,l' ho copiato e non me ne sono accorto
 


sempre, fino a quando non inventeranno di meglio :)
 

 sempre, fino a quando non inventeranno di meglio :)
 
Come Haskell? :)
 
fib 0 = 0
fib 1 = 1
fib n = fib (n-1) + fib (n-2)

 Iterative... 
 
Tutto 'sto casino per una serie di Fibonacci?
Io non lo conosco, il COBOL. Spero sinceramente che non lo conosca manco tu e che in realtà abbia scritto una cosa da principiante.

 QUELLO CHE SAPETE VOI....E MOLTO ALTRO.
 
E HO CREATO IL CIELO E LA TERRA E OGNI LUOGO!

 FRAGILE, FRAGILISSIMO ED ATTACCABILE...
 
Espandi questa affermazione.

 meno di simulare lo stack in qualche modo.
 
Però la ricorsione in genere è un male!
 
:-D
 


Certo. Basta 'a salute e un par de scarpe nove ce puoi gira' tutto er monno.

 int main() { ...
 
Qui però meglio un confronto con una mia memoria storica:
1) la firma di una funzione NON comprende il tipo del valore ritornato;
2) io raramente usavo 'int main', preferivo definire main void.


quello è il C e  le prime versioni del C++
 
in C++ std è un errore omettere il tipo di ritorno di una funzione
in C è valido f() in C++ no, occorre T f() in  cui T puo essere anche void
 
 
 
 

 2) io raramente usavo 'int main', preferivo definire main void.
 
Le uniche signature ammesse dagli standard (C e C++) sono:
 
int main(); // in C++
int main(void); // in C
int main(int argc, char* argv[]);
 
void main() puo` essere supportato da una piattaforma, ma essere del tutto non portabile su altre, quindi meglio attenersi alle prescrizioni ISO.

 in C è valido f() in C++ no, occorre T f() in  cui T puo essere anche void
 
Il tipo int implicito non e` piu` valido neanche in C.
Non per gli standard C99/C11. 
In C90 era ancora consentito.


  Non conosco Haskell ma anche in C++ si possono fare dei gioiellini 
Come questo ad esempio:
 
 
#include <iostream>
 
template <long n>
long fib()  { return fib<n - 1>() + fib<n - 2>(); }
 
 
template <>
long fib<0>() { return 0; }
 
template <>
long fib<1>() { return 1; }
 
int main() { std::cout << fib<10>() << std::endl; }
 
 
 
La cosa bella (l' efficienza è uno dei requisiti del C++)
è che il calcolo viene compiuto a compil time
 
In pratica il compilatore sostituisce fib<10> con il suo valore calcolato
 


Un coltello è male ?
 
E' uno strumento, e come tutti gli strumenti occorre saperlo utilizzare
 
 
Se lo usi per uccidere magari è il male ma per tagliare il pane 
sicuramente no
 
Così è anche la ricorsione
 


OK, grazie per la precisazione
Usando oramai molto poco il C mi sono perso l' ultimo std e comunque 
anche in C uso sempre il tipo di ritorno
 
 


credo che sia anche
int main(int argc, char* argv[],char* environ[]);
 
mai usato comunque
 
 


vuol dire i tuoi programmi c avevano normalmente un exit code casuale.


In effetti io uso spesso void main(void), il compilatore me lo segnala 
come warning, ma se c'e' la funzione main, il programma e' un 
entry-point quindi in genere me ne posso fregare senza conseguenze, per 
la presunzione che chi lo invoca, del valore di ritorno non sa cosa 
farsene o non sa come interpretarlo.

 Così è anche la ricorsione
 
 
parliamone.
 
se il compilatore non implementa la tail call optimization, come ad esempio
java ante 8 ma anche python, una funzione ricorsiva può uccidere anche 
se la usi per tagliare il pane.
 
la ricorsione per essere efficiente non deve consumare stack, altrimenti
hai un limite di profondità di cui non sei a conoscenza mentre scrivi il 
codice. in altre parole inneschi una bomba ad orologeria.
 
diverso il discorso per i linguaggi funzionali, a cui la ricorsione appartiene
come costrutto ma che non hanno (tipicamente) strumenti per implementare
le iterazioni.
 
questa è una disquisizione di guido van rossum a proposito: 
 
http://neopythonic.blogspot.co.uk/2009/04/tail-recursion-elimination.html
 
 
 
 

 
http://neopythonic.blogspot.co.uk/2009/04/tail-recursion-elimination.html
 
Sono abbastanza d'accordo su quello che dice, soprattutto per quanto 
riguarda il debug. Mi interessava un tuo parere.
 
 

 riguarda il debug. Mi interessava un tuo parere.
 
direi che è condivisibile in quanto parla di python (infatti la risposta
breve è " it's simply unpythonic"). in generale non lo è, ma lui non sta
facendo un discorso in generale.


Capisco, ma le asserzioni circa la possibilita' di debug o l'utilizzo 
della programmazione ricorsiva, possono essere estese a qualsiasi 
linguaggio, ovviamente non a linguaggi che non supportano la ricorsione 
(come il cobol 360).

 piu moderno) hanno aggiunto altre futeres tra cui lo stack ed i puntatori
 
Perdonami non ho capito bene. 
Vuoi dire che in COBOL tutte le volte che esci dalla funzione la
 variabile si
 azzera. Quindi sarebbe il contrario: la funzione non imposta il
 valore di una
 variabile globale? 
Tieni presente che potrei non aver capito una ceppa :) 
 
 
-- 

 void main() puo` essere supportato da una piattaforma, ma essere del tutto non portabile su altre, quindi meglio attenersi alle prescrizioni ISO.
 
Questo lo condivido. E' che quando io per motivi vari ho dovuto mollare C++ lo standard ISO era talmente restrittivo che ogniuno faceva un po' quel che voleva (per dire, STL e templating non erano nello standard).
 
-- 
Ciao!
Luca

 E' uno strumento, e come tutti gli strumenti occorre saperlo utilizzare
 
Questo è vero. Ma quante volte viene usato dicendo 'che figo' senza considerare i potenziali problemi e causando potenti mal di testa a chi (io, nel caso) va poi a fare manutenzione?
 
Poi, se sai che cosa stai facendo, e in modo MOLTO limitato, ben venga. Io resto dell'idea che comunque la domanda "devo proprio usarla?" uno se la debba comunque fare.
 
-- 
Ciao!
Luca

 vuol dire i tuoi programmi c avevano normalmente un exit code casuale.
 
Ho scritto in effetti normalmente applicazioni in cui l'exit code era assolutamente irrilevante.
 
-- 
Ciao!
Luca

 diverso il discorso per i linguaggi funzionali, a cui la ricorsione appartiene
 
Ah ecco!
 
-- 
Ciao!
Luca

 Tieni presente che potrei non aver capito una ceppa :)
Ecco, allora tieni presente che parlare di funzioni il COBOL e' un 
azzardo! :)
In ogni caso, ti do' un'informazione: in un programma COBOL non esiste 
lo scope delle variabili, sono solo globali.
Fanne buon uso. :)
 

 Oh bella! A quanto ne so io, la ricorsione per definizione usa stack. Cosa non so?
 
http://en.wikipedia.org/wiki/Tail_call
 
https://wiki.haskell.org/Tail_recursion
 
 

 Ho scritto in effetti normalmente applicazioni in cui l'exit code era assolutamente irrilevante.
 
???
che facessero regolarmente ciò che devono fare oppure no fregava niente a
nessuno? al limite uno mette un return 0, per lo meno se va in
segmentation fault te ne puoi accorgere.

 int main(int argc, char* argv[],char* environ[]);
 
Non e` standard. E` un'estensione dei sistemi UNIX (e neanche supportato su tutti gli UNIX). Lo standard prevede solo le due forme che citavo.

 farsene o non sa come interpretarlo.
 
Usare void main() rende il tuo codice non portabile. Si e` discusso per anni di questo sui vari gruppi (comp.lang.c, per es.). Se te ne freghi della portabilita` e dei warning del compilatore, se usare void main() va bene sulla tua piattaforma, allora okay, ma se punti a rendere il tuo codice portabile, DEVI usare int come valore di ritorno.
 

 Ricordo vagamente che sia la prima versione dello Stroustrup che il libro di Lippman definivano così la firma, e che questo serviva fondamentalmente per individuare quale fosse il metodo corretto da chiamare in una classe che ne avesse di overloaded.
 
Stai parlando di name mangling dei metodi ai fini della risoluzione degli overload. Quello di cui parlo io e` il prototype della funzione/metodo. Il valore di ritorno non viene considerato nel name mangling, perche` il compilatore non sarebbe necessariamente in grado di risolvere chiamate di metodi overloaded basandosi sul solo tipo di ritorno.

 Ho scritto in effetti normalmente applicazioni in cui l'exit code era assolutamente irrilevante.
 
Il problema e` che main() e` un contratto tra l'applicazione e il sistema operativo. Non e` il programmatore che decide se restituire un exit code o meno. Restituire 0 in caso non ci siano errori e` sempre una buona regola, nel caso a qualcuno venga in mente di analizzare il codice di uscita della tua applicazione in un contesto piu` ampio.

 codice. in altre parole inneschi una bomba ad orologeria.
 
Questo pero` non e` necessariamente vero. Certi algoritmi ricorsivi non vanno necessariamente in profondita` senza controllo. Sei tu che stabilisci quando interrompere la ricorsione, e la ricorsione viene MOLTO comoda quando devi lavorare con strutture dati (penso agli alberi) "naturalmente" ricorsive. Io  ho scritto codice ricorsivo sapendo che non sarebbe andato oltre una certa profondita`, e che non avrebbe sicuramente esaurito stack o altre risorse. In questi casi, secondo me, e` importante usare linguaggi in cui la distruzione degli oggetti e` deterministica (come in C++) mentre in quelli garbage-collected bisogna fare molta piu` attenzione. In C++ posso avere codice ricorsivo che, so gia`, alloca una gran quantita` di memoria andando fino al nodo piu` basso di un albero, ma la dealloca deterministicamente risalendo. Ho allocazioni "esplosive" che vengono sempre rilasciate istantaneamente. Con i linguaggi garbage-collected, devo rinunciare a questa garanzia.


In C, in C++ se si omette il return ci pensa la routine di init (quella 
che chiama main) a fare ritornare 0 al kernel
 


quello che affermi è vero, ma ritengo sempre che occorre saperla gestire
 

On Sunday, 22 February 2015 13:50:59 UTC, enoquick  wrote:
 
[...]
Si parlava del caso "void main()"
 


 
Sai che penso in questo caso ?
 
azzi suoi
 
Ognuno è responsabile di quello che fa
 
 


Tu hai ragione, ma se programmo in C lo faccio per OS400, su altre 
piattaforme utilizzo altri linguaggi. Ho smesso di utilizzare il C su 
intel da quando e' scomparso l'OS2, ma anche l'IBM C-Set era permissivo 
in tal senso. Se ho una preoccupazione di piattaforma uso il Java.

 resto dell'idea che comunque la domanda "devo proprio usarla?" uno se la debba comunque fare
 
Concordo. Ma questo vale per tutto. Se e` per questo, molte persone dovrebbero andare piu` a monte, chiedendosi "ma devo proprio fare il programmatore?" :)


Non,non è che le variabili si azzerano
Le variabili sono semplicemente globali
 
Se conosci il C:
 
 
int a;
int f()  {  ... }
 
 
a è globale, non sta nello stack
in cobol si definiscono  nella working-storage
 
 
mentre:
 
int f() { int a;...}
 
a sta nello stack
 
in Cobol si definiscono nella local-storage (per quei compilatori che 
supportano local-storage)
 
 
 
 
 
 


quello non è std, comunque se il compilatore segue lo std la init fa 
ritornare 0
 

 ritornare 0
 
Si`, e vale anche in C, oltre a C++.
 

 segmentation fault te ne puoi accorgere.
 
No; sono convinto, e per la verità la convinzione si è rafforzata negli anni, che sia più proficuo progettare una buona gestione degli errori e un logging adeguato. Se hai fatto bene queste due cose, l'exit code serve davvero a poco.
 
-- 
Ciao!
Luca

 Ognuno è responsabile di quello che fa
 
Ragionamento corretto se te la fai e te la gestisci; se sei in un progetto ampio, che coinvolge più persone e che magari verrà manutenuto nel tempo da altre, non son così sicuro.
 
-- 
Ciao!
Luca

 supportano local-storage)
La mia conoscenza del cobol e' limitata, pero' mi risulta che non sia 
esattamente la stessa cosa. Per quanto ne so, definire una variabile 
nella local-storage section ha come unico effetto che ad ogni chiamata 
viene reinizializzata al valore della sua clausola VALUE.
Correggimi se sbaglio.
 

 Stai parlando di name mangling dei metodi ai fini della risoluzione degli overload. Quello di cui parlo io e` il prototype della funzione/metodo. Il valore di ritorno non viene considerato nel name mangling, perche` il compilatore non sarebbe necessariamente in grado di risolvere chiamate di metodi overloaded basandosi sul solo tipo di ritorno.
 
E mi sa che c'hai ragione, a naso. Vado a verificare...
 
-- 
Ciao!
Luca

 Concordo. Ma questo vale per tutto. Se e` per questo, molte persone dovrebbero andare piu` a monte, chiedendosi "ma devo proprio fare il programmatore?" :)
 
Eh, che drastico! :)
Io ho conosciuto gente che aveva problemi, cui bastava solo qualche spintarella nella giusta direzione.
 
-- 
Ciao!
Luca
 

 Il problema e` che main() e` un contratto tra l'applicazione e il sistema operativo. Non e` il programmatore che decide se restituire un exit code o meno. Restituire 0 in caso non ci siano errori e` sempre una buona regola, nel caso a qualcuno venga in mente di analizzare il codice di uscita della tua applicazione in un contesto piu` ampio.
 
Per carità, visto il costo, metterle un exit code potrebbe essere una buona pratica. Il mio considerarlo così poco è perché nei contesti in cui ho operato in effetti  a) l'esecuzione parte con la partenza del SO e deve terminare con la terminazione del SO, e tutto quel che accade nel mezzo deve essere gestito internamente evitando accuratamente l'uscita o b) ho a che fare con applicativi dotati di interfaccia utente. Diventa invece molto rilevante in applicazioni che potrebbero essere usate come componenti di uno script - però allora l'exit code viene progettato in modo adeguato!
 
-- 
Ciao!
Luca

 No; sono convinto, e per la verità la convinzione si è rafforzata negli anni, che sia più proficuo progettare una buona gestione degli errori e un logging adeguato. Se hai fatto bene queste due cose, l'exit code serve davvero a poco.
 
non mi pare proprio.
 
come lo capisce il chiamante se il tuo programma ha fatto quello che doveva
fare? per esempio in uno script, dove magari farebbe comodo interrompersi
se qualcosa è andato storto. 
e cosa intendi con "una buona gestione degli 
errori" in questo contesto? forse che i tuoi programmi gestiscono tutte le
situazioni e non escono mai con un errori non recuperabili? mi sembra 
eccessivamente ambizioso... 

 situazioni e non escono mai con un errori non recuperabili? 
 
No, è che in caso di errore non recuperabile io preferisco un bel log file in modo da poter capire quale sia il problema.
 


come tutti quelli che sanno lavorare.
questa è la piu grande differenza tra lavoro e mondo accademico.
 
-- 
(..) la rivoluzione non è un pranzo di gala, non è una festa letteraria, 
non è un disegno o un ricamo; non si può
fare con tanta eleganza, con tanta serenità e delicatezza, con tanta 
grazia e cortesia. La rivoluzione è un atto
di violenza, è l'azione implacabile di una classe che abbatte il potere 
di un'altra classe. (Mao Tze-tung)

 questa è la piu grande differenza tra lavoro e mondo accademico.
 
No, questa è la differenza tra ambito applicativo e ambito applicativo. Sarei scemo se pensassi che la programmazione sia solo ciò che ho visto io, anche se bazzico da quasi 30 anni nell'ambiente. C'è tanta di quella roba, li fuori, su cui non ho messo ancora mano...
 
-- 
Ciao!
Luca


 
Questo vale sempre,praticamente per tutto
 
 


No, e' l' equivalente di:
 
vod f() { int a=3; ...}
 
la variabile a sta comunque nello stack
 
 
http://www-01.ibm.com/support/knowledgecenter/SS6SG3_4.2.0/com.ibm.entcobol.doc_4.2/PGandLR/concepts/cppgm28.htm
 
 
 
A separate copy of LOCAL-STORAGE data is allocated for each call of a 
program or invocation of a method
 
 
Quindi non puo essere globale
E se non puo essere globale,heap a parte ma non è questo il caso, deve 
risiedere nello stack
Per forza, a meno che non esistono altri modi (e non ne conosco)
 
 
 
 
 

 Se conosci il C:
 
Ok. Posso capirlo tramite python, ruby. 
 
-- 
Massimiliano Adamo


In realtà ho fatto un piccolo errore,l' equivalente è:
 
static int a;
void f() {}
 
 
quindi locale al file di compilazione
 
In COBOL non esiste l' equivalente di:
 
int a;
void f();
 
< altro file>
 
extern int a;
 


 
come non detto
 

 Intendi usi i coltelli per cucinare,normale amministrazione
 
Nono. A me piace spignattare. Però adoro i coltelli. Per dire, ieri mi sono fatto un regalo, è arrivato un santoku. Per cui capita a volte che non uso i coltelli per cucinare, cucino per usare i coltelli! :D
 
-- 
Ciao!
Luca


capisco
usali bene :)
 

 No, è che in caso di errore non recuperabile io preferisco un bel log file in modo da poter capire quale sia il problema.
 
scusa ma perché "preferisco"? non sono alternative.
è come dire: "non chiudi la porta di casa quando esci?" "no, la lascio aperta
e preferisco mettere l'allarme". che senso ha?
 

 che chiama main) a fare ritornare 0 al kernel
 
il return type del main deve essere int anche secondo lo standard c++. se il
return type è int allora omettere il return equivale a return 0, ma se
il return type è void il risultato è indefinito. 

 ritornare 0
 
no. lo standard esplicitamente non definisce il comportamento nel caso in cui
il return type sia diverso da int. nella migliore delle ipotesi dipende dalla
implementazione.


difficile dirlo visto che un return void non è std
Infatti la mia era una supposizione ma se hai qualcosa che dimostra il 
contrario ben accetto
Naturalmente C++
 


purtroppo gli standard iso si pagano per cui non posso portarteli come prova,
se però ti fidi di stackoverflow qui ne parlano prova a leggere la risposta
di tale jonathan leffler:
 
http://stackoverflow.com/questions/204476/what-should-main-return-in-c-and-c
 


Guarda un po, g++ offre un bel errore in compilazione se main ritorna void
Un compilatore non std farà quello che vuole lui,probabilmente
Non è una cosa di cui mi interessa molto se un compilatore non segue gli 
std;
 


letto,trovato questo:
 
The current standard (C11) explicitly mentions these two:
 
int main(void);
int main(int argc, char* argv[]);
 
oppure:
 
3.6.1 Main function [basic.start.main]
 
1 A program shall contain a global function called main, which is the 
designated start of the program. [...]
 
2 An implementation shall not predefine the main function. This function 
shall not be overloaded. It shall have a return type of type int, but 
otherwise its type is implementation defined. All implementations shall 
allow both of the following definitions of main:
 
int main() { /* ... */ }
and
 
int main(int argc, char* argv[]) { /* ... */ }
 
 
 
sul return void niente
 
Ti dico subito con certezza che un void main in g++ e clang++ offrono un 
bel errore di compilazione
Non warning proprio errore
VC++(visual studio 2012) invece neanche un warning
 
non ho provato a vedere che fa vc++ (visual studio 2012) in caso di void 
main, ma visto che non segue gli std in questo caso, non mi interessa molto
 

 sul return void niente
 
The C++ standard explicitly says "It [the main function] shall have a return type of type int, but otherwise its type is implementation defined"


defined", and requires the same two signatures as the C standard. So a 
'void main()' is directly not allowed by the C++ standard, though 
there's nothing it can do to stop a non-standard implementation allowing 
alternatives.
 
 
 
 

 END PROGRAM fibonacci.
 
sciapo' per la trollata
 
-- 
Soprano