Newsgroup: it.comp.lang.c++
Titolo: C++ e il web

Mi chiedevo quali soluzioni fossero disponibili per fare applicazioni
web con C++, io conosco solamente Wt ( 
http://www.webtoolkit.eu/wt/
 )
che è però piuttosto limitato, sembra più simile a GWT di Google più
che ad un framework web completo. Conoscete altro?
Visto che il gruppo è frequentato anche da gente che usa altri
linguaggi (specialmente quelli dinamici) vorrei chiedervi di evitare
flame sull'utilità dello sviluppare applicazioni web in C++,
semplicemente considerate come assiomatico che tutti gli altri
linguaggi e relativi framework siano immondizia pura :-).

 che ad un framework web completo. Conoscete altro?
Visto la tua nota a margine sulla *necessità* di fare le cose in C++
(nota che un manager che ponesse tale requisito sarebbe da malmenare
ripetutamente), dovresti dirmi di più sull'ambiente.
Hai intenzione di usare Apache? CGI? Cosa puoi avere? Puoi fare quello
che vuoi?
Poi ancora cosa intendi con 'applicazione web'? La classica cosa che
chiama un db avanti e indietro e presenta pagine web? Quanto è
importante la parte grafica rispetto alla logica? Per caso hai già fatto
qualcosa?
Per esempio hai magari già il model fatto perchè viene da un'altra
applicazione?
Detto tutto questo, ti va di spiegarmi il perchè vuoi farlo in C++? È un
requisito che qualcuno ti ha imposto? Conosci solo C++ e non vuoi
imparare altro? Pensi che conoscendo bene C++ di fare prima, oppure di
ottenere prestazioni superiori? Hai mezza applicazione già fatta in C++?
Stai facendo il port di un'applicazione desktop in C++ sul web? Vuoi
aggiungere una parte web per presentare lo stato 'interno' di
un'applicazione esistente (ovvero aggiungere un'interfaccia web ad
un'applicazione esistente)?
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

linguaggi e relativi framework siano immondizia pura :-).
Ok.

ripetutamente)[...]
E' impossibile. Significherebbe che sa cos'è il C++ e questo contrasta
con l'essere un manager.

 con l'essere un manager.
ROTFL :)


 un'applicazione esistente)?
Rispondere a questa domanda mi sembra paurosamente simile a buttare la
benzina sul fuoco, spero di non innescare io stesso l'odioso flame che
vorrei evitare.
La motivazione è semplice: ritengo che le differenze vere tra i
linguaggi non siano costituite tanto dai linguaggi stessi quanto dai
framework che si hanno a disposizione. C++ tuttavia ha dei punti di
forza in velocità (ok, abbastanza trascurabile se non si va su
applicazioni grosse e/o molto usate come Amazon) e uso di memoria
(abbastanza rilevante anche su scala più piccola).
Non voglio dilungarmi oltre, questo dovrebbe bastare a suscitare l'ira
funesta di molti che tuttavia potrei ignorare allegramente... davvero,
non mi importa poi molto discutere su questo.

 Ok.
Era un "Ok-allora-non-ho-niente-da-dire" ? :-p

 sistema di template, ecc...
Conoscevo giŕ questo:
 
http://www.total-knowledge.com/progs/cppserv/
Cercando un po', ho trovato questi:
 
http://stud3.tuwien.ac.at/~e9626231/cse/home.html
 
http://www.tntnet.org/
 
http://www.micronovae.com/CSP.html
L'ultimo non č multipiattaforma.
Devo dire, tuttavia, che quello che hai segnalato tu (che non conoscevo) mi
sembra piů moderno e interessante come concezione. Non ho avuto, perň, il
tempo di esaminarlo a fondo. In quali aspetti l'hai trovato "limitato"?
Max

 No, non ho ancora fatto niente. :-p
Allora non posso che consigliarti di rivedere la tua scelta. Come vedi
ho cercato di aiutarti secondo le mie possibilità: il fatto è che quasi
nessuno usa C++ per il web perchè è *scomodo* e non porta vantaggi.
Come ti ho detto la velocità la ottieni minimizzando i colli di
bottiglia, ottimizzando gli accessi al db e con un buon caching
(eventualmente con load balancing su più macchine e tutto). Di per se
sono cose che hanno poco a che fare con il singolo linguaggio e più con
la disponibilità di un buon framework me competenze specifiche (penso
all'ottimizzazione delle query al db). Sei libero di non credermi, ma
questo è.
E questa è la ragione per cui nessuno che lavora con sta roba ti
suggerirebbe di usare C++: nessun vantaggio e molti svantaggi, specie in
termini di tempo che ti ci va per finire le cose. Per non parlare poi
dei problemi di deployment.
Nota che in molti stanno mollando perfino Java perchè poco adatto alle
applicazioni web, poco agile, ingessato, ciclo di sviluppo troppo lungo.
Ma ognuno chiaramente fa come crede, eh.


 tempo di esaminarlo a fondo. In quali aspetti l'hai trovato "limitato"?
Neanche io ho avuto molto tempo per provarlo, semplicemente leggendo
le feature sembra più un sistema di widget ajax, a dire la verità
anche io speravo di sentire il parere di qualcuno che l'avesse
provato :-).

