Newsgroup: it.comp.lang.c++
Titolo: Poll: Apriamo alle librerie libere e gratuite?

Ciao a tutti,
faccio seguito ad alcune idee emerse dal thread "PyConUno" per
reiterare una proposta: apriamo, in via sperimentale, il newsgroup
alle discussioni sulle librerie C++ portabili e reperibili
gratuitamente?
Questi sono i vincoli che avevo gia' proposto:
- Che si tratti di librerie liberamente scaricabili da internet;
- Che siano compilabili con almeno g++ ed un altro compilatore;
Potremmo darci appuntamento alla fine di agosto ed a quel punto
decidere se continuare definitivamente o tornare indietro.
Vi diro' che e' un po' che mi sono reso conto di una differenza che
trovo preoccupante tra i newsgroup che si occupano di C++ e quelli che
si occupano di Python; sui "nostri" si parla prevalentemente del
linguaggio in se', sugli altri si parla piu' spesso di cio' che ci si
puo' fare. Aprire il newsgroup potrebbe essere un modo per
riequilibrare la situazione.
Esprimente le vostre opinioni!
Ciao,
Nicola

 Esprimente le vostre opinioni!
Pienamente d'accordo.
Ma cosa significherebbe in pratica "aprire l'NG?". Cambiarne il
manifesto? Perché se non si cambia manifesto non serve nessun accordo,
chi vuole può comunque rispondere alle domande sulle librerie.
E.

 - Che siano compilabili con almeno g++ ed un altro compilatore;
Io aggiungerei che la libreria deve essere multipiattaforma, altrimenti 
è meglio che ci si rivolga nel NG di competenza.
+++
Già che ci siamo qualcuno usa una libreria C/C++ multipiattaforma per 
scaricare e spedire la posta decente e "facile" da capire? In Python 
farlo è imbarazzantemente facile, anche se i messaggi in formato MIME 
sono rognosi a prescindere.
-- 
mai più senza: 
http://www.genux.com/scheda.asp?idprod=47974
la cultura è importante: 
http://www.libreriadellautomobile.it

 Esprimente le vostre opinioni!
Mi sembra interessante, pero' ho un po' paura che poi il newsgroup si possa
riempire di thread del tipo "come faccio per usare il QTWidget per fare
questo e quello...?"
Propongo qualcosa del genere:
- si puo' discutere di *design* di librerie (come faccio a costruire questa
classe che fa questo e quello?);
- si puo' discutere della libreria XYZ (come si usa la classe
xyz::pincopallo?), ma dopo una piccola "elezione" su di essa.
Sembra fattibile?
Mi farebbe molto piacere discutere di temi legati, faccio un esempio, a
boost, oppure a Loki o magari anche ad ACE, ma non so fin dove si puo'
arrivare senza essere OT...
Io sto partecipando allo sviluppo di una libreria C++ (l'ennesima?) per il
threading, ma non ho mai postato molto, un po' per il tempo ed un po' per
non andare offtopic, pero' mi piacerebbe farlo.
Ciao,
Frank.


Tendenzialmente significa che smetto di mordere chi posta messaggi sui
temi che ho descritto, che secondo la lettera del manifesto sono OT.
Ciao,
Nicola

 sono rognosi a prescindere.
Ogni tanto penso che qualcuno dovrebbe prendersi la briga di
spulciarsi la libreria standard di Python e riscrivere ciascun
componente in C++.
Ciao,
Nicola

 non andare offtopic, pero' mi piacerebbe farlo.
Spero stiate tenendo conto di quello che si muove a livello di Boost e
soprattutto di comitato di standardizzazione.
Ciao,
Nicola

 soprattutto di comitato di standardizzazione.
Prima di iniziare avevo guardato boost:thread ma era troppo limitato per i
nostri scopi (RealTime Scheduling), pero' ho preso spunto da li'.
Che lo standard si stesse muovendo non lo sapevo finche' non ho letto
qualcosa a proposito in un tuo post di qualche settimana fa, e nella
mia "short-term TODO list" c'e' la voce "andarci a guardare!".
:-)

 trovare qualcuno che usa la libreria che gli interessa :-)
Beh, basta che tu faccia un po' da "sovrano assoluto" nel dispensare gli
RTFM e dovrebbe funzionare.
Io saro' un suddito ubbidiente... ;-)

 riequilibrare la situazione.
Parlare di cosa si può fare con il linguaggio va bene ma aprendolo nel senso 
che dici tu temo che diventerebbe un luogo in cui parlare dei mille dettagli 
insignificanti (per quanto riguarda il linguaggio in sé) delle librerie.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 - Che siano compilabili con almeno g++ ed un altro compilatore;
Ho letto gli interventi degli altri e personalmente accetterei la
trattazione di librerie non necessariamente multipiattaforma (c'è chi
programma prevalentemente su determinate piattaforme e potrebbe
ugualmente essere interessato all'argomento).
Imporrei però la regola di "taggare" i propri messaggi con determinati
tag: [BOOST], [ACE], [QT] ecc..

 insignificanti (per quanto riguarda il linguaggio in sé) delle librerie.
Capisco le tue preoccupazioni; certamente aprire il newsgroup a
specifiche librerie comporta con ogni probabilita' il comparire di
thread che di volta in volta interessano nello specifico un esigua
minoranza dei lettori.
Se pero' le discussioni riescono a mantenersi su un livello un po'
piu' alto di "come faccio a mettere il bottone nella finestra?",
possono anche diventare un'occasione di scoprire cose interessanti di
cui non si conosceva l'esistenza.
In altri momenti non avrei fatto una proposta del genere, ma
ultimamente, sparito Kiuhnm, il newsgroup si muove sull'ordine di uno-
due thread al giorno. Siamo vicini al rischio estinzione, e sarebbe un
peccato.
Ciao,
Nicola

 specifiche librerie comporta [...]
Che ti devo dire, allora proviamo. :-)


 tag: [BOOST], [ACE], [QT] ecc..
