Newsgroup: it.comp.lang.c
Titolo: domanda idiotissima

scusate la cazzata
ma perchč la main() non puň richiamare se stessa???
posso avere una risposta che non sia : č perchč il C e cosi' etc etc....
                                                          non č possibile e
basta.....
                                                          il compilatore non
lo permette etc etc....
mi piacerebbe sapere il perchč??? dato che K.R. non l'hanno spiegato sul
RefMan.

 basta.....
Perche la main() e' la principale.
E, tu, l'hai mai sentita la
principale richiamare se stessa?
--
AmMaT | Tolomeo
m   w | aveva
M   A | ragione:
a   i | la Terra,
TwAiN | e' piatta.

ma perchč la main() non puň richiamare se stessa???
Credo che sia una limitazione introdotta a livello di standard, ovvero: non
si puň richiamare main() perché le regole del C dicono che non si puň e
basta.
Quale puň essere il motivo di tutto ciň? Da profano (non programmo
compilatori), direi che č stato fatto per permettere ai creatori di
compilatori di usare regole "speciali" per la chiamata ed il ritorno da
main(). Avrai notato che non č una funzione come tutte le altre, ad esempio
perché viene chiamata con 2 set di argomenti diversi (o void oppure un
char** piů un int, cosa vietata per le altre funzioni), non la devi
dichiarare e cosě via. Se main() fosse stata richiamabile, probabilmente i
creatori di compilatori avrebbero dovuto macchinare un po' di piů nel
programmare i loro prodotti.
Lanugo

ok

Probabilmente può essere anche perché richiamare il main ricorsivamente non
ha senso!! Nessuno ci vieta cmq di fare una cosa del tipo:
int x() {
  ...
 return x();
}
int main() {
 return x();
}
invece di:
int main() {
  ...
  return main();
}
o sbaglio?


sebbene non voglia dire nulla, ti posso confermare che il BC3.1 tratta main
come qualsiasi altra funzione, ed e' possibile fare programmi che chiamano
ricorsivamente il main. Non ci sono controindicazioni. E' sicuramente un
caso particolare!
ciao
donCiccio

ha senso!!
Non ho capito questa frase. Non è vero che richiamare il main ricorsivamente
non ha senso. Perché non dovrebbe avere senso?
Lanugo

non ha senso. Perché non dovrebbe avere senso?
A livello di logica, e' come se uno volesse mangiare se stesso.
Onestamente, non trovo casi validi di programmazione in cui il
programma principale richiama ricorsivamente se stesso, quindi non
vedo perche' stare qui a farsi seghe mentali se sia sensato o meno
metterlo in pratica.  Vogliamo discutere, almeno per una volta, di
cose che hanno attinenza pratica ?
Il problema e' di facile risoluzione, se il compilatore tratta main
come una normale funzione (caso molto probabile) non c'e' alcun
problema.

 cose che hanno attinenza pratica ?
scuasa, non potrebbe essere un modo comodo per implementare fork() dove 
non esiste, passando un arg apposito?

non esiste, passando un arg apposito?
No.
Con fork si ha una copia del processo al quale viene restituito un
valore, nel punto in cui fork viene chiamata, in modo che esso possa
distinguere se e' un processo padre o un processo figlio (pid del
figlio viene restituito al padre e 0 al figlio).
La ricorsione e' un'altra cosa : agisce sempre sullo stesso codice.

metterlo in pratica.
Come vuoi.
Lanugo

alcun problema.
E gli interi sono molto probabilmente a 32 bit, i char signed
e il paddind dei membri di struttura a 8 byte vero ?
Personalmente non ho mai avuto problemi con main() ricorsivo
(non ho mai scritto codice serio che usasse questa cosa) ma
se lo standard lo vieta allora un motivo ci sara'.
Non credo che i membri del gruppo di standardizzazione siano
dei pazzi furiosi che inventano regole senza senso (anche se
a volte e' incredibile cosa riesca a partorire un comitato
di persone che, prese singolarmente, sono molto intelligenti).
Andrea
NOTA:
  Ovviamente sull'utilita' pratica di risparmiare
  caratteri in un programma che risolve il problema
  delle 8 regine stavo scherzando :)))
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 La ricorsione e' un'altra cosa : agisce sempre sullo stesso codice.
 
non avevo considerato che l'esecuzione non sarebbe stata contemporanea.

