rilevante

Il 27/01/2012 21:36, Archaeopteryx ha scritto:
> Il 27/01/2012 15:28, Soviet_Mario ha scritto:
>
> In effetti quando scrivevo alla fine che sapevo che era in
> questione altro, è a quel che dici che implicitamente mi
> associavo.
>
> Lo so che il C++ ha tutto quel che ha il C ma per me, dico
> solo per me, senza pretesa di dare validità generale, di
> fatto la differenza c'è stata. Se avessi usato il C++ c'è
> poco da fare, avrei usato le comodità della STL, e un
> sacco di altre comodità del C++ con cui potevo modellare
> assai meglio il mio problema. Qualche tentativo pilota ha
> mostrato che il codice cresceva a dismisura. Voglio dire,
> il C mi ha costretto a essere conciso riformulando,
> rinunciando a certe caratteristiche che volevo
> implementare e così via.

mah, non so. Imho è una diffidenza un po' esagerata. Anche
con la STL rimane un linguaggio abbastanza spartano.
Te lo dico da recente NET-addicted. Lì si che impari a
viziarti e impigrirti usando tutto il prefabbricato possibile :)
Capirei di più le remore che dici se parlassi di Java.
Cmq, alla fine il tuo sw era scientifico ed essenzialmente
di calcolo numerico : non è certo il contesto in cui il C++
faccia valere le maggiori potenzialità sul C.
Mi dicono (dottoranda in fisica teorica) che per programmi
schiettamente scientifici si usa persino ancora il FORTRAN.

> Ho "scoperto" che quando hai un
> linguaggio più potente è perché o serve (e allora il
> codice cresce per un motivo) oppure ci si adagia sulla sua
> potenza allentando il controllo sulla concisione e il
> senso della misura, e allora il codice cresce per un'altra
> ragione. Ma è solo "colpa" mia, lo so.

più che altro credo che il tuo tentatore fosse STL, non
tanto il C++ in sé e per sé. Io non l'ho mai usata
praticamente. Credo che le tue necessità ricadano nella
categoria che avevo definito molto rara, in cui i bisogni
sono così tecnici, specifici e necessitanti di efficienza
estrema, in cui le routine GENERICHE, per quanto testate e
ottimizzate, non possano rivaleggiare con codice ad hoc.
OVviamente è un caso che presuppone anche una notevole
specializzazione e competenza per scrivere un ottimo codice
proprio, cosa che è il caso.
Quindi, LOL, nell'anomalia del caso non fai tanto testo :-)
eh eh he

>> Il compilatore esiste, ma su certi hardware il compilatore
> è targettato esattamente su quello. Una ditta che li fa
> che manco ricordo quale sia (mi pare AVR) vende un
> compilatore diverso per ogni processore e mi pare di
> ricordare che il C++ fosse addirittura fuori budget
> rispetto al C.
>
> Insomma se si esce dal mondo ideale platonico in cui il
> C++ *può* funzionare esattamente come il C, vengono in
> essere mille vincoli mentali, economici, di fattibilità e
> così via. Pensa solo che quando si "toccano" gli ultimi 5k
> liberi della ram del processore su cui ho lavorato,

e anche questo non è tanto comune su computer "classici".

> il
> compilatore comincia a produrre codice buggato (relata
> refero, ma forse ho pure toccato con mano). Magari il C++
> non lo fa, chi sa.

mah ... che problemi erano grossomodo ? Crashava lo heap
manager ? Collisioni dello stack ?

>
>> a questo punto mi incuriosisce sapere che tipi di
>> programmi sviluppi e su che hardware ... controllo
>> numerico ? Cosa ?
>
> Una dispositivo biomedicale; in sostanza si è trattato di
> implementare un modello biofisico. Ma adesso non ci voglio
> pensare perché il modello ora in commercio è arrivato nel
> momento peggiore, di recessione;

azz, mi spiace ... e dire che il settore sanitario è in
teoria noto come uno degli anti-ciclici per antonomasia.
Ma forse sono retaggi da stato-vetero-sociale che vanno
evaporando. Quando la sanità sarà a tutti gli effetti
un'azienda pari alle altre, e la salute una merce pari alle
altre, la recessione non risparmierà la sanità come accadeva.