forza in velocità[...]
Il C++ ha indubbiamente un punto di forza nelle performance, ma a mio
parere ha poco senso fare leva solo su queste, quando le applicazioni
web vivono la latenza cronica della rete...

 web vivono la latenza cronica della rete...
Infatti ho considerato la velocità di esecuzione come marginale,
semmai la memoria ha un po' più di peso. Il punto principale rimane
però "perché i framework per il web non vengono sviluppati in C++ se
con C++ tutto sommato potrebbero venire ottimi allo stesso modo?".

 con C++ tutto sommato potrebbero venire ottimi allo stesso modo?".
Forse perchè parti con assunzioni sbagliate. Sbagli pensando che i
linguaggi siano tutti uguali (tanto per dirne una, tu stesso riconosci
che C++ sia più efficiente, quindi non sono tutti uguali). Inoltre se
fossero tutti uguali, la gente sarebbe rimasta con C. Non sarebbero nati
svariate decine di linguaggi in seguito.
Riguardo alla tua frase non posso che dire una cosa: parti dall'assioma
che potrebbero venire ottimi allo stesso modo facendoli in C++. Sei
completamente sicuro che questo sia vero? Non ti viene il dubbio che
*forse* questa affermazione *non* è vera: e la riprova è che C++ è il
terzo linguaggio più diffuso su sourceforge (per dire), C il secondo e
che insieme sarebbero il macro blocco più grosso[0] *non* offrono
framework web al pari degli altri?
Il perchè te lo ho detto io e te lo ha detto Andrea: i punti di forza
del C++ sono poco rilevanti sul web, mentre le sue debolezze lo sono
molto di più. Tutto qui.
Una volta i CGI in C erano piuttosto comuni. Poi si sono accorti che in
Perl funzionavano anche meglio, era un linguaggio più sicuro, dava meno
problemi e si faceva prima. Anche se, indubbiamente, un CGI Perl da
performance minori di un CGI C. Poi è nato quel cesso di PHP. 
Nel frattempo fortunatamente sono maturati splendidi framework per altri
linguaggi. 
-----
[0] Non è questione che C e C++ siano lo stesso linguaggio,
semplicemente il fatto è che sarebbe abbastanza banale fare una libreria
in C e poi farne un wrapper in C++, per cui è interessanto vedere come
nemmeno  i programmatori C hanno dato segni di volerlo più di tanto.



Cerchi di portare la diffusione come garanzia di qualità? No perché
alla fine del discorso hai nominato anche PHP e quello è più diffuso
degli altri :-p.
A me francamente viene da pensare che la gente non abbia sviluppato un
framework serio per il web in C++ semplicemente perché tutto sommato
ce n'erano già degli altri in altri linguaggi.
Comunque questo flame, ribadisco, non mi interessa proprio, spero che
finisca alla svelta prima che inizino ad arrivare squadre di troll da
altri gruppi... :p

con C++ tutto sommato potrebbero venire ottimi allo stesso modo?".
Perché se verrebbero ottimi allo stesso modo, non c'è ragione di
svilupparli.

Comunque questo flame, ribadisco, non mi interessa proprio[...]
Quale "flame"?

 altri gruppi... :p
Io non confonderei flame con 'qualcuno non è d'accordo con te'. Per
inciso una discussione sul fatto che C++ sia o meno adatto per uno
specifico compito mi sembra perfettamente IT, anche se la tesi di
qualcuno è che non lo sia.
Ribadisco, un flame è una cosa diversa.


 Ribadisco, un flame è una cosa diversa.
Ok, hai ragione, riformulo: sospettavo che la discussione potesse
prendere una piega per me completamente sterile come questa e mi sono
quindi preoccupato di chiedere che fossero evitate questioni del
genere.
Se non è OT per il gruppo lo è almeno per il topic specifico poiché il
topic era ben definito sulle possibili librerie e su eventuali
esperienze con tali librerie.
Non vorrei sembrare troppo acido ma a distanza di 5-6 post sento
incombere tenebrosa l'ombra del "dinamici vs statici" :-p.

incombere tenebrosa l'ombra del "dinamici vs statici" :-p.
Bah... io questo rischio non lo vedo. Sei tu che stai "evocando" il
flame :-)

