Newsgroup: it.comp.lang.c++
Titolo: Vorrei imparare...

Salve ragazzi...
Mi presento, sono nuovo del gruppo e sono qui per imparare (mi dispiace
per voi :-))!!!.
Quando potro' cerchero' di aiutare, ma per il momento capisco solo il
10% del contenuto dei vostri messaggi :)
Il motivo per cui scrivo e' per un consiglio, un manuale.
Vorrei cominciare a programmare qualche cosina (con VisualC++ ?) ma mi
servono dei manuali!
Avete dei consigli da darmi?
Spenderei circa 200.000 per un manuale, ma vorrei che fosse
comprensibile per chi comincia adesso e COMPLETO anche per il futuro.
Spero in un vostro consiglio!
Grazie mille
Ciao
-- 
Giulivo Navigante
mailto:
giulivo....@bigfoot.com
http://giulivo.cjb.net

Salve ragazzi...


comprensibile per chi comincia adesso e COMPLETO anche per il futuro.
Se sei un principiante di programmazione in assoluto, ti consiglio di
cominciare con un linguaggio diverso dal C++, piu` facile, e piu`
adatto ai principianti; secondo i tuoi gusti e il tuo carattere, puoi
sceglierne uno "rigido e preciso" come Pascal (Delphi), uno di
media rigidezza/precisione come Java, uno decisamente "lasco"
come Visual Basic oppure Python (Java e Python hanno l'ulteriore
vantaggio di essere gratis; di Delphi e VB puoi trovare versioni
vecchie o limitate su CDROM con riviste in edicola).
Se sai gia` programmare, e hai deciso di imparare anche C++...:
Per il C++ Standard, in inglese, Lippman e Lajoie, C++ Primer 3rd
Edition, Addison Wesley; US$ 45.95 prezzo scontato da Borders
(penso che Amazon, ecc, lo facciano a meno, in rete).  Soddisfa
i tuoi requisiti purche` possa per te essere "comprensibile" un testo
in inglese; la *completezza*, pero`, riguarda solo e rigorosamente,
appunto, lo _standard_ del C++, NON, certo, le infinite aggiunte che a
quello standard si possono fare e in pratica si fanno:
    -- programmazione di database (teoria del DB relazionale,
        linguaggio SQL, meccanismi di aggancio ad esso, ...)
    -- programmazione di rete (teoria del TCP/IP, le socket, i
        protocolli piu` vari dall'ICMP all'HTTP, i linguaggi descrittivi
        come HTML, XML, SGML, ecc, relativi object-models,
        style-sheets, ecc ecc, classi di incapsulamento per parte
        o tutta questa ricchezza)
    -- programmazione di sistema (interazioni "a fondo" con i
        filesystem, gestione dettagliata dei processi, allocazione
        di risorse, multithreading e multitasking, ecc ecc, per i
        vari sistemi, Win/Nt, Win95, OS/2, Linux, Unix BSD,
        MVS, VMS, ... -- device drivers per i vari S.O. e per la
        enorme varieta` di hardware esistente)
    -- grafica (2D, 3D, interfacce utente grafiche, elaborazione
        e trattamento delle immagini, ...)
    -- suoni (elaborazione del segnale, sintesi e riconoscimento
        della voce, MIDI, altre interfacce musicali, ...)
e mille altri ancora "paradigmi fuoribordo" (per mutuare l'ottima
e colorita espressione di Coplien) che in pratica si desidera
usare con linguaggi come il C++.  Spero sia chiaro che ciascuno
di questi temi merita e necessita, anche solo per una decente
introduzione, di almeno un libro di "spessore" (sia fisico, 1000+
pagine, sia concettuale) assolutamente paragonabile a quello
che Lippman e Lajoie dedicano al solo C++ (linguaggio e librerie
standard).
Inoltre, se si desidera qualcosa piu` di una introduzione, ciascuno
di questi temi puo` meritare anche piu` testi; e questo si applica
anche al tema specifico "programmazione in C++".  In 1200+
pagine puoi imparare molto a fondo i dettagli del linguaggio e
delle sue librerie, con _cenni_ a problematiche di progettazione,
idiomi basilari, modello a oggetto, eccetera; ma ci sono testi
di simile spessore anche su sottotemi molto specifici, ad
esempio l'ottimo testo di Austern su Generic Programming ed
STL dedica 500+ pagine (non certo sprecate) al solo specifico
approfondimento di questo (importante, certo) sotto-tema (che,
nel quadro complessivo del linguaggio, e` solo uno di tanti).
In particolare, visto che nomini _Visual_ C++, immagino che
tu sarai interessato ad approfondire almeno uno dei framework
che accompagnano il compilatore vero e proprio, ad esempio
le MFC; su queste, secondo me, e` indispensabile un buon
testo introduttivo "per conto suo" (suggerisco il testo di
Prosise, edito in italiano da Mondadori Informatica), da
leggersi dopo avere acquisito almeno una prima infarinatura
sul C++ in quanto tale.  Le MFC comprendono vari ausilii per
temi assai vari (accesso a database, rete, GUI, ecc ecc), ma
non credo che "conoscere le MFC" basti per fare buon uso di
queste varie altre risorse, senza qualche cultura specifica in
merito a ciascuna (con la possibile eccezione di GUI e un po'
di semplice grafica bidimensionale).
Inoltre, merita di scaricare gratuitamente dalla rete (alla URL
www.BruceEckel.com
) il testo "Thinking in C++, 2nd edition"
(sempre in inglese) benche` sia ancora in versione incompleta
("beta", secondo l'autore).
Alex

Se sai gia` programmare, e hai deciso di imparare anche C++...:
--
(o-  T | Unix is simple and coherent , but it takes a genius  to understand
//\  U | and appreciate  its simplicity .
V_/_ X |                                    Dennis Ritchie .
email: r.salmaso (at) 
flashnet.it
 | salmaso.raffaele (at) 
iname.com

Completo. Per 10Klire non e' per niente un brutto affare...
Infatti, un ottimo affare -- e` anche importante, pero`, sapere
che si tratta di una versione molto vecchia (C++Builder 3 e`
in giro da oltre un anno, la 4 e` imminente, e quella che si
trova con la rivista e` invece la 1), come appunto accennavo.
Alex


Ueh raga!
Innanzitutto grazie per la risposta!
Comunque, indipendentemente dall'ottimo affare... io del tuo primo
messaggio ci ho capito davvero poco!
Cioe', praticamente sono ancora agli inizi e diciamo che circa il 70%
del testo che compariva nel tuo messaggio per me era ARABO!
Ti sarei ancora grato quindi se potessi cercare di essere piu'
"comprensibile" :)
Ora, se vuoi ancora aiutarmi e non vogliamo disturbare il gruppo,
potresti rispondermi in mail... ma sia chiaro che io non ho problemi a
seguire i messaggi, e' solo che forse farei troppe domande "da FAQ", per
esempio :)
Grazie


potresti rispondermi in mail... ma sia chiaro che io non ho problemi a
Penso sia meglio che restiamo qui, per le solite ragioni:
1. quando faccio affermazioni controverse, non manchera` chi fa
    affermazioni contrarie; in questo modo, "senti entrambe le
    campane" e hai quindi piu` possibilita` di decidere tu;
2. quello che diciamo puo` certo essere di interesse ad altri, "puri
    ascoltatori" (il rapporto fra chi scrive un gruppo e chi lo legge,
    storicamente, e` di almeno uno a dieci, spesso uno a cento);
3. visto lo specifico problema, quando dico qualcosa di non chiaro,
    hai piu` chance che qualcun altro lo chiarisca;
ecc, ecc.
Dunque, ricapitolando, io dicevo:
a. se non sai per nulla programmare, non ti conviene secondo me
    iniziare con linguaggi difficili (C, C++, Assembler, Ada, ...); scegli
    invece un linguaggio facile -- a seconda dei tuoi gusti, puoi
    sceglierne:
    a1. uno rigido e preciso: ad es. Pascal (Delphi)
    a2. uno flessibile e lasco: Visual Basic, Python, Perl, Rexx, o
            uno qualsiasi dei tanti linguaggi di scripting, sempre a
            seconda dei gusti ecc;
    a3. uno intermedio in termini di rigidezza: ad es. Java
b. se sai gia` programmare e hai lo specifico obiettivo di
    imparare il C++, ti conviene partire con un buon libro
    sul linguaggio (Lippman e Lajoie, C++ Primer, 3rd Edition,
    Addison-Wesley), un buon compilatore gratis (egcs 1.1),
    e una decente implementazione della libreria standard
    (STLPort).
Alex

 Costa circa £ 130.000, dipende dal cambio del dollaro...
Tutto ok!
Mille grazie, ma...
E' proprio scritto in inglese?


     (STLPort).
Uhmmm... STLPort?
Comunque ancora mille grazie!!


 programmazione?
Secondo me (purtroppo, aggiungo...), nonostante il linguaggio sia
incoerente e pieno di bugs, alla fine si riescono a scrivere tutti i
programmi che si vuole (io ho esperienza solo sui gestionali, però) in
un tempo relativamente contenuto.
EMG


Ok, ma in molti mi hanno consigliato Borland C++ Builder.
Pensi che siano equivalenti?
Ciao
Grazie, ovviamente!



A livello di linguaggio, in generale, qualsiasi problema risolvibile con uno e`
risolvibile anche con l'altro. Cio` che differenzia i linguaggi e` sostanzialmente
il paradigma di programmazione (ovvero il modo in cui il linguaggio ti permette
di modellare la soluzione al problema) e la libreria a supporto (il pascal
standard ad esempio e` molto povero, il C ed il C++ invece sono molto
ricchi).
Ovviamente il fatto che due linguaggi siano equivalenti non vuol dire che
sono adatti ad ogni tipo di problema, ma questo e` un altro discorso.
Paolo
----------------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
  e-mail: 
mar...@cli.di.unipi.it
 
----------------------------------------------------------

Ciao


Uhmmm... STLPort?
Si`, STLPort, perche`...?
Alex

programmazione?
Come linguaggio il VB č un pň lascivo ma sostanzialmente ti
permette la creazione delle stesse applicazioni che potresti fare
con il C++ (anche se VB č piů utilizzato per applicazioni gestionali)
bisogna perň dire che il C++ ha delle ottime librerie.
Per iniziare ti consiglio Java che facilita l'introduzione alla
programmazione ad oggetti, e poi passare al C++ (nel quale
ho trovato molte similitudini) magari con il C++ Builder della
Borland (ora Inprise) o altri, a seconda dei tuoi gusti.
Nel caso hai iniziato ad utilizzare Delphi, tieni presente che
il C++ Builder ha la stessa interfaccia e ti permette l'allacciamento
con l'Object Pascal utilizzato sempre da Delphi, e le librerie
caratteristiche del Builder (VCL) sono scritte in OP, e sono le
stesse usate da Delphi.
A te la scelta!!

 stesse usate da Delphi.
Dunque vorrei ringraziare tutti e dare "il verdetto finale":
1) Ho scaricato un ottimo manuale free per imparare Java (da' anche
piccole lezioni di C e C++)
2) Vedo se riesco a trovare con qualche offerta speciale una versione
relativamente nuova del Borland C++
3) Acquisto il manuale Thinking C++ (consigliato anche su C++Warriors)
Beh, che dire... ho gia' fatto il mio primo programmino in C (somma e
moltiplica due numeri tra di loro... ho usato anche #define :-)).
Mi serve solo qualche compilatore free per il momento, in modo da poter
provare qualcosa senza Borland ed in attesa di avere il manuale!
Ancora grazie a tutti!!


 Pensi che siano equivalenti?
Il Visual Basic e il C++ sono _notevolmente_ diversi sia filosoficamente
che implementativamente. Non ti so dire specificamente del Builder
perché non lo conosco. Sicuramente il C++ richiede un periodo di
apprendimento fatto come si deve mentre con il VB (entro certi limiti)
ti puoi anche sedere ed iniziare a fare programmi.
EMG

Pensi che siano equivalenti?
Assolutamente no.  C++ in qualsiasi forma e` un linguaggio molto
piu` difficile, con potenzialita` molto maggiori di qualsiasi altro, ma
sono potenziali che si pagano a caro prezzo in termini di difficolta`
per impadronirsi alla perfezione del linguaggio e usarlo idem.
Tutti gli altri linguaggi (con la possibile eccezione di Ada, e di
alcune versioni molto, MOLTO ricche di Common Lisp) sono
meno difficili del C++ (e non permettono di fare il 100% di quello
che in C++ puoi fare; magari il 99% si`, ma non il 100).
Visual Basic (se lo vuoi lasco e pragmatico) o Delphi (se lo
vuoi rigido e preciso) sono buoni linguaggi se non hai nessun
problema di portabilita` (cioe` se ti basta Windows, e non hai
obiezioni ai linguaggi proprietari, incluso il costo degli ambienti
di sviluppo ecc); Java, forse un po' meno facile e con qualche
magagna, offre pero` ottima portabilita` e strumenti gratuiti, e
una discreta "eleganza".
Penso che la grande maggioranza dei programmatori si
trovera` piu` a suo agio (piu` produttiva, piu` felice) con
VB, Delphi, o Java, che non utilizzando il C++.
Alex

 programmazione?
 
