Newsgroup: it.comp.os.linux.development
Titolo: fork() e oggetti...

Ciao a tutti.
Mi sto avvicinando alla programmazione Linux/UNIX , e sto studiando la
programmazione concorrente. Ora mi sto chiedendo: come può essere utilizzata
la funzione fork() all'interno di un programma ad oggetti?
Mi spiego meglio: la system call "fork()" suddivide un processo in due
sottoprocessi con memoria separata che condividono lo stesso codice. Ma in
un programma ad oggetti, si dovrebbe avere "un oggetto" che funziona in un
processo differente. Cosa ne pensate? Qual'è il modo tipico di effettuare
programmi ad oggetti multiprocesso/multithread/concorrenti/distribuiti ?
GRAZIE
Daniele.

programmi ad oggetti multiprocesso/multithread/concorrenti/distribuiti ?
Difficilmente chi ha bisogno di alte prestazioni programma ad oggetti.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *
      | (Ri)scoprire fidonet: 
http://bbs.mi.linux.it

programmi ad oggetti multiprocesso/multithread/concorrenti/distribuiti ?
Per esempio CORBA.


ERESIA!

Difficilmente chi ha bisogno di alte prestazioni programma ad oggetti.
Dipende da cosa intendi per "concorrenti/distribuiti".
Se ti riferisci ad un calcolatore parallelo a memoria condivisa 
è un conto, se parli di sistemi client/server complessi il collo di 
bottiglia sarà tipicamente la rete, per cui l'OOP è accettabile, 
se non necessaria per gestire tutta quella complessità.
E per le alte prestazioni in genere, il mondo è cmq pieno di
programmi scritti in Ada e Fortran 90 che sono molto OO :-))

 Difficilmente chi ha bisogno di alte prestazioni programma ad oggetti.
Battutaccia: Windows e` scritto in C++ infatti.
-- 
  /Kinkie
Se sulla scatola c'e` scritto "Per windows 95 e superiori", dovrebbe
funzionare sotto Linux, vero?

Battutaccia: Windows e` scritto in C++ infatti.
Penso a quei coglioni della NASA che hanno usato CORBA per Hubble.
Penso a quegli imbroglioni dell'ESA che usano Ada per l'Ariane.
Mi vergogno pensando a chi gli ha suggerito di passare ad Eiffel.
Teste vuote quelle che hanno definito il Fortran 90 con scemenze
tipo il polimorfismo.
Ringrazio te per aver invece portato un contributo illuminato 
alla discussione.
 

 tipo il polimorfismo.
Sono perfettamente d'accordo con te! Seguendo il ragionamento del
"efficiente = non ad oggetti" allora tutte le applicazioni di una certa
dimensione non potrebbero essere efficienti!
Faccio notare poi che non è indispensabile usare il C++ per avere degli
oggetti: anche in C (e chi sviluppa LINUX lo sa bene) è possibile scrivere
degli "oggetti", senza ereditarietà magari, ma pur sempre ad oggetti!
Forse c'è ancora chi pensa che siamo rimasti a 10 anni fa, quando per avere
applicazioni veloci era indispensabile usare certi trucchetti... peccato che
ora i compilatori sono un po' più intelligenti, e ad esempio sono in grado
di ottimizzare codice che usa gli array rendendolo veloce come uno che usa
l'aritmetica dei puntatori. Però gli array sono più leggibili -
manutenibili. Ma queste cose non servono, vero?
Consiglio chi non è della mia opinione di andare a dare un'occhiata
all'articolo di Pescio che parlava di questo argomento. Di me è giusto non
fidarsi, ma di Pescio ...
Comunque il problema della fork() l'ho risolto (ringrazio a questo proposito
il Sig. Rimassa): nel caso di applicazioni ad oggetti non va usata né la
fork() né le pipe; molto meglio thread e  socket!
Ciao
Daniele.

degli "oggetti", senza ereditarietà magari, ma pur sempre ad oggetti!
Tipo ampie sezioni del kernel, che sono scritte con un approccio OO.

 writes:
    Zefram> Penso a quei coglioni della NASA che hanno usato CORBA per
    Zefram> Hubble.  Penso a quegli imbroglioni dell'ESA che usano Ada per
    Zefram> l'Ariane.  Mi vergogno pensando a chi gli ha suggerito di
    Zefram> passare ad Eiffel.  Teste vuote quelle che hanno definito il
    Zefram> Fortran 90 con scemenze tipo il polimorfismo.
    Daniele> Sono perfettamente d'accordo con te! Seguendo il ragionamento
    Daniele> del "efficiente = non ad oggetti" allora tutte le applicazioni
    Daniele> di una certa dimensione non potrebbero essere efficienti!
Dipende dalle priorita`. Ricordo per esempio che il primo compilatore C++
era un preprocessore che generava codice C (ancora adesso il CFRONT
funziona cosi`). Questo significa sostanzialmente che il c++ non aggiunge
potenza semantica rispetto al C, ma "solo" costrutti che possono facilitare
la vita al programmatore. Non fraintendetemi, ritengo che c++ sia un buon
linguaggio, solo che come ogni strumento non e` adatto a ogni scopo.
    Daniele> Faccio notare poi che non è indispensabile usare il C++ per
    Daniele> avere degli oggetti: anche in C (e chi sviluppa LINUX lo sa
    Daniele> bene) è possibile scrivere degli "oggetti", senza ereditarietà
    Daniele> magari, ma pur sempre ad oggetti!  Forse c'è ancora chi pensa
Vedi GTK+.
    Daniele> che siamo rimasti a 10 anni fa, quando per avere applicazioni
    Daniele> veloci era indispensabile usare certi trucchetti... peccato
    Daniele> che ora i compilatori sono un po' più intelligenti, e ad
'nzomma.. io tendo a diffidare delle cose 'intelligenti'. Sono tipicamente
quelle che fanno errori non rimediabili perche` cercano di essere piu`
furbe di te.
    Daniele> esempio sono in grado di ottimizzare codice che usa gli array
    Daniele> rendendolo veloce come uno che usa l'aritmetica dei
    Daniele> puntatori. Però gli array sono più leggibili -
Non sempre sono usabili, e non sempre sono equivalenti.
    Daniele> manutenibili. Ma queste cose non servono, vero?  Consiglio chi
    Daniele> non è della mia opinione di andare a dare un'occhiata
    Daniele> all'articolo di Pescio che parlava di questo argomento. Di me
    Daniele> è giusto non fidarsi, ma di Pescio ...  Comunque il problema
Pescio chi?
    Daniele> della fork() l'ho risolto (ringrazio a questo proposito il
    Daniele> Sig. Rimassa): nel caso di applicazioni ad oggetti non va
    Daniele> usata né la fork() né le pipe; molto meglio thread e socket!
