Come programmatore C # di lunga data, di recente ho imparato di più sui vantaggi di Resource Acquisition Is Initialization (RAII). In particolare, ho scoperto che il linguaggio C #:

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

ha l'equivalente in C ++:

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

nel senso che ricordare di racchiudere l'uso di risorse come DbConnectionin un usingblocco non è necessario in C ++! Questo sembra un grande vantaggio di C ++. Ciò è ancora più convincente se si considera una classe che ha un membro di istanza di tipo DbConnection, ad esempio

class Foo {
    DbConnection dbConn;

    // ...
}

In C # avrei bisogno di implementare Foo IDisposablecome tale:

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

e quel che è peggio, ogni utente Foodovrebbe ricordarsi di racchiuderlo Fooin un usingblocco, come:

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

Ora, guardando C # e le sue radici Java, mi chiedo ... gli sviluppatori di Java hanno apprezzato appieno ciò che stavano abbandonando quando hanno abbandonato lo stack in favore dell'heap, abbandonando così RAII?

(Allo stesso modo, ha Stroustrup apprezzare appieno il significato di Raii?)

Ora, guardando C # e le sue radici Java, mi chiedo ... gli sviluppatori di Java hanno apprezzato appieno ciò che stavano abbandonando quando hanno abbandonato lo stack in favore dell'heap, abbandonando così RAII?

(Allo stesso modo, Stroustrup ha apprezzato appieno il significato di RAII?)

Sono abbastanza sicuro che Gosling non abbia avuto il significato di RAII al momento in cui ha progettato Java. Nelle sue interviste ha spesso parlato delle ragioni per tralasciare i generici e il sovraccarico degli operatori, ma non ha mai menzionato distruttori deterministici e RAII.

Abbastanza divertente, anche Stroustrup non era consapevole dell'importanza dei distruttori deterministici al momento in cui li progettò. Non riesco a trovare la citazione, ma se ti piace davvero, puoi trovarla tra le sue interviste qui: http://www.stroustrup.com/interviews.html

Sì, i progettisti di C # (e, ne sono certo, Java) hanno deciso espressamente contro la finalizzazione deterministica. Ho chiesto ad Anders Hejlsberg di parlarne più volte tra il 1999 e il 2002.

In primo luogo, l'idea di una semantica diversa per un oggetto basata sul fatto che sia basata su stack o heap è certamente in contrasto con l'obiettivo di progettazione unificante di entrambi i linguaggi, che era quello di alleviare esattamente i programmatori di tali problemi.

