Newsgroup: it.comp.lang.c++
Titolo: Operatore new

Raramente nel codice (anche quelli di esempio) vedo che viene testato il
valore di ritorno dell'operatore new, che fallisce nel caso non ci sia piu'
memoria disponibile. Chiedendo un po' in giro ho sentito dire che quando
fallisce il new il sistema e' molto in crisi e la gestione dell'errore e'
inutile, mentre altri accettano di proposito che l'applicazione vada in
crash nel caso non ci sia piu' memoria disponibile. Che ne pensate?
E poi, quando verificate se un puntatore ha un valore valido, usate:
if ( pPointer == 0 )
{
	// ...
}
oppure:
if ( pPointer == NULL )
{
	// ...
}
ho saputo che su quest'ultima cosa ci sono diverse correnti di pensiero...
ciao
Merlino
--
Posted from 
firewa...@xgate.ebi.it
 [194.243.48.2]
via Mailgate.ORG Server - 
http://www.mailgate.org

 
L'uso della costante NULL deriva dal C, dove l'interscambio di tipi di
puntatori e' piu' libero che in C++. Non tutti i compilatori definiscono
NULL allo stesso modo (in origine era #define NULL (char *)0 ).
Ciao,
Nicola

 ho saputo che su quest'ultima cosa ci sono diverse correnti di pensiero...
Puoi scommetterci -- io non scrivero` mai altro che
    if(!pPointer)
Troppe volte ho visto, in sede di code review, cose del tipo:
    if(pPointer = NULL)
...:-).
Alex

 ho saputo che su quest'ultima cosa ci sono diverse correnti di pensiero...
Io personalmente preferisco il valore zero in quanto non nasconde
eventuali strane definizioni di NULL mentre è un valore perfettamente
ammissibile per un puntatore ed indica che quest'ultimo non punta a
niente.
EMG

...:-).
Io scrivo sempre 
if ( NULL == pPointer )
anche se non si capisce poi che cosa voglia dire ! ;))
--
Andrea Laforgia        (
andrea_...@bigfoot.com
)

 anche se non si capisce poi che cosa voglia dire ! ;))
Be`, si legge "se e` nullo il puntatore" -- non c'e`
poi male.  Ma continuo a preferire "not" ("!").
Alex

 niente.
E pensare che una volta invece consigliavano di NON usare lo zero, poichè
l'implementazione di NULL era dipendente dalla piattaforma...
Beh, comunque visto che oramai è standard...
--
Alessandro Monti

diventa un puntatore smart, un operator! sara` sicuramente
Che cos'e' un puntatore smart ?
--
Andrea Laforgia        (
andrea_...@bigfoot.com
)

 Che cos'e' un puntatore smart ?
Un puntatore smart, o "smart pointer" o "puntatore furbo"
che dir si voglia, e` una classe (normalmente un template)
che riproduce un tot delle caratteristiche dei puntatori ma
al contempo ne aggiunge altre utili.  L'esempio presente
nello standard C++ e` std::auto_ptr<>, che aggiunge
al normale comportamento dei puntatori la caratteristica,
spesso assai comoda, di effettuare automaticamente il
delete dell'oggetto a cui punta nel suo distruttore (cio`
ti garantisce la corretta deallocazione della risorsa sia
in casi di return da qualsiasi punto del codice, sia anche
in caso di uscita anormale via exception).
Alex

 flag.
Esattamente. Io continuo a preferire
if(pPointer == 0)
e un accorto uso degli warnings che ti avvertano se per sbaglio scrivi
if(pPointer = 0)
EMG

 non ho [ricevuto un] puntatore [valido]"...
Va bene, ma non tutti i puntatori li puoi chiamare pPointer. A quel
punto affiderai la leggibilità al solo prefisso del nome della
variabile. Es.:
if ( !pNome )
e
if ( !bNome )
sarebbe una differenza un po' troppo piccola tra il controllare se per
un puntatore è stata allocata memoria o se nel flag booleano è contenuto
il valore falso. Almeno secondo i miei gusti "letterari". :-)
EMG

ti garantisce la corretta deallocazione della risorsa sia
Quindi, fammi capire, questa e' la risposta orientata agli oggetti
alla classica domanda dei neofiti del C sulla deallocazione di matrici
bidimensionali, per esempio, quando non si sa, avendo allocato un:
int **p ;
con 
p = malloc( num_elementi_verticali * sizeof( int * ) ) ;
for ( i = 0 ; i < MAX_H ; i++ )
    p[i] = malloc( num_elementi_orizzontali * sizeof ( int ) ) ; 