Il punto, secondo me, non e` tanto fino a che punto arrivi, ma COME ci arrivi.
Con VB, se fai cose non banali, magari ci riesci, ma a volte con giri e rigiri
(e magari "sporcizie") che con un altro linguaggio possono benissimo essere
evitati. Senza contare, in molti casi, l'uso sovrabbondante di risorse della
macchina.
In definitiva, anch'io ti consiglierei di cominciare con un linguaggio diverso
dal C++ (che
forse e' il piu` difficile in assoluto), e cioe` con Java (meglio) oppure
Delphi.
Saluti
Paolo

 provare qualcosa senza Borland ed in attesa di avere il manuale!
http://space.tin.it/computer/rgerola/compil.html
consigliato EGCS Mingw32 (by Mumit Khan).
E se vuoi un consiglio spassionato, risparmia i soldi del Borland
(IMHO).
-- 
Roberto Gerola
Email: 
roge...@tin.it
WWW: 
http://space.tin.it/computer/rgerola

 provare qualcosa senza Borland ed in attesa di avere il manuale!
Ah e volevo ancora una volta ringraziare tutti per gli ottimi consigli!!
Credo che mi abbaite risparmiato un sacco di soldini inutili e ve ne
saro' davvero grato... se poi riesco anche fare qualche cosa di buono
(Java, Delphi, VB o C++ che sia) ve ne saro' immensamente grato!!


 Si`, STLPort, perche`...?
Manno'... scusa... era un modo per dire che non avevo capito cosa
significasse STLPort :)
A proposito... grazie per il consiglio su egcs... corro a cercarlo per
il download!


oppure Delphi.
Scusa, ma "l'uso sovrabbondante di risorse della macchina" non mi pare
corretto nel paragone fra VB e Java: tutte le implementazioni Java che ho
provato sinora (non ho provato Visual Cafe, ma dalle review sulle riviste
non e` che la differenza sia clamorosa) producono codice sostanzialmente
piu` lento di quello che si ottiene coi compilatori nativi ottimizzanti di VB5
e VB6 (e un poco di attenzione a usare tipi di dati giusti, naturalmente).
Delphi (e ancor piu` C++) permettono sicuramente di produrre codice
ancora piu` efficiente, ma le motivazioni per consigliare Java rispetto a
VB (consiglio certo condivisibile, su molti piani e per molti potenziali
studenti) non dovrebbero invece comprendere l'efficienza del codice,
secondo me.
Siamo anche d'accordo sul fatto che C++, fra i linguaggi diffusi, sia
forse il piu` difficile in assoluto (mi pare che solo Ada possa competere!-).
Alex

 il download!
