Newsgroup: it.comp.lang.c++
Titolo: Info Paradigma

 Posso usare il C++ con paradigma procudurale o sono obbligato ad usare
l'OOP?
Utilizzandolo come procedurale tolgo l'overhead che causa l'OOP????
Tnk^_^

non sei obbligato a usare la programmazione OOP col c++, puoi scrivere anche
un programma in procedure

Quindi posso usare il C++ come C, giusto???
Ma per l' I/O quale dovrei usare............stream o quello del C?

 Utilizzandolo come procedurale tolgo l'overhead che causa l'OOP????
qua' dipende molto anche dal compilatore ... il gcc se non usi rtti e eccezioni 
lui non le inserisce nel codice e non ti appesantisce ...
il borland mi pare che le compili cmq e sei tu a doverle disabilitare in 
compilazione con le flag giuste ...
ed il vc di ms mi pare invece che le ha disabilitate di standard e devi passare 
delle flag per inserirle ...
ciao

 
quello che ti pare e piace ???
sinceramente non ci sono ne obblighi ne doveri in C++ puoi fare quel cavolo che 
ti pare come in C, anche programmare un programma che va in segfault ogni 3 
secondi ;-)
ciao

 Utilizzandolo come procedurale tolgo l'overhead che causa l'OOP????
Se devi usare un linguaggio procedurale usa il C.
Non si può, secondo me, concepire il C++ senza una visione del mondo ad
oggetti.
Anche se certamente il compilatore te lo permette.
Andrea


Cosa intendi per overhead introdotto dall'OOP ?? Cioč, so cosa significa
overhead etc ma non vedo dove l'OOP introduca overhad in piů.
Andrea

E il DevC++(Myngw)???


Che vantaggi avvrei ad usare il C al posto del C++ procedurale???


 Utilizzandolo come procedurale tolgo l'overhead che causa l'OOP????
Quale overhead?
Chi l'ha detto che l'OOP provoca overhead?
Anzi... in certe condizioni il compilatore potrebbe addirittura ottimizzare
meglio (allo stesso modo in certe altre potrebbe fare di peggio), ma
non vedo perchè, a priori, l'OOP dovrebbe provocare overhead.
Aggiungo inoltre che il più delle volte la prestazione pura è l'ultima delle
necessità, a favore di altre caratteristiche quali l'estensibilità, la
mantenibilità e in generale la chiarezza del codice. Caratteristiche che
l'utilizzo del paradigma OOP non garantisce, ma che certo favorisce.
...spero di essere stato chiaro...
-- 
Gerolamo

 l'eseguibile.
No, in realtà la pesantezza dipende da quanto bene uno scrive il codice e
dalle scelte del compilatore.
Come ha già scritto qualcuno i vantaggi di progettazione e manutenzione del
codice nel mondo OOP superano nettamente eventuali overhead che comunque
secondo me rientrano nella norma.
Diciamo che in certe situazioni si  ha a che fare con codice non ad oggetti
per ragioni storiche... Se ad esempio metti mano al software di rete su Unix
(o simili) oppure al Kernel di Linux hai a che fare con codice scritto in
modo procedurale ed in C.
Andrea

 Che vantaggi avvrei ad usare il C al posto del C++ procedurale???
Nessuno in termini di velocità etc. E' solo per essere coerenti.
Scusa la domanda: ma che genere di progetto vuoi sviluppare?
Secondo me la scelta del paradigma di programmazione dipende anche da cosa
vuoi fare.
Andrea

 
il mingw che non e' nulla'tro che il nome di una collezione di header librerie 
compilatori ed utilita' ... su che compilatore si basa ???
(se la risposta alla domanda e' GCC ti sai gia' ripsondere dasolo ...)
ciao

Andrea Sini wrote:
[cut]
andre mai sentito parlare di rtti e di eccezioni ??? sono quelle due cose che 
creano il massimo overhead da una implementazione all'altra ...
per non parlare della polimorfia e della vtable che ne porta altro ...
quindi si puo' dire benissimo che se non si usano queste feature del c++ un 
codice scritto in c o in c++ e' assolutamente uguale in tempi di esecuzione ecc ...
il punto e' che se usi il c++ senza quelle cose non ci fai nulla di vero c++ ed 
OO ;-)
ciao

 
leggiti anche le mie risposte per capire dove viene inserito overhead nel c++ e 
magari capisci ...
ciao