[..]
  Io considererei anche un aspetto di mantenimento....il web è in genere 
molto dinamico e spesso i siti cambiano molto in fretta... almeno il 
look and feel per il marketing ...  in C++ se voglio cambiare una 
applicazione devo ricompilare.... nei linguaggi interpretati od in java 
sostituisco il singolo pezzo testo o bytecode che sia e tutto è fatto 
... inoltre sia java che i linguaggi di scripting (perl, ruby, php, tcl 
(penso a vignette) e chi + nè ha + nè metta ) hanno l'enorme vantaggio 
di poter essere sviluppati su windows e depositati sui sistemi di 
produzione che spesso sono unix based senza le noie che  un linguaggio 
nativamente compilato si porterebbe dietro ...
ciao
Pier Paolo

sostituisco il singolo pezzo testo o bytecode 
Il bytecode non dà nessun vantaggio, in questo senso, rispetto al
codice nativo, perché si ottiene comunque per una forma di
compilazione. Nessuno si sogna di distribuire i sorgenti su un server
di produzione. Ciò che può essere distribuito, al massimo, è il
template, vedi la pagina JSP, ma modificare il template raramente ha
impatto solo sul template. Bisogna comunque, prima o poi, ricostruire
gli "eseguibili".

Andrea Laforgia ha scritto:

Beh nn sono molto d'accordo ... in php od in perl in produzione mandi 
direttamente i sorgenti in quanto sono linguaggi interpretati ... il 
bytecode ti offre il vantaggio di poter compilare su windows e 
distribuire su unix ... nelle realtà enterprise mi sembra una cosa 
considerata non da poco ....

 considerata non da poco ....
Aggiungo   che il cmq noto che per lo sviluppo di web application , 
oltre al c++ non mi sembra che nessun altro linguaggio che dia 
compilazione nativa abbia poi avuto tutto sto successo ...

direttamente i sorgenti in quanto sono linguaggi interpretati ... 
Ecco perché non uso né php, né perl.

compilazione nativa abbia poi avuto tutto sto successo ...
Non è un problema di compilazione nativa ed anche il C++, a proposito
di web, non ha avuto un gran successo.

 provato :-).
Dunque, non l'ho veramente provato, ma mi sono fatto un'idea più precisa.
L'approccio è differente da quello di qualsiasi toolkit per il Web che abbia
avuto modo di esaminare, ed assomiglia, invece, a quello dei framework per
lo sviluppo di GUI. La somiglianza non riguarda solo la struttura delle
API, ma anche e soprattutto la logica con cui funziona l'applicazione.
Nell'ambito di una determinata sessione i vari widget che compongono
l'interfaccia corrispondono a specifiche istanze di oggetti C++. Questo
significa che ogni sessione è stabilmente associata a un singolo processo
lato-server, che può comunque gestire più di una sessione (anche
simultaneamente, mediante multithreading). In questo senso, le applicazioni
sviluppate con WT sono intrisicamente "stateful": le strutture dati che
vengono istanziate alla creazione (o nel corso) della sessione sono
materialmente responsabili del mantenimento dello stato. Si tratta, perciò,
di un'architettura diversa da quella della tradizionale applicazione Web
(con diverse implicazioni anche per per quanto riguarda la scalabilità).
WT si occupa di generare (in modo trasparente e cross-browser) tutta la
strumentazione Javascript necessaria per notificare le azioni dell'utente,
aggiornare l'interfaccia e gestire egli eventi generati lato-server (tutta
la parte Ajax, insomma), ma è in grado di funzionare anche in assenza di
Javascript (con alcune limitazioni). 
Non è perciò necessario conoscere il Javascript. Non è nemmeno necessario
conoscere l'HTML o CSS, in quanto WT consente di programmare astraendo da
tutto questo.
L'autore sembra molto competente ed esperto di C++. Lo stile del codice mi
pare elegante e pulito. Si fa uso di Boost e di librerie di moderna
concezione, come l'Asio.
Nel complesso mi pare un toolkit molto potente, e -per quello che ho visto-
completo. Ovviamente non è generico: serve esclusivamente a scrivere
applicazioni con quel tipo di architettura.
Max

 di web, non ha avuto un gran successo.
Beh nn sarą un problema di compilazione nativa .... ma di linguaggi che 
generano eseguibili nativi e che hanno avuto successo per la costruzione 
di web application nn me ne vengono in mente .... a parte forse il c++ 
per i filtri isapi su microsoft....

di web application nn me ne vengono in mente
Ma, ripeto, non č un problema di compilazione nativa...

 Ma, ripeto, non è un problema di compilazione nativa...