> si vende poco e sono
> depressissimo. Come tutti gli esseri umani sarei contento
> di vedere il mio lavoro apprezzato da critica e mercato...
> :( Si stava pensando alla serie successiva ma la vedo
> difficile. Magari ti dico di più in prv per non rompere le
> scatole qua.

dai racconta
non so se hai ancora la mail, cmq una che va è

pasquale__esposito


>
> Comunque implementare l'integrazione di eq.
> differenziali usando l'aritmetica intera è stata una bella
> sfida

belin immagino !

> :D e son contento di esserci riuscito; letteratura
> ce n'era pochissima.
>
> ciao!

ciao a te
Soviet

Soviet_Mario <Soviet.Mario> wrote:

> però se è proprio quella complessità che riesce a
> permetterti di affrontare modelli molto complessi, a me pare
> inscindibile dall'aspetto buono.

No. Io trovo che sia complessita' che, puro e semplice, ti complica il
problema.

>
> A me capita spesso di voler portare routine dal C++ al
> visual basic (e un tempo al pascal) : ogni volta il codice
> si intrica all'inverosimile, perchè quei linguaggi "più
> semplici" non supportano le stesse cose incasinate.

Visual Basic non e' un linguaggio semplice o complesso: e' un linguaggio
schifoso. Il *nuovo* pascal e' ugualmente potente (in essenza) di C++ ed
e' anche grosso modo ugualmente complesso. Alcune cose sono un pelo piu'
semplici, altre un pelo piu' complicate. Rimane molto piu' facile e
veloce da compilare... fine.

> (ad es. non so perché in NET abbiano implementato solo
> l'ereditarietà singola, ma tant'è è stata quella la scelta,
> e anche delle classi semplici ma interdipendenti ti
> costringono a creare tutta una sfilza di contenitori inutili
> e un comune ancestor che non serve a niente altro che a
> rettilineizzare ... e fa cmq pena).

L'ereditarieta' singola di implementazione mi sembra una cosa molto
sensata. Pensa al bel macello che introduce in C++.

Uso molto di rado l'ereditarieta' in qualunque linguaggio: dal punto di
vista dell'ingegneria del software introduce uno dei livelli di
accoppiamento piu' elevati fra due classi. Disaccoppiare e' bene.

La maggior parte dei design pattern basati su ereditarieta' (di
implementazione) ne hanno versioni piu' semplici ed efficaci che non ne
fanno uso.

In Python e in C++ ho ereditarieta' multipla: non l'ho praticamente mai
utilizzata, per scelta. La uso (in C++) perche' ci sono classi che
logicamente si comportano come interfacce, o al piu' interfacce
cicciose. E in questi casi la mancanza non e' davvero letale.

> poi non conosco abbastanza altri linguaggi per dire se
> riescano a unire la stessa potenza ma in modo più semplice,
> da poter dire più di questo.

"Potenza"? Non e' una macchina. ;)

Carlo Milanesi <carlo.nospam.milanesi> wrote:

> Io penso invece che abbia senso chiedersi quali tipi di software si
> possano sviluppare con un dato linguaggio.

Possibile... ma e' una cosa che ha davvero senso? Alla fine, sulla mia
esperienza, nella maggior parte delle cose la faccenda dipende piu' che
altro dalla presenza di librerie.

I casi in cui sia una questione di implementazione sono un pochetto piu'
frequenti (per esempio usare qualcosa con una fase di compilazione
esplicita puo' essere molto scomodo in determinati contesti -- pensa al
web --; viceversa usare qualcosa che *non* abbia un eccellente
ottimizzatore e' scomodo in altri contesti -- a meno che non ci siano le
famose librerie di cui sopra --).

Il caso in cui sia proprio il linguaggio vero e proprio il limite sono
rari. E ancor piu' rari se parliamo di linguaggi relativamente vicini
come C o C++.

> Principalmente, perche' per produrre del software con un linguaggio
> serve un sistema di sviluppo (compilatore o interprete, e librerie), e
> per ogni coppia piattaforma-linguaggio di programmazione, possono
> esistere zero o più compilatori decenti.

Sono assolutamente d'accordo: ma qui non parliamo piu' di tipologie di
software. Parliamo di specifiche implementazioni su specifici sistemi.