Scusate se sono duro di comprendonio ma... egcs per quali ambienti è
disponibile? Anche per DOS?
EMG

 disponibile? Anche per DOS?
Per DOS non credo.
Le piattaforme supportate (per quello che so io)
sono Linux e Win32.
Ciao


sono Linux e Win32.
Anche un'enorme varieta` di Unix, ma anch'io non credo
che sia supportato Dos.
Alex

 disponibile? Anche per DOS?
Si... sul sito (
space.tin.it/..
.) ho trovato il link al sito in cui si
trovano le distribuzioni e c'erano anche i link alle versioni per dos.
Il problema e' che che poi (piattaforma Win32), cliccando sul relativo
sito da cui fare il download vengo catapultato in una directory che
contiene diversi files!
Quale scaricare?


 e VB6 (e un poco di attenzione a usare tipi di dati giusti, naturalmente).
Non mi riferivo tanto all'efficienza del codice compilato (sul quale sono
convinto che entrambi i linguaggi faranno progressi in futuro, tendenzialmente
annullando le differenze, e comunque non e` qualcosa legato intrinsecamente al
linguaggio), quanto all'uso massiccio, in Visual Basic, dei componenti COM
(questo si, legato al linguaggio, o comunque all'impostazione dell'ambiente di
sviluppo), che non si puo` dire abbiano il dono della leggerezza...
Saluti
Paolo