se si puo' deallocare solo con:
free(p) ;
oppure se bisogna effettivamente deallocare tutti gli elementi puntati
(cosa che, lo sanno tutti, si e' obbligati a fare in aggiunta
all'istruzione precedente).
Usando un puntatore smart, si puo' avere una funzione free() che si
occupi di deallocare anche tutto il resto ?
Ho capito male (in tal caso picchiami pure ;) o e' cosi' ?
Grazie, comunque, per le impeccabili spiegazioni ;)
--
Andrea Laforgia        (
andrea_...@bigfoot.com
)

 Beh, comunque visto che oramai č standard...
Proprio per questa ragione bisogna usare invece lo zero.  Che e'
garantito essere convertito dal compilatore, se unato in un
contesto appropriato, a qualsivoglia sia la rappresentazione
interna del puntatore nullo.
Il motivo fondamentale e' comunque quello che e' stato citato
prima; mescolando certe convenzioni tipiche del C, come il
definire NULL (void *) 0, con la tipizzazione forte del C++
che non converte da (void *) al tipo di puntatore necessario
senza obiettare, nascevano casini.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 Grazie, comunque, per le impeccabili spiegazioni ;)
Prego!
Alex

 il valore falso. Almeno secondo i miei gusti "letterari". :-)
E allora la distinzione fra, che so,
    if(cout << 3) // ecc
e
    if(iout  << 3) // ecc
...?-)
La differenza fra controllare se sia andata a buon fine l'emissione
della costante 3 su standard output, e controllare se si sia ottenuto
zero shiftando 3 bit a sinistra un valore intero, puo` essere certo
considerata "semanticamente" assai vasta, eppure la sintassi dei due
casi, in C++ Standard, e` molto, molto simile.
Lo stesso possiamo dire per la distinzione fra il "+" fra interi, che
somma, e quello fra stringhe, che le concatena; e cosi` via.
C'e` chi non sopporta gli overload, e allora gli conviene usare Java
(qualche overload "di sistema" lo subira` comunque, ma pochi).
Chi ama il C++, presumibilmente, apprezza gli overload ben usati.
Il concetto di poter fare overload di operator! su di un qualsiasi
oggetto X e` che quell'X *SI PUO` TRATTARE COME BOOLEANO*.
In altri termini: *IN ADDIZIONE* a qualsiasi altra semantica di X,
esso mette a disposizione un "test naturale" di "vero o falso".
Ad esempio:
    if(!cout)    // se ho avuto errori sullo std::iostream cout
    if(!flag)     // se il booleano "flag" vale 0 ("falso")
    if(!ch)       // se il carattere ch vale 0 ("fine stringa tipo-C")
    if(!p)         // se il puntatore p non punta a nulla
    if(!X)         // se l'oggetto X di classe Y e` "falso/finito/non valido/..."
Questa "unificazione" concettuale e` veramente potente, ed e` la
radice del "generic programming" incorporato nella Standard C++
Library.  Uno stream, un booleano, un carattere, un puntatore, un
oggetto di una classe Y definita dall'utente, ..., tutti hanno diverse,
diversissime semantiche, *MA*, *NEL CONTESTO* di una semplice
verifica "booleana", posso _ignorare_ queste differenze, perche`, IN
QUEL CONTESTO, *non importano*; importa SOLO il fatto che si
puo` verificare lo "stato naturale si/no dell'oggetto" con una ben
definita semantica -- e sintassi perfettamente uniforme.  E`, se vuoi,
un caso particolare di quel fondamentale concetto dell'informatica
che e` la "information hiding" -- concetto che ha stravolto non pochi
ascoltatori dal tempo ormai lontano in cui Parnas lo introdusse.  La
"informazione" sul tipo dell'oggetto che sto "testando" qui non e`
molto "nascosta", in quanto sicuramente quell'oggetto e` dichiarato
e il suo tipo si puo` quindi leggere facilmente (inoltre, molti amano
codificare nel nome delle variabili una indicazione di tipo, secondo
varianti della cosiddetta "notazione ungherese"); ma _agli scopi del
mio test_, posso IGNORARE questa informazione, che a quegli scopi
e` non significativa, non rilevante.
Chi capisce veramente bene questo, e se mai si stupisce del perche`
l'information hiding possa sorprendere chicchessia, e` chi ha una
buona cultura matematica.  Non voglio dimostrare teoremi "sugli
interi" se non mi servono TUTTE le moltissime proprieta` degli
interi -- se mi basta, come e` di solito, un sottoinsieme di queste
proprieta`, voglio "nascondere" tutte le altre informazioni, poiche`
"localmente non rilevanti", e dimostrare quindi il mio teorema per
qualsiasi "gruppo" (in senso algebrico), ovvero "gruppo abeliano",
ovvero "anello", ecc ecc.
Cosi` pure, se in un angolino del mio codice mi serve SOLO la
possibilita` di verificare un dato oggetto per vero/falso con il
comune operator!, e` meglio "nascondere", per cosi` dire, tutte
le altre moltissime proprieta` di quel dato oggetto (ad esempio
il fatto di essere confrontabile per eguaglianza con 0, ecc ecc),
e usare _solo_ quel pochissimo che e` "localmente rilevante".
Con un uso giudizioso dell'information hiding, anche in questa versione
tanto limitata, si MIGLIORA la leggibilita` del proprio codice, ben
lungi dal peggiorarla.
Alex

if ( pPointer == NULL )
Non uso mai NULL, a seconda di come e` definito potrebbe causare
problemi. Oggi il problema non dovrebbe porsi piu` di tanto, ma io
preferisco utilizzare direttamente 0
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

 per errore (pPointer = 0).
Heh heh, una volta tanto siamo d'accordo io e te, che stia
per venire a nevicare?-).  Relativamente alla ridondanza, in
effetti, ricordo quando un grande papavero cercava, in un
"manuale di stile" di un progetto, di imporre l'uso dell'"==0"
e "!=0" esplicito in questi casi -- controproposi:
    if( (((espressione da testare) != 0) != 0) != 0)
