Newsgroup: it.comp.lang.c++
Titolo: Compatibilita' nei due sensi...

Cioe':
supponiamo di avere una libreria di funzioni C, che operano su delle
strutture.
ad esempio
void lib_struct_new(const struct& struttura, <parametri>);
void lib_struct_set_param1(const struct& struttura, <nuovo valore>);
eccetera.
supponiamo di voler portare la libreria in c++, cosi'
class struttura{
    // ....
    public:
    struttura(<parametri>);
    void set_param1(<nuovo valore>);
    // ...
};
Non si vuole mantenere codice C, percio' escludiamo le classi wrapper,
tanto  la libreria va riscritta ex novo in C++.
Non si vorrebbero scrivere funzioni wrapper per il C, per non andare a
modificare include etc... dei programmi C gia' esistenti, e che debbono
essere tenuti aggiornati mentre vengono sviluppati i successori in C++.
come si puo' risolvere?
Si deve mantenere per forza le libreria C e sviluppare quella in C++, senza
poter cominciare gia' ad utilizzarla nei vecchi programmi?

 poter cominciare gia' ad utilizzarla nei vecchi programmi?
Se non vuoi scrivere funzioni wrapper come lib_struct_new, eppure per
vincolo devono esistere, allora devi continuare a usare le vecchie, e
questo sillogismo mi pare lampante.
Cos'e` che non ho capito...?
Alex

 wrote in message
8l1rls$s7t$1...@serv1.iunet.it...
[...]
| > Non si vorrebbero scrivere funzioni wrapper per il C, per non andare a
| > modificare include etc... dei programmi C gia' esistenti, e che debbono
| > essere tenuti aggiornati mentre vengono sviluppati i successori in C++.
| Questa non la capisco.  Se non si vogliono modificare per nulla i
| programmi C gia` esistenti, compresi gli include, essi chiameranno
| lib_struct_new, ecc, e quindi funzioni cosi` chiamate (ed extern "C")
| devono esistere.  "Non si vorrebbero scrivere"?  E allora come
| fanno ad esistere?
Perche' che fine fanno poi gli oggetti creati dalle funzioni wrapper? li
restituisco come puntatori a struct? e visto che allocano dinamicamente
memoria (gli oggetti, non le strutture), i distruttori vengono chiamati "in
ogni caso"? quanto sarebbe type safe ritornare un
[reinterpret | dynamic | static]_cast<struct struttura*>? molto poco...
almeno credo.
Capito il perche' vorrei evitarlo? ho usato il condizionale apposta
Ma mi sa che devo farle 'ste funzioni...
| Se non vuoi scrivere funzioni wrapper come lib_struct_new, eppure per
| vincolo devono esistere, allora devi continuare a usare le vecchie, e
| questo sillogismo mi pare lampante.
gia', e infatti prima di cominciare, voglio essere sicuro che non c'e'
altro metodo...

 almeno credo.
L'idioma "puntatore a struct che non ti dico come e` fatta dentro",
detto piu` concisamente "token", e` comune in C, e si puo` benissimo
usare a questo scopo.
Dal punto di vista del C apparira` qualcosa come:
    typedef struct misteriosa* handle;
dove handle e` il tipo passato alle varie lib_struct_boh.
In C++, avrai da qualche parte
extern "C"
{
    struct misteriosa {
        // contiene envelope, smart-pointer, o
        // che altro serva, alla class che si usa
    };
    void lib_struct_buttavia(handle);
    // ecc ecc
}
che implementa questa roba.
Alex

 wrote in message
[...]
| In C++, avrai da qualche parte
|
| extern "C"
| {
|     struct misteriosa {
|         // contiene envelope, smart-pointer, o
|         // che altro serva, alla class che si usa
|     };
|
|     void lib_struct_buttavia(handle);
|
|     // ecc ecc
| }
|
| che implementa questa roba.
Rileggendo la bibbia dei pattern, ho risolto, per ora solo a livello di
design, ma non vedo buchi:
Command per gestire la libreria C++
Proxy per ritornare e gestire i giusti riferimenti.
Che ne pensi?

 Che ne pensi?
Passo, perche` il mio "Design Patterns" e` in prestito permanente:-).
Alex