Newsgroup: it.comp.lang.c++
Titolo: Re: try / catch

 Se io scrivo una cosa cosi':
Il tuo esempio mi da i seguenti risultati:
BCC55:
inizio
errore
fine
MS VC++ Toolkit 2003:
inizio
errore
fine
GCC 4.1.0:
inizio
fine
Forse in GCC bisogna attivare la gestione delle eccezioni da switch di 
compilazione. Comunque sembra funzionare.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

compilazione. Comunque sembra funzionare.
E' strano. Sulla mia macchina:
gcc version 3.4.2 (mingw-special):
inizio
errore
fine

 
Saluti  Manlio Perillo

 fine
Ok, allora sarà undefined behavior come dice Manlio.


livello, e non il C++.
Io non sarei cosě sicuro che usando un linguaggio di piů alto livello
del C++ ci si metta completamente al riparo dai comportamenti
indefiniti. Credo che qualunque linguaggio, quale piů quale meno,
abbia delle "condizioni limite". O meglio, qualunque programmatore,
con qualunque linguaggio, č in grado di creare codice dal
comportamento indefinito.

 comportamento indefinito.
Beh, dipende. In Python per dire la maggior parte delle porcate ti scoppiano
un'eccezione in faccia. Non viene in mente sui due piedi un comportamento
sbagliato che sia passato sotto silenzio.
C++ ha parti in cui gli errori sono segnalati subito con eccezione (esempio
una new 'standard' che non ha memoria), altre volte invece è più reticente
e mi lascia andare avanti senza dire nulla. Giusto: se l'efficienza importa
non voglio controlli (se non importa ci sono i vari at()).
-- 
  Enrico Franchi (RiK0)
[ Yellow Dog Linux User ]
[ #299188 Linux Counter ]
[ MacOS X User          ]

 Ok, allora sarà undefined behavior come dice Manlio.
Non ho sotto mano lo standard, ma iirc il punto è che new[] come argomento
un coso unsigned. Per cui -1 diventa una *grossa* allocazione positiva.
Sulla mia piattaforma viene lanciata per l'appunto std::bad_alloc.
Se le cose sono come ho scritto (e mi secca, ma non ho lo standard sotto
mano su sta macchina) allora semplicemente nel punto in cui non ha dato
errore significa che la macchina è riuscita a fare l'allocazione.
Se no, ho detto una cagata pazzesca. :)


 errore significa che la macchina è riuscita a fare l'allocazione.
Dev'essere proprio così in quanto fino a
496 * 1024 * 1024
non mi dà errore.


sbagliato che sia passato sotto silenzio.
Cercalo bene :-)

  Si, ma č un errore mandare un programma in undefined behaviour. :)
Non necessariamente.
In alcuni casi sfruttare undefined behaviour (generali) con risultati
ben definiti (e addirittura documentati) sulla specifica versione del
compilatore che si utilizzera', non e' un errore. Basta sapere cosa si
sta facendo =) Se si sta sviluppando codice che (si suppone) sia
portabile, beh... e' decisamente un errore =)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 70 days.
You should really try it!
http://www.malcom-mac.com/nemo

 Cercalo bene :-)
Giuro, non mi viene in mente. Per quello che vedo l'uso delle eccezioni
è totalmente pervasivo, non riesco a pensare ad un errore che non dia
luogo ad eccezioni (salvo errori puramente relativi alla funzionalità,
ma non a livello di linguaggio).
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

undefined behaviour. 
No, la chiave di volta č "this International Standard imposes no
requirements". Il codice utente che crea un undefined behavior *NON
E'* codice errato, č codice che genera un undefined behavior. Non se
ne puň dare una definizione piů specifica.

portabile, beh... e' decisamente un errore =)
Quindi in generale non è un errore, è solo comportamento indefinito.

 comportamento indefinito.
