Newsgroup: it.comp.lang.delphi
Titolo: Delphi o C++?

Grazie dell'attenzione.
io credo che sia un mischietto di routine fatte in vari linguaggi (assembler
e C++ diciamo).
Mi spiego meglio.
Tu non è che puoi partire scrivendo un sistema operativo con un linguaggio
ad altissimo livello come Delphi ed andare a giostrare (senza un vero
sistema operativo) con l' hardware e la sua gestione.
In pratica Delphi è troppo legato a Windows e ogni chiamata viene fatta al
sistema operativo e poi ci pensa lui. Pensa alle API !!
Ugualmente con il C++. Oddio, forse con questo (tralasciando tutte le
chiamate al sistema operativo attuale) puoi fare qualcosa di bassissimo
livello, ma non so fino a che punto.
Quindi tu per fare un sistema operativo dovresti partire dal livello più
basso e farti una sorta di "scaletta" per arrivare ad un sistema grafico
come Windows o Linux.
Poi devi definire degli standard proprietari del tuo sistema operativo.
Quindi un formato eseguibile ecc....
Già per inventarmi un formato eseguibile mi prende un colpo. Ti rendi conto
?
Poi se inventi il formato eseguibile devi realizzare un compilatore per fare
quel formato eseguibile !! E' assurdo. A questo punto conviene studiarsi l'
attuale formato eseguibile di Windows e far riferimento a questo in modo
tale da mantenere anche una certa compatibilità.
Comunque secondo me è difficilissimo, inoltre devi conoscere a fondo la
macchina e l'assembler come il tuo nome altrimenti che routine fai ?
Se già si riuscisse a far un disco di avvio che avvia il PC con un sistema
operativo proprietario, sarebbe un gran passo avanti !!
In libreria avevo visto un bel manuale che parlava esclusivamente di sistemi
operativi analizzando le varie chiamate a basso livello ecc.....
Ok, ti saluto !!!
Ciaooo !!!
Antonio Tarolla
BSSoftware Tips Mailing - List Support

Non è neanche domanda da porsi: il C++!!


 operativi analizzando le varie chiamate a basso livello ecc.....
Ciao Antonio,
non credo però che un lavoro del genere possa essere fatto da una
persona sola (lascia stare Linus), anche perchè i pc oggi sono molto
evoluti; credo che convenga mettere su un gruppo di persone che sanno
usare VERAMENTE BENE il c/c++ e A PERFEZIONE l'assembler della macchina
su cui vuoi costruire il tuo so, e lavorare intensamente con loro,
altrimente da solo non giungi a nulla che possa essere chiamato Sistema
Operativo.
A dirla tutta ci avevo pensato anch'io a fare un so, ma avevo messo in
programma di impiegare un paio d'anni per mettX-Mozilla-Status: 0009e
avvii il pc ed emetta un suono. Ma era solo un'idea ;))

persona sola (lascia stare Linus)
Stai affermando che qualcosa non si puo' fare, "lasciando stare" chi
invece ci e' riuscito ! Non capisco !...
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
---------------------------------------------

 invece ci e' riuscito ! Non capisco !...
Sto dicendo che è una cosa talmente complessa che solo poche persone
sono capace di farlo: se non ci fosse stato Einstein, quanto tempo ci
sarebbe voluto per scoprire la relatività e le sue conzeguenze?
Volevo dire che fare un so non è cosa da tutti, Linus ci è riuscito, ma
quanti di noi ne sarebbero capaci? Io no sicuramente e molti altri sono
nella mia stessa condizione, quindi stavo solo dicendo (visto che non
conosco personalmente l'autore del messaggio originale) che fare un so è
una cosa talemnte complessa, ormai, che una persona da sola non ritengo
possa neanche iniziare a pensare di fare un so. Poi c'è sempre
l'eccezione che conferma la regola (ammesso che quello che io ho detto
sia una regola) e quindi ci si poù riuscire, ma è molto, molto
difficile.
Mi dispiace tu mi abbia frainteso.
Ciao

Fare un sistema operativo Windows-like non e' certo compito fattibile da una
persona sola. Quello che un buon programmatore, da solo, potrebbe fare, a
patto di avere sufficiente documentazione, tempo e soldi, sarebbe fare un
semplice sistema operativo tipo C64, che aveva un risorse hardware ben
definite (e limitate) e il cui scopo in definitiva era poco piu' che gestire
un interprete basic, una unita' a disco, e un modulo video davvero
elementare.
Anche per fare cio', comunque, servirebbe davvero tanta documentazione, e
parecchio tempo, oltre a ottime conoscenze di programmazione.
Ciao, Sandro


