Sign in to follow this  

Recommended Posts

Già, è solo per quello. Ah, se solo il C avesse l'allocazione statica... nel mondo dei sogni, si potrebbe addirittura scegliere il tipo di allocazione con keyword come "auto", "static", "register"... OH SHI-

Quale parte di solo non riesci a capire?

Share this post


Link to post
Share on other sites

Quale parte di solo non riesci a capire?

Oh, hai infranto le bolas. Se non sei buono di scrivere codice C efficiente sono fatti tuoi. Ma non tutto il male viene per nuocere: questo mi fa venire in mente una differenza tra .net e Java.

Se non sbaglio, .net supporta due modelli di gestione della memoria dinamica, quello tradizionale in cui se ne occupa il programma, e quello tipo Java con la garbage collection etc.

Java invece parte dal presupposto (corretto) che chi lo usa non abbia idea di quello che sta facendo, quindi si occupa sempre lui di gestire la memoria, non ci sono alternative. Il risultato sono programmi come Azureus, che per scaricare un file occupa seicento mega di RAM (misura effettuata da un mio amico su Linux, ovviamente io non uso Azureus).

Share this post


Link to post
Share on other sites

Per la precisione, il risultato è che visto che è cosi facile fare programmi spreconi, la maggior parte dei programmatori li fa tali. Ad esempio, allocare un oggetto è così facile da farsi che è fatta in continuazione, con ovvie conseguenze. Per non parlare della miriade di classi d'utilità che ti permettono di scrivere una cosa complessa in due righe, ma di farla eseguire in molto più tempo.

Nota sulla garbage collection automatica: in teoria sarebbe più efficiente. Il garbage collector rispetta di più il principio di località negli accessi alla memoria, così che c'è un migliore utilizzo della cache del processore. Al contrario con la garbage collection manuale disallochi con accessi sparsi e in modo imprevedibile.

Share this post


Link to post
Share on other sites

Oh, hai infranto le bolas. Se non sei buono di scrivere codice C efficiente sono fatti tuoi.

Finiscila con questi attacchi ad personam, non c'entrano niente.

Se non sbaglio, .net supporta due modelli di gestione della memoria dinamica, quello tradizionale in cui se ne occupa il programma, e quello tipo Java con la garbage collection etc.

Che io sappia no. Almeno non da C# e da VB.NET. Per quel poco che conosco di Managed C++ mi pare di no, che pero` permette di mischiare codice managed e unmanaged e sul codice unmanaged, ovviamente, non gira il garbage collector. Per essere sicuro dovrei ridare un'occhiata all'MSIL. A meno che tu non ti riferisca alle struct (che sono sempre allocate sullo stack).

Java invece parte dal presupposto (corretto) che chi lo usa non abbia idea di quello che sta facendo, quindi si occupa sempre lui di gestire la memoria, non ci sono alternative. Il risultato sono programmi come Azureus, che per scaricare un file occupa seicento mega di RAM (misura effettuata da un mio amico su Linux, ovviamente io non uso Azureus).

Qui si entra in un problema di psicologia del programmatore. E` ovvio che il gc semplifica il problema della gestione della memoria, per il programmatore, ma non lo elimina, perche' deve comunque stare attento a non tenere riferimenti ad oggetti che non usa piu`. E` lecito chiedersi se il programmatore, abbagliato dal gc, sia piu` propenso a scordarsi della gestione della memoria. Pero` di programmi con memory leak enormi se ne sono visti tanti anche nei linguaggi senza gc.

Share this post


Link to post
Share on other sites

Per la precisione, il risultato è che visto che è cosi facile fare programmi spreconi, la maggior parte dei programmatori li fa tali. Ad esempio, allocare un oggetto è così facile da farsi che è fatta in continuazione, con ovvie conseguenze.

Il problema non e` creare tanti oggetti, i GC di java e .net suppongono che vengano creati molti oggetti dalla vita breve e trattano il caso abbastanza bene, il problema e` tenere i riferimenti.

Per non parlare della miriade di classi d'utilità che ti permettono di scrivere una cosa complessa in due righe, ma di farla eseguire in molto più tempo.

Nota sulla garbage collection automatica: in teoria sarebbe più efficiente. Il garbage collector rispetta di più il principio di località negli accessi alla memoria, così che c'è un migliore utilizzo della cache del processore. Al contrario con la garbage collection manuale disallochi con accessi sparsi e in modo imprevedibile.

A cosa ti riferisci con "garbage collection manuale"? Cose tipo gli auto_ptr<> di C++?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this