Mi sapresti indicare un esempio di comportamento indefinito secondo le 
specifiche di Java, C#, Python, Visual Basic, Smalltalk, o qualche altro 
linguaggio i cui programmi tipicamente non vengono compilati in 
linguaggio macchina dal programmatore?
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 ne può dare una definizione più specifica.
*Se* avessero scritto 


 linguaggio macchina dal programmatore?
Non ho tempo, né voglia di farti esempi. Quella che ho scritto è
un'ipotesi. Dubito molto, tuttavia, che esista un linguaggio 100%
safe. Che diavolo c'entra, poi, il fatto che un codice venga o meno
compilato?

 compilato?
C'entra per il fatto che conosco dei linguaggi compilati che hanno 
alcune espressioni dal comportamento indefinito, ma non ne conosco da 
linguaggi non compilati. Per esempio, in C, C++, Pascal, e Fortran, 
l'espressione "a[10] = 0" ("a[10] := 0" in Pascal) mi pare che abbia 
comportamento indefinito se "a" e' un array di 5 elementi, e non si 
attiva il controllo opzionale dei limiti degli array.
Invece, mi pare che nei linguaggi citati nel messaggio precedente tale 
espressione ha sempre un comportamento definito (eccetto forse in codice 
"unsafe" di C#), che consiste nel sollevare un'eccezione catturabile.


 catturabile.
Tanto per cominciare, qualsiasi linguaggio interpretato è scritto in un 
altro linguaggio NON interpretato
che di base ha sicuramente di queste debolezze, per cui nessuno puo' 
escludere a priori che determinate
costruzioni del linguaggio sovrastante non vadano a sollecitare una di 
queste 'indeterminatezze', ti pare?
Oppure non hai mai avuto dei crash con java o phyton o c# o .net ??? 
Sfortunatamente io ne ho
incontrare parecchie anche con applicativi scritti con questi linguaggi! 
Certo, e' piu' difficile fare cazzate
in modo piu' o meno volontario, ma questo non pone completamente al 
riparo il codice!
Bye,
Brix

 riparo il codice!
Un linguaggio che non ha comportamenti indefiniti non garantisce 
l'impossibilita' dai crash. Garantisce invece che se un'istruzione abbia 
sempre lo stesso comportamento, cioe' o produce sempre un crash o non lo 
produce mai. Notorialemente un programma scritto in Assemply/C/C++ puo' 
avere dei crash saltuari, dovuti, per esempio al fatto che si accede 
oltre i limiti di un array, o che si accede a un'area di memoria 
disallocata, o che si disalloca due volte la stessa area di memoria.
Mi pare che nei linguaggi di livello piu' alto il comportamento dei 
programmi e' piu' deterministico (nell'ottica del programmatore), cioe' 
le stesse istruzioni fanno sempre le stesse cose: se sono errate, 
crashano sempre (o meglio, sollevano un'eccezione, che se non e' gestita 
dal codice applicativo, produce uno stack dump seguito dalla 
terminazione del programma).


 programma).
si e no, perche' se il problema riguarda corruzioni di memoria, in realta'
il comportamento del programma in oggetto non e' lo stesso sempre...
e mi e' anche capitato, in java....
Molta parte dell' implementazione dei linguaggi di 'alto livello' poi si
appoggia pesantemente su servizi del sistema operativo sottostante,
con tutti i problemi del caso (Vero che NON sono in linea teorica
parte del liguaggio e delle sue specifiche, ma di fatto e' cosi' e non se
ne puo' prescindere)
Bye
brix 

 e mi e' anche capitato, in java....
Ma, ti chiedo, tali corruzioni di memoria che ti sono capitate 
programmando in Java, che erano ovviamente degli errori, erano errori di 
programmazione in Java (cioe' errori tuoi o di altri programmatori del 
tuo team o errori di libreria), o errori dell'implementazione del 
linguaggio (cioe' del compilatore da Java a bytecode, o della macchina 
virtuale)?


 (cioe' del compilatore da Java a bytecode, o della macchina virtuale)?
Nella maggior parte dei casi, errori di programmazione, o del sistema 
sottostante,
specie del garbage collector, che non ha dereferenziato correttamente 
oggetti in
situazioni particolari...in altri casi non si e' riusciti a capire la 
situazione, specie
girando lo stesso programma su macchine con SO diversi (in questi casi, si 
e'
riscritto diversamente il codice)
Bye!
tx

 linguaggio) 
Non mi sembra affatto sia così.
Forse questo è quello che accade con DOS e Windows 95, non di certo con i 
sistemi operativi moderni.
Potrei sbagliarmi, non so come i sistemi operativi implementino la 
protezione della memoria.
Manlio Perillo

 definita, ma il suo risultato no
Questa e' una contraddizione in termini. Sospetto che molta della
discussione in corso sia causata da un uso peculiare del termine
'semantica'.
Ciao,
Nicola

 ma il suo risultato no,
Io chiamo semantica (denotazionale) di un'istruzione la trasformazione 
dal valore dei dati prima dell'istruzione al valore dei dati dopo di 
essa. Se non e' definito il risultato, non e' definita neanche la semantica.
Un'altra definizione di semantica (quella operazionale) definisce 
un'istruzione del linguaggio in base alla sequenza di istruzioni 
equivalenti di livello piu' basso.
Ma un'implementazione corretta dello standard del linguaggio "potrebbe" 
anche intercettare tutti gli accessi a un array con indici fuori dal 
range definito, sebbene nessuna lo faccia, per motivi prestazionali.
Pertanto, una semantica operazionale ammessa dallo standard sarebbe 
accedere all'area di memoria esterna all'array, ma un'altra semantica 
ammessa sarebbe controllare se l'indice e' valido, e se non e' valido 
non fare niente. Le due semantiche sono ben diverse, e quindi 
l'istruzione sorgente non ha una semantica univoca.


 queste 'indeterminatezze', ti pare?
Se tu riuscissi a distinguere *semantica* da implementazione sarebbe
possibile affrontare questo discorso.
In particolare se dai una semantica e un'implementazione non è conforme
alla semantica si chiama *baco*.
Per inciso, ci possono essere bachi anche nella macchina fisica: in
questo caso pure non diciamo che *nessun* linguaggio che viene compilato
per quella macchina è indeterminato. Diciamo che quella macchina fisica
ha un baco. Fine della storia. :)


 definita,
No. La semantica *non* è definita. Se leggi lo standard lo dice
chiaramente.


 Cercalo bene :-)
