Newsgroup: it.comp.lang.c++
Titolo: Pattern Raii

Ciao a tutti.
Qualcuno può cortesememte illustrarmi il pattern raii? Vuol dire che 
ogni varibaile che alloco devo preoccuparmi personalmente di 
deallocarla?Cioè che ad esempio ad ogni new che faccio corrisponde una 
delete?
Grazie mille!!
Ciao!!!

ojj ha scritto:

In generale, RAII o no, devi preoccuparti di deallocare qualunque 
risorsa allochi; quindi ad ogni new deve corrispondere un delete, ad 
ogni new[] un delete[], ad ogni fopen un fclose, ecc...
RAII e' una tecnica che rende implicita la liberazione delle risorse, di 
fatto togliendoti il pensiero. Il trucco sta nel piazzare il codice che 
acquisisce la risorsa nel costruttore di un oggetto automatico e, 
parallelamente, il codice per liberarla nel distruttore.
In sostanza, al posto dei new/delete, utilizzerai degli auto_ptr; al 
posto dei new[]/delete[] dei vector (o qualcosa di simile); al posto di 
fopen/fclose utilizzo degli stream (o qualche altro wrapper) ecc...
In questo modo ottieni due grossi vantaggi:
_ non ti dimentichi di liberare qualcosa che hai acquisito;
_ rendi il blocco in questione "exception-safe".
  bye
	av.

 _ rendi il blocco in questione "exception-safe".
Sarebbe il caso di approfondire il discorso della exception safety.
Purtroppo non è proprio così banale.
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 al posto dei new[]/delete[] dei vector (o qualcosa di simile)
ma i vector sono allocati sullo stack?
grazie
Mauro


Penso si riferisse agli array. I vector mantengono gli elementi sullo heap.
E.

?manu* ha scritto:

No, intendevo proprio i vector.
In questo modo l'oggetto in se (pochi byte) e' allocato sullo stack, 
quindi la sua distruzione e' garantita; gli elementi invece vengono 
allocati sull'heap, come con new, ma il distruttore si occupa di 
deallocarli.
  bye
	av.

 Purtroppo non è proprio così banale.
D'accordo, ma diventa una cosa lunga...
Di articoli sulla RAII penso se ne trovino parecchi in giro; sicuramente 
spiegati meglio di come avrei potuto fare io.
Comunque un breve esempio:
Versione 1:
{
  A*a=new A();
  ...
  delete a;
}
Problema: se viene lanciata un'eccezione tra il new e il delete, a non 
viene deallocato.
Versione 2:
{
  A*a=new A();
  try {
   ...
  } catch (...) {
   delete a;
   throw;
  }
  delete a;
}
Il problema e' risolto, ma il codice e' piu' complesso e meno leggibile 
(e qui abbiamo un'allocazione sola!).
Versione 3 (RAII):
{
  std::auto_ptr<A> a(new A());
  ...
}
Problema risolto senza complicare il codice, che, anzi, e' piu' breve di 
prima.
  bye
	av.

 prima.
Il punto è che non c'è nulla che questo codice sia exception safe.
Non è che per rendere il codice exception safe basti usare l'idioma
RAII. Bisogna *anche* rendere il costruttore exception safe esso stesso.
Se un'eccezione è lanciata dentro il costruttore, il distruttore non
viene chiamato (poichè l'oggetto non è completamente costruito). Come
conseguenza hai un potenziale resource leak. 
Poi possiamo entrare nel discorso di codice intrinsecamente non
roll-backabile etc etc etc.


 conseguenza hai un potenziale resource leak. 
Il costruttore (di A penso tu intenda) non l'ho riportato.
Mi sono limitato, come ho detto, ad "un breve esempio"; non volevo 
assolutamente entrare nel discorso in modo approfondito.
Credo che la parte di codice che ho riportato sia exception safe...
E' chiaro che un programma intero lo e' se tutti i suoi pezzi di codice 
lo sono, ma non potevo analizzare anche quello che non ho riportato, che 
magari avrebbe anche potuto essere in una libreria fatta da terzi...
  bye
	av.

 Credo che la parte di codice che ho riportato sia exception safe...
A me non sembra. I motivi sono chiaramente spiegati da crxor 666.
Metti un break nel distruttore e guarda se ci passa.
class Papero
{
public:
   Papero():quack(0)
   {
     quack = new int();
     throw std::exception("boh");
   }
   ~Papero()
   {
      if(quack)
        delete quack;
   }
private:
   int* quack;
};
int main(bla bla)
{
	using namespace Host;
	try
	{
		std::auto_ptr<Papero> a(new Papero());
	}
	catch(const std::exception& mah)
	{
		int ciao = 0;
	}
   return 0;
}
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 Metti un break nel distruttore e guarda se ci passa.
Ma tu hai provato almeno a compilare il tuo esempio? Non sto dicendo che il 
tuo punto di vista sia errato ma che se vuoi dimostrare qualcosa almeno 
accertati di riportare un esempio compilabile.
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
 

 Metti un break nel distruttore e guarda se ci passa.
No che non ci passa!
Pero' e' la classe Papero (che io avevo chiamato A senza preoccuparmi di 
riportarla) a non essere "exception-safe". Pertanto *questa* andrebbe 
riscritta in modo diverso.
Io la scriverei, ancora una volta, utilizzando un auto_ptr:
class Papero {
  std::auto_ptr<int> quack;
public:
  Papero():quack(new int()) {
   throw std::exception("boh");
  }
};
main invece e' scritta in modo "exception-safe" e questo io dicevo; o 
sbaglio?
Tra l'altro non vedo in che altro modo possa essere scritta, altrimenti, 
per ovviare al problema: se usi una classe che non e' exception-safe non 
mi risulta ci sia modo di "recuperare" nel blocco da cui la istanzi.
  bye
	av.

 Ma tu hai provato almeno a compilare il tuo esempio?
Veramente si, bla-bla a parte.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 risulta ci sia modo di "recuperare" nel blocco da cui la istanzi.
Se butti nella spazzatura la classe la Papero fai prima.
Devo dire però che io evito come la peste gli auto_ptr, e il caso di 
avere un'eccezione nel distruttore o nel costruttore di una classe è 
più accademia che caso reale, per la mia realtà. Anzi, di norma, 
preferisco non avere codice exception-safe. In caso di eccezione 
preferisco vada in crash tutto. Di solito non sono in grado di 
mantenere la coerenza interna in presenza di una eccezione, che nei 
miei casi sono abbastanza un'eccezione :-)
Di solito il mio problema è essere thread-safe, e debaggare i bugs che 
succedono "una volta ogni tanto".
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 magari avrebbe anche potuto essere in una libreria fatta da terzi...
Il problema è che il tuo codice è exception safe se anche quello che
chiami lo è. Se un qualunque pezzo di quello che tu chiami non lo è (e
tu non lo isoli opportunamente), anche il risultato non è exception
safe.
Tipicamente il tuo codice è exception safe *se* hai dimostrato che A è a
sua volta exception safe. In caso contrario no.


 Veramente si, bla-bla a parte.
No, scusa, copia e incolla quello che hai riportato nel tuo messaggio e 
prova a compilarlo. Ti assicuro che non compila. Purtroppo non tutti qui 
sono così esperti di exception safeness (come in tanti altri argomenti) da 
poter capire un esempio senza farlo girare (io almeno non lo sono).


 almeno non lo sono).
Va beh, ma non esageriamo. Mancano gli header, e il main non è 
corretto, ma non mi sembra un impresa titanica aggiungere queste cose.
Invece quell'using namespace mi è scappato con il taglia e incolla, e 
non centra niente. Comunque se proprio vuoi la versione compilabile:
#include <exception>
#include <memory>
class Papero
{
public:
   Papero():quack(0)
   {
     quack = new int();
     throw std::exception("boh");
   }
   ~Papero()
   {
      if(quack)
        delete quack;
   }
private:
   int* quack;
};
int main(int argc, char* argv[])
{
    try
    {
        std::auto_ptr<Papero> a(new Papero());
    }
    catch(const std::exception& )
    {
    }
	return EXIT_SUCCESS;
}
++
Aggiungo che in questo giocattolo *l'unico problema* reale sarebbe che 
se fallisce la new essa lancia una std::bad_alloc. Ora, non è detto che 
tu possa farci qualcosa con un patata bollente simile, e una buona 
politica potrebbe essere il crash del sistema. Essere resistenti alle 
eccezioni può essere una cattiva politica.
Dico questo perché mi è capitato di ereditare un programma mastodontico 
fatto in un modo simile:
int main(int argc, char* argv[])
{
   while(true)
   {
      try
      {
         return Programma(argc, argv);
      }
      catch(...)
      {
      }
   }
   return EXIT_SUCCESS;
}
Formalmente non andava mai in crash. Funzionava da culo, però non 
andava in crash. Ovviamente la prima cosa che ho fatto è stata togliere 
quel try/catch, vedere i crash in diretta, e correggere gli errori. Ci 
ho messo un paio di anni, ma adesso funziona che è un orologio.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 }
Azz! :-)


 Grazie! Purtroppo il GCC 4.2.2 mi da il seguente errore:
Adesso non ho voglia di accendere una macchina virtuale con un linux 
per provare un GCC. Tra i costruttori di std::exception della libreria 
del VC2005 ne ho uno simile:
exception(const char *const&);
Immagino manchi negli altri qualcosa di simile. Come sono i costruttori 
di std::exception nella libreria standard del GCC?
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 standard del GCC?
Intendi questa?
  class exception
  {
  public:
    exception() throw() { }
    virtual ~exception() throw();
    /** Returns a C-style character string describing the general cause
     *  of the current error.  */
    virtual const char* what() const throw();
  };


 di std::exception nella libreria standard del GCC?
Ha ragione gcc. Il costruttore che indichi e' un'estensione. Il
problema lo aggiri includendo <stdexcept> e lanciando
std::runtime_error, oppure semplicemente eliminando il messaggio.
Ciao,
Nicola

 Ha ragione gcc. Il costruttore che indichi e' un'estensione.
Se ne impara sempre una nuova :-)
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 Se ne impara sempre una nuova :-)
E' questo uno degli scopi di un newsgroup.


 ho messo un paio di anni, ma adesso funziona che è un orologio.
Non sono d'accordo. Tu intendi una cosa 'strana' con exception safety,
vedo. In particolare il livello più basso di exception safety è che 'se
un\'eccezione viene lanciata, ogni cosa nel programma rimane in uno
stato valido'. Il programma da come lo descrivi tu *non* restava in uno
stato valido, probabilmente. Dubito per esempio che le invarianti di
classe venissero rispettate.
Poi ci possono essere motivi di performance per non essere exception
safe (vedi il costo del copy & swap per la strong exception safety, vedi
alcune operazioni intrinsecamente irrevocabili).
bad_alloc pure è una rogna: spesso quando parte sono d'accordo che si
possa fare ben poco. C++ mette a disposizione meccanismi (piuttosto
complessi) per provare a recuperare la faccenda. A seconda di come è
fatta l'applicazione e dal motivo della bad_alloc magari si può fare
qualcosa, magari no. 
Ad ogni modo, non mi sembra sbagliato comunque catchare l'eccezione e
mettere in salvo i dati salvabili oltre che evenutalmente salvare da
qualche parte informazione a sufficienza per capire la causa
dell'eccezione. 
Tipicamente quando sto lavorando su un programma e questo esplode senza
avere salvato (o backuppato) i files su cui sto lavorando, mi incazzo
come un'aquila.
Nota che il problema nel programma che hai aggiustato mi pare da come lo
hai descritto che fosse che i fallimenti passavano sotto silenzio
"Errors should never pass silently.
 Unless explicitly silenced." (Zen of Python)
Oltre che, sui due piedi, non mi pare che fosse necessariamente
exception safe il tutto. Non è solo questione di intercettare le
eccezioni, ma di lasciare il tutto in uno stato consistente. 


crxor 666 ha scritto:

Pienamente d'accordo.
  bye
	av.

come un'aquila.
Personalmente me ne infischio assai. Mi interessa lo stato iniziale che 
ha generato il problema. Io non scrivo software per macchine salvavite, 
per un cuore artificale per interderci. Un crash è una scelta 
accettabile nel mio caso. Orami mi capita spesso che se perdo tempo a 
debaggare qualcosa è per i casi in cui l'errore si presenta se c'è una 
sequenza temporale di fattori ( caso del "bug che salta fuori ogni 
tanto" ), oppure con i thread/task che non sincronizzati bene. Casi in 
cui le eccezioni in se non mi sono di aiuto.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 exception safeness
Magari "exception safety" :-))

 Magari "exception safety" :-))
Ops! :-)


 Personalmente me ne infischio assai.
Io ti dico da *utente* che un'applicazione desktop che alla minima
eccezione mi fa scoppiare tutto senza salvarmi i dati finirebbe molto
alla svelta nel cestino perchè *inaffidabile*.


 alla svelta nel cestino perchè *inaffidabile*.
La mia teoria è che i *miei* programmi non devono avere mai eccezioni, 
e mai errori. L'unico errore che concepisco sono dati iniziali di 
partenza sballati. In quel caso insulto l'installatore e esco con 
grazia. Il consumo di memoria deve essere ridicolo, e devono partire da 
subito con un buon grado di ottimizzazione. Se poi mi manca sotto il 
naso la memoria, o mi sparisce l'HD vado in crash. Già se mi manca la 
rete o il DB vado in uno stato di wait, e aspetto.
Insomma, non scrivo codice "eccezionale" :')
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 scrittura di codice di qualità.
Io non uso molto spesso le eccezioni, ma ci sono delle situazioni in cui 
sono molto appropriate.
Ad esempio metti di dover implementare un parser. Se il file che stai 
leggendo ha degli errori, devi sicuramente gestirli. A più basso livello 
lanci un'eccezione con una stringa che descrive l'errore. Man mano che 
l'eccezione sale ci aggiungi informazioni come il numero di riga e il 
nome del file. Ovviamente questo lo puoi fare anche utilizzando i valori 
di ritorno, ma risulta molto più complesso.
Un altro esempio che mi è capitato è nello scrivere un cgi. In un 
programma del genere non puoi uscire brutalmente. Se stai mandando un 
file HTML devi scrivere il messaggio di errore e comunque devi 
completare la pagina... anche in questa situazione ho trovato molto 
comodo l'uso delle eccezioni...
E.

 DB vado in uno stato di wait, e aspetto.
beh, quest'ultimo è già qualcosa appunto (e se cricca un disco 
fisso, lì penso proprio che non ci sian santi per nessuno).
ciao
Soviet


 leggendo ha degli errori, devi sicuramente gestirli.
Ripeto, non sono contro le eccezioni, e trovo che sia meglio che ci 
siano rispetto il non averle. Però infarcire il codice di eccezioni non 
migliora ne la leggibilità ne la qualità.
Bisogna usarle con della testa. Per esempio, nel tuo caso non so se 
siano un "bene". Il programma che deve parsare un file si accorge che 
il file non c'è, che fare? Per me messaggio di errore e tanti saluti. 
Per questo comportamento non è necessario "lanciare" eccezioni, il 
vechio sistema può andare bene.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 di resume futuro) non sarebbe malvagio.
Sempre lo stesso esempio sbagliato. Cosa centra questo con l'uso di una 
tecnica o dell'altra per la gestione dell'errore? Ritornare l'errore o 
lanciare un'eccezione non cambia nulla. Il codice scritto bene adotterà 
soluzioni ragionevoli. Io semmai contesto che l'uso delle eccezioni, 
renda di per sè il codice di "qualità". Codice di qualità lo puoi fare 
con il codice d'errore e il codice può risultare ugualmente leggibile, 
solido, mantenibile. Forse un poco più prolisso sì, questo te lo 
concedo.
Però io ho smesso di fare le gare del tipo: "tutto in una linea". Se il 
codice è più leggibile con l'uso di variabile temporanee e in tre 
linee, io scrivo tre linee.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 di ritorno, ma risulta molto più complesso.
Uhm, vai a postare un'argomentazione simile su comp.compilers, e
vediamo cosa ti rispondono...
Secondo me un parser e' un pessimo esempio, perche' in genere al
momento di gestire un errore e' necessario avere a disposizione tutte
le informazioni possibili per poter tirare a indovinare una possibile
correzione e proseguire nella scansione dell'input.
Non ti e' mai capitato un messaggio tipo "confused by earlier errors,
bailing out"? Questo potrebbe essere gestito con un eccezione, ma il
risultato e' la terminazione rapida.
Ciao,
Nicola

 correzione e proseguire nella scansione dell'input.
Non è questo il tipo di parser a cui stavo pensando. Pensa invece ad un 
parser per leggere un file di configurazione o un file di dati. Al primo 
errore puoi fermarti e dire all'utente che il file non è valido, però 
devi anche dargli i dettagli del perché non è valido. In ogni caso non è 
detto che terminare il programma sia la cosa giusta da fare.
E.

 
ciao
Soviet

 attraverso un interfaccia omogenea (al massimo estensibile)
Beh, ma perchè re-inventare la ruota? Il linguaggio C++ non ti può 
vincolare ad una particolare interfaccia, ma la libreria standard ti dà 
una strada da seguire, e cioè usare <stdexcept>. Hai già pronta una 
gerarchia di eccezioni da cui derivare, e tutte hanno il metodo .what() 
per ottenere una stringa con il messaggio di errore.
E.

?manu* ha scritto:

beh, un po' scarna come introspezione !
Da un oggetto interrogabile vorrei un po' id più.
Certo, un throw avrebbe molto più overhead, ma non mi 
dispiacerebbe che venisse compilata un'istanza di eccezione con 
almeno il nome e/o un qualche identificativo della routine che 
l'ha generata, orario, lo stato dei parametri e delle variabili 
locali, o cose simili, magari anche info sulla riga di codice 
che ha toppato, al limite lo stato dei registri.
capisco che ho un concetto di eccezione molto "pesante", ma in 
effetti non le concepisco come scorciatoia per ritornare un 
valore, ma come un minicataclisma che incombe, e come tale da 
essere trattate coi guanti. L'evento eccezionale non dovrebbe 
penalizzare le performance ordinarie ... forse complicare il 
codice si, ma in velocità non penso che inficierebbe tutto.
Per avere solo un magro messaggio di testo ci arrivo anche da solo.
Per quanto riguarda la derivazione di classi ad hoc, è vero che 
funzia, ma si ricasca nel pericolo che diceva Quack : se non 
stradocumenti il codice (tuo o altrui), non sai bene cosa 
aspettarti, e ti riduci comunque a fare un catch (...) 
indiscriminato per non lasciare filtrare qualcosa.
ciao
Soviet


 qualcosa.