sviluppo), che non si puo` dire abbiano il dono della leggerezza...
Perche` non si puo` dirlo, visto che (se gli oggetti sono bene implementati)
e` invece perfettamente vero?!  Ho misurato molto accuratamente gli
eventuali
overhead del COM, e la chiamata a un metodo di un oggetto COM (in-process)
risulta avere un overhead medio di circa 2 istruzioni macchina rispetto alla
chiamata di un metodo virtuale C++: queste istruzioni macchina sono, in
sostanza, il PUSH e il POP di "this" sullo stack, che in COM e` necessario,
mentre (nella convenzione di chiamata __thiscall) viene risparmiato passando
"this" nel registro CX (piccola ma importante ottimizzazione).  Su di una
particolare macchina su cui misuravo, per chiamate con vari parametri, il
costo della pura chiamata+ritorno risultava attorno ai 47 nanosecondi per il
caso C++ puro, 52 per il COM, con notevoli variazioni dovute alle
interazioni
di cache, pipeline stalls, ecc, in entrambi i casi; se la chiamata veniva
fatta
a un metodo con convenzione di chiamata alla C (__cdecl), essa era piu`
lenta
che per la chiamata a COM (l'inefficienza di __cdecl rispetto a __stdcall,
che
e` la convenzione base di COM, e` notevole), eppure non ho mai sentito
accusare il C di "non avere il dono della leggerezza"!!!  (Incidentalmente,
la
*cosiddetta* __fastcall era la peggiore, interferendo pesantemente l'uso
dei pochi registri delle CPU Intel per il passaggio di parametri, con le
varie
ottimizzazioni -- ma questo forse si applica solo a compilatori ottimizzanti
con i controfiocchi, in grado di spremere veramente ogni ciclo-macchina
dalla CPU).
Sono veramente sbalordito di sentirti criticare la tecnologia COM proprio su
quello che e` forse il piu` clamoroso dei suoi punti forti, cioe` l'estrema
leggerezza dell'overhead che impone alla comunicazione fra componenti.
Alex

 Quale scaricare?
Mi sembra ci sia anche un file che ti dà delle indicazioni al riguardo,
o sbaglio?
EMG

 Quale scaricare?
In:
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/egcs-1.1.1/
i files da scaricare sono:
egcs-1.1.1-docs.zip
egcs-1.1.1-mingw32.zip
egcs-1.1.1-msvcrt40-runtime.zip
I README dovrebbero essere compresi nei pacchetti,
ma nel dubbio (sono pochi Kbyte) prendi pure quelli
Nella subdir split dovresti trovare il file:
egcs-1.1.1-mingw32.zip
suddiviso in piu` parti per agevolarti nel download:
per non rischiare di arrivare al 99% del download,
perdere la connessione e dover ripartire da zero.
Meglio ancora se puoi usare un programma per FTP
con funzione di resume, facendo login come anonymous
sulla macchina remota.


 egcs-1.1.1-msvcrt40-runtime.zip