Qualsiasi cosa, purche` funzioni :-)


furbe di te.
Questo è infatti il motivo chiave per cui il kernel di Linux non verrà
scritto in C++.


Carlo Pescio, 
www.eptacom.net
Un grande!
Daniele.

scritto in C++.
Anche gcc (cc1) usa dei trucchetti di ottimizzazione, non solo g++ (cc1plus),
pertanto questo ragionamento non e' corretto.
Le ottimizzazioni che fa il compilatore sono molto utili, e sono fatte (in
generale) da persone che sanno il fatto loro.
Il problema del kernel credo che sia nel fatto che il C++ e' per sua natura
piu' difficile da debuggare a basso livello (dove il C e' invece avvantaggiato).
Inoltre se gcc e' uno dei migliori compilatori C in giro, questo
non si puo' dire di g++, che ha ancora qualcosa da imparare a livello
di standard ISO (che se non sbaglio ha rigide richieste di prestazioni,
nonsostante qualcuno dica che il C++ e' piu' lento del C).
-- 
"Non e` bello cio` che e` bello ma e` bello cio` che piace ... a ME!"
Massimo Lauria a.k.a. Gargamella on Usenet
mailto: 
garga...@mclink.it
Proud member of: NonSense Delivering Service

 scritto in C++.
Immagino che i motivi siano anche altri: per un kernel e` molto
importante la consistenza e prevedibilita` di
1) interfacce da e verso assembler
2) modelli di accesso alla memoria, impaccamento delle strutture,
   endianness e chi piu` ne ha piu` ne metta
Queste cose sono molto piu` stabili e prevedibili con C che con C++.




Il motivo chiave è che se tu scrivi "x=y+z" in C++ può essere tradotta
in chissà cosa.

in chissà cosa.
Questa mica l'ho capita.
--
 (o-  | c:\> win2000patch001.exe
 //\  | This Microsoft(c) patch fix all bugs present. All rigth reserved.
 V_/_ | Insert Linux boot disk to continue ... loading kernel ...
http://pinguin.linuxbox.com
 r.salmaso(at)
flashnet.it

Questa mica l'ho capita.
Overloading.



Overloading di cosa, scusa? Se x,y, e z sono tipi built-in non puoi
overloadare (nè ridefinire) nulla. Se si tratta di classi, l'uso di '+' è
solo un modo "carino" (syntax sugar) per applicare un metodo o una
funzione, e non capisco come possa essere tradotto in "chissà cosa" visto
che la dichiarazione e il significato funzionale di operator+() sono
presumubilmente informazioni disponibili per il programmatore che vuole
usare quelle classi.
O mi sfugge qualcosa?
Max

 O mi sfugge qualcosa?
Direi che hai ragione...
Saluti,
Fabio Alemagna

 in chissà cosa.
Occhio, mi stai dando ragione :-)