Ma se tutte le tue eccezioni implementano .what() e derivano da 
Exception (non mi ricordo se sia questo il nome) allora chi cattura 
l'eccezione sarà almeno in grado di stampare un messaggio. Poi se si 
guarda la docucmentazione potrà andare anche a prendere l'ora il nome 
della routine e la fase lunare...
E.

 Ma se tutte le tue eccezioni implementano .what()
Dunque, qual'è il significato ultimo di .what()? Secondo me darti 
informazioni sul problema, giusto una stringa. Quello che manca è 
qualcosa che ti dia informazioni sulla classe d'errore. Poi quando sai 
qualcosa della classe potrai interrogare l'istanza per avere 
informazioni sull'errore.
Sull'introspezione però il C++ è deficitario. Non riesco a pensare ad 
altro ad un dynamic_cast o un typeid su un oggetto passato per 
puntatore che derivi da una classe base. Non è il massimo come 
meccanismo, e non so se possa essere realmente utile.
Magari c'è qualche trucco per fare quel che dico, ma che io non 
conosco.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 che ha toppato, al limite lo stato dei registri.
In effetti diversi linguaggi associano alle eccezioni una traccia
dello stack [1]. Questo in C++ non e' possibile ottenerlo, ma con una
macro e una classe eccezione opportunamente disegnata non dovrebbe
essere difficile realizzare un'approssimazione di quello che chiedi.
Ciao,
Nicola
[1] Al proposito evitero' di tediarvi con cio' che penso dei messaggi
di errore di Eclipse ;-)

 so se possa essere realmente utile.
Perché tutto questo? Il catch già ti seleziona il tipo di errore a cui 
sei interessato.
E.

 interessato.
Siamo sempre lì. Accademicamente è vero, ma realisticamente le persone 
non scrivono cose tipo:
void Papero(..) throw(errore_1, errore_2, altro_tipo);
Nel mondo reale hai cose tipo:
void Papero(..);
ovvero che qualsiasi eccezione può essere lanciata.
Nella mia ditta, secondo me, c'è un fenomeno, 9 programmatori buoni e 
90 normali. Io mi metto tra i buoni. Forse solo il fenomeno fa le cose 
a regola d'arte. Con gli altri 99 devo convivere, e per altro 95 sono 
passati felicemente al C#.
Quindi, dal punto di vista accademico hai ragione alla grande. Dal 
punto di vista pratico, per quel che conta la mia esperienza, non regge 
il confonto con la vecchia scuola:
int Papero(..);
Almeno c'è un codice d'errore. Non è molto, ma viste le alternative. 
Nel mondo reale al massimo hai la documentazione per il codice 
"vecchio".
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

dello stato di parametri di ciascuna funzione,
Vedendo altri linguaggi mi viene da dire che sento la mancanza di una 
introspezione forte. Cosa che farebbe comodo nella gestione delle 
eccezioni. Non è però una mancanza tale fa farmi abbandonare il C++; 
anche se ormai sono asserragliato nel mio cubicolo, e mi difendo con il 
fucile dai programmatori C# che hanno invaso l'azienda. Per ora 
resisto, ma un giorno mi sa che riusciranno a sfondare le barricate :/
Però è forte la tentazione di scappare sulla scialuppa di salvataggio 
scritta in python con moduli speciali scritti in C ;-)
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 void Papero(..);
Beh, chiaro che se uno scrive una funzione che lancia eccezioni senza 
specificarne il tipo (o senza almeno documentarlo), non può pretendere 
che vengano gestite correttamente... D'altra parte anche i codici di 
ritorno devono essere documentati, altrimenti sono inutili.
E.

Nicola Musatti ha scritto:

avresti la possibilità di abbozzare una macro suddetta ?
Io non sono riuscito a pensare a niente di meglio a quelle 
antiche macro tipo va_start, va_arg e va_list per accedere a 
roba assortita sullo stack (che però, nel caso di una funzione 
dal prototipo ben definito, potrebbe assumere un senso diverso 
anche per il chiamante, che sapendo cosa ha messo sullo stack, 
boh, magari potrebbe fare qualche controllo di cosa sia successo 
... certo che la cosa più utile, ma difficilissima, sarebbe 
poter ottenere come immagine l'ultima fotografia di stack frame 
valido PRIMA del crash, più che la fotografia appena dopo 
l'eccezione)
Cmq se hai tempo, qualche suggerimento su queste macro e la 
classe adatta sarebbe molto interessante
ciao
Soviet


 stringa con .what() e stop, 
Non puoi neanche chiamare .what() su una eccezione generica... se vuoi 
utilizzare e.what() devi fare catch(Exception &e), non catch(...). Tra 
l'altro mi pare anche sensato.
E.

 sballati. 
Perché stai riparando a canoni di pessima programmazione portati avanti
da altri.

 sistema può andare bene.
Può anche. Tutto si può fare.
La questione è che se ci sono degli strumenti, e sono stati introdotti
per migliorare certi aspetti, è limitante non utilizzarli perché possono
essere male utilizzati. Certo è che se non li usi hai le tue buone
ragioni, anche se non le condivido per come le hai descritte.

 valori dummy per lavarsene le mani.
ni, nel senso che nel 99% dei casi si finisce con ignorare quel valore
(un pessimo programmatore è un pessimo programmatore, ca va sans dir).

 inutile.
Tra l'altro lo spirito sarebbe giusto quello di gestire solo quello che
sai gestire.
Pertanto l'unico uso legale del catch generico è, a mio parere, nel main
 ( o similare ).

 l'eccezione)
Veramente non pensavo a niente di piu' che a qualcosa del tipo:
#define my_throw(msg) throw MyException(msg, __LINE__, __FILE__)
class MyException : public std::runtime_error {
  MyException(const std::string & msg, const std::string & line, const
std::string & file);
...
};
Come dicevo il C++ standard non prevede stack trace e quindi ogni
eventuale ulteriore informazione sullo stato locale va messa a manina.
D'altra parte mi pare molto piu' utile un debugger che si blocca al
lancio delle eccezioni che non ritrovarsi con un log molto prolisso
che a posteriori dice abbastanza poco. Meglio avere un bel core dump,
sulle piattaforme che lo forniscono.
Ciao,
Nicola

 
esistono i debugger per queste cose, semplice.
seriamente che te ne fai di un backtrace completo a runtime?

 void Papero(..) throw(errore_1, errore_2, altro_tipo);
Fortunatamente, aggiungo. 
Con la semantica di C++ se scoppia un'eccezione che non è errore_1,
errore_2 e altro_tipo (il che può accadere, vedi come si infila dentro
il templating e tutto), con C++ è un evento catastrofico. 
Non si passa più per la normale gestione delle eccezioni, ma è un
macello.
In particolare l'unica cosa del genere che io trovo utile è la throw()
per cose che *sicuramente* non lanciano eccezioni, qualunque cosa
succeda e cascasse il mondo (e se l'eccezione parte siamo a livello di
calamità naturale :P)
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 scritta in python con moduli speciali scritti in C ;-)
O anche in C++, eh. :)


 di errore di Eclipse ;-)
Ne vorrei sapere invece.


 In particolare l'unica cosa del genere che io trovo utile è la throw()
Già usare la libreria standard però è a rischio perché tutti i 
prototipi sono definiti come
qualcosa Funzione(qualcosaltro);
e non come
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 In particolare l'unica cosa del genere che io trovo utile è la throw()
Già usare la libreria standard però è a rischio visto che tutti i 
prototipi sono definiti come:
qualcosa Funzione(qualcosaltro);
e non come:
qualcosa Funzione(qualcosaltro) thorw();
qualcosa Funzione(qualcosaltro) thorw(std::exception);
Bellissimo nel mondo accademico, ma nel mondo reale mi capita di usare 
anche la libreria standard. Su quella non ho certezze, se non leggermi 
la documentazione. Non mi sembra il massimo.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 sono inutili.
err = Papero();
if( erro == SUCCESS )
{
   printf("Maledetto papero.\n");
   printf("Adesso spiegami tu cosa devo fare con l'errore %i.\n", err);
}
mi pare meglio di:
try
{
  Papero();
}
catch()
{
   printf("Ops, c'è stato un problema.\n");
}
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 Ne vorrei sapere invece.
Non e' niente di particolare, ma ai miei utenti ogni tanto Eclipse va
in crash e loro speranzosi mi mandano un capture del messaggio
d'errore, che tipicamente e' un error code tipo 8192, seguito da un
lunghissimo stack trace, del quale non mi faccio assolutamente niente.
Tanto varebbe avere un meccanismo per l'invio della traccia al team di
sviluppo.
Pero' c'e' qualcosa di gratificante nel vedere un'applicazione Java
andare a picco per una NullPointerException ;-)
Ciao,
Nicola

 Pertanto l'unico uso legale del catch generico è, a mio parere, nel main