In secondo luogo, anche se si riconosce che ci sono vantaggi, vi sono significative complessità di attuazione e inefficienze nella contabilità. Non puoi davvero mettere oggetti simili a stack nello stack in una lingua gestita. Ti resta da dire "semantica simile a uno stack" e impegnarti in un lavoro significativo (i tipi di valore sono già abbastanza difficili, pensa a un oggetto che è un'istanza di una classe complessa, con riferimenti che entrano e ritornano nella memoria gestita).

Per questo motivo, non si desidera la finalizzazione deterministica su ogni oggetto in un sistema di programmazione in cui "(quasi) tutto è un oggetto". Così si fa necessario introdurre una sorta di sintassi programmatore controllato per separare un oggetto normalmente monitorati da uno che ha finalizzazione deterministica.

In C #, hai la usingparola chiave, che è arrivata abbastanza tardi nella progettazione di quello che è diventato C # 1.0. Il tutto IDisposableè piuttosto disgraziato, e ci si chiede se sarebbe più elegante usinglavorare con la sintassi del distruttore C ++ che ~segna quelle classi a cui il IDisposablemodello della piastra della caldaia potrebbe essere applicato automaticamente?

Tieni presente che Java è stato sviluppato nel 1991-1995 quando il C ++ era un linguaggio molto diverso. Eccezioni (che rendevano necessaria la RAII ) e modelli (che rendevano più semplice l'implementazione di puntatori intelligenti) erano caratteristiche "nuove". La maggior parte dei programmatori C ++ proveniva da C ed era abituata a gestire manualmente la memoria.

Quindi dubito che gli sviluppatori di Java abbiano deliberatamente deciso di abbandonare RAII. Tuttavia, è stata una decisione deliberata per Java preferire la semantica di riferimento anziché la semantica di valore. La distruzione deterministica è difficile da implementare in un linguaggio di semantica di riferimento.

Quindi perché usare la semantica di riferimento invece della semantica di valore?

Perché rende la lingua molto più semplice.

• Non è necessaria una distinzione sintattica tra Fooe Foo*o tra foo.bare foo->bar.
• Non è necessario un compito sovraccarico, quando tutto il compito è copiare un puntatore.
• Non sono necessari costruttori di copie. ( Occasionalmente è necessaria una funzione di copia esplicita come clone(). Molti oggetti non devono essere copiati. Ad esempio, gli immutabili no.)
• Non è necessario dichiarare i privatecostruttori di copie e operator=rendere una classe non copiabile. Se non vuoi copiare oggetti di una classe, non devi semplicemente scrivere una funzione per copiarla.
• Non sono necessarie swapfunzioni. (A meno che tu non stia scrivendo una sorta di routine.)
• Non sono necessari riferimenti al valore rx in stile C ++ 0x.
• Non è necessario per (N) RVO.
• Non ci sono problemi di taglio.
• È più facile per il compilatore determinare i layout degli oggetti, poiché i riferimenti hanno una dimensione fissa.

Il principale svantaggio della semantica di riferimento è che quando ogni oggetto ha potenzialmente più riferimenti ad esso, diventa difficile sapere quando eliminarlo. È più o meno avere avere gestione automatica della memoria.

Java ha scelto di utilizzare un garbage collector non deterministico.

GC non può essere deterministico?

Sì, può. Ad esempio, l'implementazione C di Python utilizza il conteggio dei riferimenti. E successivamente aggiunto GC di tracciamento per gestire la spazzatura ciclica in cui i conteggi falliscono.

Ma il conteggio è orribilmente inefficiente. Molti cicli di CPU spesi per l'aggiornamento dei conteggi. Ancora peggio in un ambiente multi-thread (come il tipo per cui Java è stato progettato) in cui tali aggiornamenti devono essere sincronizzati. Molto meglio usare il Garbage Collector null fino a quando non è necessario passare a un altro.

Si potrebbe dire che Java ha scelto di ottimizzare il caso comune (memoria) a spese di risorse non fungibili come file e socket. Oggi, alla luce dell'adozione di RAII in C ++, questa può sembrare una scelta sbagliata. Ma ricorda che gran parte del pubblico target per Java era programmatori C (o "C con classi") che erano abituati a chiudere esplicitamente queste cose.

Ma che dire degli "oggetti stack" C ++ / CLI?

Sono solo zucchero sintattico perDispose ( link originale ), proprio come C # using. Tuttavia, non risolve il problema generale della distruzione deterministica, poiché è possibile creare un anonimo gcnew FileStream("filename.ext")e C ++ / CLI non lo eliminerà automaticamente.

Java7 ha introdotto qualcosa di simile a C # using: L'istruzione try-with-resources

una trydichiarazione che dichiara una o più risorse. Una risorsa è come un oggetto che deve essere chiuso al termine del programma. L' tryistruzione -with-resources assicura che ogni risorsa sia chiusa alla fine dell'istruzione. Qualsiasi oggetto che implementa java.lang.AutoCloseable, che include tutti gli oggetti che implementano java.io.Closeable, può essere utilizzato come risorsa ...

Quindi immagino che o non abbiano scelto consapevolmente di non implementare la RAII o che nel frattempo abbiano cambiato idea.

Java non ha intenzionalmente oggetti basati su stack (aka oggetti valore). Questi sono necessari per la distruzione automatica dell'oggetto alla fine del metodo.

A causa di ciò e del fatto che Java viene raccolto in modo inutile, la finalizzazione deterministica è più o meno impossibile (es. E se il mio oggetto "locale" venisse referenziato da qualche altra parte? Quindi quando il metodo termina, non vogliamo che venga distrutto ) .

Tuttavia, questo va bene per la maggior parte di noi, perché non c'è quasi mai bisogno di una finalizzazione deterministica, tranne quando si interagisce con risorse native (C ++)!

Perché Java non ha oggetti basati su stack?

(Altro che primitivi ..)

Perché gli oggetti basati su stack hanno una semantica diversa rispetto ai riferimenti basati su heap. Immagina il seguente codice in C ++; Che cosa fa?

return myObject;

• Se myObjectè un oggetto basato su stack locale, viene chiamato il costruttore di copia (se il risultato è assegnato a qualcosa).
• Se myObjectè un oggetto basato su stack locale e stiamo restituendo un riferimento, il risultato non è definito.
• Se myObjectè un membro / oggetto globale, viene chiamato il costruttore di copia (se il risultato è assegnato a qualcosa).
• Se myObjectè un membro / oggetto globale e stiamo restituendo un riferimento, viene restituito il riferimento.
• Se myObjectè un puntatore a un oggetto basato su stack locale, il risultato non è definito.
• Se myObjectè un puntatore a un membro / oggetto globale, quel puntatore viene restituito.
• Se myObjectè un puntatore a un oggetto basato su heap, viene restituito quel puntatore.

Cosa fa lo stesso codice in Java?

return myObject;

• myObjectViene restituito il riferimento a . Non importa se la variabile è locale, membro o globale; e non ci sono oggetti basati su stack o casi puntatore di cui preoccuparsi.

Quanto sopra mostra perché gli oggetti basati su stack sono una causa molto comune di errori di programmazione in C ++. Per questo motivo, i designer Java li hanno eliminati; e senza di essi, non ha senso usare RAII in Java.

La tua descrizione dei buchi di usingè incompleta. Considera il seguente problema:

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

Secondo me, non avere sia RAII che GC era una cattiva idea. Quando si tratta di chiudere i file in Java, è malloc()e free()lì.

Sono piuttosto vecchio. Ci sono stato, l'ho visto e ci ho sbattuto la testa molte volte.

Ero a una conferenza a Hursley Park in cui i ragazzi IBM ci dicevano quanto fosse meraviglioso questo nuovissimo linguaggio Java, solo qualcuno ha chiesto ... perché non c'è un distruttore per questi oggetti. Non intendeva la cosa che conosciamo come distruttore in C ++, ma non c'era neanche un finalizzatore (o aveva finalizzatori ma sostanzialmente non funzionavano). Questo è molto indietro, e abbiamo deciso che Java era un po 'un linguaggio giocattolo a quel punto.

ora hanno aggiunto Finalizzatori alle specifiche del linguaggio e Java ha visto l'adozione.

Naturalmente, in seguito a tutti è stato detto di non mettere i finalizzatori sui propri oggetti perché rallentava enormemente il GC. (poiché doveva non solo bloccare l'heap, ma spostare gli oggetti da finalizzare in un'area temporanea, poiché questi metodi non potevano essere chiamati poiché il GC ha messo in pausa l'app in esecuzione. Invece sarebbero stati chiamati immediatamente prima del successivo Ciclo GC) (e peggio, a volte il finalizzatore non veniva mai chiamato affatto quando l'app si chiudeva. Immagina di non avere mai il tuo file handle chiuso, mai)

Poi abbiamo avuto C # e ricordo il forum di discussione su MSDN in cui ci è stato detto quanto fosse meraviglioso questo nuovo linguaggio C #. Qualcuno ha chiesto perché non ci fosse una finalizzazione deterministica e i ragazzi della SM ci hanno detto come non avevamo bisogno di queste cose, poi ci hanno detto che dovevamo cambiare il nostro modo di progettare le app, poi ci hanno detto quanto fosse fantastico GC e come erano tutte le nostre vecchie app spazzatura e mai lavorato a causa di tutti i riferimenti circolari. Quindi hanno ceduto alla pressione e ci hanno detto che avevano aggiunto questo schema IDispose alle specifiche che potevamo usare. A quel punto ho pensato che fosse praticamente tornato alla gestione manuale della memoria nelle app C #.

Naturalmente, i ragazzi della SM in seguito hanno scoperto che tutto quello che ci avevano detto era ... beh, hanno fatto di IDispose un po 'più di una semplice interfaccia standard, e in seguito hanno aggiunto l'istruzione using. W00t! Si sono resi conto che la finalizzazione deterministica mancava dopo tutto alla lingua. Certo, devi ancora ricordarti di metterlo ovunque, quindi è ancora un po 'manuale, ma è meglio.

Quindi perché l'hanno fatto quando avrebbero potuto disporre automaticamente della semantica in stile utilizzo su ogni blocco dell'ambito dall'inizio? Probabilmente efficienza, ma mi piace pensare che non se ne siano resi conto. Proprio come alla fine si sono resi conto che hai ancora bisogno di puntatori intelligenti in .NET (google SafeHandle) hanno pensato che il GC avrebbe davvero risolto tutti i problemi. Hanno dimenticato che un oggetto è molto più di una semplice memoria e che GC è progettato principalmente per gestire la gestione della memoria. sono rimasti intrappolati nell'idea che il GC avrebbe gestito questo, e hanno dimenticato che hai messo altre cose lì dentro, un oggetto non è solo un blob di memoria che non importa se non lo elimini per un po '.

Ma penso anche che la mancanza di un metodo finalize nella Java originale avesse un po 'di più: che gli oggetti che hai creato riguardassero solo la memoria e se volessi eliminare qualcos'altro (come un handle DB o un socket o altro ), quindi ti aspettavi di farlo manualmente .

Ricorda che Java è stato progettato per ambienti embedded in cui le persone erano abituate a scrivere codice C con molte allocazioni manuali, quindi non avere il free automatico non era un problema: non l'avevano mai fatto prima, quindi perché dovresti averne bisogno in Java? Il problema non aveva nulla a che fare con i thread, o stack / heap, probabilmente era proprio lì per rendere un po 'più semplice l'allocazione della memoria (e quindi la de-allocazione). Nel complesso, l'istruzione try / finally è probabilmente un posto migliore per gestire risorse non di memoria.

Quindi IMHO, il modo in cui .NET ha semplicemente copiato il più grande difetto di Java è la sua più grande debolezza. .NET avrebbe dovuto essere un C ++ migliore, non un Java migliore.

Bruce Eckel, autore di "Thinking in Java" e "Thinking in C ++" e membro del C ++ Standards Committee, è del parere che, in molte aree (non solo RAII), Gosling e il team Java non abbiano fatto il loro compiti a casa.

... Per capire in che modo il linguaggio può essere sia spiacevole e complicato, sia ben progettato allo stesso tempo, è necessario tenere presente la decisione progettuale principale su cui pende tutto in C ++: la compatibilità con C. Stroustrup ha deciso - e correttamente così , sembrerebbe - che il modo per far spostare le masse di programmatori C su oggetti fosse rendere trasparente lo spostamento: per consentire loro di compilare il loro codice C invariato in C ++. Questo è stato un enorme vincolo, ed è sempre stato il più grande punto di forza del C ++ ... e la sua rovina. È ciò che ha reso C ++ tanto efficace quanto complesso e complesso.

Ha anche ingannato i designer Java che non capivano abbastanza bene il C ++. Ad esempio, hanno pensato che il sovraccarico dell'operatore fosse troppo difficile da usare per i programmatori. Ciò è fondamentalmente vero in C ++, poiché C ++ ha sia allocazione di stack che allocazione di heap e devi sovraccaricare i tuoi operatori per gestire tutte le situazioni e non causare perdite di memoria. Difficile davvero. Java, tuttavia, ha un unico meccanismo di allocazione della memoria e un garbage collector, che rende banale il sovraccarico dell'operatore - come è stato mostrato in C # (ma era già stato mostrato in Python, che ha preceduto Java). Ma per molti anni, la linea in parte del team Java è stata "Il sovraccarico dell'operatore è troppo complicato". Questa e molte altre decisioni in cui qualcuno chiaramente non ha

Ci sono molti altri esempi. I primitivi "dovevano essere inclusi per efficienza". La risposta giusta è rimanere fedeli a "tutto è un oggetto" e fornire una botola per fare attività di livello inferiore quando era richiesta efficienza (ciò avrebbe anche permesso alle tecnologie di hotspot di rendere trasparentemente le cose più efficienti, come avrebbero fatto avere). Oh, e il fatto che non è possibile utilizzare direttamente il processore a virgola mobile per calcolare le funzioni trascendentali (invece è fatto nel software). Ho scritto su questioni come questa per quanto posso sopportare, e la risposta che sento è sempre stata una risposta tautologica all'effetto che "questo è il modo di Java".

Quando ho scritto di come sono stati progettati i generici male, ho ottenuto la stessa risposta, insieme a "dobbiamo essere retrocompatibili con le precedenti (cattive) decisioni prese in Java". Ultimamente sempre più persone hanno acquisito sufficiente esperienza con Generics per vedere che sono davvero molto difficili da usare - in effetti, i modelli C ++ sono molto più potenti e coerenti (e molto più facili da usare ora che i messaggi di errore del compilatore sono tollerabili). Le persone hanno persino preso sul serio la reificazione - qualcosa che sarebbe utile ma che non metterà molto a dura prova in un progetto che è paralizzato da vincoli autoimposti.

L'elenco prosegue fino al punto in cui è solo noioso ...

Il miglior motivo è molto più semplice della maggior parte delle risposte qui.

Non è possibile passare oggetti allocati in pila ad altri thread.

Fermati e pensaci. Continuate a pensare .... Ora C ++ non aveva discussioni quando tutti erano così entusiasti di RAII. Anche Erlang (cumuli separati per thread) diventa icky quando passi troppi oggetti in giro. C ++ ha ottenuto solo un modello di memoria in C ++ 2011; ora puoi quasi ragionare sulla concorrenza in C ++ senza dover fare riferimento alla "documentazione" del tuo compilatore.

Java è stato progettato dal (quasi) primo giorno per più thread.

Ho ancora la mia vecchia copia di "Il linguaggio di programmazione C ++" in cui Stroustrup mi assicura che non avrò bisogno di thread.

Il secondo motivo doloroso è quello di evitare l'affettatura.

In C ++, usi funzionalità di linguaggio di livello inferiore più generiche (distruttori chiamati automaticamente su oggetti basati su stack) per implementarne uno di livello superiore (RAII), e questo approccio è qualcosa che la gente C # / Java sembra non essere troppo affezionato. Preferiscono progettare strumenti specifici di alto livello per esigenze specifiche e fornirli ai programmatori già pronti, integrati nella lingua. Il problema con strumenti così specifici è che sono spesso impossibili da personalizzare (in parte è ciò che li rende così facili da imparare). Quando si costruisce da blocchi più piccoli, una soluzione migliore può trovare il tempo, mentre se si hanno solo costrutti integrati di alto livello, questo è meno probabile.

Quindi sì, penso (in realtà non ero lì ...) è stata una decisione consapevole, con l'obiettivo di rendere le lingue più facili da imparare, ma secondo me è stata una decisione sbagliata. Poi di nuovo, in genere preferisco la filosofia C ++ dare ai programmatori una possibilità di lanciarsi, quindi sono un po 'di parte.

Hai già chiamato l'equivalente approssimativo di questo in C # con il Disposemetodo. Anche Java ha finalize. NOTA: mi rendo conto che la finalizzazione di Java non è deterministica e diversa da quella Dispose, sto solo sottolineando che entrambi hanno un metodo di pulizia delle risorse insieme al GC.

Semmai il C ++ diventa più un dolore perché un oggetto deve essere distrutto fisicamente. In linguaggi di livello superiore come C # e Java dipendiamo da un garbage collector per ripulirlo quando non ci sono più riferimenti ad esso. Non esiste tale garanzia che l'oggetto DBConnection in C ++ non abbia riferimenti o puntatori non autorizzati.

Sì, il codice C ++ può essere più intuitivo da leggere, ma può essere un incubo da debug perché i confini e le limitazioni messi in atto da linguaggi come Java escludono alcuni dei bug più aggravanti e difficili, oltre a proteggere altri sviluppatori da comuni errori da principiante.

Forse si tratta di preferenze, alcune come la potenza, il controllo e la purezza di basso livello del C ++ in cui altri come me preferiscono un linguaggio più sandbox che è molto più esplicito.