se un confronto inutile e ridondante e` piu` leggibile di zero, 
due saranno ancora piu` leggibili di uno, e tre, anche meglio, 
no?-)  [Vanno bene anche gli ==0, purche` in numero pari:-].
(P.S.: riuscii ad averla vinta, sia pur non senza che ne
risultasse un po' di cattivo sangue, ma tanto, ci sono
abituato:-).
Alex

 lungi dal peggiorarla.
Sai che ti dico? Mi hai convinto. La prossima volta che mi capiterà di
dover testare un puntatore terrò sicuramente presente la visione delle
cose che mi hai presentato.
EMG

vector all'inizio di ciascuna riga).
Capito ;) grazie.
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

per venire a nevicare?-).
Puo` essere... :)
Comunque ci sono molte altre cose in cui la penso come te...


 Comunque ci sono molte altre cose in cui la penso come te...
Che vi stiate per fidanzare? He he he!
Scusate, ma non ho proprio resistito.
Per auto-punizione mi flagellerò scrivendo un programma interamente in VB.
--
Alessandro Monti

Per auto-punizione mi flagellerò scrivendo un programma interamente in VB.
Meglio direttamente in binario e utilizzando le schede perforate.


> Meglio direttamente in binario e utilizzando le schede perforate.
Non è proprio la stessa cosa, ma qualcosa di simile l'ho già fatta, su
macchine tessili piuttosto vecchiotte...
Credo invece che scrivere un programma in VB sia molto meno stimolante
intellettualmente e più complicato per mancanza di una formalizzazione seria
del linguaggio. Dover testare ogni linea di codice non solo per la sua
correttezza, ma anche per vedere se effettivamente fa quello che promette la
sintassi, è enormemente frustrante. Inoltre non ho mai usato VB per
programmi che andassero al di là del test veloce di qualche specifico
controllo, per cui credo che la fatica sarebbe maggiore.
Domanda: ma per perforare le schede è sufficente una "pinzatrice" di quelle
per il cuoio? (non so come si chiami esattamente)
--
Alessandro Monti

per il cuoio? (non so come si chiami esattamente)
Non saprei, ma visto che la punizione ti pare un giochetto potresti
utilizzare uno spillo e nessun altro strumento di ausilio, neanche una
riga per calcolare la posizione in cui fare i fori!!!!!!


 sintassi, è enormemente frustrante.
Condivido nel modo più assoluto!
EMG

 wrote in message news:38450693...@flashnet.it...

Interessante... questa e` fondamentalmente la mia impressione
del Perl, linguaggio che uso (e tanto!), e la cui potenza e` davvero
splendida (o spaventosa che dir si voglia), ma di cui una qualsiasi
"formalizzazione" e` virtualmente impossibile (mi sembra).  Con
VB -- forse perche` l'ho usato meno, forse perche` come testi ho
usato "Hardcore VB" e "O-O Programming in VB", che danno una
impostazione sensata -- la mia esperienza e` molto meno disastrosa
della vostra (certo non e` un linguaggio con la potenza del Perl, ma
questo si puo` dire anche del 99.9% degli altri linguaggi...:-).
(Devo ammettere che, anche come linguaggio di scripting, sto
cercando di convincermi a passare invece al Python, che ha fra
i suoi principali vantaggi quello di un'assoluta pulizia e formalismo
di sintassi e semantica, e i vantaggi che a questo conseguono
[tipo, migliore integrazione con Win32 -- essendo piu` semplice
e limpido, e` piu` facile da portare; salvataggio del bytecode
in forma precompilata, idem; e cosi` via] oltre naturalmente che
gli svantaggi [meno _pragmatico_, come lo sono assolutamente
il Perl e il VB, e in qualche misura il C++; quindi non altrettanto
versatile/multiparadigma -- mentre nei linguaggi 'pragmatici' ci
sono sempre vari modi semi-giusti di affrontare un problema, e
_uno_ di essi e` facile che venga alla mente, in quelli piu` puri,
come Python o Sather, e` piu` probabile che ci sia UN modo
clamorosamente giusto -- se/sinche` non ti viene in mente
quello, la vita puo` essere amara...:-)]).
Alex

 riga per calcolare la posizione in cui fare i fori!!!!!!
Ok, di solito uso le punte delle forbici per fare i buchi e un dischetto da
3"1/2 per misurare le distanze, non avendo una riga a disposizione quando
serve :-)
Suggerimenti per il programma? Considera che l'hardware che le legge, se si
trova ancora, è molto semplice...
Devo calcolare le traiettorie dei colpi di cannone?
--
Alessandro Monti

 della vostra (certo non e` un linguaggio con la potenza del Perl, ma
