Newsgroup: it.comp.lang.c++
Titolo: Dove sta andando il C++ ?

Linguaggio che ho scoperto da un anno a questa parte e che trovo
meraviglioso.
La domanda sarà forse banale ma secondo voi questa linguaggio avrà ancora un
futuro ?
Oppure verra sostituito da java, c# o altri ancora più orientati al web ?
Ciao a tutti e buon divertimento con il C++.

Oppure verra sostituito da java, c# o altri ancora più orientati al web ?
IMHO il C++ non morirà e convivrà insieme ai vari linguaggi .NET
centrici.
-- 
Lawrence "Rhymes" Oluyede (
rhy...@myself.com
)
"Per cambiare, per diventare un'altra
cosa dobbiamo prima sapere cosa siamo"
(Bruce Lee)

centrici.
errata corrige: il C++ fa parte di 
VS.NET
 e 	quindi non muore
proprio :)


Oppure verra sostituito da java, c# o altri ancora più orientati al web ?
Onestamente penso che sarebbe molto meglio se fosse sostituito da
altri linguaggi in alcuni campi dove non è necessaria tutta la potenza
del C++ ma è meglio avere un linguaggio più flessibile e produttivo.
Invece per tutti quei campi in cui serve un linguaggio con le
caratteristiche del C++ non vedo possibili alternative.
-- 
Marco Barisione (ICQ 84277092)

Oppure verra sostituito da java, c# o altri ancora più orientati al web ?
Prova a scrivere qualcosa come Unreal con Java o C# poi ne riparliamo.
Il Ghenio
---------
// TODO: Place your ass here

 wrote in message
news:PElsPPHPGkn70abmxX8AfVN0w=U...@4ax.com...


 tale da giustificare la maggiore complessità del suo utilizzo.
Il problema non e' solo di efficienza, ma anche di espressivita'.
Nessuno degli altri linguaggi ragionevolmente popolari al giorno d'oggi
ha la potenza espressiva del C++. Certo, bisogna imparare ad usarla, ma
dopo programmare ad esempio in Java e' come per un pianista suonare
senza i tasti neri.
Ciao,
Nicola

ha la potenza espressiva del C++
Cosa intendi esattamente con "potenza espressiva del C++"?


efficienza con Java e VB,
Invece non cambierà nulla, perché le esigenze delle applicazioni
cresceranno assieme alla potenza dei processori, ed é parità di
potenza di processore i vantaggi di una programmazione a basso livello
rimaranno gli stessi.
Inoltre io non parlavo solo di prestazioni, ma anche e soprattutto di
potenza espressiva, facilità di definirsi strutture dati complesse
partendo da quelle più semplici, ed in questo il C++ é nettamente
superiore ai linguaggi che hai nomitato(in particolare al secondo).


 Cosa intendi esattamente con "potenza espressiva del C++"?
La disponibilita' di un ampia gamma di costrutti, che consente di
modellare con particolare precisione le caratteristiche degli elementi
che compongono il dominio applicativo. Qualche esempio:
Tramite variabili allocate non dinamicamente ed overload di operatori
posso definire classi le cui istanze abbiano la semantica dei valori (ad
es. di grandezze fisiche, ma non solo).
Tramite i template posso rappresentare comunanze di carattere
strutturale tra elementi del dominio, o anche comunanze di carattere
funzionale, ove non sia necessaria la sostituibilita' tra elementi.
Non solo, ma la metaprogrammazione dei template puo' avere dei risvolti
concreti applicabili ben piu' frequentemente di quanto si possa pensare
considerando l'"esoterismo" delle piu' popolari librerie che applicano
queste tecniche.
Tramite l'ereditarieta' multipla posso attribuire piu' identita' alle
mie istanze, in modo che coprano ruoli diversi in porzioni diverse delle
mie applicazioni, ad esempio un'interfaccia utilizzata dalla gestione
interna dei dati ed un'altra utilizzata per presentare i dati
all'utente.
Persino l'eredita' multipla di implementazione puo' risultare efficace,
se usata con attenzione, per non parlare poi di "banalita'" come
ereditarieta' e funzioni membro virtuali.
Questi meccanismi possono essere ulteriormente combinati, penso al
lavoro di Andrei Alexandrescu sulle classi policy e la programmazione
generica in generale.
Esistono altri linguaggi che hanno una simile ricchezza, ma non sono
molto noti, ed anche questo ha la sua importanza, nel bene e nel male.
Tutto questo serve sempre? No, ovviamente, dipende dal dominio
applicativo. Ad esempio se ti occupi di manipolazione di testi
probabilmente te la cavi con una o due classi per rappresentare le
stringhe (immutabili e modificabili) e *molti* algoritmi da applicare a
queste classi. Pero' questa ricchezza di costrutti trova applicazione
efficace in settori molto diversi tra loro.
Le argomentazioni circa la maggior efficacia di linguaggi piu' semplici
(penso a Python) non mi convincono se le si ritiene applicabili a
qualsiasi ambito. Comunque quello che e' certo e' che linguaggi come
Java o C# non hanno ne l'elasticita' di Python ne l'espressivita' del
C++.
Ciao,
Nicola