Non sono completamente d'accordo. IMHO è una bella rogna dovere tenere
sul webserver gli strumenti per compilare l'eseguibile,
oppure mettere su una suite di cross-compilazione sulle macchine di
sviluppo.
Sicuramente è più rognoso che poter buttare su il progetto e basta.


 scrivere qualcosa di innovativo, tanto meglio, accomodati :-)
Sempre dal mio punto di vista, piu' che per i motivi che dici tu, io non lo
farei perche' "sai che due bolas"...
Cosi' come immagino che un programmatore abituato ad occuparsi
di problemi del web farebbe la stessa affermazione se dovesse fare quello che
ho fatto io nei primi mesi dell'anno scorso e che mi ha 
divertito come non accadeva da tempo (estrazione di dati da file
binari, avendo specifiche sul formato di tale file binario non coerenti
con i file effettivamente presenti nel sistema => quindi ricostruzione di
tali specifiche sulla base dell'osservazione delle prove fatte leggendo i
vari bit)
Ciao,
Marco

 sul webserver gli strumenti per compilare l'eseguibile,
Sono d'accordissimo, ma sto affermando che non è questo il motivo per
cui lo sviluppo per il web, con linguaggi che prevedono normalmente la
compilazione nativa, non si è diffuso, perché il problema di compilare
per diverse piattaforme esiste per molto altro software, allo stesso
modo. Se si fosse stati realmente intenzionati a usare il C++ per lo
sviluppo web, si sarebbe trovato il modo di superare agevolmente
questo scoglio.

 Ma ognuno chiaramente fa come crede, eh.
Su questa gradirei non poco vedere la fonte dei dati, specialmente se
non è verso il mondo .NET che c'è stato il passaggio.
Aggiungo che non risponderò ancora ed eventuali post su argomenti che
non mi interessano, non immagini quante volte ho affrontato questa
stessa discussione senza mai pervenire ad un nulla di fatto.

 usano al posto di java ?
Direi che *questo* discorso è estremamente OT, visto che riguarderebbe
Java e altri linguaggi che non sono C++.
Ad ogni modo in Italia, come sempre, si è indietro. Le cose,
fortunatamente, sono parecchio diverse all'estero.


 stessa discussione senza mai pervenire ad un nulla di fatto.
Ma devi per forza precisarlo? Se non ti va di rispondere a un post non
c'è *nulla* che ti impedisce di farlo. A essere sincero potevi anche
risparmiarti questo post, con cui oltre ad aver fatto presente che le
mie argomentazioni sono ridicole, hai anche mostrato di non avere letto
il pezzo del mio post in cui ti nominavo alcune soluzioni di cui ero a
conoscenza.
Poi visto che lo invocavi da un po', non aspetto che il colpo di pistola
per crearlo davvero il flame.


 stessa discussione senza mai pervenire ad un nulla di fatto.
Ma devi per forza precisarlo? Se non ti va di rispondere a un post non
c'è *nulla* che ti impedisce di farlo. :)


stessa discussione senza mai pervenire ad un nulla di fatto.
Dovresti allora cominciarti a chiedere se non sia l'argomento alla
base ad essere sterile ;-)

 Java e altri linguaggi che non sono C++.
OK, ma potresti almeno consigliare un posto dove *questo* discorso sia "IT" ?
Ciao,
Marco

marco guidi ha scritto:

Per rimanere ai gruppi in italiano, prova it.comp.programmare, 
it.comp.java, it.comp.www, it.comp.www.server.
In generale, trovo che la discussione è degenerata rapidamente. L'OP 
aveva chiesto informazioni su librerie per programmazione in C++, 
chiarendo che non era interessato a discorsi su altri linguaggi; invece 
la maggior parte degli interventi riguarda il confronto tra il C++ e 
altri linguaggi.
Per trattare il confronto tra linguaggi, penso che il gruppo piu' 
appropriato sia it.comp.programmare.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

In generale, trovo che la discussione è degenerata rapidamente. 
Non sono d'accordo. E' vero che l'OP ha chiesto informazioni su
librerie per programmazione in C++, ma non si può considerare
"degenerata" una discussione che, secondo me, è ugualmente utile: il
C++, *visti gli strumenti disponibili in giro*, non è probabilmente lo
strumento migliore per fare certe cose. Alla fine, per quanto avallati
dall realtà, li si può considerare dei punti di vista e ignorarli. I
gruppi di discussione servono a discutere e una discussione può essere
utile anche se non risponde direttamente alla domanda.

 utile anche se non risponde direttamente alla domanda.
Concordo ... ed anche dire che all'estero java lo stanno abbandonando e 
sapere verso cosa si sta andando ... magari è OT ... ma penso possa 
essere utile a tutti .... ci sono OT ... ed OT :)