A dire il vero non ho usato mai VB in modo serio, ma solo per delle
piccolissime prove. Uso però correntemente (e poco correttamente) VFP, che
ha molti punti di contatto con VB, Forse migliore come paradigma ad oggetti,
anche se ancora incompleto, come gestione dei databases (la sua ragione di
esistere), ma assolutamente incomprensibile in certi suoi comportamenti. Ad
esempio, ho scoperto a mie spese che là dove è ammesso usare una variabile,
spesso è meglio non porre dei membri di oggetto, che pure contengono i
valori giusti, pena crash ripetuti che non si presentano necessariamente nè
alla stessa riga di codice, nè apparentemente per nessun altro motivo. A
volte bastava cancellare la procedura e riscriverla ex-novo (dopo averla
magari stampata o magari copia-incollata su un documento di notepad) per non
avere più problemi. Inutile dire che scoprire quale fosse il problema è
stato arduo... Adesso mi premuro di creare delle variabili locali per poi
scrivere cose del tipo:
m.a = thisform.textbox1.value
e passarle poi ai costrutti meno tolleranti.
So che VB in questo è molto più stabile, ma avendo amici che lo usano per
lavoro e che mi raccontano le sue magagne, ho molta paura... Uno di essi ha
dovuto persino segnalare un bug a MS italia, per sentirsi rispondere dopo
qualche ora che sì, il problema c'è, ma che solo negli USA lo avevano
scoperto, e solo da poco. (Scaricare patch di una decina di Mb circa per
risolvere il problema).
A questo punto, fare dei buchi in una scheda di cartone mi sembra poca
cosa...
--
Alessandro Monti

 piccolissime prove.
Io invece lo uso e l'ho usato parecchio per lavoro e ogni volta mi
vengono i conati di vomito...
EMG

Devo calcolare le traiettorie dei colpi di cannone?
Magari le traiettorie delle componenti di un atomo in un accelleratore
 :)
E` piu` esoterico!