Su questo concordo, peccato che però a con il catch generico non hai 
informazioni sull'errore.
L'unica è far derivare l'errore da una classe generica (std::exception) 
con un minimo di informazioni sull'errore, e poi mettere un catch sulla 
classe base nel main.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 classe base nel main.
Purtroppo si trovano ovunque cose tipo throw 1; oppure throw "Errore
generico". Probabilmente se fosse possibile derivare ogni oggetto da una
classe Object contenente un metodo ToString(), sarebbe possibile
trattare con una catch ( Object &e )  e stampare l'errore. Ma quando hai
a che fare con throw 1; sei fregato.
Del resto la classe std::exception è messa li  a posta.

 O anche in C++, eh.
Non lo so. Trovo che l'ultimo punto di forza del C/C++ sia che 
decompilare e capire un programma scritto con questi linguaggi non sia 
ridicolarmente facile come in Python o DotNet.
L'altro punto a favore, ma minore, è che ci vuole un po' di disciplina 
per sopravvivere in C++; cosa per niente necessaria in VB o C#. Non è 
colpa del linguaggio, ma con questi ultimi due vedo delle schifezze 
tali da farmi rabbrividire. Gbyte di roba passata per parametro o tra 
computer perché "tanto funziona lo stesso".
Contro c'è che la libreria di Python è assolutamente incredibile. C'è 
veramente di tutto, e con il fatto che puoi esternderla in C puoi 
andare oltre l'immaginazione (se non ti interessa il multipiattaforma).
Un'altra cose che rimpiango che non sia standardizzato in C++ è il 
naming (o come cavolo si dice) e il caricamento dinamico dei moduli. 
Così non si può usare una lib compilato con XYZ nel tuo programma. 
Grossissima mancanza per me. Devi sempre usare un ponte in C per queste 
cose, o ricompilarti tutto sul tuo compilatore.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 Del resto la classe std::exception è messa li  a posta.
Se però il Musatti mi dice che non sono standard i costruttori:
   exception(const char *const&);
   exception(const char *const&, int);
mi vien voglia di mandare a cagare chi l'ha progettata.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 }
Io avrei fatto:
try {
	Papero();
} catch(exception &e) {
	cerr<<"Ops, è capitato l'errore '"<<e.what()<<"'..."<<endl;
	cerr<<"Se non sai che vuol dire devi chiedere a Papero."<<endl;
}
il catch() generico è del tutto inutile in questo caso. Mi sembra di 
capire che il problema che tu (o i tuoi programmatori) avete più 
esperienza con il C che con il C++, anche a giudicare dall'utilizzo di 
printf.
E.

 
L'importante non è il costruttore, ma il metodo d'accesso al messaggio,
il what().
Infatti per ogni progetto generalmente mi costruisco una classe
MyProject : public std::exception che definisce un costruttore che
prende come parametro una const string &.
Diventa quindi banale una
throw MyException ("Si è verificato l'errore X in " __LINE__ " file
"__FILE__ );
e poi la catch (std::exception) che stampa il tutto con la what().

 #define my_throw(msg) throw MyException(msg, __LINE__, __FILE__)
In particolare se si usa g++ noi usavamo __PRETTY_FUNCTION__, non
standard, ma ti da il nome e la classe del metodo.


 seriamente che te ne fai di un backtrace completo a runtime?
Dai, fra il dire che lo facciano i debugger e dire che non sarebbe
comodo che per lo meno quando schianta desse più informazioni, ce ne
passa.
Cioè anche io troverei comodo che quando esplode il tutto mi da un po'
più di informazione, eh.


 anche a giudicare dall'utilizzo di printf.
Mi permetti di non essere d'accordo?
1) std::exception è consigliato, ma non obbligatorio. Quindi non è 
detto che catch(exception &e) funzioni. Se tutti facessero le cose per 
bene non avremmo codice con bugs. Poi se uno lancia l'eccezione 
derivata da std::exception? Devi usare come minimo un puntatore.
2) Questa cosa che se uno usa la printf invece dei modi didattici 
allora è un programmatore C mi fa incavolare. Primo printf fa parte 
dello starndard, quindi niente di male se una la usa. Tra i tanti 
problemi di printf, e ne ha parecchi, c'è che la "mia" quack_printf 
(cioè la printf scritta da me) è thread safe. Ti voglio vedere 
riscrivere in modo thread safe "umano" codice simile:
ippopotamo_cout << "io esisto" << "ma magari un altro thread si è messo 
nel mezzo" << std::endl;
Capisco gli esempi didattici e accademici, ma nel mondo reale devo 
preoccuparmi di dettagli come lo scrivere codice multithread e 
multitask. Non è che se una cosa c'è essa debba essere utilizzata per 
forza. In ambiente multithread cout è una scelta pessima tanto quanto 
la printf, ma almeno la printf è replicabile in qualcosa di 
accettabile, in modo che un solo thread alla volta scriva sulla console 
un messaggio intelleggibile. Quindi, se uso la printf nei miei esempi 
c'è un motivo. Poi trovare il motivo stupido, su questo non discuto. 
Però dirmi che sono un programmatore C per una printf lo trovo 
irrittante.
Detto ciò, aggiungo, io non ci vedo niente di male ad usare il C++ come 
un banale C con classi. Ti togli delle opportunità, ma c'è di peggio.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 prende come parametro una const string &.
Sei coscente che potresti non avere memoria per creare la std::string 
che passi per parametro?
Detto ciò uno dei problemi che non c'è un metodo standard per avere 
l'elenco delle chiamate sullo stack, i parametri e altre informazioni. 
Con la possibilità di togliere questa possibilità nel rilascio finale, 
con uno sorta di comando strip. Per esempio in Python tutto questo è 
gratis. Non devi nemmeno fare un try/catch nel main. Poi avere i 
sorgenti praticamente sempre disponibili ha i suoi lati negativi. Però 
diavolo che comodità.
Per testare i miei programmi in C++ ormai uso esclusivamente "ambienti" 
scritti in python. Rispetto quelli un tempo scritti in C++ e in VB ci 
metto meno tempo a estenderli, e meno tempo a debaggarli. Aggiungo che 
io scrivo quasi solo esclusivamente programmi senza interfaccia 
grafica, cosa che considero una cosa bellissima.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 mi vien voglia di mandare a cagare chi l'ha progettata.
std::exception dovrebbe essere l'interfaccia generica da intercettare.
Le eccezioni da lanciare dovrebbero essere quelle definite in
<stdexcept>.
Ciao,
Nicola

 un banale C con classi. Ti togli delle opportunità, ma c'è di peggio.
No, infatti. Ma non puoi dire che utilizzare le opportunità in più (le 
eccezioni, ad esempio) sia un male.
E.

 printf.
Ti confesso che per buttare giů un esempio cosě anche io avrei usato
printf (nota nemmeno fprintf(stderr, ...) ). Principalmente perchč mi
pare di digitare meno :)
Anzi forse puts.


 la documentazione. Non mi sembra il massimo.
E quindi? Io mica ho detto che devi *sempre* usare throw(). Ho detto che
se *sai* che il tuo codice *non* lancia eccezioni, e nemmeno il codice
che chiami da li (pensa a molte funzioni matematiche, per dire), puoi
usarlo. 
Dopo di che, non mi piacciono tantissimo questi continui accenni al
'mondo accademico' e al 'mondo reale' inteso come 'il tuo mondo'. Sarò
sicuramente io che capisco male, eh. :)


 il what().
Quoto.


 andare a picco per una NullPointerException ;-)
Credo che sia parte del fatto che è type-safe, si sono scordati che il
null pointer è valore valido per tutti gli oggetti. Aggiungo che in modo
abbastanza divertente tale eccezione non è obbligatoriamente da catchare
(e capisco perchè, va bene essere verbosi all'inverosimile, ma se no si
esagerebbe): per cui ecco come il castello di carte crolla.


 cose, o ricompilarti tutto sul tuo compilatore.
Si, quoto tutto.


 un banale C con classi. Ti togli delle opportunità, ma c'è di peggio.
Penso che la differenza di visione sia tutta qui. 


 uno più compatto e con una maggiore quantità di informazione.
Dipende da chi e' l'utente. Io il codice di Eclipse non ce l'ho e non
voglio averlo, per cui dello stack trace non me ne faccio proprio
niente, lungo o corto che sia.
Ciao,
Nicola

 niente, lungo o corto che sia.
Chiaro: io parlo mentre debuggo il mio software o un sw di cui sono
responsabile. Gli stack trace di Java li trovo quasi inutili (non so se
hai mai avuto la sfiga di fare qualcosa con J2EE, non sono rari stack
trace di lunghezza comparabile con il sorgente stesso <g>).
Viceversa uno stack trace con un po' di informazioni ma non troppe
sarebbe utile anche in C++. Eventualmente abilitato con qualche flag
(pure in produzione potrebbe essere comodo eh, visto che i clienti non
sanno dire molto più che 'non funziona'). 


 po'più di informazione, eh.
E sopratutto, non sempre quando esplode c'e' un debugger pronto
all'uso... tipo quando esplode solo sulla macchina del cliente :).
--*PaN!*


-- 

I'm using an evaluation license of nemo since 164 days.
You should really try it!
http://www.malcom-mac.com/nemo

 sanno dire molto più che 'non funziona'). 