Ma l'OOP è un paradigma nn un obbligo come in java

 
si ed all'ora ???

...

Questo ragionamento non ha senso. Per parlare di overhead dovresti
confrontare funzionalita' presenti in contesti diversi, implementate
in modo diverso. E' chiaro che se un linguaggio non ha una
funzionalita' non ne paga il peso, ma e' come dire che un programma
che non fa una cosa pesa di meno di uno che la fa; verissimo, ma il
primo programma e' inutile, mentre il secondo no.
E' possibile scrivere codice OO in C, ma per farlo e' necessario
implementare esplicitamente il polimorfismo, l'RTTI, ecc. E quante
persone sono in grado di farlo meglio degli autori del loro
compilatore C++?
Ciao,
Nicola

 oggetti.
E perche' no? Certo e' limitante, ma secondo me il C++ e' un
linguaggio lievemente migliore del C per scrivere codice procedurale.
Ciao,
Nicola

 l'eseguibile.
Anche questo non ha senso. Dovresti paragonare un'implementazione ad
oggetti ed una procedurale di uno stesso programma. Se i due programmi
fanno le *stesse* cose, non e' detto che quello ad oggetti sia piu'
pesante.
Ciao,
Nicola

 Anche se certamente il compilatore te lo permette.
non e` che "lo permette". Il C++ e` nato espressamente per essere
multiparadigma, e` uno dei suoi punti di forza.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

E questo che intendevo.


 namespace... perche` mai rinuciare ad esse?
ci credo... anche se io so che sto scrivendo codice C++ prima o poi la
classe mi scappa... voglio dire... e' troppo comodo...
il C mi piace, a mio avviso per molte cose e' ancora insostituibile, ma
se scelgo di usare il C++ non vedo proprio perche' non usare le
classi...
voglio dire, se mi capita di dovere usare una struct e poi scrivere
delle funzioni per manipolara, per me e' piu' logico usare la classe...
molto imho...
e poi non dimentichiamo i template!!! :-)))))
-- 
Primo Teorema di Franchi:
L'insieme dei bachi di uindous e' isomorfo a R.
Corollario:
Il numero dei bachi di uindous non e' numerabile.

Ma i template mica sono legati all'OOP...........o sbaglio?

 Ma i template mica sono legati all'OOP...........o sbaglio?
no... 
uno li puo' usare anche per creare funzioni templatizzate (si dice
cosi'?)
Template di Funzione capitolo 10 del Lipman Lajole
Template di Classe, capitolo 16...


Mo controllo sulla mia copa del lippman

OO ;-)
L'RTTI non credo venga usato in modo così esaustivo, lo usi se devi
fare cose specifiche (vedi la persistenza di oggetti) o risalire a
informazioni particolari.  Personalmente, poi, infilare una mano nel
sedere di una classe, per vedere che c'è dentro non mi piace molto
come tecnica ;-)... Il polimorfismo è tipico, poi, di un linguaggio
object-oriented e porta con se i vantaggi dell'OOP.  Non si può
parlare di "vero C++" perché non si sa bene neanche che cosa
significhi "vero OO".  La definizione di object-oriented è talmente
generica...

Chi l'ha detto che l'OOP provoca overhead?
Io formulerei la domanda diversamente: perché si pensa che, per
svolgere un compito, il C++ NON debba usare le risorse necessarie ?
Esistono linguaggi in cui, per svolgere lo stesso compito, si usa un
numero inferiore di risorse ?
Se si risponde a queste domande in modo significativo, allora si può
cominciare a parlare della presenza o meno di "overhead".  
Finora, tutti i linguaggi OO che ho visto richiedono un numero di
risorse pari a quello del C++ per assolvere agli stessi compiti.

 L'RTTI non credo venga usato in modo così esaustivo
la gestione delle eccezioni usa RTTI implicitamente
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!


Davvero??? Non lo sapevo :O

la gestione delle eccezioni usa RTTI implicitamente
Ma, a parte che la presenza delle eccezioni è uno di quei vantaggi
introdotti da un linguaggio come il C++, esse sono, appunto,
"eccezioni" e come afferma il buon Eckel "[...]exceptions should occur
only rarely, so the overhead is piled on the exception and not on the
normally executing code.".  
Tanto per confermare quanto detto precedentemente.   

 Tanto per confermare quanto detto precedentemente.   