Uuhhhhmmm, vedo troppo spesso post che fanno domande un po'
discutibili!!
Programmazione a basso livello <=> C
L'assembler non lo considero, direi che e' veramente tramontato (a
parte determinati obiettivi/sottoparti).
Non si puo' parlare di C++, VB, OPascal per SO, emulatori, et similia,
non perche' non sia possibile, ma perche' introducono overhead
inaccettabili in applicazioni dove la velocita' di esecuzione e'
fondamentale.
Ciao
--
Piero Bonanno
bop...@libero.it
pie...@tiscalinet.it
bop...@tin.it
bpie...@hotmail.com
______________________________________________
"Madame, lei ha tra le gambe uno strumento
che puo' offrire piacere a migliaia di persone,
e tutto quello che sa fare e' grattarlo"
- Sir Thomas Beechan a una violoncellista

 parte determinati obiettivi/sottoparti).
Non sono completamente d'accordo...
L'assembly è poco utilizzato solo perchè richiede capacità ed esperienza e,
anche avendo entrambe queste doti, cmq richiede tempi lunghi per lo sviluppo
del software.
Certo è da stupidi scriversi un gestionale in assembly (ma se ci si riesce
allora + che stupidi direi che si è dei genietti...) ma per molte cose
[calcolo, grafica, ecc] l'asm è sempre il top...
Ovvio che, essendo anche _strettamente_ vincolato all'architettura hardware
su cui gira , è da escludere per tutti quei progetti che mirano alla
portabilità ma resta sempre un qualcosa di affascinante (controllo
_assoluto_ sulla macchina...)
Sono dell'idea che usare un linguaggio ad alto livello per costruire la
struttura sia l'ideale (ovviamente) ma, se si può, ottimizzare poi dei pezzi
di codice in asm sia una cosa pregevole...
Poi capita di vedere gente che si riscrive funzioni come la Pos o la Length
in asm per cercare di essere + veloci delle funzioni fornite con Delphi e si
comincia a sorridere... ;-)
Ciao :-)
--
(¯`·.¸¸.·´¯`·.¸¸.-> Andrea <-.¸¸.·´¯`·.¸¸.·´¯)
AntiSpam: rimuovere il trattino basso dall'indirizzo per rispondere
AntiSpam: remove the underscore from the e-mail address to reply

 comincia a sorridere... ;-)
mmm, io sono uno di quelli ... (a volte!!) e penso che sia positivo il
"tenersi in allenamento"
anche facendo cose abbastanza "inutili", per non dover, all'occorrenza,
iniziare a far fumare
il cervello.
Bah, questa č la mia opinione, c'č qualche altro "pazzerello" come me ?  8-)
Ciriciaoz ! Davide DG

comincia a sorridere... ;-)
Vedi RX... :-)


 il cervello.
D'accordo, sperimentare è sempre un'ottima cosa, se lo fai per motivi
"didattici" è tanto di guadagnato, ma avere la presunzione di riuscire a
riscrivere (magari in OP come ho visto fare) funzioni che sono scritte in
asm ottimizzato "coi fiocchi" è un po' troppo...


 Vedi RX... :-)
Non so, non le ho mai installate... [anche se le ho scaricate + volte...]



    Diciamo che Assembly non è proprio tramontato. E' vero che con
l'introduzione dell'architettura RISC i compilatori fanno veramente miracoli
(alcune volte ottimizzano il codice macchina talmente bene da essere 1,5
volte più veloce di quello scritto da un essere umano) però è vero anche che
se si conosce come vengono effettivamente gestiti i dati nei registri e
nell'elaboratore, allora queste conoscenze determinano il tipo di
programmazione usata. Quello che voglio dire è che assembly fornisce una
forma mentis che permette di migliorare il codice ancora quando è in fase di
scrittura (se io so già che tipi di dato andrò ad inserire e se so che il
processore li gestisce meglio se faccio un ciclo in un determinato modo al
posto di un altro, scriverò quello più adatto)...
    E in più non dimentichiamo la programmazione real - time dove assembly
detta ancora legge...
    Saluti!
______________________________________
Gian Luca Dalla Torre
E - Mail: 
gianluca....@casteo.net
______________________________________

 fondamentale.
Gia' ma se in C++ o OP fai il tuo bel compilatore JIT come fanno i
principali emulatori di console recenti (e gli emulatori win per mac) non
hai problemi, tanto il programma gira sul tuo assembler.
Ciao Uberto

hai problemi, tanto il programma gira sul tuo assembler.
Per compilatore JIT intendi un compilatore che traduce una volta per
tutte il codice nativo della console in assembler del PC? Vabbe' cosi'
e' sleale :-) si potrebbe fare anche in QBasic! :-)


Non so, non le ho mai installate... [anche se le ho scaricate + volte...]
Toh! La cosa e' + unica che rara! Perche'?


 e' sleale :-) si potrebbe fare anche in QBasic! :-)
Tecnicamente sì. Cmq mi piacerebbe fare qualche esperimento in delphi anche
banale come un add di due interi compilato in asm e lanciato dal programma.
Ciao Uberto
--
Uberto -- D&D Support Team
Per risposte professionali e notizie abbonatevi a
dedonline, 
http://www.marcocantu.it/dedonline
.

 Toh! La cosa e' + unica che rara! Perche'?
Non ne ho mai avuto la necessità... anche se spesso sento parlare di
componenti che dovrebbero essere proprio buoni...
Ciao :-)
Ps: scusa il ritardo nella risposta...


detta ancora legge...
Io ho visto pubblicita' sul Dr Dobb's Journal, di ambienti di
programmazione in C per sistemi real-time... :-)


ereditarietą multipla.
Le eccezioni ci sono da tempo. Sono d'accordo sull'ereditarieta' e su
proprieta'/interfacce, sulle classi friend temo siano inevitabili
(d'altronde in OP c'e' quel maccanismo dell'accesso dalla unit..).
Aggiungerei la classe TObject intrinsecamente comune a tutte le
classi.
Io dell'OP non sopporto: sintassi orrenda, parole chiave a iosa e
alcune incongruenze formali (obj:=TObject.Create e' mostruoso).


 alcune incongruenze formali (obj:=TObject.Create e' mostruoso).
Beh... all'inizio si resta interdetti ma a me fa schifo obj.create del java.
In OP e' molto piu' chiaro cosa si sta creando (=allocare memoria) e chi la
sta puntando.
Detto questo anche a me alcune cose non piacciono.
L'end del Case e del With sarebbe bene se fosse diverso dall'end normale.
Non si capisce perche' non vanno il punto e virgola prima dell'else (cioé il
motivo lo so ma non mi piace lo stesso).
Il permesso di non mettere il punto e virgola prima di qualsiasi end
ecc. ecc.
Ciao Uberto

 ecc. ecc.
E' più o meno come sopra: il punto e virgola deve separare un'istruzione
dell'altra, ma è inutile metterlo prima di un end perchè non deve
eseguire nessun'altra istruzione

ecc. ecc.
Purtroppo l'OP tradisce l'origine del Pascal di essere un linguaggio
"severo" a fini educativi. Il C/C++ ha soprattutto il vantaggio di
essere nato con "il programmatore" in mente.


componenti che dovrebbero essere proprio buoni...
Piu' che altro sono l'estensione naturale della VCL. E poi c'e' un
pugno di unit StrUtils, DateUtils, BDEUtils ecc veramente utili.


 essere nato con "il programmatore" in mente.
Non estremizziamo... direi che l'OP resta un ottimo linguaggio, anche a
fronte del C++... ogni linguaggio ha le sue magagne...
Ciao :-)


fronte del C++... ogni linguaggio ha le sue magagne...
Non mi riferisco alla qualita'. E' un linguaggio un po' prolisso, poco
adatto a trucchi bastardi (vedessi certe cose che si possono fare in C
]:) ), ma tutto sommato si e' rivelato adatto alla tendenza odierna di
astrarre di piu' il programmatore dalla macchina (geniale l'idea di
nascondere i puntatori nella gestione degli oggetti, se non sbaglio e'
stata ispirazione anche per i progettisti di Java).


 Tipo endcase o endwith? Io mi aiuto con dei commenti del tipo
Esatto
Solo che non e' il massimo.
Ciao Uberto

Semplice divergenza di opinioni.
Infatti, non e' una cosa su cui mi strappo i capelli (gia' pochi di
per se') :-)


 stata ispirazione anche per i progettisti di Java).
Mah, con Delphi ti puoi spingere anche a basso livello (addirittura
inserendo proc. asm...).
Cmq per il discorso degli oggetti-puntatori: parlavo giusto di questo tempo
fa con una persona che conosco che è un ottimo programmatore sia C++ che
Delphi (e anche altro (!) )...
Se ti metti nell'ottica di un programmatore C++ il fatto di non "vedere" i
puntatori veri e proprio può sembrare un "accrocco strano"...
In effetti una delle critiche + pesanti che si fanno a VB è di "ravanare di
brutto" sotto il codice che scrivi e (agli occhi di un "purista") questa
comodissima peculiarità di Delphi può sembrare un passo verso quella
direzione...
Il mio parere in proposito (e anche quello della persona con cui parlavo) è
che cmq Delphi resta un ottimo ambiente, coerente anche sotto questo punto
di vista alla logica della "pulizia" rispetto della "meccanicità" del C++...


di vista alla logica della "pulizia" rispetto della "meccanicità" del C++...
Sono due cose diverse. E' anche un po' ingiusto paragonarli. Il C++ e'
davvero una bestia di linguaggio, pero' Delphi e' + protettivo e
docile. Ma non mi fare dire altro... :))


 Sono due cose diverse. E' anche un po' ingiusto paragonarli.
Condivido in pieno, la mia considerazione non era "assolutistica". ;-)