> Secondariamente, per una coppia piattaforma-linguaggio di
> programmazione, pur essendo possibile sviluppare del software,
> potrebbero esserci svantaggi di vario tipo, come l'inefficienza
> inaccettabile, la carenza di documentazione o di librerie, la
> difficolta' di trovare persone da assumere, la penuria di articoli,
> libri, blog, forum, corsi che trattino l'argomento.

Assolutamente d'accordo. Ma, a mio avviso, fra C e C++ questo tipo di
considerazioni non si applicano davvero.

enoquick <enoquick> wrote:

> Non si puo, ma visto che i template in C non esistino, non si perde
> nulla rispetto al C

Il punto non e' questo, no? Vedi sotto.

> extern "C" non significa che il codice sia C,ma che la convenzione di
> chiamata è C

No, non significa nemmeno questo. Le convenzioni di chiamata sono una
cosa *diversa* (in realta' completamente slegata e ortogonale),
tipicamente dipendente dalla piattaforma (sebbene su certe piattaforme
convivano piu' convenzioni di chiamata) non e' parte del linguaggio
(ovviamente, visto che tratta qualcosa che sta sotto), ma si puo'
tipicamente specificare tramite opportuni flags.

extern "C" significa solo che la specifica di linkage e' C. E tante
delle cose belle che C++ consente di fare se na vanno in questo caso.

> E' possibile costruire una classe C++ in un wrapper a extern "C" e
> buttare il tutto in una libreria perfettamente usabile anche da altri
> compilatori.

Qui non e' chiaro cosa intendi con wrapper. Comunque, per farla breve
tutto quello che non riguarda il linking (ovvero quello che succede
*dentro* una funzione) e' piu' o meno safe. A parte che fare uscire
un'eccezione non sarebbe salutare.

> E visto che anche qui, il concetto di classe non esiste in C
> non si perde nulla rispetto al C

Quindi cosa abbiamo concluso? Che essenzialmente usando C++ come fosse C
e rinunciando alle "innovazioni" possiamo farci linkare facilmente da
fuori?

Gia'... scrivendo C in C++ possiamo fare proprio questo.

Il problema e' che scrivere una libreria in C++ moderno (che e' quello
che vorrei fare se scelgo di usare C++ invece di C, come dicevo, se devo
usare C++ grosso modo come userei C, faccio a meno) diventa un problema
se la si vuole usare da qualcosa che non sia C++.

In particolare e' un problema su cui mi sono scontrato: fare un API
essenzialmente C sopra una bella libreria C++ che faccia massiccio uso
di templates, tecniche "moderne" (di 10 anni fa) tipo le policy e
compagnia e' essenzialmente un bagno di sangue. Fine della storia: e'
qualcosa che funziona su cose molto piccole, molto poco C++ oppure come
estrema ratio.

Semmai funzionano meglio oggetti come swig (con tutto il macello che si
porta dietro) per semplificare il boilerplate. Ma non mi sembra di dire
nulla di sconvolgente, sono cose note a tutti.

E la mia posizione e' che per scrivere qualcosa che voglio chiamare dal
resto del mondo, se devo scegliere fra scrivere del cattivo C++ o
dell'ottimo C, preferisco semplicemente scrivere in C. Scrivere
dell'ottimo C++ semplicemente non e' un'opzione per come funzionano oggi
le cose.

Il 28/01/2012 17:10, Enrico Franchi ha scritto:
> enoquick<enoquick> wrote:

Ammetto che sei stato molto convincente :)
Purtroppo finirò per dimenticare le tue argomentazioni,
perchè non ho mai l'esigenza pratica di dover realizzare
librerie usabili da terzi.
CUT

> Semmai funzionano meglio oggetti come swig

per curiosità, di cosa si tratta ? Non conosco questo
acronimo o nome o quel che è. Se si può accennare in due parole.

ciao
Soviet
[..]