questa cosa che scrivi e' logicamente corretta ma realmente incorretta ... 
perche' da compilatore a compilatore l'uso delle eccezioni nel codice richiede 
molte piu' prestazioni ... disolito il GCC non aggiunge codice per le eccezioni 
se non lo usi ... ma qualsiasi compilatore che aggiunge il codice per le 
eccezioni non riesce a generare l'uguaglianza con lo stesso codice senza 
eccezioni ... quindi anche se il codice non generera' mai eccezioni il codice 
con l'handling di tali e' piu' pesante di uno senza ... questo e' un fatto per 
ora ... non e' detto che un domani un compilatore riesca a darti un vero WYUIWYP.
per il resto non sto incitando ad usare linguaggi a piu' basso livello ... e' 
solo un discorso che apre gli occhi ai solo conoscitori del codice scritto e che 
non si interessano di come viene generato il codice eseguibile ...
ciao

[...]solo un discorso che apre gli occhi [...]
Be', sull'"apre gli occhi" è tutto da vedere ;-)

 Be', sull'"apre gli occhi" è tutto da vedere ;-)
non lo so pare che non riesco a farmi capire su quello che voglio dire ... :-\

un male per tutti quegli ambiti in cui il massimo prestazionale e' ricercato ...
Tutto da dimostrare: non c'è nessuna implicazione logica, tra un
astrazione e un calo di performance.

 ...)
Come lo senti, per telepatia?
     Mauro

 che quanto affermi è vero.  Dammi dei benchmark.
io non ho piu' sotto mano il link di un vecchio post dei forum che leggo in cui 
c'era il confronto prestazionale di vari linguaggi ...
qua' se qualcuno mi puo' aiutare plz ...
per il resto che dirti ... devi prima vedere e leggere di mano i bench ecc ... 
per vedere il tutto ...
ciao

 Come lo senti, per telepatia?
... :-\ un profiler conteggio occupazione memoria ed uso tempo cpu ???

 ato ...
Come gia' detto bisogna vedere quanto sei capace di far meglio.
Ciao,
Nicola


Forse non ho capito io quello che si diceva ma leggendo il thread mi trovo
d'accordo con Goul_..
Qualunque algoritmo se risolto in maniera personalizzata e non usandone
altri generici è semrpe più performante.Leggendoti mi "pare" di capire che
tu invece non lo hai preso sotto questo punto di vista.Se si implementa un
qualsiasi algoritmo in C che in qualche modo *simuli* una programmazione a
oggetti, sarà sempre più performante che fatta con un meccanismo generico.Io
credo che Goul_dukat intendesse proprio questo.Le difficoltà che troverai in
C saranno sicuramente maggiori e sinceramente credo che sia per pochi
implementre un meccanismo a oggetti come in c++,ma il solo riuscire a
personalizzarlo per le proprie esigenze sicuramente ne aumenterà le
prestazioni.Ma tutto questo credo che dipenda molto anche dal compilatore e
dalle sue ottimizzazioni.
ciao :)
------------------------
http://visualwx.altervista.org/
nuova release 0.77 [freeware]
VisualWx rad per c++,python,perl,lua e wxwindows

prestazioni.
Dimostrare, prego.
Evitate di parlare a vanvera e dimostrate quanto affermate con dati
concreti.

 concreti.
Sui newsgroup un minimo di educazione ci vuole e soprattutto bisognerebbe
rispettare il pensiero altrui.
I pensieri espressi non sono dimostrabili in 2 istruzioni, ma il dire che un
algoritmo personalizzato e' piu' performante di un altro generico mi pare
ovvio.
Se richiedi dimostrazioni fallo tu per primo altrimenti sarai altrettanto
mancante.
ciao


 prestazioni.
Sicuramente? Non credo e mi aspetto da voi esempi concreti. Per ora
avete solo espresso opinioni campate per aria.
Ciao,
Nicola

 avete solo espresso opinioni campate per aria.
Scusami ma questa è solo presunzione che le tue non lo siano.Tu non hai
mostrato nessun esempio concreto(almeno io non ne ho visti) di quello che
dici.
Io non ho la presunzioni di dire che ho ragione,ma se vale il presupposto
che un algoritmo personalizzato sia migliore di uno generico (come penso),
le opinioni campate per aria sono le tue.
ciao


 oggetti, sarà sempre più performante che fatta con un meccanismo generico. (...)
