Programmare sotto Linux

[cdimauro]

Originariamente inviato da tomminno

Si, uno che non parte dal C non capisce l'importanza dei metodi "Dispose" per il rilascio delle risorse anche in linguaggi dotati di GC.
Per cui non è vero che con il GC non devi pensare alla deallocazione delle risorse (che non significa solo deallocare memoria, ma pure chiudere connessioni al db/rete, chiudere un file...), anzi hai pure delle rogne per tutte le possibili eccezioni che possono generarsi.

Il vantaggio dei linguaggi managed è l'enorme libreria, non la gestione della memoria, perchè devi lottare comunque con il rilascio delle risorse.

Anche mia figlia capisce che quando entra nella stanza ed accende la luce, prima di uscire la deve chiudere.

Mia figlia non ha la benché minima conoscenza dei metodi "dispose" perché non sa programmare, ma ha già ben presente il concetto di accesso e rilascio di una risorsa.

No strutture C e C++ sono diverse e generano sulla carta codice differente.
le strutture C++ hanno costruttore e distruttore esattamente come le classi (e anche l'uso di this), le strutture C no.
La differenza di codice dovrebbe (ripeto dovrebbe) essere nulla tra una struct C++ e una classe C++ con stessi metodi e stessa visibilità.

Fin da quando ha presentato il C++, Stroustrup ha SEMPRE specificato che le vecchie caratteristiche del C non dovevano assolutamente essere penalizzate. Quindi soltanto quelle nuove, giustamente, possono portare EVENTUALMENTE a un decadimento delle prestazioni.

Questo, se non ricordo male, l'ha anche riportato nel libro che ha scritto sul linguaggio.

L'uso di strutture SENZA utilizzare alcuna caratteristica peculiare del C++ NON deve generare alcun codice addizionale / penalizzante. Se si verifica, è il compilatore che è scritto male.

Ad esempio, prendiamo questo codice:

struct sPunto
{
  int x, y;
};

class cPunto
{
public:
  int x, y;
};

struct sPunto s;
s.x = 320;
s.y = 256;

cPunto c;
c.x = 320;
c.y = 256;

Non c'è nessun costruttore da chiamare: si tratta di strutture statiche, senza metodi virtuali né codice di inizializzazione, per cui il compilatore deve accorgersene e non generare nessun codice a parte l'assegnazione.

Originariamente inviato da marco.r

Dipende dal linguaggio. La soluzione "alla Java", ovvero di gestirle manualmente oppure aspettare il GC non e' la migliore ma neanche l'unica. Ad esempio in Ruby si puo' usare in modo molto elegante

File.open("myfile") do |file|
file.each_byte {....}
end

che fa si' che il file venga chiuso immediatamente finito il blocco. E' un pattern abbastanza standard nei linguaggi con GC.

Esatto. In Python:

with open('myfile') as f:
  for ch in f.read()

Originariamente inviato da 71104

infatti questa è una cosa che non ho mai capito: che differenza c'è in C++ tra una struct e una classe?

in alcune situazioni ho visto usare addirittura l'ereditarietà con le struct; mi pare che in MFC la classe CPoint derivi dalla struct POINT.

Esattamente. Questo perché, appunto, non c'è nessuna differenza fra struct e classi, tranne per la visibilità di default, che nelle prime è pubblica, e nella seconda privata.

Quindi in teoria potresti benissimo usare sempre e soltanto le struct per dichiarare classi e programmare a oggetti. Stroustrup introdusse la keyword class per marcare la differenza col "passato"; inizialmente il suo obiettivo era di aggiungere il minimo indispensabile al linguaggio C per supportare nuove funzionalità, e quindi sfruttò la keyword struct per introdurre l'uso delle classi, e ciò rimase nel linguaggio.
IMHO avrebbe fatto meglio a lasciare le struct come sono in C, e permettere di usare le innovazioni delle classi con la keyword class.

[tomminno]

Originariamente inviato da cdimauro

Anche mia figlia capisce che quando entra nella stanza ed accende la luce, prima di uscire la deve chiudere.

Mia figlia non ha la benché minima conoscenza dei metodi "dispose" perché non sa programmare, ma ha già ben presente il concetto di accesso e rilascio di una risorsa.

Già ma se fosse abituata a lasciarla accesa perchè tanto la spengono i genitori...

Fin da quando ha presentato il C++, Stroustrup ha SEMPRE specificato che le vecchie caratteristiche del C non dovevano assolutamente essere penalizzate. Quindi soltanto quelle nuove, giustamente, possono portare EVENTUALMENTE a un decadimento delle prestazioni.

Questo, se non ricordo male, l'ha anche riportato nel libro che ha scritto sul linguaggio.

Prova questa struct in C

struct Prova
{
	int p;
	Prova() { cout << "costruttore Prova" << endl; }
	~Prova() { cout << "distruttore Prova" << endl; }
	Prova * Get() { return this; }
};

Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.
Ah e prova a mettere int p = 0; nella struct e leggi il bellissimo messaggio di errore che viene fuori:

error C2864: 'Prova:' : only static const integral data members can be initialized within a class

saranno anche uguali a quelle del C ma a me non sembra proprio.

Esatto. In Python:

with open('myfile') as f:
  for ch in f.read()

Peccato che ad esempio in C# se non chiudi esplicitamente un file o utlizzi il costrutto using (che è la stessa cosa solo più sicura a causa delle eccezioni che escono come funghi dal .NET), il file rimane aperto fino a che il GC non decide di terminare l'oggetto.
E se ti arriva una eccezione il file rimane aperto.

string towrite = null;
StreamWriter sw = new StreamWriter("myfile.txt",true);
sw.Write(towrite);

[marco.r]

Originariamente inviato da 71104

infatti questa è una cosa che non ho mai capito: che differenza c'è in C++ tra una struct e una classe?

in alcune situazioni ho visto usare addirittura l'ereditarietà con le struct; mi pare che in MFC la classe CPoint derivi dalla struct POINT.

Nessuna, o meglio una sola, le struct di default hanno membri public mentre le classi hanno membri privati, tanto che qualcuno usa costantemente solo struct. Un effetto del voler introdurre una keyword piu' comprensibile e di dover rimanere compatibili col C.

[k0nt3]

Originariamente inviato da marco.r

Nessuna, o meglio una sola, le struct di default hanno membri public mentre le classi hanno membri privati, tanto che qualcuno usa costantemente solo struct. Un effetto del voler introdurre una keyword piu' comprensibile e di dover rimanere compatibili col C.

leggasi: massimizzare il numero di porcherie possibili

[71104]

Originariamente inviato da k0nt3

leggasi: massimizzare il numero di porcherie possibili

per me il fatto che classi e struct siano quasi la stessa cosa non è una porcheria, è una confusione; se vuoi vedere una vera porcheria allora parliamo della keyword friend

[DanieleC88]

Originariamente inviato da 71104

se vuoi vedere una vera porcheria allora parliamo della keyword friend

Perché, povera lei?

[marco.r]

Originariamente inviato da tomminno

Prova questa struct in C

struct Prova
{
	int p;
	Prova() { cout << "costruttore Prova" << endl; }
	~Prova() { cout << "distruttore Prova" << endl; }
	Prova * Get() { return this; }
};

Non ho capito l'esempio , il bisogno di mantenere la struct era nato dalla volonta' di far si' che il codice C fosse il piu' possibile leggibile come codice C++, non il contrario.

Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.

Ed in effetti se uso una struct "alla C" (ovvero contenente solo tipi primitivi o strutture) fa la stessa cosa che fa in C, ovvero niente.

saranno anche uguali a quelle del C ma a me non sembra proprio.

Non sono uguali, sono un superset di quelle del C

Peccato che ad esempio in C# se non chiudi esplicitamente un file o utlizzi il costrutto using (che è la stessa cosa solo più sicura a causa delle eccezioni che escono come funghi dal .NET), il file rimane aperto fino a che il GC non decide di terminare l'oggetto.
E se ti arriva una eccezione il file rimane aperto.

Ma questo e' un problema di design delle librerie, non del GC. La gestione delle risorse la fai con costruttori e distruttori di oggetti se questi hanno una vita predicibile, altrimenti procedi per altre vie.
Certo che se si parte dall'idea che deve sembrare il piu' possibile al C++ oppure che non si puo' implementare perche' altrimenti il linguaggio diventa troppo complesso i risultati sono quelli che sono...

[71104]

Originariamente inviato da DanieleC88

Perché, povera lei?

perché se era proprio necessario metterla tanto valeva eliminare tutto il concetto di visibilità e tanti saluti

[DanieleC88]

Originariamente inviato da 71104

perché se era proprio necessario metterla tanto valeva eliminare tutto il concetto di visibilità e tanti saluti

E vabbe', almeno puoi definire delle "eccezioni", non credo sia così... perniciosa.

[k0nt3]

in realtà il concetto di friend function serve a sopperire alla mancanza del concetto di package.. hanno usato il mezzo sbagliato per risolvere il problema giusto IMHO
il tutto sempre per massimizzare il numero di porcherie ammissibili

[marco.r]

Originariamente inviato da k0nt3

leggasi: massimizzare il numero di porcherie possibili

Boh, son solo due keywords praticamente identiche per cui non parlerei di porcheria. Diciamo allo stesso livello di poter omettere "int" quando si parla di short o long. O meno peggio del non sapere se "char" e' uguale a "unsigned char" o "signed char".

[marco.r]

Originariamente inviato da DanieleC88

E vabbe', almeno puoi definire delle "eccezioni", non credo sia così... perniciosa.

Anche perche' non e' che si usi poi molto. Sicuramente non e' una soluzione "pulita", ma cosa lo e' in C++ ?

[cdimauro]

Originariamente inviato da tomminno

Già ma se fosse abituata a lasciarla accesa perchè tanto la spengono i genitori...

I genitori devono fare soltanto una cosa: educere, che nell'etimologia della parola vuol dire "condurre".

Il resto, visto che ha una testa e le funziona pure bene, deve imparare a farlo da sola.

Prova questa struct in C

struct Prova
{
	int p;
	Prova() { cout << "costruttore Prova" << endl; }
	~Prova() { cout << "distruttore Prova" << endl; }
	Prova * Get() { return this; }
};

Volendo puoi omettere costruttore e distruttore tanto ci pensa il C++ a metterli per te.
Ah e prova a mettere int p = 0; nella struct e leggi il bellissimo messaggio di errore che viene fuori:

saranno anche uguali a quelle del C ma a me non sembra proprio.

L'esempio è sbagliato: quello che hai postato non è codice C.

Il codice C e l'esempio giusto è quello che ho postato prima, con la struct prima e la class poi.

Ovviamente in C può andare soltanto la parte relativa alla struct.

A me premeva far notare che l'uso, in C++, di una struct nella STESSA maniera in cui si farebbe in C non comporta NESSUN overhead, e che lo stesso vale per la dichiarazione di una classe che, anche questa, non aggiunge nulla a ciò che farebbe un'equivalente struct in C.

Sul resto concordo con quel che ha scritto Marco.

Originariamente inviato da k0nt3

in realtà il concetto di friend function serve a sopperire alla mancanza del concetto di package.. hanno usato il mezzo sbagliato per risolvere il problema giusto IMHO

Vero. Avrei preferito l'introduzione (finalmente) del concetto di modulo/unit/package.

il tutto sempre per massimizzare il numero di porcherie ammissibili

Almeno hanno provato a migliorare un linguaggio, il C, che è stato messo in frigorifero e ibernato...