Il 28/01/2012 17:10, Enrico Franchi ha scritto:
> enoquick<enoquick> wrote:
>> Il punto non e' questo, no? Vedi sotto.
>> No, non significa nemmeno questo. Le convenzioni di chiamata sono una
> cosa *diversa* (in realta' completamente slegata e ortogonale),
> tipicamente dipendente dalla piattaforma (sebbene su certe piattaforme
> convivano piu' convenzioni di chiamata) non e' parte del linguaggio
> (ovviamente, visto che tratta qualcosa che sta sotto), ma si puo'
> tipicamente specificare tramite opportuni flags.
>
> extern "C" significa solo che la specifica di linkage e' C. E tante
> delle cose belle che C++ consente di fare se na vanno in questo caso.

Ok, ammetto la disattenzione
La convenzione di chiamata è un' altra cosa
La frase voleva fare capire che extern "C" non significa scrivere solo
codice C

>
>> E' possibile costruire una classe C++ in un wrapper a extern "C" e
>> buttare il tutto in una libreria perfettamente usabile anche da altri
>> compilatori.
>
> Qui non e' chiaro cosa intendi con wrapper. Comunque, per farla breve
> tutto quello che non riguarda il linking (ovvero quello che succede
> *dentro* una funzione) e' piu' o meno safe. A parte che fare uscire
> un'eccezione non sarebbe salutare.
Ho cercato un po in rete
qui dovrebbe essere piu chiaro
http://www.pluto.it/files/ildp/HOWTO...open/x146.html
Gli esempi sono per l' ambiente linux


>
>> E visto che anche qui, il concetto di classe non esiste in C
>> non si perde nulla rispetto al C
>
> Quindi cosa abbiamo concluso? Che essenzialmente usando C++ come fosse C
> e rinunciando alle "innovazioni" possiamo farci linkare facilmente da
> fuori?
No, il C++ con tutta la sua potenza si puo usare tranquillamente anche
per fare una libreria binaria, con l' accortezza che la sua interfaccia
pubblica sia extern "C" e le eccezioni non vengano propagate all' esterno

[..]
> Semmai funzionano meglio oggetti come swig (con tutto il macello che si
> porta dietro) per semplificare il boilerplate. Ma non mi sembra di dire
> nulla di sconvolgente, sono cose note a tutti.
>
> E la mia posizione e' che per scrivere qualcosa che voglio chiamare dal
> resto del mondo, se devo scegliere fra scrivere del cattivo C++ o
> dell'ottimo C, preferisco semplicemente scrivere in C. Scrivere
> dell'ottimo C++ semplicemente non e' un'opzione per come funzionano oggi
> le cose.
>
E quindi rinunci al C++ solo perchè è "complicato" costruire una
libreria dinamica portabile ?
Mi sembra troppo riduttivo a meno che la tua professione sia quella di
costruire solo librerie

Soviet_Mario <Soviet.Mario> wrote:

> per curiosità, di cosa si tratta ? Non conosco questo
> acronimo o nome o quel che è. Se si può accennare in due parole.

E' piu' facile "mi sento fortunato" su Google. :)
http://www.swig.org/

Praticamente (in teoria) ti fa il mestieraccio di wrappare C++ perche'
sia facilmente compreso dal resto del mondo in automatico. In pratica e'
molto meno automatico di quello che ti "vendono" e bisogna insomma
starci attenti (specialmente testare accuratamente sui pochi linguaggi
che uno decide di supportare attivamente).

enoquick <enoquick> wrote:

> La frase voleva fare capire che extern "C" non significa scrivere solo
> codice C

Giusto per capire, ti sei mai trovato nell'esigenza di dovere fare un
interfaccia "C" per una larga libreria C++ moderna (ovvero una che
faccia massiccio uso di templates, policies e combriccola cantante)?

Hai presente quanta e' bella la soluzione con policies ai problemi di
offrire generalita', efficienza tutto insieme?

Ecco... hai presente quando devi togliere i template per mettere il
tutto in extern cosa succede?

> Ho cercato un po in rete
> qui dovrebbe essere piu chiaro
> [..]
> Gli esempi sono per l' ambiente linux

Qua il link non sembra funzionare. Ma comunque a me e' piuttosto chiaro
il marchingegno, visto che ci sono passato in mezzo.

> No, il C++ con tutta la sua potenza si puo usare tranquillamente anche
> per fare una libreria binaria, con l' accortezza che la sua interfaccia
> pubblica sia extern "C" e le eccezioni non vengano propagate all' esterno

Quindi devi progettare l'interfaccia *senza* fare uso della potenza di
C++. E quindi mi sembra tendenzialmente buffa l'affermazione. Il
problema e' proprio che questa cosa di viene in mezzo ai piedi
*parecchio*. Parliamo di avere un'interfaccia senza templates, per
dire... che vuole dire specializzare a mano... per cosa?

Significa in particolare rinunciare alla principale feature che rende
potenzialmente C++ piu' agevole di C, ovvero templates (belli) vs.
void*.

E ti ripeto, non e' *necessariamente* una buona idea scrivere tutta una
libreria con le logiche di C++ e poi dovere scrivere un superstrato che
le fa sparire e usa quelle di C. Alla fine e' molto piu' naturale, se si
usa C++ usare molto poco C++ fin da subito, in modo da avere molti meno
problemi facendo il bridge.

> E quindi rinunci al C++ solo perchè è "complicato" costruire una
> libreria dinamica portabile ?

Veramente rinuncio a C++ perche' mi fa perdere un mucchio di tempo e
fine della storia. Poi voglio dire, e' uno dei tanti coltellini che so
usare, se ne avessi bisogno e' ancora li. Al momento non ne ho bisogno.

Sono invece piuttosto affascianato da 2011, che pare abbiano pezzato
molte delle cose che mi infastidivano soverchiamente. Si vedra'.

Comunque il thread diceva essenzialmente per quali cose va meglio C e
quali C++. L'ipotesi dominante sul ng (di C++, guardacaso) e' che C++ fa
tutto quello che fa C (meglio) e che non c'e' ragione per per usare C.

Io trovo che invece ci siano anche ragioni per usare C (alcune delle
quali sono state esposte da altri) e questa e' stata esposta da me.

Il 29/01/2012 11:24, Enrico Franchi ha scritto:
> Soviet_Mario<Soviet.Mario> wrote:
>
>> per curiosità, di cosa si tratta ? Non conosco questo
>> acronimo o nome o quel che è. Se si può accennare in due parole.
>
> E' piu' facile "mi sento fortunato" su Google. :)
> [..]