Non sono d'accordo. Prenscindendo dalla preparazione e dalle abilità
specifiche del programmatore, che cmq possono fare la differenza,
è tutto da dimostrare che le prestazioni siano sempre e comunque migliori,
e per 'migliori' intendo 'evidentemente migliori'.
Nel caso specifico di una programmazione ad oggetti col C
ritengo si riduca a mero esercizio di stile. Sarebbe fine a sé stessa.
Senza adoperare i costrutti/operatori/meccanismi OO messi a disposizione dal 
linguaggio, l'analisi del codice, la lettura e anche la scrittura
diverrebbero ardue imprese: il vantaggio di un linguaggio OO
è proprio quello di rendere *facile* l'implementazione in un paradigma
altrimenti 'simulabile' ma difficilmente 'interpretabile' con linguaggi diversi...


 diverrebbero ardue imprese: il vantaggio di un linguaggio OO
ma guarda che non si parlava di semplicità quello che hai scritto non
c'entra molto.
Lo standard,almeno per quanto ne so,non dice che c++ debba esserre più
veloce del C o il contrario e nemmeno prevede meccanismi per la generazione
del compilato .
Noi non stavamo parlando di qualche compilatore e ottimizzazioni degli
stessi ,ma era una stupida comparazione di implementazione a oggetti tramite
C e una simile tramite C++ e sua gestione degli oggetti. C++ nella sua
gestione degli oggetti usa algoritmi generici che non puoi confrontare con
algoritmi specifici generati da un codice C.Anche solo parlare di versalità
è sbagliato in quanto è personalizzabile con un'implemantazione specifica.
Se invece trascrivi il codice C in C++ le prestazioni dovrebbero essere
identiche  (come gia detto dipendono dal compilatore).
Non vedo il perchè continuate a parlare di semplicità o "bravura" del
programmatore senza che nessuno l'abbia presa in considerazione(almeno non
io).


