BOOST

[clros]

Ciao....
qualcuno mi sa dire come fare ad usare la libreria Boost con Win (sotto Devc++ oppure VisualC++ 2008EE)?
Possibile che sia così complesso?
Con Amiga basta includere una libreria statica...è quasi tt pronto...

Inoltre...mi chiedavano se e come si può usare BOOST con il MAC (e XCode ??)

UIltima cosa... sto usando BOOST perchè dovrei usare i thread. l'altra soluzione che conosco è la libreria pthread.
Cosa mi consigliate?

[riko]

> qualcuno mi sa dire come fare ad usare la libreria Boost con Win (sotto > Devc++ oppure VisualC++ 2008EE)?
> Possibile che sia così complesso?

Uhm, non mi è sembrato complesso. Si tratta di sapere usare il proprio IDE/scrivere un Makefile. Poi aggiungi la directory dove stanno gli header di boost nei file dove cercare gli header (tipo con gcc opzione -I), idem per le librerie (-L) e poi linki alle librerie boost che ti servono (o nessuna, se usi roba 'headers only').

Comunque come consiglio suggerisco di passare a Code::Blocks. Lo trovo nettamente superiore a Dev-C++ (lo vedo usato anche professionalmente in aziende che potrebbero comprarsi quello che vogliono) *e* perfino a VC++EE. Tra l'altro gira (bene) su Windows e su Linux e contiene un sacco di progetti interessanti (sia per usare vari compilatori sia per certe librerie)

> Inoltre...mi chiedavano se e come si può usare BOOST con il MAC (e XCode ??)

Si, si può fare. Lo faccio normalmente, non devi fare nulla di particolare. Se mi dai maggiori dettagli ti do qualche dritta.

> UIltima cosa... sto usando BOOST perchè dovrei usare i thread. l'altra
> soluzione che conosco è la libreria pthread.
> Cosa mi consigliate?

La prima cosa che consiglio è "non usare i thread". Se ci si trova in uno degli sfortunati e piuttosto rari casi in cui è conveniente farlo (con la consapevolezza di perdere performance nella maggior parte dei casi), allora userei senza dubbio boost::thread rispetto a pthread.

Alternativamente che so.. potresti usare i Thread di Qt, se programmi con Qt, etc etc etc.

[clros]

Ecco, lo sapevo che prima o poi avresti risposto!

Uhm, non mi è sembrato complesso. Si tratta di sapere usare il proprio IDE/scrivere un Makefile. Poi aggiungi la directory dove stanno gli header di boost nei file dove cercare gli header (tipo con gcc opzione -I), idem per le librerie (-L) e poi linki alle librerie boost che ti servono (o nessuna, se usi roba 'headers only').

Si si...ma cl DEV-C nn ci riesco (vabbè, nn ho più provato).
Insomma, per dirti: cn AmigaOS4 ti installa tt l'SDK e poi, cm dici tu, basta includere l'header o indicare la libreria durante la compilazione.TT qui.

Comunque come consiglio suggerisco di passare a Code::Blocks. Lo trovo nettamente superiore a Dev-C++ (lo vedo usato anche professionalmente in aziende che potrebbero comprarsi quello che vogliono) *e* perfino a VC++EE. Tra l'altro gira (bene) su Windows e su Linux e contiene un sacco di progetti interessanti (sia per usare vari compilatori sia per certe librerie)

