Newsgroup: it.comp.programmare.win32
Titolo: COM

Sto scrivendo un tutorial su COM. Si può dire che i metodi sono
l'equivalente delle funzioni virtuali in C++ ? E' corretto ?
Ciao
Grazie

 wrote in message
news:8870bs$fsp$1...@nslave1.tin.it...

Mi sembra un po' una forzatura, dato che COM di fatto non supporta
l'ereditarieta` (almeno non in senso "stretto").
... I am free of all prejudice. I hate everyone equally.
---
Bye! Lorenzo Lutti
http://www.geocities.com/SiliconValley/Peaks/6258/

 l'equivalente delle funzioni virtuali in C++ ? E' corretto ?
Si`, e` abbastanza corretto.
Alex

 l'ereditarieta` (almeno non in senso "stretto").
Guarda che la supporta benissimo. la Vtbl del file COM č uguale a quella
che crea qualsiasi classe del C++. Ho dei seri dubbi comunque che si
possano dopo aggiungere variabili alla classe cosě ottenuta, ma per
quanto riguarda funzioni (anche virtuali) si puň fare.
Per poter accedere sia alle funzioni virtuali di un COM che poter avere
una classe con vita propria, invece č impossibile se non includere la
struttura *Vtbl nella propria classe, ma dopo l'accesso ai membri non č
piů tanto virtuale...
Bisogna fare delle prove.

Guarda che la supporta benissimo.
Per quel poco che ho letto, non mi pare che COM supporti l'ereditarieta`
(proprio per scelta dei suoi ideatori). E` invece simulata tramite
contenimento e con opportuni meccanismi.
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 contenimento e con opportuni meccanismi.
COM non supporta la eredita` *DI IMPLEMENTAZIONE*; non puoi
cioe` esprimere in COM un discorso come "questa co-class 'eredita'
da quest'altra co-class".
COM supporta l'eredita` *DI INTERFACCIA*, cioe` puoi benissimo
esprimere il concetto "questa interfaccia eredita da quest'altra"; in
IDL,
    [ object ]
    interface IPippo: IPluto {
        // _aggiungi_ metodi e proprieta` -- tutte quelle
        // di IPluto sono gia` implicitamente incluse
    }
*Attenzione* che "eredita`" non implica qui necessariamente
"conformabilita` polimorfica" (non lo implica neppure in C++,
naturalmente: in quel caso, e` solo una *pubblica* eredita`
che deve necessariamente, fra le altre cose, comportare la
conformabilita` polimorfica).
In altri termini, una co-class che sceglie di implementare la
interfaccia IPippo *non e` tenuta* a permettere l'accesso
anche alla sua interfaccia IPluto; *puo`*, selettivamente,
farlo (nella sua QueryInterface), ma puo` anche scegliere
di non farlo (rispondendo E_NOINTERFACE alle richieste).
Sostenere che questo significa che in COM l'eredita` "non
e` supportata, ma simulata" ha piu` o meno lo stesso
significato che fare asserzioni del tutto analoghe relative
a Smalltalk, Python, Eiffel, e altri linguaggi/modelli ad
oggetti: implica, cioe`, che il modello dell'eredita` che il
C++ sceglie di dare e` "l'unico e solo" ad essere "vero",
e tutti gli altri, "pallide imitazioni".
(Notiamo che anche in Eiffel, esplicitamente a compile
time, e in Smalltalk e Python, implicitamente a run-time,
si puo` inibire l'accesso da parte di codice-cliente alle
classi da cui quella corrente eredita, anzi, nel caso di
questi linguaggi, si puo` farlo anche selettivamente,
metodo per metodo e proprieta` per proprieta`, mentre
in COM la granularita` e` quella dell'intera interfaccia).
Alex

 e tutti gli altri, "pallide imitazioni".
Non esagerare, nessuno ha mai fatto affermazioni del genere. Pero` e`
anche vero che se diversi grossi autori fanno un distinguo fra
"inheritance" e "containment", un qualche motivo ci sara`.
Di certo il C++ (e Java) danno un'interpretazione piu` "pura", almeno
concettualmente, di ereditarieta`: in un certo senso e` l'intero oggetto
ad essere ereditato, e non soltanto la descrizione delle sue interfacce.
In ogni caso il problema di base mi sembra un altro: il C++ e Java sono
linguaggi di programmazione, e si basano anche su concetti astratti. COM
e` uno standard (sempre che una cosa della M$ si possa chiamare cosi`)
di interfaccia. Anche se esistessero delle analogie fra funzioni
virtuali del C++ e interfacce COM, mi sembra un po' aberrante paragonare
due cose fondamentalmente diverse.
... If you're not confused, you're not paying attention.


 più tanto virtuale...