ok grassie

Soviet
[..]

Il 29/01/2012 11:24, Enrico Franchi ha scritto:
> enoquick<enoquick> wrote:
>
>> La frase voleva fare capire che extern "C" non significa scrivere solo
>> codice C
>
> Giusto per capire, ti sei mai trovato nell'esigenza di dovere fare un
> interfaccia "C" per una larga libreria C++ moderna (ovvero una che
> faccia massiccio uso di templates, policies e combriccola cantante)?
>
personalmente no
comunque i template non si possono immettere in una libreria binaria
si esporta una o piu istanze di un template


> Hai presente quanta e' bella la soluzione con policies ai problemi di
> offrire generalita', efficienza tutto insieme?
>
> Ecco... hai presente quando devi togliere i template per mettere il
> tutto in extern cosa succede?

i template non si tolgono, occorre istanziare

>
>> Ho cercato un po in rete
>> qui dovrebbe essere piu chiaro
>> [..]
>> Gli esempi sono per l' ambiente linux
>
> Qua il link non sembra funzionare. Ma comunque a me e' piuttosto chiaro
> il marchingegno, visto che ci sono passato in mezzo.
non so che dire, a me quel link funziona

>
>> No, il C++ con tutta la sua potenza si puo usare tranquillamente anche
>> per fare una libreria binaria, con l' accortezza che la sua interfaccia
>> pubblica sia extern "C" e le eccezioni non vengano propagate all' esterno
>
> Quindi devi progettare l'interfaccia *senza* fare uso della potenza di
> C++.
E' il limite per un libreria binaria
Una classe od un template non esistono a livello binario


E quindi mi sembra tendenzialmente buffa l'affermazione. Il
> problema e' proprio che questa cosa di viene in mezzo ai piedi
> *parecchio*. Parliamo di avere un'interfaccia senza templates, per
> dire... che vuole dire specializzare a mano... per cosa?
>
> Significa in particolare rinunciare alla principale feature che rende
> potenzialmente C++ piu' agevole di C, ovvero templates (belli) vs.
> void*.
Solo a livello interfaccia
tutta la parte non esportata puo essere codice C++ anche complesso