Perfetto. Mille grazie e te e ad Enrico
Comunque avendo a disposizione Linux (che installero' a giorni) potrei
usare direttamente quello per compilare?
Ah e a proposito di libri:
Thinking C++ e' in inglese... ne esiste anche la versione italiana, ma
non vorrei che fosse tradotta una schifezza.
Qualcuno quindi puo' darmi delle info (soprattutto se le frasi hanno
senso compiuto, anche dopo la traduzione :)) su questo e su altri libri
scritti o tradotti in ITALIANO!!??
Ancora infinitamente grazie e scusate per le continue domande!!
Ciao


 chiamata di un metodo virtuale C++
Veramente mi riferivo all'occupazione di memoria, che secondo me costituisce
un aspetto critico piu` frequentemente di quanto non capiti per la velocita`. 
Non ho fatto misurazioni, ma mi risulta che usare un oggetto COM
(anche gli attuali ActiveX) o un corrispondente "oggetto windows" (ma anche un
corrispondente componente VCL) faccia una certa differenza, da questo punto di
vista.
Se hai effettuato misurazioni anche su questo aspetto, ti invito a rendercele
note.
Saluti
Paolo

 Ancora infinitamente grazie e scusate per le continue domande!!
Di niente, figurati. Se si puo` si aiuta volentieri.


 non vorrei che fosse tradotta una schifezza.
A parte la traduzione, ti conviene prendere l'ultima versione sulla rete
(anche se in inglese) in quanto quelle già uscite su carta rischiano di
riferirsi ad un C++ non più attuale.
EMG

non vorrei che fosse tradotta una schifezza.
La traduzione e` comunque della versione VECCHIA, e, visto che
il C++ e` cambiato cosi` drasticamente da allora (e infatti cambia
di conseguenza profondamente il testo di Eckel nella nuova, 2a
edizione che, naturalmente in inglese, puo` gratuitamente venire
scaricata da 
www.BruceEckel.com
), non puo` assolutamente essere
consigliata.
Lo stesso vale per i testi di Lippman e Stroustrup: in ambo i casi,
la versione tradotta, Addison-Wesley Italia, e` della versione
VECCHIA e NON sarebbe un buon investimento acquistarla.
Alex

note.
Implementati con l'Active Template Library (ATL) di Microsoft, i componenti
COM risultano sorprendentemente piccoli; il framework ATL e` scritto con una
cieca, fanatica, totale devozione alla generazione di *codice piccolo*, e
riesce
estremamente bene nel suo intento.  La cosa e` talmente clamorosa che non
ho sentito nessun bisogno di fare misurazioni sistematiche, perche` neppure
i piu` retrogradi nemici di COM, trincerati a difesa del vecchio "codice
monolitico", l'hanno mai messa in dubbio -- basta dare un'occhiata al suo
codice assembler, una delizia per intenditori.
Non vi e` nessun overhead di spazio implicito nell'uso del protocollo COM,
rispetto a quello che imporrebbero normalissime vtable C++.
Alex

 e studiare anche il Coplien!) e` piu` flessibile e potente...