Noi sulle nostre applicazioni linux intercettiamo i segnali di 
terminazione e prima di chiudere l'applicazione tramite backtrace(), 
backtrace_symbols() e demangle() ricostruiamo uno stack trace piuttosto 
completo ed utile, la stessa cosa purtroppo non e` possibile farla in un 
catch a livello di mainloop perche` lo stack si e` gia` "srotolato", ma 
volendo e' possibile farlo dove si spara la throw, magari nel 
costruttore dell'exception stessa...
Ovviamente richiede la glibc sto giochetto.
Bye,
  Gabry

 linee, io scrivo tre linee.
Saggio. Ma questo è un esempio di codice *semanticamente* uguale ma più
chiaro.


 indiscriminato per non lasciare filtrare qualcosa.
Idem non sapendo che codice di errore aspettarti, non fai proprio nulla.


On Jan 30, 6:44 pm, 
r...@despammed.com
 (crxor 666) wrote:

Ti diro', tutti gli IDE con cui lavoro si fermano al lancio di
eccezioni e alla ricezione di segnali per cui, almeno quando faccio
debug, non sento particolarmente la mancanza di stack trace. Lo stack
vero e proprio e' molto meglio :-)
Ciao,
Nicola

 Ovviamente richiede la glibc sto giochetto.
No default os x, quindi...


 No default os x, quindi...
OSX lo stack trace lo fa di default quando crasha un'applicazione (anche 
diviso per bene thread x thread), quindi suppongo ci sia un modo 
altrettanto comodo x ottenerlo!
Bye,
  Gabry

 altrettanto comodo x ottenerlo!
Il giochino della Console.app. Si, possibile. 
Magari però è roba a livello sottostante di kernel, e sicuramente non
portabile.


 'mondo accademico' e al 'mondo reale' inteso come 'il tuo mondo'.
Guarda, con mondo accademico non intentendo nemmeno tanto il mondo 
"accademico", quanto il modo "accademico" di fare le cose. Non sai 
quante volte mi sono sentito controbattere che sul libro sacro XYZ si 
fa così. Le mie risposte, di solito scortesi, sono del tipo: io non 
voglio fare in quel modo per la ragione A, B, C, discutiamo delle mie 
ragioni. Spesso, non sempre ma spesso, mi sento rispondere che non 
importano le mie ragioni nel nostro problema contingente, il metodo 
"giusto" è XYZ.
Ancora oggi, per fortuna ora raramente, mi capita di dovere intervenire 
per "sostituire" programmatori scarsi e indottrinati per far portare a 
termine una consegna. Che palle però.
Non sono contro le eccezioni, se non quando diventano dottrina. Quando 
diventano il modo giusto di fare le cose a prescindere. Infondo con 
questi miei interventi a gamba tesa, se mi sono preso del pomposo 
imbecille ma ho instillato il dubbio in qualcuno, sono pure contento. 
Che usi poi felicemente le eccezioni, ma in modo consapevole.
Tanto pomposo imbecille, se lo sono, lo rimango a prescindere :-)
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 <stdexcept>.
Va beh, qui pago la mia ignoranza sulla libreria standard con questa 
correzione ad una mia fesseria. Sono come minimo a 2. Poi ho smesso di 
contare.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 portabile.
Questo non credo, andando a memoria con quello che mi fece vedere un 
collega sotto windows. Lui usava il misconosciuto windbg della 
microsoft, però faceva qualcosa di simile.
Approfondirò l'argomento perché mi interessa moltissimo. Fossanche che 
funziona solo sotto linux sarei contento lo stesso.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 perchè non potrebbe ignorare i codici di errore.
C'è da dire che io, in parte, gioco sporco. Sul codice che faccio 
faccio quel che mi pare, e sono sempre d'accordo con me stesso. Sul 
codice che deve essere usato da altri, impongo la questa visione:
1) Sei libero di ignorare l'errore, equivalente ad un catch(..), se 
posso ci metto una pezza io.
2) Se l'errore è grave termino io il programma con tanto di log :-)
3) Ignora perché la libreria funziona, usala e basta.
La filosofia della black box ha un suo perché. La fregatura è che mi 
sento dire: il programma non funziona bene, sicuramente è colpa della 
tua libreria "so tutto io", e non del mio codice.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 eccezioni, ad esempio) sia un male.
Infatti non lo dico. Dico che usare in modo automatico un'opportunità 
non è la stessa cosa che usare quella stessa opportunità in modo 
consapevole. Se uno gestisce gli errori solo per una timida scritta sul 
log, per esempio, scrivi codice più veloce se non usi le eccezioni. Nel 
mio caso, per esempio, la velocità di esecuzione non è un dettaglio 
trascurabile.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 Infatti non lo dico. 
Allora siamo d'accordo.
E.

 contare.
In realta' il mio uso del condizionale e' legato al fatto che quanto
ho scritto sopra non e' dovuto a particolari letture, quanto a una
conclusione personale alla quale sono giunto mentre leggevo il tuo
post precedente.
Ciao,
Nicola

 oriented.
Con printf ovviamente no. Con una generica print, potresti.
Ad ogni modo se vuoi vedere degli stream veramente caotici, guarda Java.
In C++ non sono malaccio: devi capire quello che stai facendo, come in
tutto quello che riguarda C++.
Aggiungo poi che se std::cout non è thread safe, spulciando lo standard,
non lo è per scelta di chi lo ha implementato, non per necessità
intrinseca. Riformulo: chi ha bisogno di roba thread safe, non lo userà,
se l'implementazione non è thread safe. Tuttavia se ci fosse
un'implementazione thread safe (fattibile, IMHO, anche se magari non c'è
per motivi di 'costo'), si potrebbe usarla.
Oh, poi per fare un po' di logging c'è di meglio degli stream, IMHO.
Ovvero un concetto *separato* di stream di log. A questo punto che siano
funzioni che implicitamente lo usano, un oggetto o whatever, cambia
poco.
BTW, da quello che ricordo la libreria C++ distribuita con il
compilatore Intel, per lo meno sotto Linux e MacOS X è definita
thread-safe. Suppongo esserlo pure gli stream standard.


 "giusto" è XYZ.
E' vero. E' un problema frequente: il problema è che molte persone
appoggiano una soluzione senza avere *davvero* interiorizzato il perchè.
Per cui a prescindere dal fatto che abbiano ragione loro o tu nello
specifico, più che citare ex cathedra l'autorità superiore non possono
fare. Il che ovviamente è negativo: se avevano ragione non sanno imporre
la cosa giusta (perchè non ne conoscono i motivi), viceversa se hanno
torto non capiranno *perchè*, non apprenderanno la lezione che
implicitamente stai dando loro e non capiranno magari nemmeno che nel
libro sacro la soluzione canonica aveva precondizioni più o meno
implicite che nel vostro caso non sono date.


 non oggetti definiti dall'utente.
template<typename Obj>
int oprintf(const Obj& o) {
  puts(o.string().c_str());
}
Supponendo che come convenzione gli oggetti che voglio stampare
definiscano questo metodo string.
Nota che non č concettualmente diverso da dire che bisogna implementare
operator<<.


::pre_order_iterator> > const&, sitx::fork_type::type>::Main() + 94
8   com.stuffit.stuffitcore             0x003d05d5
qpthr::QpRunnable::InvokeMain() + 25
9   com.stuffit.stuffitcore             0x003d1f3d
qpthr::QpPThread::Main() + 213
10  com.stuffit.stuffitcore             0x003d1316
qpthr::QpThread::invoke_main(void*) + 46
11  libSystem.B.dylib                   0x930df075 _pthread_start + 321
12  libSystem.B.dylib                   0x930def32 thread_start + 34
Thread 7:
0   com.stuffit.format.sitx             0x0d15e9e4
nio::input::read_char() + 0
1   com.stuffit.format.sitx             0x0d04cb2b
brimstone::compressor::run() + 287
2   com.stuffit.format.sitx             0x0d1697f7
sys::thread::entry(void*) + 27
3   libSystem.B.dylib                   0x930df075 _pthread_start + 321
4   libSystem.B.dylib                   0x930def32 thread_start + 34
Thread 8:
0   libSystem.B.dylib                   0xffff06b0 __bzero + 176
1   com.stuffit.format.sitx             0x0d1bb4ca void
eeko::natural_codec::ProcessComponent1Quantized<unsigned short>(bool) +
1038
2   com.stuffit.format.sitx             0x0d13e13d
eeko::natural_codec::Encode(nio::output&, int, int, void**, int*, int*,
unsigned int, eeko::algorithm_type::type, unsigned long, unsigned int,
unsigned int) + 685
3   com.stuffit.format.sitx             0x0d0a49f8
image::compress_single(image::vector_component&, nio::output&,
image::compressor_type::type, int) + 442
4   com.stuffit.format.sitx             0x0d0b74c7
tif::helper::compress_image_data(nio::vector&, nio::vector&, int,
image::compressor_type::type) + 769
5   com.stuffit.format.sitx             0x0d0b4848
tif::compressor::run() + 2744
6   com.stuffit.format.sitx             0x0d1697f7
sys::thread::entry(void*) + 27
7   libSystem.B.dylib                   0x930df075 _pthread_start + 321
8   libSystem.B.dylib                   0x930def32 thread_start + 34
Thread 4 crashed with X86 Thread State (32-bit):
  eax: 0x95340000  ebx: 0x954ea7f3  ecx: 0x966fffb0  edx: 0x00000001
  edi: 0x00678af0  esi: 0x00000000  ebp: 0xb0226b78  esp: 0xb0226abc
   ss: 0x0000001f  efl: 0x00010246  eip: 0x95340006   cs: 0x00000017
   ds: 0x0000001f   es: 0x0000001f   fs: 0x0000001f   gs: 0x00000037
  cr2: 0xdad88038