>
> E ti ripeto, non e' *necessariamente* una buona idea scrivere tutta una
> libreria con le logiche di C++ e poi dovere scrivere un superstrato che
> le fa sparire e usa quelle di C. Alla fine e' molto piu' naturale, se si
> usa C++ usare molto poco C++ fin da subito, in modo da avere molti meno
> problemi facendo il bridge.
relativamente d' accordo , se la complessità del corpo è alta
e l' interfaccia è semplice puo essere meglio usare C++ in tutta la sua
bellezza

>
>> E quindi rinunci al C++ solo perchè è "complicato" costruire una
>> libreria dinamica portabile ?
>
> Veramente rinuncio a C++ perche' mi fa perdere un mucchio di tempo e
> fine della storia. Poi voglio dire, e' uno dei tanti coltellini che so
> usare, se ne avessi bisogno e' ancora li. Al momento non ne ho bisogno.
i saggi usano lo strumento che ritengono giusto per quello che devono fare
Anch'io se dovessi costruire una libreria binaria valuterei lo strumento
da usare

>
> Sono invece piuttosto affascianato da 2011, che pare abbiano pezzato
> molte delle cose che mi infastidivano soverchiamente. Si vedra'.
Si, sono interessanti, ma non apro una discussione su C++2011
[..]

enoquick <enoquick> wrote:

> > Giusto per capire, ti sei mai trovato nell'esigenza di dovere fare un
> > interfaccia "C" per una larga libreria C++ moderna (ovvero una che
> > faccia massiccio uso di templates, policies e combriccola cantante)?
> >
> personalmente no

Non ti dico di fidarti perche' non credo nel principio di autorita'.
Pero' ecco... ne riparliamo se mai dovrai farlo.

> comunque i template non si possono immettere in una libreria binaria
> si esporta una o piu istanze di un template

Vedo che sotto continui a parlare di libreria binaria. Il problema non
e' "libreria binaria". Il problema e' libreria chiamabile dal resto del
mondo.

Certo, ad un certo punto hai il binario: ed e' quello che ti serve per
eseguire! Ma non e' quello il problema.


> >> [..]

> non so che dire, a me quel link funziona

Qua continua a non funzionare.

> E' il limite per un libreria binaria
> Una classe od un template non esistono a livello binario

Non e' un problema di "libreria binaria". Il fatto e' che quando vuoi
linkarti, ti linki per forza a qualcosa di binario. Tutto qui. Poi posso
anche distribuire gli headers, il punto non cambia.

Quando voglio chiamare quel codice da qualcosa che non sia C++ devo per
forza passare per un'interfaccia extern'zata oppure pagare il costo
concettuale di oggetti come swig.

> Solo a livello interfaccia
> tutta la parte non esportata puo essere codice C++ anche complesso

Mi sa che non ci siamo. Probabilmente non sono stato in grado di
spiegarti il problema; non ci ho investito molto, pensavo fosse
abbastanza ovvio.

Al mondo esiste altro oltre C++. Questo altro parla piu' o meno
universalmente bene con C.

Quando scrivo in un linguaggio, a me piace progettare il lavoro usando
le features di quel linguaggio. Di solito il lavoro viene meglio. Quando
progetto una libreria in C++, tipicamente voglio usare templates e
namespace *anche* nell'interfaccia.

C++ offre delle cose comode *specialmente* quando si progetta una
libreria. I templates sono praticamente il nocciolo di scrivere codice
riusabile in un linguaggio con static typing: o hai un type system
decente come Haskell, oppure, senza i templates, devi fare magheggi.

Se uso C++ e' perche' non voglio magheggiare con i void* (non che sia un
problema, eh, ma visto che ho comunque il typing fra le scatole, almeno
che faccia qualcosa di utile -- vedi templates --).

Riprogettare un'interfaccia perche' *non* faccia uso di templates *e*
sia comoda non e' banale. Certo, se scrivi C++ molto elementare
probabilmente non ci sono grosse questioni.

Il problema e' che se devo scrivere C++ elementare, allora tanto vale
usare C. Io voglio usare C++ come si deve. E questo *non* si puo' fare
dentro gli extern.

