Newsgroup: it.comp.lang.c++
Titolo: Chiamare metodi C++ da un programma C

Salve a tutti.
Vorrei sapere se e' possibile chiamare metodi C++ da un programma C.
Supponiamo di avere il seguente programma C++:
class A {
public:
   void A() {
        count=0;
   }
   void inc() {
        count++;
   }
   void print() {
        cout << count;
   }
   int count=0;
};
I metodi "print" e "inc" devono poter essere chiamati da un programma C
compilato con gcc.
C'e' un metodo per far questo?
Grazie mille per l'aiuto.
Giovanni Perbellini
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Vorrei sapere se e' possibile chiamare metodi C++ da un programma C.
Puoi rendere una FUNZIONE C++ (NON un *metodo*) richiamabile da
*CODICE* C linkato assieme alla funzione C++ (NON da "un programma",
intendendosi un programma separato), usando
        extern "C"
L'unico modo di "rendere chiamabile un metodo" da C e` fornire in C++
una funzione ausiliaria che prende fra i parametri l'oggetto su cui il
metodo stesso va chiamato.
Gli standard C e C++ non prevedono alcuna modalita` di "chiamare
funzioni" fra programmi separati; qui si va sul tema dell'IPC (Inter-
Process Communication ovvero Inter-Program Communication a
seconda di chi interpreta la sigla) che esula dal tema di questo
gruppo (Corba e altri schemi di RPC offrono queste possibilita`, ma
non so su quali gruppi se ne discute; non qui, perche` qui si parla
solo di C++ standard e lo standard di questi temi non si cale).
Alex


Corba ed RPC non fanno parte di  cio che comunemente si intende con il
termine IPC,in quanto appunto le IPC sono uno strumento per condividere
informazioni tra diversi processi all' interno della stessa macchina,
mentre Corba e' uno standard nato per  faciltitare la comunicazione di
vari processi in  ambienti distribuiti.
--
Ivan Molella
__LINUX__ the choice of the  __GNU__ generation

vari processi in  ambienti distribuiti.
Falso.  
IPC = Inter Process Communication = Comunicazione tra
processi.  Non allude a niente che sia solo locale.
Le mail-slot e le pipe, sotto Windows, per esempio, sono
meccanismi di IPC e non si limitano alla comunicazione su
una sola macchina.
-- 
Andrea Laforgia - walkietalkie(at)
libero.it
"Meglio cieco che negro" (Stevie Wonder)

 vari processi in  ambienti distribuiti.
E qui dai lezioni a quei novellini del Cern, ad esempio, che invece a
http://wwwinfo.cern.ch/pdp/as/linux/gnome/gnome_kde/comparison/corba/ipc.html
dicono "CORBA is an IPC standard based on OO"; a Scott Metzler di
Caltech, che a 
http://chep2000.pd.infn.it/pres/pre_d290.ppt
 "CORBA is 
useful for IPC"; Ed Freeborn, che parla in
http://www.public.asu.edu/~image/PUBs/ABSTRACTS98/Freeborn.html
di "synchronous vs asynchronous CORBA IPC"; e, anche qui, altre
centinaia o migliaia di autori, visto che tante presentazioni sul KDE e/o
GNOME, come quella suddetta del Cern, spiegano come l'uno o
l'altro di questi ambienti usino "il Corba per l'IPC".
IPC significa comunicazione fra processi (o, secondo alcuni secondo te
insensati, fra programmi) e non implica affatto che questi processi si
debbano trovare sulla stessa macchina.  Corba e` nato per facilitare la
comunicazione OO, senza limiti di scalabilita` distribuita ma certo senza
neppure impedire che gli oggetti si trovino (generalmente in processi
[o programmi?] diversi:-) sulla stessa macchina.  Alcuni ritengono che
Corba abbia overhead eccessivo per questo, ma tanti altri non la
pensano cosi`, ad esempio i progettisti di Gnome hanno scelto di
usarlo come IL meccanismo IPC di Gnome (anche se la maggior
parte dei programmi, o processi, che devono comunicare entro un
ambiente di desktop sono tipicamente sulla stessa macchina).
In altri termini, mi pare che entrambi i tuoi appunti critici al mio post 
siano inesatti, ma questo secondo, in particolare, lo sia davvero tanto.
Alex