Hints? 



La protezione di memoria funziona solo se si scrive fuori dall' area che e'
stata assegnata ad un processo dal SO, Se sfortunatamente si scrive
in modo erroneo all' interno della propria area , non verra' sollevata 
nessuna
eccezione (di solito un segment fault).

 sorgente non ha una semantica univoca.
Qui non ci capiamo : credo si confonda la semantica con il comportamento
indefinito: per me (ma e' solo una opinione), le due cose sono ben distinte.
La semantica puo' essere definita, in solodoni= So ESATTAMENTE cosa fa 
quella
istruzione (non torno a ripetermi!), ma non so' l' esito che dara' quando 
eseguita
con particolari parametri in un particolare sistema.
E con cio' ? Significa solo che una particolare funzione del tuo insieme non 
avra' un risultato
definito, non significa che la sua sematica non sia definita.
E dire di chiudere qui!
Byte
Brix


Lo standard dice solo che il comportamento e' indefinito == lasciato al 
sistema:
che catturi una eccezione, vada in crash o faccia pipi' non e' la semantica 
ad
essere in questione: ma questa e' la mia personale opinione.
Brix

 semantica ad essere in questione: ma questa e' la mia personale opinione.
Ti confondi fra undefined behaviour e implementation defined. Sono due
cose *profondamente* diverse.


   
Puo' darsi ........ma resto della mia opinione.
Bye!
Brixxx

 avverra' nello stack 
Non è detto. Potrebbe benissimo essere utilizzato un registro.
E.

 Puo' darsi ........ma resto della mia opinione.
Fammelo sapere la prima volta che lavori su una piattaforma tipo
OpenBSD.