C++.
Perché credi mi piacci tanto Python? :-)
Inoltre Python può rivelarsi un'ottima scelta proprio per sfruttare la
potenza del C++ nelle parti di progetto in cui effettivamente serve.


 potenza del C++ nelle parti di progetto in cui effettivamente serve.
Anche questo pero' dipende dall'ambito applicativo. Se il sistema di
tipi definiti dall'utente e' particolarmente complesso e' possibile che
da una parte non valga la pena di esportarlo tutto verso Python, mentre
dall'altra un'approccio a grana piu' grossa puo' limitare in modo
svantaggioso il grado di raffinamento ottenuto col C++.
Ciao,
Nicola

Scrivere shell script in C++ sarebbe un incubo.
Come dicevo per ogni campo esistono dei linguaggi più adatti, in
questo caso è Python (o perl o altri linguaggi), in altri sicuramente
c++.


 del C++ ma è meglio avere un linguaggio più flessibile e produttivo.
non so se te ne sei accorto ma gia esistono... :))
ciao

 tale da giustificare la maggiore complessità del suo utilizzo.
Questi discorsi sono sempre stati errati. Per il semplice fatto che si pensa 
che essendo i processori piu' veloci lo saranno solo per un tipo di 
linguaggio, e cio' e' sbagliato.
Io ho avuto la mia prima versione del VB nel 1994 penso, quando ancora erano 
in giro i 486dx33. Avresti potuto fare lo stesso discorso all' epoca : 
vedrai che nel 2002 con i processori a 2Ghz non ci sara' piu' alcuna 
differenza tra VB e C++...
Questo si e' sempre dimostrato palesemente falso.
Voglio dire, i processori non vanno piu' veloce solo per gli applicativi 
Java :-) (Leggi: e' ovvio che anche quelli C++ ne trarranno vantaggio)
-- 
FUSION (fyu zh & n) n: 
1) the Act or Process of Fusing or Melting Together... 
2) the State of being Fused... 
3) to Join or become Combined...

 ha scritto nel messaggio
news:MPG.16d754813...@newsproxy.camb.scee.sony.co.uk...


parere!).
IMHO sě, ma meglio dopo aver imparato un altro linguaggio piů
semplice.


 efficienza con Java e VB,
E neanche di portabilità, immagino... :-)))))
P.
-- 
_____
http://theunixplace.com/~entropia/index.html_____
 
  Mutationem motus proportionalem esse vi impressae 
et fieri secundum lineam rectam qua vis illa imprimitur
	I. N.

non so se te ne sei accorto ma gia esistono... :))
Marco intendeva penso dire che questi linguaggi già esistono....ma ciò
non significa che abbiano rimpiazzato il C++ :)


tale da giustificare la maggiore complessità del suo utilizzo.
non ne sono completamente convinto...se i software che usciranno
richiederanno come minimo una configurazione tale?


parere!).
Il C++ è un ottimo bagaglio culturale ed è vendibile sul mercato
----
Lawrence "Rhymes" Oluyede
rhy...@myself.com