mancante.
You miss the point: io non sto facendo alcuna affermazione, non ho
alcunché da dimostrare, sto invece ribattendo a delle affermazioni
precise chiedendo un minimo di dimostrazione.  E` del tutto lecito
aspettarsi che, a fronte di un'affermazione precisa, vi sia una
dimostrazione di quanto detto.

veloce del C 
Lo standard è una "formalizzazione" degli aspetti di un linguaggio che
non deve perdere compatibilità col passato, dal punto di vista delle
prestazioni.  Quindi, seppure indirettamente, lo standard lo afferma
eccome.

 eccome.
Ma da cosa l'hai capito? .
Non puoi pensare che uno standard preveda che il proprio linguaggio sia
sempre più veloce di un altro, è un qualcosa di impossibile,soprattutto se
l'altro linguaggio è molto simile.
Non capisco cosa vuoi dire....


 dimostrazione di quanto detto.
Però qui mi pare tu voglia perdere solo tempo.Sei tu che hai messo in dubbio
i consigli che ha dato goul_dukat senza dimostrarne il motivo.
Comunque mi fermo qui perchè stiamo diventando patetici :)))


 le opinioni campate per aria sono le tue.
Siccome il presupposto non e' stato dimostrato, fino a prova contraria
ho ragione.
Ciao,
Nicola


Hai ragione ?
Se il tuo scopo è solo aver ragione per me non è così importante.
Comunque io su questo argomento penso di aver detto tutto e di aver espresso
a sufficienza quello che pensavo...
Alla prossima ...


i consigli che ha dato goul_dukat senza dimostrarne il motivo.
Cioè, fammi capire: tu fai un'affermazione (perché non si parla di
"consigli", sono affermazioni precise), io ti chiedo di dimostrarla,
tu mi dici che sono io in torto, perché non ti dimostro il contrario.
Ammetterai che è piuttosto bizzarro ;-)

sempre più veloce di un altro
Ma posso pensare che uno standard venga progettato perché le
implementazioni del linguaggio non soffrano di problemi prestazionali
e mantengano compatibilità col passato.  Tanto per fare un esempio, lo
standard C++ non prevede alcuna "garbage collection".

 a sufficienza quello che pensavo...
No, il mio scopo e' scrivere cose di cui sono convinto e mettere in
evidenza le contraddizioni che vengono scritte sul newsgroup,
soprattutto quando alimentano miti che non hanno alcun fondamento
pratico. In generale ritengo di avere ragione fino a che qualcuno non
mi dimostra che ho torto; questo ne tu ne Goul lo avete fatto, bensi'
vi siete limitati ad esprimere dogmi.
Ciao,
Nicola

 vi siete limitati ad esprimere dogmi.
Quella che vedo è solo presunzione.Tu chiedi esempi e contesti il parere di
altri senza portarne alcuno.
Continueremo a ripetere le stesse cose ?
ciao :))


Andrea Laforgia wrote:
[cut]
senti sotto mano non ho link che mostrano questo ... avevo link di test 
effetuati confrontanto la stl con altri linguaggi ma non ho piu' neanche quel 
link ...
quindi senti visto che io non ti dimostro nulla puoi benissimo cercare tu le 
prove se le mie affermazioni sono vere o false ... o fai un po quel che vuoi 
basta che non continui solo a inficiare quello che dico senza dimostrare il 
contrario ... puoi prendere per vero o per falso quello che dico ma e' un'opione 
tua, come quello che ho scritto non trovanfo prove (e non avendo tempo di 
cercarle) rimane opinione mia ...
ciao

 ho ragione.
per tanto cosi' chiunque fino a prova contraria ha ragione ... :-\ mi sa che 
qua' non caviamo un ragno dal buco ...
ciao

Bobo O wrote:
[cut]
io sto studiando e non ho tempo di perdere 8 ore a cercare prove/test per 
dimostrare solo che un algoritmo che risolve un certo problema in C e' migliore 
dello stesso algoritmo generico in C++ (occupazione di memoria e di tempo cpu)
io mi chiedo solo una cosa ... come mai i SO si scrivono in C/asm e non in C++ 
all'ora ???
ora plz lasciamo pure le nostre idee sul NG alla valutazione del lettore e 
torniamo a spendere il nostro tempo per qualcosa di piu' utile a noi ... io devo 
finire di studiare e di trovare paper per il programma di CG che sto facendo ...
ciao

 non in C++ all'ora ???
Chi l'ha detto questo?
Che c'entra l'asm?
E poi c'è un problema di disponibilità di compilatori per C e per C++...
Compilatori C li trovi anche per microcontrollori, compilatori per C++
(che sano suffifientemente maturi) quasi fai fatica anche per x86...
-- 
Gerolamo

...

Certamente no, finche' vi limitate a pontificare e a diffondere FUD,
invece di presentare esempi concreti.
Ciao,
Nicola

 Continueremo a ripetere le stesse cose ?
No, io mi fermo qui perche' mi pare che tu abbia delle difficolta' a
seguire ragionamenti logici e sono stufo di perdere il mio tempo. Ti
prego solo di evitare di diffondere come verita' assolute tue opinioni
personali prive di fondamento.
Ciao,
Nicola

 all'ora ???
Perche' tutti i sistemi operativi di una certa popolarita' attualmente
in uso (vedi NT, Linux e Unix) sono stati concepiti quando il C++ non
era ancora un linguaggio maturo, o addirittura non esisteva.
Mi risulta che BeOS sia scritto in C++, e forse anche OS/400. In un
intervista di qualche anno fa Bill Joy affermava che avrebbe voluto
riscrivere Solaris in C++, ma che non se ne era fatto niente.
Ciao,
Nicola


Non ti rispondo più sulle altre motivazioni perchè non sai neppure il
significato della parola personalizzare oltre ad essere maleducato nel non
rispettare il pensiero altrui.
Hai tirato fuori argomenti tipo:
1) La bravura del programmatore: Ma che cosa c'entra sull'argomento in
questione ? è chiaro che se un programmatore è incapace non potrta mai
implementare un'algoritmo migliore come quello c++.
2) hai contestato il parere di altri senza portarne esempi validi e invece
li richiedi.Oltretutto è impossibile visto che sono architetture complicate.
3) Non sai il significato della parola personalizzare.
Questa è la definizione del garzanti alla parola "personalizzare":
"
adattare ai gusti, alle esigenze di una persona, di un gruppo di persone, di
una clientela: personalizzare un ambiente, un prodotto, un software.
"
Il tuo "generalizzare" un algoritmo  non potra' mai soddisfare tutti i
requisiti di un software meglio di uno scelto per le proprie esigenze.
Dovresti essere un po' meno arrogante e rispettare il pensiero altrui.
Noi non ti abbiamo insultato tu invece si..
addio



Come prima cosa bisognerebbe vedere che parte del codice è programmato in
C++.Il dire programmato in c++ non significa che in tutte le parti cruciali
(come puo' essere il kernel) sia usata una programmazione a oggetti di un
compilatore c++ "generico".
Ammettiamo pure  che un SO sia programmato "completamente in c++".
Questa ti sembra una cosa sensata?
Il kernel deve essere programmato nel miglior modo possibile e non affidarsi
a teconologie generiche che non hanno mai preso in considerazione un
"kernel"...
E adesso chiedimi di programmarti un kernel in c migliore di uno in c++.


cercarle) rimane opinione mia ...
Ah ecco, se parliamo di "opinioni" mi fermo qui.  Ti ricordo solo che
sono opinioni molto poco credibili, se non avallate da prove concrete.

all'ora ???
Sei solito fare affermazioni senza dimostrarle.  Non è affatto vero
che i sistemi operativi non si scrivano in C++, prova a guardarti
attorno, fai delle ricerche e impara.  Per quanto riguarda Linux, la
scelta sul C è stata determinata dalla maggiore semplicità e più
diffusa conoscenza di questo linguaggio (parole di Torvalds) e *NON*
dai possibili vantaggi prestazionali che si sarebbero ottenuti.

E adesso chiedimi di programmarti un kernel in c migliore di uno in c++.
Visto che fai certe affermazioni, sarebbe il minimo che tu facessi.

li richiedi.Oltretutto č impossibile visto che sono architetture complicate.
Se non sai portare esempi validi, č inutile esprimere un punto di
vista categorico ("č sempre cosě").  O si parla per esperienza, o si
esprime un'opinione (e si DICE che č un'opinione), oppure si sta
zitti.

 zitti.
hai detto la cosa giusta,non hai portato esempi allora stai zitto,oppure
espreimi il tuo parere rispettando quello delgi altri.


 >compilatore c++ "generico".  (ho messo anche le "" per evidenziarlo)
Con questo volevo dire che non è preferibile una gestione ad oggetto
generica come quella nei compilatori c++ "comuni". ( nota le "" )
Scusa cerca di capire prima quello che leggi e poi magari continui(o al
limite chiedi chiarimenti)...


 E adesso chiedimi di programmarti un kernel in c migliore di uno in c++.
Tanto ti tireresti indietro... ;-)
Ciao,
Nicola

 espreimi il tuo parere rispettando quello delgi altri.
http://www.catb.org/~esr/faqs/smart-questions.html#not_losing

 Tanto ti tireresti indietro... ;-)
il passo indietro lo fatto tu per primo  :))))
Ma poi che esempio vorresti  ??
una completa gestione ad oggetti scritta in C che ne simuli una scritta in
C++ ??
Per fare un confronto attendibile C e CPP bisognerebbe crearne una simile
tra i due.CI hanno messo anni per progettarne una che funzioni abbastanza
bene e tu ne pretendi una in pochi minuti da me ? ( sinceramente son ben
lontano da poterlo fare )
Tu quanto tempo ci metteresti ad implementarla ?
ciao :))
------------------------
http://visualwx.altervista.org/
nuova release 0.77b [freeware]


espreimi il tuo parere rispettando quello delgi altri.
SEI TU CHE DEVI PORTARE ESEMPI.
Te lo scrivo a stampatello così magari lo capisci una volta per tutte.
Quando avrai portato esempi di quanto affermi, allora si può
riparlare.  Per ora, considero quanto hai detto delle sciocchezze.  A
Giunti a questo punto, non esistono opinioni o "pensieri" da
rispettare, esiste la realtà dei fatti da constatare o meno con
dimostrazioni.

generica come quella nei compilatori c++ "comuni". ( nota le "" )
Ma che cosa cavolo significa "gestione ad oggetto generica" ???

creata una per le proprie esigenze.
Unix è nato quando il C++ non esisteva ancora.  Se fosse stato scritto
oggi, da zero, sarebbe stato riscritto tranquillamente in C++, come
d'altronde molti altri sistemi operativi.  Immagino, anche, che tu non
abbia mai sentito parlare di sistemi operativi object-oriented.
Alcuni esempi sono Mach, Choices, Chorus Micro-kernel, NachOS, Spring,
PenPoint OS, ecc...

 Te lo scrivo a stampatello cosě magari lo capisci una volta per tutte.
sei piuttosto noioso,oltre a non capire nulla di quello che leggi
addio
------------------------
http://visualwx.altervista.org/
nuova release 0.77b [freeware]


sei piuttosto noioso,oltre a non capire nulla di quello che leggi
Io penso, invece, di capire fin troppo ;-)
*plonk*

 *QUALE* genericità ?
questo dimostra quanto cose inutili hai scritto senza capire una mazza di
quello che si diceva.
e io che perdo tempo con te
addio


Mio dio cosa ho fatto :(

 creata una per le proprie esigenze.
Per forza. Unix e' stato scritto qualcosa come dieci anni prima che
fosse inventato il C++!
Ciao,
Nicola


si colpa tua :)))
in camera tua e senza cena stasera..
ciao :)
guarda che queste genere di discussione divertono,anche se alcuni elementi
stressano in quanto non sanno tenere una discussione in modo educato (parlo
in generale nessun riferimento a questo thread)  :P



ma che c'entra?
sei tu che porti esempi sbagliati.. stavamo parlando di c++ e la "SUA"
gestione ad oggetti.
Che poi non č provante prendere in esame un SO o qualsiasi altro
programma.Gli sviluppatori non prendono *SOLO* in considerazione il miglior
linguaggio per il miglior algoritmo ma anche tantissimi altri fattori.Per
esempio a me piace usare python,che certamente per tanti versi non puo avere
le stesse prestazioni di c++,perň lo trovo molto piů semplice e veloce nello
sviluppo (almeno per quanto mi riguarda).
ciao :)


 "eccezioni" [...]
Eckel può dire quel che gli pare. Resta il fatto che non c'è altro modo 
di annullare la costruzione di un oggetto, e questa è una gran vaccata
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.3. C, C++ and ASM developers
                               and beta testers are welcome!

 di annullare la costruzione di un oggetto, e questa è una gran vaccata
A me pare un meccanismo particolarmente solido. Almeno ti da la
garanzia che ciascun oggetto possa esistere solo in uno stato
consistente. Se non ti interessa puoi sempre rinunciare alla
costruzione ed implementare funzioni esplicite di inizializzazione.
Ciao,
Nicola

di annullare la costruzione di un oggetto, e questa è una gran vaccata
Che razza di ragionamento è ? "costruire" un oggetto significa una
cosa ben precisa.  Nicola ti ha già risposto in merito.

 Che razza di ragionamento è ?
stiamo parlando di C++ per la scrittura di sistemi operativi da qualche 
parte nel thread, no? bene, le eccezioni sono una complessità eccessiva 
che nessuno vorrebbe *dover* aggiungere, in quest'ambito


 A me pare un meccanismo particolarmente solido
ma perchè *deve* usare RTTI? perchè non può esserci nessuna alternativa 
*standard* che non sia così esageratamente type-safe? possibile che tra 
setjmp/longjmp e le eccezioni del C++ nessuno sia riuscito a trovare un 
compromesso accettabile?


 compromesso accettabile?
C'e' n'e' davvero bisogno?
Ciao,
Nicola

 compromesso accettabile?
C'e' n'e' davvero bisogno?
Ciao,
Nicola

 compromesso accettabile?
C'e' n'e' davvero bisogno?
Ciao,
Nicola

[Eckel] non ha voce in capitolo. 
Ma per piacere !

Scusate il messaggio molteplice. 
Posting.google.com
 faceva le bizze stamattina.
Ciao,
Nicola

 C'e' n'e' davvero bisogno?
no, ovviamente. Appunto parlo di "alternativa *standard*": ne posso già 
usare una non-standard, e funziona perfettamente. Solo, mi stupisce che 
sia rimasto questo buco nello standard, che praticamente preclude l'uso 
della STL in ambiente embedded (STLPort, se compilata senza il supporto 
per le eccezioni, anzichè throw usa abort. Immaginati un sistema intero 
che va in crash alla prima allocazione di memoria fallita)
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.4. C, C++ and ASM developers


 che va in crash alla prima allocazione di memoria fallita)
Non riesco a raffigurarmi il tipo di meccanismo che ti aspetti.
Basterebbe impedire che catch operasse sul tipo dell'eccezione, ad
esempio imponendo di lanciare interi? Come interagirebbe con lo stack
unwinding?
Ciao,
Nicola

 Come interagirebbe con lo stack unwinding?
lo stack unwinding non ne sarebbe toccato