Binary Images:
    0x1000 -    0x3efea +com.stuffit.DropStuff 12.0.1 (12.0.1)
<11ca1d7085f444c6825faf8a72985a3c> /Applications/StuffIt
12/DropStuff.app/Contents/MacOS/DropStuff
   0x54000 -    0x7fff7  com.apple.DiscRecordingUI 4.0 (4000.4.10)
<f7d79479e05b83b6b5af98cc92308bdb>
/System/Library/Frameworks/DiscRecordingUI.framework/Versions/A/DiscReco
rdingUI
  0x134000 -   0x1fdff5  com.apple.DiscRecording 4.0 (4000.4.10)
<d4130992c67baeb1ec39e6b63e080550>
/System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecord
ing
  0x268000 -   0x2abfdb  com.apple.DotMacKit ??? (1.2)
/Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/DotMacKit.framework/Versions/A/DotM
acKit
  0x2d9000 -   0x320feb +com.stuffit.sdk 12.0.1 (12.0.1)
<f75ca13b084b4b83aa7a7b13a7f8cea0> /Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/StuffIt.framework/Versions/B/StuffI
t
  0x384000 -   0x40ffd1 +com.stuffit.stuffitcore 12.0.1 (12.0.1)
<b625f52a4e264a51b15c3c7cdb49abb1> /Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/StuffItCore.framework/Versions/A/St
uffItCore
  0x568000 -   0x568ffe +org.xlife.InquisitorLoader 3.0 (49)
/Library/InputManagers/Inquisitor/Inquisitor.bundle/Contents/MacOS/Inqui
sitor
  0x56d000 -   0x56ffff +net.culater.SIMBL 0.8.2 (8)
/Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL
  0x575000 -   0x576fff +com.1passwd.InputManager 2.5.4 (5707)
<7887d5465cdf53e3261f84c1e55bb7ef>
/Library/InputManagers/1PasswdIM/1PasswdIM.bundle/Contents/MacOS/1Passwd
IM
  0x57b000 -   0x580fff +com.macromates.edit_in_textmate ??? (1.0)
/Library/InputManagers/Edit in TextMate/Edit in
TextMate.bundle/Contents/MacOS/Edit in TextMate
 0xd022000 -  0xd34ffff +com.stuffit.format.sitx 164.204.581
(164.204.581) <a8d029e3b32d487db2714bd70c92e345> /Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/StuffItCore.framework/Versions/A/Pl
ug-Ins/sitx.bundle/Contents/MacOS/sitx
 0xdb0e000 -  0xdbf4ff7  com.apple.RawCamera.bundle 2.0 (2.0)
/System/Library/CoreServices/RawCamera.bundle/Contents/MacOS/RawCamera
 0xe400000 -  0xe414fff +com.stuffit.format.mime 164.204.581
(164.204.581) <552c8c2636ae480bae6307cac703bfae> /Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/StuffItCore.framework/Versions/A/Pl
ug-Ins/mime.bundle/Contents/MacOS/mime
 0xe430000 -  0xe482fff +com.stuffit.format.zip 164.204.581
(164.204.581) <0fc52c59b6784d7894f90aae266eb35d> /Applications/StuffIt
12/DropStuff.app/Contents/Frameworks/StuffItCore.framework/Versions/A/Pl
ug-Ins/zip.bundle/Contents/MacOS/zip
0x8fe00000 - 0x8fe2d883  dyld 95.3 (???)
<81592e798780564b5d46b988f7ee1a6a> /usr/lib/dyld
0x90003000 - 0x90053ff7  com.apple.HIServices 1.6.0 (???)
<d74aa73e4cfd30a08fb169198a8d2539>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/HIServices.framework/Versions/A/HIServices
0x90054000 - 0x90178fe3  com.apple.audio.toolbox.AudioToolbox 1.5 (1.5)
/System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbo
x
0x90179000 - 0x90229fff  edu.mit.Kerberos 6.0.11 (6.0.11)
<33c25789baedcd70a7e24881775dd9ad>
/System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
0x90236000 - 0x9023bfff  com.apple.backup.framework 1.0 (1.0)
/System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
0x9023c000 - 0x90263fff  libcups.2.dylib ??? (???)
<6b61eb99e6f5dd2d66cd224e9f82427d> /usr/lib/libcups.2.dylib
0x90269000 - 0x90310fff  com.apple.QD 3.11.50 (???)
<e2f71720ae1dad06a8883ac80775b21a>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/QD.framework/Versions/A/QD
0x90311000 - 0x90721fef  libBLAS.dylib ??? (???)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ve
cLib.framework/Versions/A/libBLAS.dylib
0x90722000 - 0x90ab8ff7  com.apple.QuartzCore 1.5.1 (1.5.1)
<deb61cbeb3f734a1b2f4669f6268b9de>
/System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
0x90ab9000 - 0x90b45ff7  com.apple.LaunchServices 284 (284)
<0fb50a7a6fd38875f727fc2592a496e4>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
LaunchServices.framework/Versions/A/LaunchServices
0x90b46000 - 0x90b6eff7  com.apple.shortcut 1 (1.0)
<057783867138902b52bc0941fedb74d1>
/System/Library/PrivateFrameworks/Shortcut.framework/Versions/A/Shortcut
0x90c7a000 - 0x90d0dfff  com.apple.ink.framework 101.3 (86)
<bf3fa8927b4b8baae92381a976fd2079>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.fr
amework/Versions/A/Ink
0x90d0e000 - 0x90d1cffd  libz.1.dylib ??? (???)
<5ddd8539ae2ebfd8e7cc1c57525385c7> /usr/lib/libz.1.dylib
0x90d1d000 - 0x911e9ffe  libGLProgrammability.dylib ??? (???)
<e8bc0af671427cf2b6279a035805a086>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLPr
ogrammability.dylib
0x91208000 - 0x9134dff7  com.apple.ImageIO.framework 2.0.0 (2.0.0)
<154d4d8cda2bd99518cbabc9f2d69833>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/ImageIO
0x9134e000 - 0x9137dfe3  
com.apple.AE
 402 (402)