Sono d'accordo.
Ciao,
Nicola

 Sono d'accordo.
E chi la seguirą se non i frequentatori abituali?


 gratuitamente?
Come già detto nell'altro thread, per me sarebbe un ottimo modo per
rivitalizzare il newsgroup e quindi non posso che essere d'accordo.

 componente in C++.
Quello sarebbe facile. Un "ponte" e usi direttamente la libreria di 
python da codice C/C++. Però istintivamente mi fa ribrezzo questa 
soluzione. Preferisco avere il codice "in mano".
Ultimamente sto anche guardando come evolve IronPython e PyPy. Per 
motivi diversi potrebbero portare a qualcosa di interessante per il mio 
lavoro.


 peccato.
Il rischio è alto. Meglio del rumore di fondo, che il silenzio.
Io voto per provare. Vediamo cosa succede.


 trattazione di librerie non necessariamente multipiattaforma
Voglio spiegare perché invece io sono contrario.
Sapere la differenza di significato di un processo in Linux, Windows o 
un PLC per me è importante, perché alla fine nessuno di noi programma 
sulla luna. Questo non è C++ però fa parte del mondo reale.
Però non possiamo scendere nel dettaglio dell'API di Windows, o 
dell'uso delle curses. Non esagererei nell'apertura dell'NG.
Quanto all'architettura di cui ho letto in un altro post, onestamente 
io non ne parlo dell'NG. Non ne sento il bisogno. Perderei molto tempo 
a spiegarmi, e dubito che accetterei i consigli :-)


 Esprimente le vostre opinioni!
Nulla in contrario, ma sono un po' scettico.
Se lo scopo e' quello di tenere fuori gli OT, la maggior parte non 
rientrerebbe IT neanche dopo, in quanto sono quasi sempre domande da 
it.comp.win32.
Per quanto riguarda le librerie specifiche: se parli di boost io l'ho 
sempre considerata "quasi dentro" in virtu' del fatto che l'intenzione 
e' quella di possibilmente rendere prima o poi standard i suoi 
componenti. Per le altre (QT, wxWidgets, ecc...) mi verrebbe piu' da 
chiedere sulla mailing list specifica, ma comunque...
Mi piace l'idea dei tag espressa da Andrea Laforgia.
  bye
	av.

 - Che siano compilabili con almeno g++ ed un altro compilatore;
Aggiungerei:
Con i sorgenti disponibili
Favorevole, quanto meno a provare poi vediamo come va
Ciao

 E chi la seguirà se non i frequentatori abituali?
beh, magari se si accordano gli esperti a seguire la nuova 
convenzione e poi rispondono soltanto a messaggi formattati 
correttamente, mentre agli altri generici che creano disordine 
non risponde nessuno (o al limite manda i suoi messaggi-strale 
Nicola Musatti) l'abitudine all'ordine l'acquisiscono prima o 
poi anche gli altri.
Soviet


 Con i sorgenti disponibili
Hai ragione, lo davo per scontato.
Ciao,
Nicola

 Ciao,
Ciao,
Paolo.

 - Che siano compilabili con almeno g++ ed un altro compilatore;