Sono molto curioso di sapere qual'č, secondo il tuo metodo di
apprendimento, la differenza esatta tra "leggere" e "studiare" un testo.
EMG

apprendimento, la differenza esatta tra "leggere" e "studiare" un testo.
Leggere un libro e` semplicemente leggerlo.  Studiarlo significa almeno
due letture, la seconda con un evidenziatore per rimarcare i passaggi
piu` importanti (ho provato a usare anche piu` evidenziatori di diversi
colori, per qualcuno funziona, a me personalmente fa solo confusione);
svolgere tutti gli esercizi proposti e controllare di ciascuno la soluzione;
se vi sono esempi di codice, metterli sul computer e provarli, e inoltre
ispezionarli per garantirsi di avere capito ogni passaggio (provando a
fare varie modifiche ci si puo` assicurare della comprensione); alcuni
trovano inoltre molto utile "schedare" i libri che studiano, riportandone
in poche pagine i concetti essenziali e i principali rimandi al testo, il che
[a] non dovrebbe essere difficile quando, a 2a lettura+evidenziazione
terminata, si ha tutto fresco in testa e [b] puo` essere molto comodo
pochi mesi dopo, quando le cose non sono piu` cosi` "fresche" nella
memoria, per "rinfrescarsela" rapidamente.
Personalmente, penso che circa 1 libro su 10, fra quelli che merita
leggere, valga anche la pena di essere studiato.
Alex

 COM risultano sorprendentemente piccoli; 
Sei sicuro che, mettendo un certo numero di controlli (che so, un centinaio di
TextEdit) su una finestra (poniamo in VC++), e facendo lo stesso su un'altra
finestra, ma usando componenti ActiveX che "inglobano" il controllo, come quelli
usati in VB, non ci sia una significativa differenza nella quantita` di memoria
occupata nei due casi?
Saluti
Paolo

 leggere, valga anche la pena di essere studiato.
Peccato che alcuni, come me, siano dei lettori estremamente lenti. Se si
trovasse il modo di inserire le conoscenze direttamente nel cervello...
EMG

 classe"?
Capisco la tua reazione. E' perfettamente normale. Ma se ci pensi bene
ti accorgi che forse non č generata dalla frase di Alex bensě proprio
dal fatto che quel libro (come me) non l'hai letto mentre senti che
avresti dovuto. Parlando del carattere, pur forse difficile, di Alex, io
preferirei leggere messaggi di tanti come lui piuttosto che di gente
umile, rispettosa ma poco preparata come me. E' da quelli che sto
imparando tante cose nuove da quando seguo questo ng. D'altronde lo
seguo apposta per aiutare e per imparare e non certo per fare i
convenevoli.
Non te la prendere.
EMG