Ecco, vedi...questo nn lo conoscevo affatto.
Vado subito a cercarlo, sperando che nn sia strapieno di opzioni (alla Visual studio per intenderci) perchè, per gente cm me che nn li useà mai, sn sl una perdita di tempo :-(

Si, si può fare. Lo faccio normalmente, non devi fare nulla di particolare. Se mi dai maggiori dettagli ti do qualche dritta.

Ti farò sapere.

> UIltima cosa... sto usando BOOST perchè dovrei usare i thread. l'altra
> soluzione che conosco è la libreria pthread.
> Cosa mi consigliate?

La prima cosa che consiglio è "non usare i thread". Se ci si trova in uno degli sfortunati e piuttosto rari casi in cui è conveniente farlo (con la consapevolezza di perdere performance nella maggior parte dei casi), allora userei senza dubbio boost::thread rispetto a pthread.

Grazie.
Ma anche lì avevo qualche problema cn il dev-c
Cmq...il caso in esame è la realizzazione di un banale server per una chat.
Il server accetta le connessioni da parte dei client e per ognuno di essi crea un thread che si occuperà di gestire la comunicazione cn il singolo client.
Già realizzato in java a scopo didattico (ma in Java si sa...è facilissimo...).

C'è un modo diverso per realizzarla, senza usare i thread?

Il tuo consiglio è legato alla perdita di performance su processori multicore a causa dell'invalidazione delle cache?

[riko]

> Si si...ma cl DEV-C nn ci riesco (vabbè, nn ho più provato).

Non lo conosco e non so dirti. Male che vada fatti un Makefile.

> Ecco, vedi...questo nn lo conoscevo affatto.

E' venuto fuori molto di recente.

> Vado subito a cercarlo, sperando che nn sia strapieno di opzioni (alla
> Visual studio per intenderci) perchè, per gente cm me che nn li useà
> mai, sn sl una perdita di tempo :-(

A me gli IDE di solito mi scazzano. Ma questo me lo godo abbastanza. Lo ho trovato abbastanza intuitivo, una volta che uno si rende conto che ci sono preferenze globali che vengono ereditate dai progetti quando sono creati e che poi bisogna editare le proprietà locali dopo creati.

> Il server accetta le connessioni da parte dei client e per ognuno di essi
> crea un thread che si occuperà di gestire la comunicazione cn il singolo
> client.

E' il tipico caso in cui prima della mania dei thread si usavano i processi. E tra l'altro nel problema in questione è anche l'approccio corretto *logicamente*.

> Già realizzato in java a scopo didattico (ma in Java si sa...è
> facilissimo...).

Solo apparentemente, in effetti.

> C'è un modo diverso per realizzarla, senza usare i thread?

Almeno due: il primo è utilizzando i *processi*. Il secondo è utilizzando la programmazione asincrona (poll, select, kqueues). Usando il secondo approccio nginx ha stracciato i vari altri server web, per dire.

Ma anche i processi vincono sui thread: dopo alcuni anni ora postgres su server enterprise class straccia mysql perchè usando un modello a processi scala molto meglio.

> Il tuo consiglio è legato alla perdita di performance su processori
> multicore a causa dell'invalidazione delle cache?

Fra le varie cose, si. In particolare l'altro problema (specie in Java) è che uno non ha ben chiaro che spesso deve introdurre lock e analoghi per proteggere lo stato condiviso e di fatto va a serializzare il codice con performance *peggiori* che se avesse scelto altre strade.

Inoltre reputo i thread dei falsi amici. Il problema è che finchè uno fa dei 'giocattoli', tutto bene. Appena usa i thread per risolvere un problema vero, si trova con due problemi: il problema originario e l'utilizzo dei thread. In generale dovrebbero essere l'ultima strada da percorrere, dopo avere *esplicitamente* dimostrato che le altre falliscono. Invece si sta sempre più spesso insegnando ad usarli come primo approccio. Questo si traduce poi in problemi colossali quando la gente esce dalle università e finisce nel mondo reale.

[clros]

Solo una domanda OT:
La comunicazione tra i processi la realizzeresti nelle "classiche" modalità?

[riko]

Solo una domanda OT:
La comunicazione tra i processi la realizzeresti nelle "classiche" modalità?

Sostanzialmente si. A seconda di cosa intendi con 'classiche modalità'. Tipicamente un qualche tubo fra padre e figlio funziona bene (che poi sia una pipe vera e propria, qualche giochino con stdin e stdout oppure un socket -- UNIX o TCP --). Se la comunicazione è veramente limitata, possono bastare anche i segnali.

Per inciso una chat io la scriverei (anzi, la scrissi) con il modello asincrono. Il punto è che con thread o processi devi comunque in qualche modo farti furbo: se hai solo sessanta persone che si connettono e lanci 60 thread accoppi le performance. E sessanta processi non è che siano molto meglio (anzi, non saprei).

Io lancerei una manciata di processi che tramite api asincrone agiscono solo quando devono. Ciascuno può gestire che so... 40 connessioni. Si pollano i socket, si scopre quelli su cui c'è da leggere, si legge da quelli e si procede.

Farlo in C non è una delle cose più comode della storia, ma comunque non è eccessivamente difficile. Sicuramente kqueue è molto più facile da usare di poll (select IMHO non vale la pena di prenderla in considerazione). epoll c'è su Linux, ha performance comparabili a kqueue, ma non la ho mai usata.

[clros]

Sostanzialmente si. A seconda di cosa intendi con 'classiche modalità'. Tipicamente un qualche tubo fra padre e figlio funziona bene (che poi sia una pipe vera e propria, qualche giochino con stdin e stdout oppure un socket -- UNIX o TCP --). Se la comunicazione è veramente limitata, possono bastare anche i segnali.

Si, intendevo principalmente pipe e socket.

Anche se...ho qualche dubbio sul fatto che usare dei socket per far comunicare processi sulla stessa macchina sia conveniente.
Cosa mi dici in merito?

Per inciso una chat io la scriverei (anzi, la scrissi) con il modello asincrono. Il punto è che con thread o processi devi comunque in qualche modo farti furbo: se hai solo sessanta persone che si connettono e lanci 60 thread accoppi le performance. E sessanta processi non è che siano molto meglio (anzi, non saprei).

Infatti, stavo pensando la stessa cosa...

Io lancerei una manciata di processi che tramite api asincrone agiscono solo quando devono. Ciascuno può gestire che so... 40 connessioni. Si pollano i socket, si scopre quelli su cui c'è da leggere, si legge da quelli e si procede.

Furbo!

Farlo in C non è una delle cose più comode della storia, ma comunque non è eccessivamente difficile.

Vabbè, ormai inizio a fare di tutto e nn finisco quasi nulla :-(

[riko]

> Anche se...ho qualche dubbio sul fatto che usare dei socket per far
> comunicare processi sulla stessa macchina sia conveniente.
> Cosa mi dici in merito?

Beh, chiaramente i socket TCP hanno un certo overhead. Specie se non passi da loopback.

Ad ogni modo puoi provare i socket AF_UNIX:

http://publib.boulder.ibm.com/infocente ... afunix.htm

Non ti so dire *esattamente* la differenza di performance, tuttavia *IMHO* sono buone. Lo Stevens dice che di fatto i dati vengono semplicemente copiati. Hai interfaccia a stream e a datagram, ma sei sempre reliable. Se vuoi perdere portabilità (sconsiglio) su Linux supportano pure il multicast.

Puoi usare interfacce socketlike oppure oggetti come la socketpair (indovina come funziona! :P)


> Furbo!

Diciamo che mi ci sono già immusato. A suo tempo usai Twisted.

> Vabbè, ormai inizio a fare di tutto e nn finisco quasi nulla :-(

Basta divertirsi...