Il 29/01/2012 18:53, Enrico Franchi ha scritto:
> enoquick<enoquick> wrote:
>
>>> Giusto per capire, ti sei mai trovato nell'esigenza di dovere fare un
>>> interfaccia "C" per una larga libreria C++ moderna (ovvero una che
>>> faccia massiccio uso di templates, policies e combriccola cantante)?
>>>
>> personalmente no
>
> Non ti dico di fidarti perche' non credo nel principio di autorita'.
> Pero' ecco... ne riparliamo se mai dovrai farlo.

Se capiterà agirò cosi:

in caso di di interfaccia C++ pubblica già esistente deciderò come
implementare l' interfaccia 'portabile'
nel caso inverso (sviluppo da zero) deciderò non solo l' interfaccia ma
anche il linguaggio tra quelli a disposizione
>
>> comunque i template non si possono immettere in una libreria binaria
>> si esporta una o piu istanze di un template
>
> Vedo che sotto continui a parlare di libreria binaria. Il problema non
> e' "libreria binaria". Il problema e' libreria chiamabile dal resto del
> mondo.

vuoi un binding di sorgenti tra linguaggi diversi ?

[CUT]

>> Solo a livello interfaccia
>> tutta la parte non esportata puo essere codice C++ anche complesso
>
> Mi sa che non ci siamo. Probabilmente non sono stato in grado di
> spiegarti il problema; non ci ho investito molto, pensavo fosse
> abbastanza ovvio.

L' inizio della discussione è iniziata cosi:
>Due parole: name mangling.

Al che il sottoscritto rispose:
Il name mangling si risolve con extern "C"

Il che indipendentemente dalla complessità è vero
Forse occorre rinunciare ad alcune cose come i template (che devono
essere istanziati), ma generalmente si puo fare indipendentemente dalla
complessità.

>
> Al mondo esiste altro oltre C++. Questo altro parla piu' o meno
> universalmente bene con C.
Vero, quasi tutti i linguaggi hanno un modo per interfacciarsi a
librerie o moduli binari quasi sempre solo a interfaccia C
Noi perlisti (il perl è un linguaggio unico) andiamo ben oltre,
possiamo anche fare cosi:

---> start perl
#!/usr/bin/perl
use Inline CPP;

my $r = Rect->new(2,3);
print $r->area,"\n";

__END__
__CPP__

class Rect {
public:
Rect(int x,int y) : _x(x),_y(y) {}
int area()const { return _x * _y; }
private:
int _x,_y;
};
<-- end perl

Anche se non conosci perl
puoi facilmente capire che questo permette a perl di usare una
interfaccia sorgente scritta in C++ con alcune limitazioni;
una classe template va istanziata per essere usata e le eventuali
eccezioni devono essere trappate dentro C++
Questo giochetto lo possiamo fare anche per C,ruby,java e altri linguaggi


>
> Quando scrivo in un linguaggio, a me piace progettare il lavoro usando
> le features di quel linguaggio. Di solito il lavoro viene meglio. Quando
> progetto una libreria in C++, tipicamente voglio usare templates e
> namespace *anche* nell'interfaccia.
Perfettamente d' accordo
ma nel mondo reale qualche volta non è possibile perchè esistono delle
limitazioni a cui sottostare

On Jan 29, 11:24 am, r...@despammed.com (Enrico Franchi) wrote:
> enoquick <enoqu> wrote:
>
> Quindi devi progettare l'interfaccia *senza* fare uso della potenza di
> C++. E quindi mi sembra tendenzialmente buffa l'affermazione. Il
> problema e' proprio che questa cosa di viene in mezzo ai piedi
> *parecchio*. Parliamo di avere un'interfaccia senza templates, per
> dire... che vuole dire specializzare a mano... per cosa?
>
> Significa in particolare rinunciare alla principale feature che rende
> potenzialmente C++ piu' agevole di C, ovvero templates (belli) vs.
> void*.
>
> E ti ripeto, non e' *necessariamente* una buona idea scrivere tutta una
> libreria con le logiche di C++ e poi dovere scrivere un superstrato che
> le fa sparire e usa quelle di C. Alla fine e' molto piu' naturale, se si
> usa C++ usare molto poco C++ fin da subito, in modo da avere molti meno
> problemi facendo il bridge.
>