E` proprio questo il punto. Tu devi "duplicarti" tutte le interfacce,
che a sua volta poi chiameranno (ereditarieta`) o estenderanno
(polimorfismo) quelle dell'altro oggetto.
Comunque non ho una conoscenza abbastanza buona di COM per fare
affermazioni "definitive", e in ogni caso non avevo alcuna intenzione
polemica. Semplicemente mi sembra un po' forzato associare una
caratteristica peculiare di un linguaggio con una caratteristica
"tecnologica" di un modello di interfaccia.
... Useless Invention: Braille tv guide.


 due cose fondamentalmente diverse.
Ti consiglio di spiegare bene perche` e percome questo e` aberrante al
gruppo di lavoro X3H7 dell'ANSI (American National Standards Institute),
che, non sapendo, poveretti!, di questa tua tranciante opinione, hanno
invece lavorato per quattro anni proprio a paragonare questo tipo di
"cose fondamentalmente diverse".  Vedi 
http://www.objs.com/x3h7/h7home.htm
per una descrizione di X3H7, 
http://www.objs.com/survey/objmodel.htm
 per
un buon articolo che riassume i risultati.
Specificamente, il gruppo X3H7 analizzo` e paragono` i seguenti object
model:
    Analysis and Design Methods, C++, Cecil, Component Object Model (COM and
OLE 2),
    OO COBOL, Eiffel, Emerald, EXPRESS, Management Information Model,
Matisse, ODMG,
    OMG CORBA IDL, OMG Core Object Model, OODB Task Group Reference Model,
Open
    Distributed Processing, SELF, Smalltalk, SQL3, and System Object Model
(SOM).
Nota la mancanza di Java, giustificata dal fatto che il rapporto fu
pubblicato
nel 1996.  Il punto fondamentale, comunque, e` che gli object model di vari
linguaggi di programmazione (C++, Eiffel, Smalltalk, ecc), vari standard di
interfaccia (COM e OLE 2, Corba [IDL e Core], SOM, ecc), vari standard di DB
a oggetti (SQL3, ODMG, OODB TGRM, ...), e anche quelli di puri e semplici
metodi di analisi e progetto!, possono e _devono_ essere paragonati fra loro
per fare anche solo i primi passi nel campo dell'"Object Information
Management", la nascente disciplina che X3H7 nacque appunto per aiutare
ad inquadrare... altro che "aberrante"!
Alex

 "tecnologica" di un modello di interfaccia.
Se questo e` un altro modo di esprimere quanto dicevi nel tuo
altro post, che ritieni "un poco aberrante" paragonare gli object
model che emergono da tecnologie ben diverse (linguaggi, data
base, standard di interoperabilita`, ...) non posso che ribadire il
totale dissenso (mio e dell'American National Standards Institute,
ANSI:-) rimandando ancora alle URL gia` citate.
Alex

 terza persona :)), non penso di possedere la verita`.
Io si`, nell'ambito di domini di discorso ben delineati; ad
esempio, nelle condizioni in cui valgono gli assiomi di
Euclide, "possiedo" la importante verita`che la somma
delle aree dei quadrati costruiti sui cateti equivale all'area
del quadrato costruito sull'ipotenusa dello stesso triangolo
rettangolo.
Se, come hai appena detto, tu NON pensi di "possedere"
neppure questa verita`, posso consigliarti di ripassare un
poco la geometria elementare: puo` dare molte soddisfazioni.
Similmente, potresti studiare un poco di informatica, ed
arrivare a "possedere" certe verita` in specifici ambiti di
essa.
O _anche_ nel caso di questa affermazione bisogna invece
pensare che tu ti sia espresso senza precisione?-)
Alex