proprio :)
Beh non č certo la presenza o meno in Visual Studio a determinare se un
linguaggio sopravvive oppure no.
Un Nemesis che non ha mai usato Visual Studio :)
-- 
  _  _ >>Now on Linux<<  _     || ICQ number.................Non lo uso
 | \| |___ _____ ___ ___|_|___ || Home-Page ................Non ce l'ho
 | .` | -_|     | -_|_ -| |_ -||| E-Mail................Non l'avrai mai
 |_|\_|___|_|_|_|___|___|_|___||| Un Nemesis che ha pochi e-contatti ;)

linguaggio sopravvive oppure no.
beh ovvio ma dato che penso che .NET rivoluzionerà parecchio il mondo
della programmazione e il mercato (ovviamente ci vorrà un pò di tempo)
questa è 1 assicurazione in +. Quanto all'ISO C++ penso che esisterà
sempre :) (almeno spero)


svantaggioso il grado di raffinamento ottenuto col C++.
Parlando a sproposito... chi ha sentito parlare di EIFFEL
(nel senso di uso reale, non del linguaggio in genere) ?
Io sono abbastanza incuriosito da questo linguaggio (sto
leggendo OOSC2) ma ho l'impressione di aver a che fare con
uno zombie... il newsgroup riceve pochissimi messaggi al
giorno e su web trovo poca roba aggiornata (la maggior
parte sono link rotti o puntatori a pagine che sono state
aggiornate l'ultima volta 5 anni fa) ... e questo anche
seguendo i link della FAQ di comp.lang.eiffel :(
Andrea

 Oppure verra sostituito da java, c# o altri ancora più orientati al web ?
Secondo me il C++ nei prossimi dieci anni tenderà a sostituire l'attuale uso
del C come linguaggio di programmazione di sistema, e l'attuale uso del
FORTRAN come linguaggio per il calcolo numerico, ma tenderà a essere
sostituito da Java e C# come linguaggio per il software applicativo.
Tra le applicazioni, risulterà vantaggioso usare il C++ solo per quelle che
hanno particolari vincoli prestazionali, come il software per il controllo
di apparecchiature in tempo reale (applicazioni embedded) o i videogiochi
fotorealistici, o per applicazioni vasta diffusione (software orizzontale),
come browser Web, o suite di produttività personale.
Penso che non sarà più opportuno usare il C++ per applicazioni rivolte ad un
numero limitato di utenti (software verticale) e prive di pesanti algoritmi
di calcolo, come le applicazioni di amministrazione aziendale o bancaria, o
i siti di e-commerce.
      Carlo Milanesi
http://digilander.iol.it/carlmila

del C come linguaggio di programmazione di sistem
e da dove nasce questa tua convinzione che il C verrà soppiantato?


 e da dove nasce questa tua convinzione che il C verrà soppiantato?
Il linguaggio C ha sostanzialmente soppiantato il linguaggio assembly per
due motivi:
* E' più portabile.
* E' più produttivo.
Il linguaggio C++ non è più portabile del C, ma consente una produttività
che supera quella del C di un fattore crescente con il crescere delle
dimensioni del progetto. Siccome i progetti software sono sempre più grandi,
il C++ risulta sempre più vantaggioso del C.
Naturalmente, il C viene e verrà "abusato" anche in grandi progetti, a causa
dalla resistenza di parte dei programmatori e della necessità di mantenere
software scritto in C. Tuttavia, siccome il C++ è sostanzialmente un
soprainsieme del C, non ci vuole molto tempo ad adattare un programma in C
in modo che sia un valido programma C++.
      Carlo Milanesi
http://digilander.iol.it/carlmila

alla successiva e all'oggetto GUI...
Spesso infatti chi scrive le GUI cerca di evitare questi pasticci,
comunque proprio per questi motivi anche cpython (la versione
principale di python scritta in C) non si basa più solo sul ref
counting.


counting.
Perche' dici "pasticci" ? Ci sono molti casi in cui l'oggetto
contenuto puo' voler essere interessato all'oggetto che lo
contiene... cosa c'e' di brutto in questo da un punto di
vista filosofico ? Il fatto che questo sconfigga la logica
del semplice reference counting non significa che sia una
bruttura logica... ma e' solo l'evidenziazione di un limite
del reference counting nella sua implementazione piu' semplice.
Questo e' fra l'altro solo uno dei tanti possibili casi di
"loop di reference".
Andrea

in modo che sia un valido programma C++.
Arrivati a questo punto dell'evoluzione dei due linguaggi penso non
sia più opportono parlare in termini di insiemistica. E' errato (IMHO)
dire che considerando il C++, il C sia un suo subset e ancor di meno
dire che il C++ sia una estensione del C
Oramai sono due linguaggi standardizzati con alla base filosofie di
progettazione diverse e a mio avviso scopi diversi. Il fatto che nel
99% dei casi un compilatore C++ compili anche codice C potrei
definirlo, nel bene e nel male, un effetto collaterale


vista filosofico ?
Non mi riferivo al fatto che (giustamente) una finestra sa chi è la
finestra genitore e quelle figlie, ma al fatto che quando una finestra
viene distrutta gli oggetti in memoria non vengano correttamente
distrutti, ad esempio wxPython (wxWindows per Python) fino a qualche
versione fa ogni tanto dava problemi perché c'erano dei riferimenti
circolari non previsti.
E` facile creare riferimenti circolari, ad esempio:
l = [] # crea una lista vuota
l.append(l) # aggiunge la lista a se stessa
l = None
A questo punto la lista non sarà mai cancellata solo con il reference
counting puro.


 definirlo, nel bene e nel male, un effetto collaterale