<994ba8e884aefe7bf1fc5987df099e7b>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
AE.framework/Versions/A/AE
0x913af000 - 0x9142eff5  com.apple.SearchKit 1.2.0 (1.2.0)
<277b460da86bc222785159fe77e2e2ed>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
SearchKit.framework/Versions/A/SearchKit
0x9142f000 - 0x91488fff  libGLU.dylib ??? (???)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.
dylib
0x914ce000 - 0x917e2fe2  com.apple.QuickTime 7.4.0 (92)
<0d674546d12c65dc5c33dca4c81c315b>
/System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime
0x91821000 - 0x918d3ffb  libcrypto.0.9.7.dylib ??? (???)
<330b0e48e67faffc8c22dfc069ca7a47> /usr/lib/libcrypto.0.9.7.dylib
0x918d4000 - 0x918d4ffb  com.apple.installserver.framework 1.0 (8)
/System/Library/PrivateFrameworks/InstallServer.framework/Versions/A/Ins
tallServer
0x918d5000 - 0x91c93fea  libLAPACK.dylib ??? (???)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ve
cLib.framework/Versions/A/libLAPACK.dylib
0x91c9a000 - 0x91c9afff  com.apple.Carbon 136 (136)
<98a5e3bc0c4fa44bbb09713bb88707fe>
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
0x91c9b000 - 0x91dcdfe7  com.apple.CoreFoundation 6.5 (476)
<8bfebc0dbad6fc33bea0fa00a1b9ec37>
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFound
ation
0x91dce000 - 0x91e48ff8  com.apple.print.framework.PrintCore 5.5 (245)
<9441d178f4b430cf92b67bf346646693>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/PrintCore.framework/Versions/A/PrintCore
0x91e49000 - 0x91f10ff2  com.apple.vImage 3.0 (3.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vI
mage.framework/Versions/A/vImage
0x91f11000 - 0x91f18ffe  libbsm.dylib ??? (???)
<d25c63378a5029648ffd4b4669be31bf> /usr/lib/libbsm.dylib
0x91f19000 - 0x91f76ffb  libstdc++.6.dylib ??? (???)
<04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib
0x9214d000 - 0x9218cfef  libTIFF.dylib ??? (???)
<6d0f80e9d4d81f3f64c876aca005bd53>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
0x9228f000 - 0x9229effe  com.apple.DSObjCWrappers.Framework 1.2 (1.2)
<f5b58d1d3a855a63d493ccbec417a1e9>
/System/Library/PrivateFrameworks/DSObjCWrappers.framework/Versions/A/DS
ObjCWrappers
0x9229f000 - 0x922dcff7  libGLImage.dylib ??? (???)
<202d73e6a4688fc06ff11b71910c2ce7>
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLIm
age.dylib
0x922dd000 - 0x92301fff  libxslt.1.dylib ??? (???)
<4933ddc7f6618743197aadc85b33b5ab> /usr/lib/libxslt.1.dylib
0x92302000 - 0x92307fff  com.apple.CommonPanels 1.2.4 (85)
<ea0665f57cd267609466ed8b2b20e893>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Common
Panels.framework/Versions/A/CommonPanels
0x92308000 - 0x9230afff  com.apple.securityhi 3.0 (30817)
<2b2854123fed609d1820d2779e2e0963>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Securi
tyHI.framework/Versions/A/SecurityHI
0x9230e000 - 0x9230ffef  libmathCommon.A.dylib ??? (???)
/usr/lib/system/libmathCommon.A.dylib
0x92310000 - 0x92310ffd  com.apple.Accelerate.vecLib 3.4 (vecLib 3.4)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ve
cLib.framework/Versions/A/vecLib
0x923f1000 - 0x92478ff7  libsqlite3.0.dylib ??? (???)
<273efcb717e89c21207c851d7d33fda4> /usr/lib/libsqlite3.0.dylib
0x924a5000 - 0x924bdfff  com.apple.openscripting 1.2.6 (???)
<b8e553df643f2aec68fa968b3b459b2b>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenSc
ripting.framework/Versions/A/OpenScripting
0x924be000 - 0x92589fff  com.apple.ColorSync 4.5.0 (4.5.0)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ColorSync.framework/Versions/A/ColorSync
0x9258a000 - 0x925cbfe7  libRIP.A.dylib ??? (???)
<bdc6d70bf4ed3dace321b4ff76a353b3>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib
0x925cc000 - 0x92656fff  com.apple.framework.IOKit 1.5.1 (???)
<5176a7383151a19c962334009fef2c6d>
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
0x926c5000 - 0x926e3ff3  com.apple.DirectoryService.Framework 3.5 (3.5)
<899d8c9ee31b004a6ff73dab88982b1a>
/System/Library/Frameworks/DirectoryService.framework/Versions/A/Directo
ryService
0x926e4000 - 0x926e8fff  libGIF.dylib ??? (???)
<d4234e6f5e5f530bdafb969157f1f17b>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
0x926e9000 - 0x9277bff3  com.apple.ApplicationServices.ATS 3.0 (???)
<fb5f572243dbc370a0ea5efc8e81ae11>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ATS.framework/Versions/A/ATS
0x92ac2000 - 0x92dc8fff  com.apple.HIToolbox 1.5.0 (???)
<1b872a7151ee3f80c9c736a3e46d00d9>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HITool
box.framework/Versions/A/HIToolbox
0x92dc9000 - 0x92dcffff  com.apple.print.framework.Print 218 (220)
<c35172175abbe554ddadd9b6401351fa>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.
framework/Versions/A/Print
0x92dd0000 - 0x92dd0ff8  com.apple.Cocoa 6.5 (???)
<e064f94d969ce25cb7de3cfb980c3249>
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
0x92dd1000 - 0x92dd9fff  com.apple.DiskArbitration 2.2 (2.2)
<1551b2af557fdf6f368f93e093933852>
/System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbi
tration
0x92dda000 - 0x92e34ff7  com.apple.CoreText 2.0.0 (???)
<7fa39cd5bc847615ec02e7c7a37c0508>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/CoreText.framework/Versions/A/CoreText
0x92e35000 - 0x92e45ffc  com.apple.LangAnalysis 1.6.4 (1.6.4)
<cbeb17ab39f28351fe2ab5b82bf465bc>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/LangAnalysis.framework/Versions/A/LangAnalysis
0x92e46000 - 0x92e55fff  libsasl2.2.dylib ??? (???)
<b9e1ca0b6612e280b6cbea6df0eec5f6> /usr/lib/libsasl2.2.dylib
0x92e56000 - 0x92f37ff7  libxml2.2.dylib ??? (???)
<450ec38b57fb46013847cce851001a2f> /usr/lib/libxml2.2.dylib
0x92f38000 - 0x92f56fff  libresolv.9.dylib ??? (???)
<54e6a08c2f108bdf5916fb483d51961b> /usr/lib/libresolv.9.dylib
0x930ae000 - 0x93208fe3  libSystem.B.dylib ??? (???)
<8ecc83dc0399be3946f7a46e88cf4bbb> /usr/lib/libSystem.B.dylib
0x9323e000 - 0x93262feb  libssl.0.9.7.dylib ??? (???)
<acee7fc534674498dcac211318aa23e8> /usr/lib/libssl.0.9.7.dylib
0x9331f000 - 0x933d5fe3  com.apple.CoreServices.OSServices 210.2 (210.2)
<4ed69f07fc0f211ab32d1ee96e281fc2>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
OSServices.framework/Versions/A/OSServices
0x933d6000 - 0x93418fef  com.apple.NavigationServices 3.5.1 (161)
<cc6bd78eabf1e2e7166914e9f12f5850>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Naviga
tionServices.framework/Versions/A/NavigationServices
0x93419000 - 0x93429fff  com.apple.speech.synthesis.framework 3.6.59
(3.6.59) <4ffef145fad3d4d787e0c33eab26b336>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
0x9342a000 - 0x934a1fe3  com.apple.CFNetwork 220 (220)
<0ae8fbcbadcb9bd8d673aa4531c0fcfc>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
CFNetwork.framework/Versions/A/CFNetwork
0x934a2000 - 0x934adff9  com.apple.helpdata 1.0 (14)
/System/Library/PrivateFrameworks/HelpData.framework/Versions/A/HelpData
0x934ae000 - 0x934c9ffb  libPng.dylib ??? (???)
<b6abcac36ec7654ff3e1cfa786b0117b>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
0x934ca000 - 0x934deff3  com.apple.ImageCapture 4.0 (5.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageC
apture.framework/Versions/A/ImageCapture
0x934df000 - 0x935c3ffb  com.apple.CoreData 100 (185)
<a4e63784275e25e62f57e75e0af0b94d>
/System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
0x935c4000 - 0x93638fef  libvMisc.dylib ??? (???)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ve
cLib.framework/Versions/A/libvMisc.dylib
0x93639000 - 0x9363bff5  libRadiance.dylib ??? (???)
<20eadb285da83df96c795c2c5fa20590>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
0x94aea000 - 0x94b00fe7  com.apple.CoreVideo 1.5.0 (1.5.0)
<7e010557527a0e6d49147c297d16850a>
/System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
0x94b17000 - 0x94c95fff  com.apple.AddressBook.framework 4.1 (687)
<3f005092d08e963eabe8f7f66c09cc1e>
/System/Library/Frameworks/AddressBook.framework/Versions/A/AddressBook
0x94caa000 - 0x94cadfff  com.apple.help 1.1 (36)
<b507b08e484cb89033e9cf23062d77de>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.f
ramework/Versions/A/Help
0x94cae000 - 0x94cb5fe9  libgcc_s.1.dylib ??? (???)
<f53c808e87d1184c0f9df63aef53ce0b> /usr/lib/libgcc_s.1.dylib
0x94cb6000 - 0x94deeff7  libicucore.A.dylib ??? (???)
<afcea652ff2ec36885b2c81c57d06d4c> /usr/lib/libicucore.A.dylib
0x94def000 - 0x94e25fff  com.apple.SystemConfiguration 1.9.0 (1.9.0)
<7919d9588c3b0d556646e555b7193f1f>
/System/Library/Frameworks/SystemConfiguration.framework/Versions/A/Syst
emConfiguration
0x94f75000 - 0x94f94ffa  libJPEG.dylib ??? (???)
<0cfb80109d624beb9ceb3c43b6c5ec10>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
0x94f95000 - 0x95044fff  com.apple.DesktopServices 1.4.3 (1.4.3)
<66d5ed56111c43d234e235d365d02469>
/System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions
/A/DesktopServicesPriv
0x950b5000 - 0x950b5ffd  com.apple.vecLib 3.4 (vecLib 3.4)
/System/Library/Frameworks/vecLib.framework/Versions/A/vecLib
0x950b6000 - 0x950b7ffc  libffi.dylib ??? (???)
<a3b573eb950ca583290f7b2b4c486d09> /usr/lib/libffi.dylib
0x950b8000 - 0x950b8ff8  com.apple.ApplicationServices 34 (34)
<8f910fa65f01d401ad8d04cc933cf887>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Appl
icationServices
0x950f3000 - 0x950f3ffc  com.apple.audio.units.AudioUnit 1.5 (1.5)
/System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
0x952b0000 - 0x952b0ffa  com.apple.CoreServices 32 (32)
<2fcc8f3bd5bbfc000b476cad8e6a3dd2>
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreService
s
0x952b1000 - 0x952f6fef  com.apple.Metadata 10.5.0 (398)
<4fd74fba0062c2e08ec4b1c10b40ff63>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
Metadata.framework/Versions/A/Metadata
0x952f7000 - 0x95321fef  libauto.dylib ??? (???)
<d468bc4a8a69343f1748c293db1b57fb> /usr/lib/libauto.dylib
0x95322000 - 0x95b1cfef  com.apple.AppKit 6.5 (949)
<f8d0f6d0bb5ac092f48f42ca684bdb54>
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x95b5b000 - 0x95bb7ff7  com.apple.htmlrendering 68 (1.1.3)
<fe87a9dede38db00e6c8949942c6bd4f>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HTMLRe
ndering.framework/Versions/A/HTMLRendering
0x95be8000 - 0x95c22ff7  com.apple.coreui 0.1 (60)
/System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
0x95c23000 - 0x95e9cfe7  com.apple.Foundation 6.5.1 (677.1)
<85ac18c7cd454378db6122bea0c00965>
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x95e9d000 - 0x95e9dffd  com.apple.Accelerate 1.4 (Accelerate 1.4)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
0x95ebd000 - 0x96196fe7  com.apple.CoreServices.CarbonCore 783 (783)
<8370e664eeb25edc98d5c1f5405b06ae>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
CarbonCore.framework/Versions/A/CarbonCore
0x96197000 - 0x9619eff7  libCGATS.A.dylib ??? (???)
<9b29a5500efe01cc3adea67bbc42568e>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib
0x9619f000 - 0x961acfe7  com.apple.opengl 1.5.5 (1.5.5)
<aa08b52d2a84b44dc6ee5d544a53fe8a>
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
0x961ad000 - 0x961dafeb  libvDSP.dylib ??? (???)
<a26683d121ee0f96df9a9d0bfca36049>
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ve
cLib.framework/Versions/A/libvDSP.dylib
0x96228000 - 0x9623efff  com.apple.DictionaryServices 1.0.0 (1.0.0)
<ad0aa0252e3323d182e17f50defe56fc>
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/
DictionaryServices.framework/Versions/A/DictionaryServices
0x9623f000 - 0x962bbfeb  com.apple.audio.CoreAudio 3.1.0 (3.1)
<70bb7c657061631491029a61babe0b26>
/System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
0x962bc000 - 0x96485fef  com.apple.security 5.0.1 (32736)
<8c9eda0fcc1d8a571543025ac900715f>
/System/Library/Frameworks/Security.framework/Versions/A/Security
0x965cc000 - 0x965fefff  com.apple.LDAPFramework 1.4.3 (106)
<3a5c9df6032143cd6bc2658a9d328d8e>
/System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
0x965ff000 - 0x96609feb  com.apple.audio.SoundManager 3.9.2 (3.9.2)
<0f2ba6e891d3761212cf5a5e6134d683>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Carbon
Sound.framework/Versions/A/CarbonSound
0x96617000 - 0x96623ff5  libGL.dylib ??? (???)
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.d
ylib
0x96693000 - 0x9669efe7  libCSync.A.dylib ??? (???)
<df82fc093e498a9eb5490761cb292218>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib
0x9669f000 - 0x9677efff  libobjc.A.dylib ??? (???)
<5eda47fec2d0e7853b3506aa1fd2dafa> /usr/lib/libobjc.A.dylib
0x9680c000 - 0x96ea3fef  com.apple.CoreGraphics 1.351.0 (???)
<7a6f399039eed6dbe845c169f7d21a70>
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Fram
eworks/CoreGraphics.framework/Versions/A/CoreGraphics
0x96ea4000 - 0x96eadfff  com.apple.speech.recognition.framework 3.7.24
(3.7.24) <d3180f9edbd9a5e6f283d6156aa3c602>
/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Speech
Recognition.framework/Versions/A/SpeechRecognition
0xfffe8000 - 0xfffebfff  libobjc.A.dylib ??? (???)
/usr/lib/libobjc.A.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???)
/usr/lib/libSystem.B.dylib
 ====
-- 
cc = callcc {|cc| cc.call cc}; cc.call cc

 operator<<.
Ma è concettualmente molto diverso dalla funzione printf.
E.

 della libreria standard non puň essere estesa ai tipi definiti dall'utente.
Ma su, fai l'astrazione! :)
Aggiungici un parametro all'inizio che prende la stringa di
formattazione, te la fai parsare e fa la cosa giusta. 
Se i varargs non funzionassero con roba templatica (come penso), puoi
sempre usare le tecniche implementate dentro boost per generarne con n
parametri.


 formattazione, te la fai parsare e fa la cosa giusta. 
Puoi astrarre quanto vuoi ma non è possibile fare quello che dici...
E.


    cout << format("%02d : [%_9d] \n") % 4 % Rational(8,1234);
 
    cout << format("%02d : [%_9d] \n") % 5 % Rational(1234,8);
    cout << format("%02d : [%09d] \n") % 6 % Rational(8,1234);
    cout << format("%02d : [%0+9d] \n") % 7 % Rational(1234,8);
    cout << format("%02d : [%0+9d] \n") % 8 % Rational(7,12345);


 vero e proprio e' molto meglio :-)
Anche perché, spesso e volentieri, se lo stack frame si sputtana, lo
stack trace è spazzatura.

     cout << format("%02d : [%_9d] \n") % 4 % Rational(8,1234);
Qui viene sovraccaricato l'operator% in perfetta analogia con 
l'utilizzao di operator<<. Non puoi sperare di passare gli argomenti a 
printf, per il semplice fatto che
	printf(const char *format, ...);
non puň essere sovraccaricato.
E.

 non può essere sovraccaricato.
Capisci che è una distinzione *puramente* formale?
Posso sulla base di quelle definire n versioni di oprintf sovraccaricate
secondo il numero di parametri templatici. Vai a vedere come fanno per
boost::tuple per farti un idea.


 Capisci che è una distinzione *puramente* formale?
Diciamo che in un caso hai una funzione che accetta un numero variabile 
di elementi, nell'altro hai molte funzioni ognuna che accetta 1, 2 ,3 
,.., N elementi.
E.

 ,.., N elementi.
Questa è una questione puramente implementativa: all'effetto pratico non
cambia *nulla*.
Tieni presente che tutte le implementazioni hanno comunque un numero
finito e ragionevolmente piccolo di argomenti al massimo supportati. 


 In pratica quando schianta un programma lui genera un log di questo tipo
A parti i riferimenti al sorgente queste cose le ho viste anche sotto 
windows. Senza stack trace questo output c'è gratis con il 
decompilatore gratis che c'è in ogni windows.
Quando ho tempo vado a fondo della faccenda, magari ci riesco prima 
della fine del 2008 :-(
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 della fine del 2008 :-(
Ma mi sa che non ho capito quale è l'obiettivo e/o di cosa stiamo
parlando. :)


 parlando. :)
E lo chiedi a me :') ?
Comunque vorrei avere (facilmente) in C++ quello che in Python o in 
dotnet è gratis. Linea e sorgente su tutto lo stack frame a partire 
dall'instruzione con il bugs. Che poi funzioni con il solo eseguibile 
compilato in debug mi sta bene. Se devo avere il debugger sotto mano 
no, anche per un problema di licenze se parliamo di un eseguibile che 
va in crash dal cliente.
Ci vuole un C++ compilato in modo "virtuale" che poi gira sotto una 
macchina virtuale (leggi dotnet)? Mi starebbe bene se è possibile. 
Quest'ultima cosa però non so se è *realmente* possibile. Dovrei 
studiare la cosa, e il tempo per questo proprio non ce l'ho.
Ho visto che hanno introdotto quei strani puntatori ^, e ho lasciato 
subito perdere. Altamente non portabile quei puntatori.
-- 
http://aratriel.wordpress.com/2007/11/05/in-lavorazione-il-primo-teaser-trailer-di-star-trek-2008/

 una scarpata). 
