Newsgroup: it.comp.lang.c++
Titolo: Da Java a c++, tra filosofia e pratica!

Salve a tutto il ng,
Conosco abbastanza bene il Java, che ha rappresentato il primo linguaggio oo
che ho imparato ad utilizzare, ma dovendo sviluppare alcune applicazioni
real-time sotto linux, ho bisogno di passare al C++.
Premetto innanzitutto che programmo in C da circa un decennio, e che conosco
bene le system call posix e le api delle librerie gnu + diffuse.
Le difficoltà che dunque ho non sono di tipo tecnico ma di approccio ed
impostazione...
In pratica in java ho a disposizione una libreria davvero enorme di oggetti
standard, con una documentazione ottima, completa e soprattuto "omogenea".
Pare che in c++ una cosa del genere non ci sia, o meglio sia ridotta ad un
sottoinsieme ristrettissimo che riguarda l'ìostream, le stringhe ed i
container. Potreste indicarmi altre categorie di oggetti standard o che
verranno presto standardizzati?
Queste api sono effettivamente rispettate dai diversi compilatori
disponibili?
In alcuni casi mi sono rifatto a dei "toolkit" c++ multipiattaforma (es. qt
library), da affiancare alle classi standard in modo da conservare la
compatibilità, in altri casi, invece c'è totale assenza di librerie.
Per ovviare al tale mancanza posso liberamente wrapperizzare una libreria c
all'interrno di classi c++?
In tal caso di cosa dovrei tenere conto per rendere il codice confacente ad
una specie di "style-guide" in modo da permetterne un facile riutilizzo e
condivisione?
Esiste un toolkit multipiattaforma per i thread nativi?
Ed infine una domanda banale (ed un pò pigra:))... sotto linux quali sono le
pagine del man relative ad iostream, string etc.?
grazie!
        Marco

 
Ciao,
-- 
Matteo Settenvini
FSF Associated Member
Email : 
mat...@member.fsf.org
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(-) s+:- a-- C++ UL+++
P?>++ L+++>$ E+>+++ W+++ N++ o?
w--- O- M++ PS++ PE- Y+>++
PGP+++ t+ 5 X- R tv-- b+++ DI+
D++ G++ e h+ r-- y?
------END GEEK CODE BLOCK------

 Altrimenti, cerca su Internet per altre descrizioni dell'STL.
Grazie mille per la disponibilità e gentilezza!
        Marco

         Marco
Di nulla!


 wrote in message 
news:dfp90a$ca8$1...@news.unina.it...

Io ti consiglio ACE di cui e' uscito anche un discreto libro qualche tempo 
fa (
http://www.riverace.com/acebooks/index.htm#apg
)
Lo utilizzo e utilizzato sulle seguenti piattaforme Win32, Solaris (SPARC) e 
Linux (RedHat). Il tempo per apprendere il framework non e' molto e comunque 
viene ripagato oppure puoi utilizzare il layer piu' a basso livello, un 
wrapper comune a tutti gli O.S. supportati
Ciao, Fabio
http://www.cs.wustl.edu/~schmidt/ACE.html
C++ Wrapper Facades for OS Interfaces
 Concurrency and synchronization components
 IPC and filesystem components
 Memory management components
Frameworks
 Event demultiplexing components
 Service initialization components
 Service configuration components
 Hierarchically-layered stream components
 ORB adapter components
ACE has been ported and tested on a wide range of OS platforms including 
Windows (i.e., WinNT 3.5.x, 4.x, 2000, Embedded NT, XP, Win95/98, and WinCE 
using MSVC++, Borland C++ Builder, and IBM's Visual Age on 32- and 64-bit 
Intel and Alpha platforms), Mac OS X, most versions of UNIX (e.g., Solaris 
1.x and 2.x on SPARC and Intel, SGI IRIX 5.x and 6.x, DG/UX, HP-UX 10.x, and 
11.x, Tru64UNIX 3.x and 4.x, AIX 3.x, 4.x, 5.x, DG/UX, UnixWare, SCO, and 
freely available UNIX implementations, such as Debian Linux 2.x, RedHat 
Linux 5.2, 6.x, 7.x, 8x, and 9.x, as well as the various Enterprise 
editions, SUSE Linux 8.1 and 9.2, Timesys Linux, FreeBSD, and NetBSD), 
real-time operating systems (e.g., LynxOS, VxWorks, ChorusOS, QnX Neutrino, 
RTEMS, OS9, and PSoS), OpenVMS, MVS OpenEdition, and CRAY UNICOS. A single 
source tree is used for all these platforms. 

 distante da Java proprio per la sua lentezza -e non solo-, quindi...).
Scusa, ma sul discorso "overhead" non sono particolarmente convinto.
In primo luogo non credo sia la ragione per cui non vengono fatti i
wrapper. Quando hai di mezzo rete, accessi a disco, db e compagnia,
l'ultimo dei tuoi problemi è la differenza di velocità fra C e C++.
In progetti del genere non si sente quasi differenza anche con un
linguaggio di livello nettamente più alto, per dire.
IMHO il punto è che scegliendo se implementare solo C o solo C++,
risulta che da C++ chiami C, da C in  buona sostanza non chiami C++ (se
non in determinati casi).
Poi personalmente credo che se da un lato l'approccio di Java di OOP
forzata sia eccessivo (e francamente imbarazzante, quando penso che poi
le funzioni "normali" le hanno reintrodotte dalla finestra, pensa per
dire a Math).
-- 
non vincono, non vinceranno, non hanno domani
la forza è nel puntello impugnato da oneste fortissime mani

 la sua lentezza -e non solo-, quindi...).
A giudicare dai salti mortali pazzeschi che alcune popolari librerie C
ti costringono a fare per simulare il polimorfismo (e quindi,
ovviamente, accettando in pieno il relativo overhead, vero o presunto)
l'impressione e' che in realta' molte librerie sono state scritte in C
o non riscritte in C++ solo per ignoranza e prevenzione.
Ciao,
Nicola