Sì, no, forse.
Faccio due osservazioni così, in generale, visto che purtroppo
nell'ultimo anno ho scritto una quantità di briges e wrappers da
mettersi a piangere..
- Che io abbia visto, una libreria con interfaccia C è utilizzabile
praticamente da chiunque, quindi è sicuramente la soluzione più
riusabile.
- Se ho una codebase C e devo sviluppare una libreria ovviamente non
lo faccio in C++ a meno che:
- - non debba utilizzare una libreria di terze parti in C++
- - la libreria esporta solo due/tre funzioni stupide e fa un sacco di
lavoro dentro (mettiamo ad esempio una libreria di calcoli, prende un
array in input e da un array in output: dentro posso usare vettori,
code, classi, etc.etc. per mia comodità)
Ci sono sicuramente altri casi che non mi sovvengono, ma solitamente
un po' di buon senso e si trova la soluzione migliore per il caso
specifico. Ovviamente sono possibili anche varie aberrazioni, come mi
è capitato di vedere (per connettere una libreria .NET ad un codice C
avere due DLL di bridge, una in C++/CLI e una in C/C++) il che non è
necessariamente sintomo di cattiva progettazione, ma dell'eccessiva
eterogeneità dei linguaggi.
M2C
Ciao!

enoquick <enoquick> wrote:


> vuoi un binding di sorgenti tra linguaggi diversi ?

No. Semplicemente capita spesso di volere chiamare librerie C (o anche
C++, ma e' piu' complesso). Per dire, con ctypes prendo una qualunque
libreria C e ne chiamo le funzioni cosi' come sono da Python.

> Il che indipendentemente dalla complessità è vero

Come ti dicevo, per me non e' una "soluzione", tenendo conto che pone
forti limitazioni. E', al piu' una pezza.

> Forse occorre rinunciare ad alcune cose come i template (che devono
> essere istanziati), ma generalmente si puo fare indipendentemente dalla
> complessità.

Vedi, rinunciando ai templates per me si perde ogni possibile vantaggio
ad usare C++ su qualche altro linguaggio. Per me C++ - templates non ha
nemmeno senso di esistere. O meglio, ha senso, ma e' inaccettabilmente
castrato. Come dicevo, allora, preferisco di gran lunga C puro e
semplice.

> Vero, quasi tutti i linguaggi hanno un modo per interfacciarsi a
> librerie o moduli binari quasi sempre solo a interfaccia C

Yep.

> Noi perlisti (il perl è un linguaggio unico) andiamo ben oltre,
> possiamo anche fare cosi:

Oh, poi e' OT, ma a me fare una cosa del genere pare completamente priva
di senso. Poi voglio dire, non e' che guasti, ma da un punto di vista
ingegneristico e' il tipico incubo da mantenere.

Quello che invece e' comodo e' poter avere delle FFI comode e fine della
storia. O al limite semplicemente aprire una libreria e chiamare in
automatico le funzioni (e anche questo lo ho visto fare).

[..]
> class Rect {
> public:
> Rect(int x,int y) : _x(x),_y(y) {}
> int area()const { return _x * _y; }
> private:
> int _x,_y;
> };
> <-- end perl
>
> Anche se non conosci perl

Sono stato estremamente felice di abbandonarlo definitivamente circa 8
anni fa.

> puoi facilmente capire che questo permette a perl di usare una
> interfaccia sorgente scritta in C++ con alcune limitazioni;


> una classe template va istanziata per essere usata e le eventuali
> eccezioni devono essere trappate dentro C++

Che sono limitazioni fortine, voglio dire. Sempre le solite aggiungo:
quelle che non passano extern "C".

> Questo giochetto lo possiamo fare anche per C,ruby,java e altri linguaggi

Su C gia' lo vedo nettamente piu' utile per descrivere una struct (che
puo' essere comoda per pacchettare e spacchettare dati binari).


> Perfettamente d' accordo
> ma nel mondo reale qualche volta non è possibile perchè esistono delle
> limitazioni a cui sottostare

Figurati. Ma allora, come dicevo, uso C.