Il tipo che ha postato il messaggio mi sembra utilizzasse il compilatore gcc,
da cui ho desunto che si trovasse a lavorare su un sistema operativo Unix/Unix
like,magari Linux ,i cui processi interagiscono tramite le IPC dal sistema
operativo supportate,in questo caso le IPC modello system v che non prevedono
meccanismi di comunicazione interprocesso distribuiti.


meccanismi di comunicazione interprocesso distribuiti.
Ti ricordo che hai parlato di cio' che "comunemente" si
intende con il termine IPC e il tuo discorso esula, quindi,
da una piattaforma specifica.  CORBA non riguarda solo
UNIX/Linux ed e' *comunemente inteso* come uno standard di
IPC.  Punto.
-- 
Andrea Laforgia (
walkie...@libero.it
)
"Usenet is a strange place" [Dennis Ritchie]


Io Corba non lo assimilo alla famiglia delle IPC ma bensi' alla famiglia delle
RPC dato si che il suo scopo e' appunto quello di facilitare la comunicazione OO
in ambienti distribuiti.
Ora tu puoi anche venirmi a dire che quelli di Gnome hanno pensato di scegliere
un protocollo  come Corba per gestire l'interazione tra i vari processi  locali
al sistema,ma cio non significa che questa non sia stata una scelta inappropiata.


 IPC.  Punto.
Il mio riferimento era relativo al modello classico di IPC comune agli ambienti
Unix.


 Io Corba non lo assimilo alla famiglia delle IPC ma bensi' alla famiglia
Non e` questione di "assimilare" o di famiglie.  "CORBA is an IPC standard 
based on OO": Corba e` uno standard di IPC basato sull'OO.  Il fatto che
si possa usarlo in modo distribuito non gli impedisce certo di essere uno
standard di IPC!  Sia i fatti sia migliaia di documenti lo dimostrano.  
Dunque, un'altra critica priva di solido fondamento.
Alex

 wrote:
:
: >Comunicazione tra programmi sta a Comunicazione tra processi come la
: >definizione di Programma sta a definizione di Processo.
:
: Questa me la scrivo.
Io la condivido, ci sono problemi di comunicazione anche tra diverse
'istanze' dello stesso programma, poco a che vedere con la chiamata di
metodi c++ da programmi in c. La soluzione come la chiameresti
Intra Program Communication o
Inter Program Communication o
Inter Process Communication ?
ciao
Massimo

 Dettato da chi, se non dall'uso?
Stiamo discutendo sul sesso degli angeli, penso che siamo andati abbastanza OT.


 Unix.
E io ti ho detto che non e' cio' che comunemente si intende
per IPC.  Non far finta di non capire.


 'istanze' dello stesso programma
Discutere della differenza tra programmi e processi e',
onestamente, una stupidaggine, cosi' come e' stupido
formalizzarsi su "Program" o su "Process", in IPC.


 formalizzarsi su "Program" o su "Process", in IPC.
Perfettamente d'accordo.  Comunque, FWIW, le "single Unix
specifications" che definiscono cosa e' Unix (vedi la URL
http://www.opengroup.org/onlinepubs/007908799/toc.htm
) ad
una ricerca della keyword 'ipc' rispondono con:
        ipcrm - remove a message queue, semaphore set or shared
        ipcs - report inter-process communication facilities status
        ftok - generate an IPC key
        sys/ipc.h - interprocess communication access structure
da cui mi parrebbe evidente che la 'P' stia per 'process'.  YMMV.
-- 
Maurizio Loreti - CERN Division PPE (CMS) - CH 1211 Geneve 23 - Switzerland
Office: 40 3-B32 - Tel.: 
+41 (22) 767-1551
 - EMail: 
maurizi...@cern.ch
Home: University of Padova (Italy) - 
http://www.pd.infn.it/~loreti/mlo.html