se lo standard lo vieta allora un motivo ci sara'.
Ma lo standard lo *vieta* ?
Non e' che, per caso, e' definito come "undefined behavior" ?

Non e' che, per caso, e' definito come "undefined behavior" ?
se il codice della strada, invece di vietare di passare con il rosso,
ti dicesse che potresti essere inghiottito da un drago che arriva
dalla luna, tu passeresti con il rosso? ;-)
--
Antonio Cuni, 18 anni, studente
Brainbench Certification: 
Master C++: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
http://www.brainbench.com/transcript.jsp?pid=1301688

dalla luna, tu passeresti con il rosso? ;-)
Onestamente, non capisco che obiezione sia questa.
Se lo standard definisce "undefined behavior", vuol dire che questo
meccanismo NON E' VIETATO, ma e' semplicemente non definito a livello
di standard, per cui TEORICAMENTE potrebbe succedere qualsiasi cosa.
Ma se io mi accerto che il mio compilatore tratta main come una
funzione qualsiasi e che la ricorsione del main stesso non da'
problemi, il comportamento PER IL MIO SISTEMA e' definito e quindi non
vedo perche' non utilizzarlo.
Viceversa, se e' vietato, mi aspetto che mi si elenchino i motivi.

PEr continua ad essere insensata la cosa .... e questo perché di logica si
potrebbe passare gli argomenti del main ad un'altra funzione che ragiona in
ricorsione lasciando al main le specifiche di uscita di tale funzione con
relativi messaggi e cazzi vari!!  Insensata appunto perché la ricorsione sul
main può essere tranquillamente sostituita da un'altra funzione da
richiamare passandogli gli stessi argc e argv!

 ha scritto nel messaggio
news:9arnsp$21dg$1...@stargate1.inet.it...

Ciao Pluto,
cmq io non sono un fautore della ricorsione del main, ho solo fatto notare
che UN compilatore ti permette di farlo, ai singoli la scelta se usare
questa tecnica oppure no.
ciao
donCiccio

main è appunto una funzione come tutte le altre però da ciò che ho capito
può richiamare se stessa solo se certi particolari compilatori lo
permettono.

Onestamente, non capisco che obiezione sia questa.
a livello teorico sono d'accordo anche io sul fatto che "sbagliato" e
"undefined behaviour" sono due cose diverse; a livello pratico io non
userei mai una caratteristica dal comportamento indefinito, anche se
sembra funzionare; sarebbe stato diverso se fosse stato un
comportamento implementation defined: in questo caso lo userei, ma
solo se sono certo di non dover fare il porting del programma.
Anto


solo se sono certo di non dover fare il porting del programma.
Non te ne rendi conto, ma vale lo stesso discorso.
Cio' che e' "undefined behavior", nel momento in cui si sfoglia il
manuale del proprio compilatore e si scopre che per IL PROPRIO
compilatore e' invece un "defined behavior", si usa tranquillamente.
E' il caso del famigerato fflush(stdin) che a livello standard e'
undefined behavior, ma Visual C++ (credo) lo tratta in modo definito.
Con questo compilatore, non c'e' alcun pericolo nell'utilizzare
fflush(stdin), perche' il comportamento e' ben definito (esplicitato
nell'help).
Il codice non sara' portabile, ma e' molto diverso dire che e' VIETATO
usare fflush(stdin) secondo lo standard, perche' lo standard non dice
questo.  Non avrebbe difatti motivi per vietarlo.
Lo stesso discorso vale per "implementation defined", solo che cio'
che risponde a questa definizione DEVE essere implementato dal
particolare compilatore, cio' che e' "undefined" no.

questa tecnica oppure no.
Bisogna comunque vedere se il BC 3.1 e' aderente allo standard C89.

compilatore e' invece un "defined behavior", si usa tranquillamente.
be, su questo sono d'accordo; ma solo se lo trovo esplicitato a chiare
lettere. Direi che in fondo diciamo la stessa cosa: solo che io
partivo dal presupposto che non fosse scritto da nessuna parte che il
codice si comporta in un determinato modo
Ciao Anto
PS: come mai non ti si vede più su iclc++ ?


PS: come mai non ti si vede più su iclc++ ?
Sto cambiando lavoro, sono in fase di transizione ... ;)
Ho cambiato PC e devo riassestare i gruppi di discussione.