Ma vuoi veramente cancellare il file? Y
Sei sicuro di volere cancellare il file? Y
Mr. Gates ti ricorda che non sarà più possibile leggere il contenuto del
file. Sei dunque certo oltre ogni ragionevole dubbio di volere
cancellare il file? Y
tr tr tr
Sto per cancellare il file. Confermi? Y
Ma insomma, non ti piace nemmeno un po' questo file? Y
File non cancellato.


 [...]
Manlio Perillo

 
Grazie in anticipo
ciao
Soviet

 un oggetto si trova dentro __dict__.
In fatti c'era l' 'in pratica'. Ma per spiegarlo a qualcuno che mai ha
visto Python, č di gran lunga piů comodo dirlo cosě. IMHO, eh.


 conosco affatto. Cosa sono e a cosa servono, "in a nutshell" ?
Il problema è questo: i tipi nativi *non* sanno dare informazioni su se
stessi. Perchè sono cosi stupidi; non puoi chiedere ad un intero quanto
è largo, ad un carattere idem o a un puntatore che sa fare. Puoi
chiederlo a funzioni esterne, certo, ma non a loro.
Invece i tipi definiti da te possono avere dei bei campi templatici
::size, funzioni membro etc etc etc.
Per cui quando vuoi scrivere codice che funzioni in base a informazioni
ottenute dal tipo su cui lo parametrizzi *e* vuoi che funzioni anche con
tipi 'analoghi' della stl, 'butti fuori' con un traits.
Ovvero i traits 'di base' prendono l'informazione dai tipi 'complessi'
(che contengono l'informazione) e sono specializzati sui tipi base in
modo che rendano l'informazione per questi tipi. A questo punto quando
vuoi informazione usi i traits che te le ritornano sia per i tipi base
che per i tipi costruiti.
Suggerisco di pensare un pochetto agli iterator_traits.


> conosco affatto. Cosa sono e a cosa servono, "in a nutshell" ?
rifletterò ben bene su questo tuo post, che mi è risultato 
illuminante (almeno nel senso di evidenziare quel che non sapevo 
di sapere, ed è cosa buona).
Intanto grazie ... eventualmente chiederò altri consigli, magari 
sotto thread apposito
ciao
CUT ALL

 sotto thread apposito
Ok-