IMHO si riempirebbe il gruppo con messaggi su boost (e fin qui tutto
bene) ma soprattutto sui toolkit grafici come GTK/QT/MFC (non bene,
IMHO).
Certo gli usenettiani di lungo corso probabilmente usano degli agent che
permettono di filtrare bene i messaggi, ma l'apertura non mi convince del
tutto.
Luca
-- 
Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un
uomo sposa una donna sperando che non cambi, e lei cambiera`.

 IMHO).
Probabilmente hai ragione, ma mettendo l'obbligo di tag del toolkit che 
si discute nel post nel subject (tipo [GTK], [MFC], [WX], [boost]...) 
dovrebbe essere facile "filtrare" anche senza filtri supersofisticati :)
Bye,
  Gabry

 gratuitamente?
Assolutamente sì.
Penso da un bel pezzo che parlare del C++ "da solo" sia troppo
riduttivo, questa potrebbe essere una ottima cosa.

 questo e quello...?"
Guarda che questo lo chiedono già, spesso crosspostando cafonamente :-)
In linea di massima io accetterei anche queste domande, *SE* non sono
richieste del tipo "fatemelo voi"...

Massimo Soricetti wrote:

Si, pero' quasi mai gli si risponde. Se si inizia ad accettarli come IT
probabilmente poi ne vengono postati a palate di messaggi del genere... :-)
Io in realta' sono un frequentatore un po' incostante, leggo spesso i
messaggi ma non ho mai molto tempo per partecipare, quindi posso dare solo
pareri abbastanza limitati.
Ciao.

 insignificanti (per quanto riguarda il linguaggio in sé) delle librerie.
Non credo assolutamente che nella pratica della programmazione C++ non
si usa mai nemmeno una libreria, framework o quelcheè. Anzi scommetterei
che se ne usa sempre qualcuno... e allora, visto che "il C++ da solo"
non si usa mai, "non esiste" insomma se non nelle menti dei progettisti
di linguaggi, mi sembra ovvio che un NG che parli di "C++ da solo"
languisca e muoia...

 languisca e muoia...
Il fatto è che, per la complessità del linguaggio, c'è tanto da parlare anche 
del solo C++ standard e a me sembra che quelli che chiedono dettagli sull'uso 
di qualche libreria spesso non abbiano per niente chiari neanche i concetti 
elementari.


 Esprimente le vostre opinioni!
Indovina la mia :-) 
Ciao,
Marco.

 ma dopo un po' si deve aggiungere necessariamente altro)
Resta il fatto che questo e' un newsgroup che tradizionalmente viene
sommerso di messaggi fuori tema non appena si abbassa la guardia, e
queste "ondate" hanno certamente contribuito a far passare la voglia
di partecipare a parecchie persone.
Personalmente non vedo il motivo di aprire a discussioni che avrebbero
maggior ragione di avvenire su newsgroup di C e/o Linux. Per contro
ritengo che discutere, per dire, su se sia sensato usare RAII per
rappresentare un socket mi pare perfettamente ragionevole.
Ciao,
Nicola

 elementari.
Il problema e' che, pur essendo complesso, il C++ da solo non ti da' molto
da mangiare. Invece "C++ piu' altre cose" puo' darti da mangiare. 
Tra l'altro mi pare che, pur restando nel pieno periodo del "java e' bello" 
una certa ripresa delle
richieste per chi conosce C++ ci sia. Io non sottovaluterei l'importanza
della possibilita' di trasformare una passione (il C++) in un lavoro
retribuito (come e' stato per me per diversi anni) rispetto al semplice
"purismo" del linguaggio. Stesso discorso per il C.
Personalmente ritengo prevalente il primo aspetto (trasformare una passione
in un lavoro retribuito) piuttosto che il purismo (e in genere io sul lavoro
ero considerato piuttosto "purista").
 
Ciao,
Marco.

 da mangiare.
A me non sembra inerente la questione. Se compri un libro sul C++ preferisci 
che approfondisca il linguaggio in sé oppure che ne parli superficialmente e 
poi affronti altri temi, anche se più pratici? Personalmente opto per la prima 
scelta. Se poi ho bisogno di altro mi rivolgo ad altri testi. Ecco, per i 
newsgroup la cosa la ritengo analoga.


 newsgroup la cosa la ritengo analoga.
Provo a spiegare meglio il mio punto di vista.
Forse e' qui la differenza: io non vedo i ng come un libro, ma come un posto
al quale poter eventualmente attingere (ovviamente cercando anche
di contribuire quando altri chiedono) nel caso in cui sul lavoro mi si
presenti un problema che non e' trattato dai libri che ho a disposizione in quel
momento. In genere se ho un problema stupido sul lavoro => puo' essere
che mi serva del tempo per capire cosa non va: posso comprarmi dei libri
ma generalmente mi possono servire settimane solo per farli arrivare e 
altrettante per leggerli (e talvolta
si sbaglia la valutazione del libro per cui magari il problema che pensavo
di risolvere leggendo quel libro, non lo risolvo => altro tempo). Talvlta nel
NG si puo' trovare qualcuno che in un attimo ti indica la strada giusta
da seguire. 
Esempio pratico tratta dalla mia esperienza lavorativa recente:
mi e' stato chiesto qualche tempo fa di scrivere dei client che richiamavano
dei web services (che non sapevo nemmeno cosa fossero) => ho provato
a chiedere su it.comp.java cosa potevo leggere per crearmi dei web
services utilizzando Tomcat => mi hanno indicato un link ad axis (che non sapevo
nemmeno che esistesse,
ne mai avrei potuto immaginarmi di andare a cercare "axis" su google) 
=> l'ho trovato molto utile e finalmente ho scritto il mio primo web service
client (e anche il mio primo web service server per la verita')
NB: sul ng hanno solo messo un link alla home page di axis, non e' che
mi abbiano spiegato cosa e' un web service e/o come lo si scrive. 
Se mi dicevano: sei OT! probabilmente starei ancora cercando un modo per 
farlo e, dal mio personale punto di vista, l'utilita' di quel NG sarebbe stata
molto minore => sarei stato spinto a non frequentare piu' molto. 
Questo indipendentemente da cosa dica il manifesto di it.comp.java.
Ora invece, pur non ritenendomi un megaesperto di java/j2ee => se vedo una
richiesta sul quel NG alla quale penso di saper rispondere, "sento" in qualche
modo di doverlo fare. Non lo faccio praticamente mai 
perche' non sono affatto esperto per cui spesso chiedono cose a cui non
so rispondere. Pero' mi sento invogliato a partecipare.
Ciao,
Marco.

 Provo a spiegare meglio il mio punto di vista.
Il tuo discorso però sembra implicare che non ci sia un newsgroup, un forum o 
quant'altro per cercare le informazioni desiderate il che spesso non è vero.


 ma dopo un po' si deve aggiungere necessariamente altro)
Non capisco sinceramente dove sia il problema. Programmare, nella
pratica, implica questioni che possono riguardare strettamente il
linguaggio o strettamente la piattaforma. Se ci sono problemi legati
al linguaggio, questo ng va benissimo, se ci sono problemi legati alla
piattaforma, gli altri ng che parlano della propria piattaforma vanno
benissimo. Più scelta di così si muore. Il problema è che molte
persone NON SANNO distinguere cosa sia inerente al linguaggio e cosa
alla piattaforma e questo la dice lunga sul loro studio del
linguaggio.

 da mangiare. Invece "C++ piu' altre cose" puo' darti da mangiare.
Dipende come la vedi: secondo me conoscere bene il C++ standard ti fa
mangiare eccome, perché conoscerai il C++ (a prescindere da estensioni
specifiche) sicuramente meglio di molti altri e questo, in ambito
lavorativo, è sicuramente apprezzabile (sempre che tu abbia qualcuno
che possa apprezzarlo). In ogni caso, chiunque stia qui dentro e
difenda la trattazione degli aspetti standard del linguaggio sa
benissimo (siamo programmatori, non filosofi) che nella programmazione
di tutti i giorni bisogna usare strumenti specifici (framework,
librerie, ecc...) quindi nessuno si sogna che tu possa costruire
applicazioni di un certo livello utilizzando SOLO costrutti standard.
Lo sbaglio che molte persone fanno è quello di pensare che chi difende
la trattazione dei temi standard voglia programmare SOLO con roba
standard. Sarebbe un purismo fine a sé stesso e piuttosto sterile. In
realtà, qui dentro, attenersi al "core" standard è proprio un modo per
salvaguardare la programmazione multipiattaforma. Esiste un ng come
questo in cui sarebbe bene non affrontare temi non specifici della
piattaforma ed esistono ng che trattano le diverse piattaforme.
Arrivare a dire che "col C++ da solo non si mangia" non è che sia una
gran rivelazione, lo sappiamo tutti quanti, ma il C++ è un linguaggio
talmente ampio e complesso che la sola trattazione degli aspetti
standard richiederebbe anni di discussioni continue. Piuttosto,
diciamo che gran parte dei programmatori non è stimolato a parlare di
questi, non si è interessati a conoscere bene un linguaggio, ci si
limita a smanettare con le librerie quando serve, assicurandosi di
conoscere quel tanto che basta per lavorare. Questo è normalmente ciò
che distingue un programmatore "smanettone" da un progettista. E'
forse per questo che i progettisti scarseggiano...e gli smanettoni
dilagano...

 dilagano...
Questo sara' anche vero, ma secondo me e' anche perche' quando uno 
smanettone si accorge di essere diventato "progettista" => magari non si
accontenta piu' di un tozzo di pane e magari l'azienda preferisce
dare un tozzo di pane ad uno smanettone piuttosto che pagare un progettista.
Ciao,
Marco.

 soluzione. Preferisco avere il codice "in mano".
Qualcosa di simile esiste per Haskell. Esiste un modulo Haskell che
permette di chiamare tutto il codice Python esistente.
Ma con una soluzione del genere togliamo a C++ la sua principale forza:
la velocità.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 meno persone).
Direi che non frequenti it.comp.lang.python. Dal punto di vista tecnico
è un gruppo fenomenale. 
Ho visto discussioni *estremamente* interessanti su design,
programmazione di rete, programmazione asincrona e quant'altro. Proprio
per il fatto che le cose facili sono *davvero* facili, per cui al di la
di qualche iper-niubbone fisiologico (ma anche li si fa prestissimo a
rispondere) le domande sono spesso spunti per interessanti riflessioni.
Qui in pratica gli argomenti OT sono pochi. E alla fine buona parte del
traffico è generato da domande da 'il mio primo corso di
programmazione'. E *incidentalmente* quelle sono IT, proprio perchè non
richiedono librerie esterne.
Ci sarebbero altri argomenti perfettamente IT: per esempio potremmo
discutere sul design di un compilatore Pascal (o quello che vuoi). Un
compito affascinante e perfettamente fattibile con la libreria standard
del C++. O una macchina virtuale. Ma alla fine chi è che si metterebbe
qui a parlare di questi argomenti? (lasciando stare che almeno nel primo
caso non vedrei improbabile l'uso di lex/yacc++, finendo quindi OT, ma
supponiamo che uno si faccia il suo bel parser fatto a mano -- sigh.
--).
Con il risultato che al di la di pochi thread (tipo quelli di Kiuhnm)
spesso la faccenda diventa un po' come dire... stanca. In questo sono
d'accordissimo con Nicola.


 rappresentare un socket mi pare perfettamente ragionevole.
Sarei anche d'accordo. Ma *questo* tono di domande non lo ho visto (e
penso che anche addentrandosi nei dettagli dei socket posix, per dire,
non si sarebbe gridato all'OT nel disegnare una classe C++ con tutti i
crismi per astrarre).
Purtroppo vedo molte domande da VC++ in 24 ore e simili.
Comunque anche io direi di aprire. Magari non troppo. Che so, infilare
dentro Boost, altre note librerie multipiattaforma, ma lasciando stare
roba come Wx o Qt, e specialmente lasciando stare roba come 'come scrivo
il bottone che mi apre la finestrella'?


smanettone si accorge di essere diventato "progettista"
Le trasformazioni kafkiane, in programmazione, esistono solo verso le
qualità negative. Uno smanettone non si sveglia la mattina
"accorgendosi" di essere diventato progettista. Progettisti si diventa
studiando, per atto volontario.

politica
Ma che cacchio di paragone č?!

crismi per astrarre).
Sono perfettamente d'accordo. Io credo che ognuno di noi sappia bene
che le domande che vengono poste su come progettare una classe non
siano fantasie astruse di chi scrive, ma molto probabilmente necessità
derivanti dal lavoro. Ora, una cosa però è parlare di come si progetta
una classe (sia essa destinata a lavorare nel contesto di una GUI,
astragga essa i socket, o altro), un conto è scendere nei dettagli sui
socket, per esempio. Non sarebbe neanche corretto disquisire in un ng
dedicato al C++ su come si usa la select().

Andrea Laforgia ha scritto:

Che in generale, salvo pochi irriducibili, la gente alle tribune 
politiche si annoia!
:))

 la velocità.
Però in C/C++ non è così veloce sviluppare. Comunque per quel faccio la 
velocità e tutto, e l'idea di passare da un pcode e di non avere il 
controllo diretto della memoria mi fa ribrezzo.
In ditta c'è chi ha provato a sviluppare un progetto "grosso" in 
dotnet, perché tanto si sviluppa facilmente, e ci sono le librerie per 
tutto, ma malgrado ciò è stato un marasma. Il difetto principale del 
C/C++ è anche il suo pregio migliore, ciò DEVI conoscere i dettagli, e 
non ci sono santi, ops, librerie che decidono loro cosa è meglio per 
te.
Io sono riuscito a fare impazzire la GC sia in dotnet che in Python, 
mentre riesco a mantenere la situazione sotto controllo in C++. Su 
python però, forse, questo era dovuto alla mia conoscenza superficiale 
del modulo GC.
-- 
mai più senza: 
http://www.genux.com/scheda.asp?idprod=47974
la cultura è importante: 
http://www.libreriadellautomobile.it

 veniva rilasciata
Cavolo, ci ho messo un sacco a risolvere quel problema, che ovviamente 
su Windows non c'era. Gli standard che però funzionano in modo 
lievemente diverso da piattaforma a piattaforma sono il diavolo.


 dedicato al C++ su come si usa la select().
Onestamente non lo so. Io preferisco ormai da tempo it.comp.lang.python 
a questo NG, anche se non essendo il linguaggio che mi da mangiare 
l'interesse sarebbe in partenza minore.


 del modulo GC.
A questo punto mi chiedo cosa ci facevi (e quando lo facevi).
Tipicamente il modulo gc non lo tocchi e si strega lui. Per il resto da
un po' coglie anche i cicli (salvo che uno dovrebbe cercare di non
scrivere codice in cui gli oggetti sono dipendenti in modo ciclico,
quando possibile, anche se spesso al di la di tutto č la soluzione piů
comoda, capita e non bisogna farne un dramma).
Comunque pensa, vogliono mettere un gc anche in C++ :P


 Comunque pensa, vogliono mettere un gc anche in C++ :P
Si, ma facoltativo!
Ciao,
Nicola

 Comunque pensa, vogliono mettere un gc anche in C++
Io non sono contrario alla GC, certo è che se ti serve la GC magari, in 
quel caso, potrebbe essere più comodo usare un qualche altro 
linguaggio.
Per me comunque il supporto alla memoria della libreria standard è già 
una cosa bellissima. Mi vengono i sudori freddi a pensare di sviluppare 
un allocatore. Non mi sembra una cosa facile.


 On Jun 18, 1:09 pm, 
r...@despammed.com
 (Enrico 'Mc Osten' Franchi)

anche se facoltativo si snaturerebbe il linguaggio con l'introduzione
del gc in c++ a mio parere; si cerca di portare il c++ più vicino alle
mode odierne, ho visto che si era anche proposto di togliere
completamente la gestione della memoria e i puntatori; se uno non vuole
sporcarsi le mani non usa il c++. poi basta farsi uno smartpointer siè
a posto

 un allocatore. Non mi sembra una cosa facile.
Beh, dipende da quali sono i requisiti dell'allocatore. Probabilmente
quest'estate ne devo precisamente scrivere uno (dobbiamo scrivere il
gestore di memoria di un interprete -- il resto dell'inteprete è in
Prolog, ma per ragioni di prestazioni il gestore della memoria lo
vogliono giustamente in C++).
Vedo *molto* probabile che dovremo scriverci anche un allocatore. Poi
ripeto, in se la cosa potrebbe non essere drammatica (di testi su come
gestire la memoria ce ne sono, gli algoritmi sono in letteratura, se ne
parla sia sui classici sui sistemi operativi, sia nella nuova edizione
del dragonbook). Se invece si hanno esigenze di performance strepitose,
allora la cosa è molto più rognosa, come tutti i problemi in cui a
correttezza di aggiunge performance.
Poi magari sto sottovalutando io miopemente qualche aspetto, eh.


 a posto
Un momento: distinguiamo le cose serie dalle fregnacce; lo sforzo per
introdurre un meccanismo facoltativo di GC in C++ e' guidato da Hans
Boehm, che di queste cose se ne intende, e trova un deciso appoggio,
tra gli altri, di Andrei Alexandrescu, che, come diceva Marenco, non
e' un fesso. Un altro sostenitore e' James Kanze, che di tanto in
tanto passa da queste parti e la cui competenza puo' essere
agevolmente verificata su comp.lang.c++.moderated e comp.std.c++ .
Quella di togliere la gestione della memoria e i puntatori e' una
fesseria.
L'idea che i programmatori C++ siano "fighi" perche' gestiscono la
memoria a mano mi sembra perniciosa. In moltissimi casi la garbage
collection semplifica la vita senza svantaggi oggettivi. L'importante
e' che la sua iontroduzione non comporti perdite secche, come e' stato
in Java: la distruzione deterministica e' il primo argomento che mi
viene in mente, ma non e' l'unico.
Ciao,
Nicola

 Poi magari sto sottovalutando io miopemente qualche aspetto, eh.
La cosa più rognosa per me è la gestione multithread ed essere 
prestanti. Per esempio, mi pare, che std::string nella versione 
Microsoft sia un'implementazione non banale.


 ma non e' l'unico.
Cosa intendi per perdite secche riguardanti 'la distruzione 
nondeterministica'?
In termini di performance, o l'introduzione di 'altri' problemi?
In termini di performance la distruzione deterministica non e' sempre un 
vantaggio, anzi ci son casi in cui la distruzione nondeterministica risulta 
piu' efficiente (semplicemente perche' NON dealloca, o se lo fa, lo fa in 
blocco).
Per gli "altri problemi", ci sono soluzioni, che Java non adotta per motivi 
a me ignoti =)
--
Marco

 a me ignoti =)
Java sux. (tm) :P


 In termini di performance, o l'introduzione di 'altri' problemi?
No, non parlo di performance. Parlo del fatto che in tutti i linguaggi
OO dotati di Garbage Collection non e' possibile usare RAII. Questo
per esempio costringe all'utilizzo del pessimo 'finally'.
Ciao,
Nicola

 Microsoft sia un'implementazione non banale.
Nemmeno quella del gcc :) La cosa che rende complicato std::string e' il 
meccanismo di reference counting che deve essere thread safe. Su GCC 
utilizza (internamente) delle chiamate apposite per fare operazioni 
atomiche sul counter di referencing, purtroppo sono private all'interno 
dell'implementazione di alcuni template stl perche' a tirarle fuori 
sarebbero utili in molti posti dove di solito si usano mutex...
Bye,
  Gabry

per esempio costringe all'utilizzo del pessimo 'finally'.
Hummm... il mio codice Delphi abbonda di "finally" :-) (pur non avendo
Delphi un GC). Ho sempre pensato che fosse una tecnica ottima (da
tener presente però che in Delphi si può solo allocare dinamicamente
un'istanza di un oggetto). 
Perché lo reputi pessimo?

 OO dotati di Garbage Collection non e' possibile usare RAII.
Non è esatto. In Python 2.5 hai possibilità di usare RAII tramite la
keyword with. 
D pure dovrebbe supportare RAII. In effetti è sufficiente che la
GarbageCollection non sia usata sulle cose nello stack (e che queste
vengano distrutte quando si esce dai blocchi).


 Perché lo reputi pessimo?
Non posso rispondere per Nicola, ma in generale se ficchi il codice di
pulizia nel distrutture lo scrivi una volta per tutte e quando distruggi
l'oggetto, risali lo stack, ritorni da un metodo, scoppia un'eccezione
etc etc etc il codice č *sempre* eseguito.
Con i finally hai duplicazione di codice e potenzialmente (ma questa č
colpa del programmatore) ti scordi la pulizia. Niente di tragico, ma
oggettivamente RAII č piů pulito.


 OO dotati di Garbage Collection non e' possibile usare RAII.
Neppure D?
--
Marco 

 Java sux. (tm) :P
Uff... anche se da tempo non ci lavoro piu' (oddio, non e' poi tanto 
vero...), sono pur sempre uno dei fondatori della Java Italian Association 
:p
--*PaN!* 

 oggettivamente RAII è più pulito.
Non solo: l'unica alternativa per fattorizzare il codice e'
l'approccio procedurale piu' puro che ci sia, magari attraverso l'uso
di callback e altre complicazioni simili.
Ciao,
Nicola

 un'istanza di un oggetto).
Da questo punto di vista Delphi e' il peggio del peggio, perche'
impone l'allocazione dinamica delle istanze delle classi e quindi non
consente l'uso di RAII e in piu' devi pure gestire la memoria a mano.
Ciao,
Nicola

 vengano distrutte quando si esce dai blocchi).
In effetti e' la garbage collection ad impedire l'uso dei distruttori
per implementare RAII.
Ciao,
Nicola

 :p
E io di Python Italia :P


 Neppure D?
D lo fa.


 Ho visto e devo dire che non mi dispiace.
A me piace abbastanza, anche se non ho ancora avuto il tempo e la voglia
di usarlo. Anche perchè in generale non sono completamente sicuro di
volere tagliare fuori il 2.4.
Tra l'altro quello che è bello è che è sostanzialmente equivalente ad un
semplice blocco con oggetti automatici. Devo studiarla meglio per vedere
se per caso si comportasse anche particolarmente bene in termini di
performance, ma dovrei anche meditare su come strutturare i test.


 E io di Python Italia :P
AAAH! Il male ;)
--*PaN!*

 keyword with.
Però è di utilizzo più limitato rispetto a quanto sia possibile fare in 
C++ con RAII.
Ciao.

 *medie* di un sw con gestione manuale della memoria.
Il problema non è la velocità quanto il "consumo" di memoria.
Ormai è piuttosto frequente trovare applicativi, generalmente scritti in 
Java (ma io ho avuto un problema analogo anche con Ruby, Python non lo 
uso quindi non saprei) che richiedono quantitativi assolutamente 
spropositati (ed ingiustificati) di RAM per funzionare.
Per esempio io uso Carbide (un ide basata su Eclipse per lo sviluppo su 
Symbian OS) e con 512 MB un Sempron 2500+ era più lento di un 486 (ed il 
disco mi implorava pietà..). Non ho avuto modo di utilizzarlo finché non 
ho raddoppiato la RAM.
Poi, chiaramente, anche in C++ è possibile fare altrettanto (vedere 
Firefox/Mozilla), ma con altri linguaggi sembra quasi la regola.
Ciao.

consente l'uso di RAII e in piu' devi pure gestire la memoria a mano.
Capisco che vuoi dire, però la tua critica mi sembra legata al fatto
che le istanze vengano create dinamicamente. RAII invece non dovrebbe
essere un design pattern? un concetto che prescinde da questo? Tu dici
che Delphi non consente di implementare l'uso di RAII, ma un codice
come quello che segue non è comunque  un'implementazione di RAII ? Uno
dei vantaggi riconosciuti a RAII è che consente di scrivere codice
exception-safe, ma mi sembra che anche il seguente lo sia:
interface
type 
  TMyFile = class 
  public
    // apre il file nel costruttore
    constructor Create(AFileName: string); 
    // chiude il file nel distruttore
    destructor Destroy; override;  
  end;
// tipico utilizzo:
with TMyFile.Create('pippo.txt') do
  try
    // usa il file a piacimento...
  finally
    Free();
  end;
Alludi forse al fatto che ci si potrebbe dimenticare la Free() ?
(ammetto che può succedere ed è successo che dei colleghi
particolarmente fantasiosi lo abbiano fatto, scatenando l'ira di Dio a
run-time).

 C++ con RAII.
Ovvero? Come ti dicevo, io non lo ho usato tanto. Ma non vedo nessun
limite teorico. Hai del codice che alloca le risorse, del codice che le
dealloca e un costrutto sintattico che garantisce che all'ingresso di un
blocco ci sia l'allocazione e all'uscita la deallocazione.


 run-time).
Si, il problema non e' tanto RAII in se, quanto il fatto che con la
distruzione deterministica e implicita viene gratis.
Ciao,
Nicola

 limite teorico. 
Per esempio non puoi utilizzarlo per gestire il lifetime di oggetti 
restituiti da una funzione.
Ciao.

 restituiti da una funzione.
IMHO puoi. Dopo tutto un costruttore *è* una funzione.
Se invece con lifetime intendi avere la *certezza* della distruzione
dell'oggetto (ma poi mi chiedo perchè vorresti farlo, nell'__exit__ puoi
rilasciare tutte le risorse e a quel punto l'oggetto è un guscio libero
di essere garbage collected), no, non credo che tu possa. del self IMHO
non può fungere.
from __future__ import with_statement
class FakeLock(object):
    """This lock is a fake and prints out some info"""
    def __init__(self):
        pass
    def __enter__(self):
        print "Entered critical section."
    def __exit__(self, etyp, einst, etb):
        print "Got out of critical section."
        if etyp:
            print "An exception occurred."
            print einst.message
 
def lock_builder():
    """This builds a fake Lock"""
    return FakeLock()    
 
 
with FakeLock():
    print "Foo!"
 
with lock_builder():
    print "Boo!"
 
l = lock_builder()
with l:
    print "Moo!"


 
Prova a guardare quě:
http://www.eptacom.net/pubblicazioni/pub_it/iso_12.html
In fondo all'articolo viene analizzata la differenza tra RAII C++ e 
using del C# (che mi sembra di capire essere molto simile alla with di 
Python)
Pescio fa notare che using risolve elegantemente i casi piů semplici in 
cui la risorsa viene creata e rilasciata nello stesso "stack frame"
La limitazione piů grave č nella restituzione di oggetti che con RAII si 
puň fare (vedi vari smart pointer), con using no.
Esempio:
std::auto_ptr< Resource > f()
   {
   std::auto_ptr< Resource > r = new Resource() ;
   // do something
   return r ;
   }
Questo codice che usa RAII č exception safe. In C# con using non si 
riesce a fare nulla di simile.
Citanto Pescio:
<cite>
Il nucleo del discorso, tuttavia, non cambia: l'istruzione using e' una 
soluzione comoda, copre una casistica relativamente ampia, ma non e' una 
soluzione metodologicamente completa, a differenza dell'idioma RAII del 
C++. Puo' evitarci, in scenari elementari, qualche istruzione try/catch. 
Uscendo dagli scenari elementari (che invariabilmente sono gli unici ad 
essere presentati dagli evangelisti :-), tutto torna sulle spalle del 
programmatore.
</cite>
Comunque non coniosco Python, quindi non so se quanto vale per C# sia 
applicabile anche quě.
GM

 applicabile anche quì.
Direi di si. with del Python e using del C#, per quanto certamente
piu' pratici di try/finally, condividono con tale istruzione il
peccato originale: sono inerentemente procedurali e si combinano solo
limitatamente con un approccio object oriented, in un caso dove
quest'ultimo paga.
Ciao,
Nicola

 distruzione deterministica e implicita viene gratis.
Non ricordo in che linguaggio, ma mi pare che qualcuno abbia gia' pensato di 
separare la parte deterministica (distruzione) da quella indeterministica 
(finalizzazione).
--
Marco 


E' .NET con il concetto "dispose"
GM

 E' .NET con il concetto "dispose"
Eccolo la' =) Mi pareva d'averli intravisti in C#, ma non ne ero certo non 
avendolo mai usato in un lavoro...
--
Marco 

 quest'ultimo paga.
Tuttavia non capisco il perchè dici questo. Per come la vedo io with è
in pratica un'istruzione di blocco che mi garantisce allocazione in
ingresso e deallocazione in uscita.
Il codice di allocazione e deallocazione è *dentro* gli oggetti.
La principale differenza con C++ è che in questo caso è il default (gli
oggetti sullo stack), mentre in Python va richiesto esplicitamente.


 Microsoft sia un'implementazione non banale.
Ah, vero. Multithread. Ma il nostro interprete non lo è, per cui non ci
avevo nemmeno pensato. Non solo, ma non è nemmeno previsto che lo sia a
breve :)
Anche perchè è parte di un'infrastruttura per fare analisi statica, e
per ora il multithread non è oggetto di analisi.


 prodotto gira su macchine nuove, nel migliore dei casi.
Attenzione però: ottimizzare in ASM le poche funzioni chiave non ha
necessariamente questi problemi. Se non è necessario non si fa, ma
appunto, pensa a GMP. Praticamente tutto il codice chiama per il 90%
delle volte quattro funzioni in croce (e sapevo anche quali erano).
Strizzare il metallo con queste vuole dire velocizzare tutto il resto.


 ... nell'__exit__ puoi rilasciare tutte le risorse ...
[...]
Ho fatto alcune prove con il codice che hai scritto (modificandolo in 
parte) e trovo che abbia un comportamento che io (che non conosco il 
Python) non riesco a capire, perché se tolgo il with né la __enter__ né 
la __exit__ vengono più chiamate... per cui mi risulta difficile trarre 
delle conclusioni da codice che si comporta in modo, per me, 
assolutamente incomprensibile...
Per esempio con:
[...]
print "Poo!"
l = lock_builder()
l.foo()
print "Moo!"
l'output è:
Poo!
foo()
Moo!
Ciao.

 assolutamente incomprensibile...
E' ovvio che se togli il with la __enter__ e la __exit__ non vengono 
chiamate. Python di per se è un linguaggio dinamico e garbage collected.
Gli oggetti hanno un costruttore e un distruttore. Il costruttore viene 
chiamato quando sono creati, il distruttore quando sono distrutti. Cosa 
che avviene in un certo momento dopo che non sono più riferiti da nessuno.
In particolare CPython (l'implementazione di standard) usa un meccanismo 
di reference counting, per cui è possibile che appena fuori dal blocco 
dove muore l'ultimo riferimento siano distrutti. Tuttavia l'algoritmo di 
garbage collection è un dettaglio implementativo e non è parte di Python.
Per esempio IronPython (Python su .Net) usa il garbage collector 
sottostante. Possiamo quindi concludere che *di per se* in Python non 
abbiamo modo di sapere quando un oggetto sarà rilasciato. Per cui 
normalmente si usano i blocchi try/finally e simili.
E' stato tuttavia pensato che sarebbe stato comodo dotare Python di un 
meccanismo di RAII. Questo viene attivato dal with. Quando metti un 
oggetto nel blocco with, sai che all'entrata viene chiamato __enter__ e 
all'uscita __exit__.
Tutto li. Se togli il blocco with, stai togliendo l'idioma RAII. Come se 
uno dicesse che in C++ non allocando gli oggetti sullo stack ma facendoli 
con new questi non vengono più distrutti. :)
-- 
  Enrico Franchi (RiK0)
[ Yellow Dog Linux User ]
[ #299188 Linux Counter ]
[ MacOS X User          ]

 con new questi non vengono più distrutti. :)
Già, ma neppure costruiti...
Ciao.

E cosa c'entra ciò con l'essere dinamico e garbage collected?
Be', distruzione deterministica e garbage collection fanno a cazzotti.

 Già, ma neppure costruiti...
Cosa intendi?


 Be', distruzione deterministica e garbage collection fanno a cazzotti.
Questo è ovvio :-P
Mi chiedevo però, e mi continuo a chiedere, cosa c'entri il fatto che le 
funzioni __enter__ (che io nella mia ignoranza di Python pensavo essere 
sempre chiamata alla costruzione di un oggetto) e __exit__ vengano 
chiamate solo in un blocco with con il fatto che Python sia dinamico e 
garbage collected...
Ciao.

 Cosa intendi?
Ha fatto tu il paragone... In C++ comunque io allochi un oggetto (in 
modo automatico, dinamico o statico) il costruttore viene sempre 
chiamato, mentre è stato scelto di non far chiamare la __enter__ al di 
fuori di un blocco with.
Ciao.

 fuori di un blocco with.
Quindi non vedo cosa c'entri, visto che __enter__ *non* è un
costruttore.


 costruttore.
Ok, ora ci siamo, ma me lo hai detto solo ora... al terzo messaggio...
Avrei capito pure prima, ma la mia sfera di cristallo è a riparare :)
e i miei voglia/tempo di leggermi un manuale Python per capirlo da solo 
in questo momento sono in ferie... :-P
Ciao