Un effetto collaterale di quale azione? Direi che negli obiettivi di
progetto del C++ c'è sempre stata l'esigenza di facilitare la transizione
incrementale da programmazione in C a programmazione in C++.
Per quanto riguarda gli scopi, direi che lo scopo del C è scrivere programmi
di sistema con meno di 50000 righe di codice, lo scopo del C++ è scrivere
programmi di sistema con più di 500 righe di codice.
Per programmi con meno di 500 righe (in pratica piccole utility) il C++ è
inutilmente complicato e crea eseguibili fastidiosamente grandi.
Per programmi con più di 50000 righe il C è decisamente meno produttivo del
C++.
Ritengo che nei prossimi anni diminuirà sempre più l'esigenza di produrre
piccole utility, mentre aumenterà sempre più l'esigenza di produrre grandi
applicazioni. Per esempio, in ambiente Windows già il C++ è molto più usato
del C, in Unix sono rimasti indietro, ma chi usa il C++ (per esempio
Trolltech, produttore della libreria QT e dell'ambiente KDE) produce
software di migliore qualità e in minor tempo di chi si ostina a usare il C
per scopi non appropriati (per esempio il progetto GNOME).
      Carlo Milanesi
http://digilander.iol.it/carlmila

 seguendo i link della FAQ di comp.lang.eiffel :(
OOSC2 e' uno dei tanti libri nella pila delle cose da leggere, sigh!
Condivido la tua sensazione: Eiffel non ha sfondato e la sua nicchia
appare molto stretta.
Ciao,
Nicola

 
Gli articoli sono vecchiotti; pur essendo datati 1998 presentano idee
decisamente piu' vecchie. Un programmatore C++ decente ed aggiornato
dichiarerebbe la classe iniziale in modo diverso (usando auto_ptr o
un'altro smart pointer) e si risparmierebbe buona parte del problema.
Che poi ci siano in giro parecchi personaggi che si ritengono buoni
programmatori C++ mentre non lo sono proprio e' certamente vero. Non
sono cosi' sicuro pero' che questo non valga anche per altri linguaggi.
Ciao,
Nicola

un'altro smart pointer) e si risparmierebbe buona parte del problema.
Concordo, ho visto il secondo esempio, ed il codice presentato nel
secondo link sembra veramente la trasposizione C++ di codice scritto
in Java,  anzi, guardando meglio leggo 
The Assignment Operator Revisited
by Richard Gillam
Advisory Software Engineer, Text & International
IBM Center for Java Technology Silicon Valley
peraltro il commento al primo esempio é a dir poco assurdo.
Il tizio si lamenta del fatto che un eccezione lanciata all'interno
del operatore di assegnamento potrebbe lasciare l'oggetto invariato,
ma ignora che é terribilmente sconsigliato da tutti i buoni libri di
C++ lanciare eccezioni all'interno di tale operatore( e questo vale
anche per il costruttore , compreso ovviamente quello di copia).
Inoltre usa catch{...}, che gli impedisce anche di analizzare
l'eccezione lanciata, e come hai già detto tu ignora completamente la
presenza di auto_ptr, che in questo caso gli sarebbe d'aiuto.
Il Ghenio
---------
// TODO: Place your ass here

in Unix sono rimasti indietro
a dire la verità questa è 1 sostanziale differenza che c'è tra i vari
*X e Win, in windows ci sono applicazione giganti che fanno tutto
mentre in *X vi sono applicazioni più piccole che fanno una cosa in
specifico e la fanno _bene_ e mettendo in comunicazione + applicazioni
piccole si può fare tutto.
IMHO questo approccio è migliore


 in Unix sono rimasti indietro,
Non mi sembra che gli ambienti Unix/Unix like dove ancora prevale la
programmazione in "c" abbiano qualcosa da invidiare agli ambienti Win32,
anzi......
Ivan Molella

presenza di auto_ptr, che in questo caso gli sarebbe d'aiuto.
La catch() viene usata solo per ripulire le cose prima di
lasciar passare l'exception senza modificarla. E' importante
che una classe, se non e' stata la fonte dell'errore, non
nasconda l'informazione sul problema... qualcuno a livello
piu' alto potrebbe essere interessato e sapere cosa fare
per porvi rimedio.
Se inoltre e' vero che con auto_ptr ci si evita di scrivere
catch quando quello che si vuole fare per risistemare le
cose sono solo delle "delete" (e non di array!) e' anche
vero che in casi piu' complessi le catch sei obbligato a
metterle eccome.
Andrea

sono cosi' sicuro pero' che questo non valga anche per altri linguaggi.
Per il C++ (o Java) credo ci sia molta inflazione per questioni
di marketing, sono convinto ad esempio che uno che si presenti
come programmatore Ada o Eiffel sia mediamente piu' competente
su quel linguaggio del (sedicente) programmatore C++/Java.
Ricordo un mio amico programmatore (che ovviamente conosceva il
C++ e un po' Java) che se ne era uscito con una frase del tipo
"Si... Visual J++ e' un po' come Java... solo che e' a oggetti"
(roba da farsi cadere tutti i denti dal ridere).
Riguardo al citare auto_ptr poi sono un po' dubbioso... ma forse
mi avevi detto che all'ultima riunione del comitato qualcuno
aveva detto di aver definitivamente risolto le incongruenze
logiche di quel piccolo mostro con cui tante volte il comitato
si e' trovato a litigare. Avevo anche intravisto un defect
report in cui veniva detto che l'implementazione descritta dallo
standard era *impossibile* da ottenere per via "normale"
(ovvero senza un po' di magia del compilatore) per via del
fatto che in alcuni contesti sarebbero state richieste
conversioni user-defined multiple per fare quanto richiesto
(non sono andato a fondo e forse sto dicendo una cacchiata).
Dire che il C++ e' semplice perche' c'e' auto_ptr mi sembra
una contraddizione (no, non e' la stessa cosa di un garbage
collector; se si sbaglia ad usare auto_ptr perche' non lo si
e' capito bene ci si fa un male della miseria... un garbage
collector e' piu' "esterno" al linguaggio).
Forse auto_ptr evita di scrivere un po' di righe di codice,
ma semplice e' un'altra cosa.
Andrea

appare molto stretta.
Peccato ... sto attivamente cercando un linguaggio alternativo
al C++ per ambiti in cui tutta la sua potenza (che non serve)
non giustificano tutta la sua complessita' e asimmetria.
Andrea

non giustificano tutta la sua complessita' e asimmetria.
A che ambiti ti riferisci in particolare? Python non va bene per i
tuoi scopi?


tuoi scopi?
Devo ancora dargli un'occhiata; comunque mi era gia' stato
segnalato.
Certo che, a prima impressione, un linguaggio in cui il
numero di spazi iniziali e' significativo fa molto FORTRAN
o COBOL  :-) ... io ho gia' problemi con il fatto che
la gente usa impostazioni diverse dei tab/indentazione
anche con l'editor e' lo stesso per tutti (VC++) :D
Comunque sto scaricando or ora il tutto :)
Andrea

 ma semplice e' un'altra cosa.
Certamente. Soprattutto semplice e potente sono contraddizioni di
termini.
Ciao,
Nicola

 non giustificano tutta la sua complessita' e asimmetria.
Io con Python mi sto trovando bene, sia per il linguaggio in se che per
la valanga di cose gia' fatte che si trovano in giro (ho gia' avuto modo
di usare un generatore di parser e win32com per automatizzare la lettura
di file Excel: in entrambe i casi non mi ci e' voluta piu' di qualche
ora per cercare la soluzione su Internet ed imparare a fare quel che mi
serviva).
Ciao,
Nicola

metterle eccome.
Certo, dipende dai casi, anche se é possibile crearsi degli
smart_pointer appositi per gestire le situazioni più disparate.


: Il tizio si lamenta del fatto che un eccezione lanciata all'interno
: del operatore di assegnamento potrebbe lasciare l'oggetto invariato,
: ma ignora che é terribilmente sconsigliato da tutti i buoni libri di
: C++ lanciare eccezioni all'interno di tale operatore( e questo vale
: anche per il costruttore , compreso ovviamente quello di copia).
: Inoltre usa catch{...}, che gli impedisce anche di analizzare
: l'eccezione lanciata, e come hai già detto tu ignora completamente la
: presenza di auto_ptr, che in questo caso gli sarebbe d'aiuto.
:
Non ho capito. E` terribilmente sconsigliato sollevare eccezioni
all'interno del costruttore, compreso quello di copia?
Mi era parso di capire che le eccezioni nascessero proprio per
colmare la lacuna dei costruttori che, non avendo valore di ritorno,
non potrebbero segnalare fallimenti.

smart_pointer appositi per gestire le situazioni più disparate.
Non sempre il problema e' l'allocazione ... a volte
devi "disfare" le cose che eri riuscito a fare perche'
altrimenti lasceresti l'istanza corrente e anche
l'applicazione in generale in uno stato incoerente.
Andrea

non potrebbero segnalare fallimenti.
Per natura i costruttori non hanno valore di ritorno, certo, ma il
fallimento di un costruttore può essere tranquillamente archiviato su
un data-member della classe che l'utilizzatore può controllare prima
di usare l'oggetto(oppure lo può controllare l'oggetto stesso quando
si tenta di usare una funzione membro ed in questo caso lanciare un
eccezione). Si tratta di una soluzione accettabile che non rende
affatto illeggibile il programma,tant'é che io l'ho usata spesso:
modem *s1=new mymodem(1,8,4,5);
if(s1->is_initialized())
{
/*............*/
}    
non mi sembra più brutto di un
try
    {
    modem *s1=new mymodem(1,8,4,5);
    }
catch(...)
    {
    /*............*/    


 affatto illeggibile il programma,tant'é che io l'ho usata spesso:
io preferisco isolare la parte che puo' fallire in un metodo,
cosi' posso tranquillamente usare eccezioni e non quei brutti if
"C-style"...
my 5 eurocents
--
Ciao by Allanon

"Il Ghenio" ha scritto
:
: Se non sconsigliato é quantomeno da prendere con le molle e da usare
: solo in casi particolari, oppure se si ha la certezza di poter gestire
: tutti i casi in cui potrebbe essere lanciata un'eccezione.
: I container del lib.standard ad esempio chiamano spesso costruttori e
: distruttori all'insaputa dell'utente ed assumono che queste operazioni
: vadano sempre a buon fine, percui in questo caso le eccezioni
: potrebbero diventare una mina vagante.
Non direi che i container della lib std assumano che le costruzioni
vadano sempre a buon fine. Mi pare che, a parte le operazioni di
inserimento nei vector o simili, quando un costruttore solleva un'eccezione
il container si trovi nello stato precedente a quello della chiamata
durante la quale viene sollevata l'eccezione.
Peraltro assumono che i distruttori non sollevino eccezioni, questo si.
Per dirla alla Sutter: weak exception safety sempre, e
strong (commit/rollback) quasi.
:
: >Mi era parso di capire che le eccezioni nascessero proprio per
: >colmare la lacuna dei costruttori che, non avendo valore di ritorno,
: >non potrebbero segnalare fallimenti.
:
: Per natura i costruttori non hanno valore di ritorno, certo, ma il
: fallimento di un costruttore può essere tranquillamente archiviato su
: un data-member della classe che l'utilizzatore può controllare prima
: di usare l'oggetto(oppure lo può controllare l'oggetto stesso quando
: si tenta di usare una funzione membro ed in questo caso lanciare un
: eccezione). Si tratta di una soluzione accettabile che non rende
: affatto illeggibile il programma,tant'é che io l'ho usata spesso:
Non e` solo un problema di leggibilita`, ma anche di manutenibilita`.
Immagina una classe derivata che contenga due o tre membri, non POD.
Se uno deve verificare il buon fine di tutte le costruzioni si finisce
per scrivere codice molto C-like tipo:
class myclass : base
{
    obj1_t obj1_;
    obj2_t obj2_;
    obj3_t obj3_;
    bool   good_;
public:
    myclass()
      : base(1), obj1_(2), obj2_(3), obj3_(4), good_(false)
    {
      if ( base::init() )
        if ( obj1_.init() )
        {
          if ( obj2_.init() )
          {
            if ( obj3_.init() )
            {
              good_ = true;
              return;
            }
            obj2_.release();
          }
          obj1_.release();
        }
      base::release();
    }
};
ciao
Massimo

 pimpl idiom, ad esempio), 