occupata nei due casi?
Ah, pensavo ti riferissi alla dimensione del codice (per la quale, ovviamente,
non importa se di copie di un dato controllo ne hai una, cento, o mille).
Puoi avere overhead, del tutto indipendentemente dal COM, se scegli
di incapsulare un controllo in un oggetto che mantiene propri membri
dati; il COM non ti impone di avere tali membri.  Certo, puo` valere la
pena di decidere di averli, questi dati, per offrire un modo d'uso ritenuto
piu` usabile; ad esempio, in MFC, ogni CWnd (compresa una CEdit)
consuma una mezza dozzina di doubleword a vari scopi, oltre al virtual
pointer tipico del C++ e alla handle-di-finestra; "un centinaio di textedit"
di MFC consumano dunque un paio di KByte di memoria dati in piu` di
quello che consumerebbero se fossero SOLO controlli nativi Windows.
Un controllo ActiveX, anche minimale ma veramente completo, di solito
implementa molte interfacce, e per ciascuna, naturalmente, deve avere
un vptr (esistono oggi vari livelli di controlli piu` "leggeri", naturalmente
con funzionalita` ridotta, ma di solito ce ne si preoccupa solo se il dato
controllo e` fatto per essere trasferito via rete; i controlli fatti per uso
locale sono abitualmente "veramente completi"); esattamente come
dovrebbe averlo, ad esempio, in Fresco, un altro framework GUI ben
noto, basato sul polimorfismo.
Come sempre in C++, l'overhead della _vtable_ e` per-classe, ma
quello del _vptr_ alla tabella stessa e` per-oggetto: un puntatore, per
oggetto, per interfaccia implementata.  Con una decina di interfacce
(*veramente* completo), abbiamo 40 byte per oggetto, 4K per il
"centinaio di text-edit": questo e` overhead, in termini di memoria
occupata, che puoi effettivamente addebitare a COM (o meglio, alla
varieta` di interfacce previste da ActiveX per i servizi piu` vari,
come la persistenza a/da stream, il supporto design-time, ecc;
questa granularita`, che ti costa 4 byte per oggetto per interfaccia,
e` pero` anche quella stessa che ti permette di *alleggerire* un
oggetto, implementando solo le interfacce che davvero servono,
nelle condizioni in cui il costo di questi 32 bit puo` importare
veramente, come appunto il caso di controlli pensati per migrare
qua e la lungo connessioni di rete a bassa velocita`).
In un caso concreto, e` probabile che i due overhead (2K di vari
membri dati per funzionalita` miste assortite; 4K per i vptr; il tutto
sempre per quell'ipotetico dialogo con cento controlli eguali) siano
entrambi presenti, e, sempre in proporzione alle "funzionalita`
supplementari" che si sceglie di fornire, si puo` decidere di
aggiungerne anche altri.  In sostanza, dipende tutto da quanto
"stato" tu, progettista di un dato controllo ActiveX, decidi di voler
associare al controllo stesso, e quanto sei invece disposto a
delegare altrove.  Ad esempio, se vuoi poter lavorare "windowless",
cioe` SENZA una tua window ma in un riquadro rettangolare
definito entro una altra window "ospite" (un modus operandi che,
in certi casi, puo` portare a miglioramenti di prestazioni davvero
importanti), allora inevitabilmente dovrai mantenere nel tuo controllo
tutti quegli elementi di stato che normalmente Windows associa a
ogni finestra (tutti quegli indicatori che puoi recuperare o modificare
con GetWindowLong/SetWindowLong, per intenderci), cosi` come
non potrai fare affidamento su "window procedure" standard o
comunque predefinite (common controls, ecc ecc).
Ma il gioco puo` valere la candela; la scelta e` in mano al
progettista del controllo.  Al giorno d'oggi, solitamente, non si
considera che, per risparmiare, in un esempio come quello
da te portato (cioe`, un dialogo molto piu` ricco di controlli
della media), qualche KByte di memoria a runtime, meriti
ridurre sostanzialmente le funzionalita` messe a disposizione
(ricche interfacce di persistenza, gestione completa delle
proprieta`, e cosi` via).
Faccio notare che l'overhead implicito nei controlli (o bean
che dir si vogliano) dell'AWT di Java 1.1, e ancor piu` nello
Swing di Java 2, e` abbastanza analogo a quello intrinseco 
ai controlli ActiveX; non e` un caso, infatti, che la macchina
virtuale Microsoft sia in grado di presentare, a qualsiasi
codice-cliente Java, qualsiasi ActiveX "come se" fosse un
Javabean, e, a qualsiasi codice-cliente COM, qualsiasi
Javabean "come se" fosse un controllo ActiveX, in ambo i
casi senza sostanziale aggravio nel consumo di memoria;
le informazioni di stato, e gli overhead infrastrutturali (vptr,
in pratica), sono infatti sostanzialmente congruenti (e quindi,
ovviamente, lo e` anche il consumo di risorse di memoria).
Alex

 Non te la prendere.
Non me la prendo :-)
Saluti
Paolo

 riferirsi ad un C++ non più attuale.
Perfetto ragazzi!
Ancora una volta grazie mille ad entrambi, ma... io l'inglese lo sto
ancora imparando! :)
Ne so troppo poco per acquistare un libro scritto in inglese...
sicuramente pero' provero' a scaricarmi la versione free in inglese!
Ma la carta poi?
Torniamo sempre allo stesso punto... un buon libro in italiano?
Uhm, ancora grazie e scusate l'insistenza!


 argomenti.
Puň essere, ma a me le citazioni fanno un altro effetto. Mi fanno
sembrare il discorso, come dire, piů "solido", mi sembra come se assieme
a noi stessero partecipando al discorso i "luminari" dell'informatica. E
poi il fatto di poter andare a controllare sui testi citati che quello
che viene detto č corretto mi fa stare piů tranquillo. Forse sbaglio
atteggiamento?
EMG

"perche` non ha l'eredita`", 
Un orientamento alla aggregazione come soluzione assoluta a tutti i
problemi che e' insopportabile (o COM o morte), mancanza di controllo
sui tipi nelle collection, l'impossibilita' di passare tipi
predefiniti come parametri di funzioni pubbliche di classe, un
eredita' che non aiuta il programmatore, mancanza di interfaccie
astratte, mancanza dei template (cosa aspettano ad aggiungere i
template?) .
Se ci tieni tanto alle affermazioni *corrette*, cambia l'affermazione
del Carneide in: "O creduto di vedere cio' che e' possibile fare in
C++, e sono dell'opinione che l'orientamento alla programmazione ad
oggetti del VB e' insoddisfacente". Tanto il senso delle parole e'
quello.

 Posix.  
Lo stdio esiste da molto prima dello standard Posix ed era costruito
inizialmente sopra quelle che allora erano semplicemente le chiamate di sitema
Unix. Mi riferivo alle funzioni dello stdio che provvedono allo i/o
bufferizzato; anche se la bufferizzazione non e` compresa in Unix (e in Posix),
astraevo da tali particolari,
dato che il succo del discorso era banalmente che il C, amplificando il suo
carattere di "linguaggio scarno" e di "basso livello", avrebbe (per ipotesi)
potuto non prevedere una libreria standard per l'i/o, richiedendo quindi l'uso
diretto della chiamate di sistema o
quello di librerie non standard, il che avrebbe ridotto parecchio la sua
portabilita`. Dicevo questo giusto per rendere l'idea di uno dei motivi per cui
ritengo utili le librerie Java, e riterrei utile qualcosa del genere anche in
C++.
Saluti
Paolo

 atteggiamento?
Non direi. Non c'e` nulla di sbagliato nelle citazioni in se`. Tutto dipende ca
COME e A QUALE SCOPO queste citazioni vengono usate. Se usate nel contesto
dell'esposizione di certe tesi o teorie, o quant'altro, per consentire ai
partecipanti alla discussione di approfondire certi temi, ben vengano.
Saluti
Paolo

 impedire la diffusione e la crescita di una reale cultura.
Basti pensare alla "casta" dei medici. Il tuo discorso si attaglia, mi
sembra, perfettamente a loro. Ma non ne trovo, invece, rispondenza nel
mondo dell'informatica, forse anche a causa del fatto che il materiale
conoscitivo informatico circola molto più facilmente di quello medico
(mai visto un cadavere da sezionare on-line... :-))) ).
EMG

 (mai visto un cadavere da sezionare on-line... :-))) ).
Non solo, ma nell'informatica le parti "oggettive" sono piu` rilevanti che nella
medicina, e il grado di complessita` dell'oggetto di studio non e` paragonabile.
Tuttavia, discorsi e atteggiamenti come quelli che criticavo, rischiano
ugualmente di instaurare anche nell'informatica, certo in misura minore, una
situazione di quel genere.
Saluti
Paolo

 e il grado di complessita` dell'oggetto di studio non e` paragonabile.
Non sono d'accordo: l'informatica ad un certo livello è molto ma molto
più complessa di tutte le tecniche di abilità manuale dell'alta
chirurgia. Il problema è che molti programmatori non hanno neanche il
sentore che esista questa complessità né hanno la curiosità di andare a
vedere cosa offre (leggendo, ovviamente...).
EMG

 Salve ragazzi...
[...]
Ehi, volevo ancora una volta ringraziare tutti e... ho cercato nei
limiti del possibile di seguire il resto dei post, ma ci ho capito
davvero poco!
Per il momento quindi sono costretto a lasciare il gruppo, ancora grazie
a tutti!