cosa intendi di preciso?
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 cosa intendi di preciso?
Secondo lo standard istanziare un template della libreria su un tipo
incompleto porta a comportamento indefinito, quindi gli implementatori
sono liberi di far funzionare la cosa o meno. In particolare con Borland
funziona o no in base alle opzioni di compilazione.
Ciao,
Nicola
P.S. Anche se lo standard lo permettesse, sarebbe comunque una cosa da
fare con cautela, perche' alcune funzioni membro di auto_ptr hanno tutte
le ragioni di pretendere di conoscere il tipo completo.

 }
e come la metti con il costruttore di copia? Se io ho questa funzione:
        void foo(Prova);
come faccio a passare un parametro a foo?
        Prova p;
        foo(p); // possibile errore: il copy ctor avrebbe potuto fallire
L'unica alternativa e` quella di controllare all'interno di foo se 
l'oggetto passato e` "usabile" o meno: e poi se foo scopre che il 
parametro e` inusabile cosa deve fare per procedere? Lanciare una 
eccezione?


 Borland funziona o no in base alle opzioni di compilazione.
quindi questo e` indefinito?
        class p;
        auto_ptr<p> ap;
:-((((
Non capisco il perche` di questa limitazione: in questo modo auto_ptr 
perde gran parte del suo "fascino" e utilita`.
Altra domanda: cosa si intende per "tipo incompleto"? Sicuramente una 
classe dichiarata ma non definita, ma c'e` anche dell'altro?


eccezione?
Mi pare che l'esempio da te fatto confermi proprio quello che dicevo
io, ovvero che é meglio usare un data-member per decretare il
fallimento di tale costruttore. In questo caso ho la possibilità di
controllare che la copia sia avvenuta correttamente ed al limite
lanciare un'eccezione(ma potrei anche fare diversamente) in caso
contrario l'eccezione mi sarebbe stata lanciata automaticamente ed il
codice sarebbe stato sicuramente meno controllabile.


codice sarebbe stato sicuramente meno controllabile.
Hmmm... non ti seguo. Tu proponi cioe' di mettere un membro dati
che indica "good" in ogni classe e verificare in ogni punto in
cui si accede a una istanza se questa e' "good" (inclusa ogni
funzione che ad esempio accetta un const reference ad una classe) ?
A me sembra una idea assurda...
Non credo che Stroustrup (ma neanche Schildt) abbiano mai
detto roba simile
Andrea

 Potresti dirmi dove hai letto una cosa del genere ?
c'e' una cosa simile su exceptional C++ di sutter, ma lo dice lui, non 
BS

BS
Puoi citarmi dove ? Non mi sembra di ricordare questo passaggio.
Nell'item 18 si parla diffusamente proprio del fatto che la
presenza di exceptions comporta un moltiplicarsi del numero di
percorsi possibili: ad esempio in
  String EvaluateSalaryAndReturnName( Employee e )
  {
    if (e.Title()=="CEO" || e.Salary() > 100000)
    {
      cout << e.First() << " " << e.Last()
           << " is overpaid." << endl;
    }
    return e.First() + " " + e.Last();
  }
vengono contati 23 diversi percorsi possibili di esecuzione
(contro 3 nel caso che non si considerino le exceptions).
Di questi percorsi molti sono proprio dovuti a costruttori
(di copia o di conversione) ma in nessun punto si accenna
al fatto che e' sconsigliabile che un costruttore lanci
una exception. La "guideline" conclusiva dell'articolo e'
   Always be exception-aware.
   Know what code may emit exceptions.
(regola sacrosanta se uno pensa di utilizzare le exceptions)
L'unico accenno al problema di costruttori che lanciano
exceptions che ricordo in quel libro e' quando si parla
delle (basse) garanzie offerte dalla libreria standard
su alcuni tipi di operazione di inserimento.
Nel testo sono pero' anche spiegate le ragioni di questa
scelta apparentemente discutibile in una libreria pensata
per un utilizzo in ambiti ampi.
Il libro non mi e' piaciuto tantissimo pero' e su alcune
parti ho "glissato" non ritenendo l'argomento specifico
interessante... mi parrebbe strano pero' che Sutter consigli
una tecnica (quella degli oggetti-zombie) che viene spesso
citata come errore comune e da evitare.
Ho trovato una citazione sull'uso di oggetti che abbiano
uno "class-specific invalid state" in Lakos, ma si riferisce
ad *alcuni casi* particolari e non ad una regola generale
(e nell'indice la parola exceptions manco compare ;-) ).
Nella libreria standard casi di questo tipo sono ad esempio
gli stream di I/O su file ... (in cui il fallimento
dell'apertura file raramente puo' essere considerato
realmente qualcosa di "eccezionale" e lo stato "invalido"
non e' secondo me uno stato di "serie B").
Anche su questo specifico caso pero' non tutti in questo
NG sono d'accordo sul fatto che la soluzione attuale
di un oggetto semi-zombie (che a me personalmente piace
in questo specifico caso) sia la migliore.
Andrea

 citata come errore comune e da evitare.
cioe'? parli del placement new?

cioe'? parli del placement new?
No ... mi riferivo a separare i concetti di "oggetto costruito"
e di "oggetto costruito e usabile". 
Mi scuso per "errore" che non e' sicuramente il termine
corretto (in C++ usare le istanze "zombie" e' qualcosa di
"legale" ma che molti ritengono "immorale"... ma la moralita'
e' sicuramente soggettiva); errore era da intendersi come
"errore di design" o per meglio dire "design discutibile".
Andrea

 "errore di design" o per meglio dire "design discutibile".
ma intendi quello che lui chiama idioma pImpl, oppure le istanze di 
oggetti non ancora costruiti che sollevano eccezioni, e che rimangono 
in uno stato usabile?
se e' per la prima, lui stesso dice che e' al centro di polemiche, e 
che lo usa solo in quella circostanza, per assicurare alcune proprieta' 
alla classe
Se e' la seconda, non ti seguo

Se e' la seconda, non ti seguo
Sara' l'ora tarda, ma non capisco di cosa stai parlando.
Io semplicemente ho chiesto dove Stroustrup avrebbe
scritto che era preferibile creare una istanza "zombie"
invece di sollevare una eccezione nel costruttore
(che BS lo avesse scritto lo aveva tirato fuori il
ghenio, se non sbaglio). Tu hai detto che invece lo
diceva Sutter e io ti ho chiesto dove...
Il pImpl in questo thread lo aveva tirato in ballo
Nicola (parlando del fatto che un auto_ptr non puo'
essere usato per una classe che sfrutta il pImpl
e che questo e' un peccato).
Cosa c'entra pero' questo con le classi "zombie" ?
Nell'ultimo mio messaggio ho semplicemente detto che
la creazione di classi zombie non e' un "errore" C++
(la cosa e' legale) ma semplicemente un design che
i piu' ritengono sconveniente.
Ci sono alcune eccezioni (es la parte di IO che ha
delle classi che apparentemente si comportano come
zombie invece di lanciare exceptions) ma queste sono
eccezioni e non la regola (e qualcuno anche in questo
newsgroup ritiene che persino per la libreria di IO
sarebbe stato meglio lanciare delle exceptions di
default ... io pero' preferisco l'implementazione
attuale che trovo piu' comoda da usare).
Andrea

 diceva Sutter e io ti ho chiesto dove...
non ci capiamo: io credevo stessimo ancora parlando di sutter, riguardo 
alle classi zombie, e non ricordando dove le citasse, ti chiesi di cosa 
stessi parlando :)
fine della reciproca incomprensione, spero
 

A me sembra una idea assurda...
Tale sistema viene invece utilizzato molto spesso(ad esempio da alcuni
componenti COM), spiegaci magari perché lo giudichi assurdo cosi'
capiremo meglio.


capiremo meglio.
Io lo trovo assurdo perche' scarica il problema dai
pochi (l'oggetto) ai molti (gli utilizzatori
dell'oggetto). Questo e' uno dei limiti della logica
classica di ritorno di uno status di successo... si
obbliga il chiamante a fare controlli e i chiamanti
in un programma sono molti piu' dei chiamati...
In pratica una funzione che torna un flag di successo
non e' piu' "sicura"... semplicemente fa a scarica
barile del problema invece di cercare di risolverlo...
per dirla alla B. Meyer una funzione che promette di
piu' e' piu' "usabile".
Riguardo al fatto che sia parte di qualche interfaccia
COM non vedo cosa ci sia da stupirsi. Quando qualche anno
fa ho iniziato a vedere le specifiche DirectX 3 c'era
l'impressione chiarissima che fossero state buttate giu'
da una banda di burloni.
Andrea

 codice sarebbe stato sicuramente meno controllabile.
facendo come dici tu il codice diventa immanutenibile; guarda questo
Rational foo(Rational p, Rational q)
{
        if (p.isValid())
                if (q.isValid()) {
                        Rational z = q+p;
                        if (z.isValid()) {
                                z++;
                                cout << z;
                                return;
                        }
                        else
                                // boh?
                }
                else
                        // boh?
        }
        else
                // boh?
}
A me non sembra un gran codice, cmq se a te piace...


mi indichi il paragrafo in cui dice cio`?
Sulla mia copia (3za edizione inglese, 10ma ristampa)
e' alla fine di 14.4.6.1 e nel nono elemento della
lista degli "advice" di quel capitolo.
Si tratta di segnalazioni su problemi di lanciare
exception da copy constructor e da operatori di
assegnazione (non da constructor in genere, per i
quali viene invece consigliato di lanciare exception
per segnalare il fallimento).
Viene anche detto che la libreria "assume" che il
copy constructor non lanci exception ... cosa che
vieterebbe ad esempio di usare cose come
std::vector<...> o addirittura std::string come
elementi di un container (!).
Il consiglio [9] e' stato rimosso con una successiva
errata corrige ma non ho trovato nulla riguardo a quel
paragrafo di 14.4.6.1.
Sto ancora indagando.
Andrea

 nella costruzione
non c'e` solo questo. Lanciare (e lasciar "uscire") eccezioni 
all'interno di un distruttore puo` portare all'undefined behaviour; 
supponiamo questo:
void foo()
{
        Prova p;
        throw "ciao";
        // viene richiamato il distruttore di p
}
In un caso come questo il distruttore di p viene richiamato durante lo 
"srotolamento" dello stack a causa dell'eccezione "ciao"; se in un caso 
come questo il distruttore lancia un'altra eccezione si ha undefined 
behaviour.



Purchè i S.O. non vengano ulteriormente appesantiti (ma ne dubito)
--
Ciao
Roberto

da una banda di burloni.
Beh, ti posso dire che sulle DirectX concordo,ho avuto a che fare con
la versione 8.1 per poi scoprire un mese dopo che era già pronta la
9.0. Alla fine ciò che avevo in mente l'ho fatto usando OpenGL.


// TODO: Place your ass here
???
Andrea