Visual Basic/Visual C++ vs Delphi
Paolo
Ho sempre utilizzato Delphi e mi trovo bene.
Vorrei comunque sapere quali siano, secondo voi, attualmente,
le differenze principali tra Delphi e Visual Basic/Visual C++.
Non voglio una flame!!!
Cerco differenze oggettive, non questioni "di gusto" :P
Saluti
Paolo
guastatore
> Vorrei comunque sapere quali siano, secondo voi, attualmente,
> le differenze principali tra Delphi e Visual Basic/Visual C++.
Se fai una ricerca su Google, tipo visual c++ vs delphi o visual basic
vs delphi viene fuori l'impossibile.
Se invece vuoi delle ottimizzazioni di codice per Delphi che risultano,
tavolta, superiori a quelle ottenute con il C++ puoi dare un'occhiata a
questo sito:
http://www.optimalcode.com/
Ciao
guastatore
Alberto Salvati
Io posso dirti qualcosa riguardo vb.
Lascio il c++ a chi lo conosce (beato lui....!)
Difetti di vb vb5/6
le app generate si portano dietro tonnellate di dll
l'unico tipo di componente utilizzabile è l'activex
non puoi mettere + di 250 controlli per form senza usare l'array di
controlli
l'ambiente di sviluppo è scomodo
l'help fornito solo in formato chm è a dir poco frustrante
non è object oriented: non ha la ereditarietà
la tecnologia di accesso ai dati è cambiata da vb4 a vb5 e poi da vb5 a vb6
il porting di progetti non è garantito. un prj vb4 non fa su vb5
lento a runtime
core di funzioni estremamente limitato
gestione degli errori basata su costrutto ON ERROR GOTO, risalente al
quickbasic 4.5 x dos (anno 1990)
per vb.net sono ripartiti praticamente da zero. xche, secondo te?
Pregi di vb
Non 6 tenuto a dichiarare le variabili o a liberare le risorse allocate e
non + utilizzate (???)
E' di Microsoft (alimentiamo il monopolio di zio billy)
Svantaggi di vb.net
ti tocca imparare un nuovo linguaggio: tanto vale passare a c# o c++ o a
delphi
solo app basate su clr
la clr si basa su .net
Le 3 cose sono troppo nuove, ergo, bug bug bug......
Vantaggi di delphi
un exe delphi dipende solo da una dll (stvclnonsoche.dll) ed è molto
compatto
uso sia di activex che di vcl
non 6 obbligato a usimulare gli array di controlli
l'ide di delphi è telepatica
help in formato HLP
è Object oriented, eslcusa la ereditarietà multipla
ho personalmente preso un progetto delphi1 (16bit) e, modificando solo
alcune uses, l'ho ricompilato in delphi5 (32 bit) e dopo 2 giorni di test
molto molto cattivi lo abbiamo dato al cliente. Tempo totale del porting
inferiore a 3 giorni)
velocità di esecuzione molto elevata
core di funzioni e di classi molto esteso (in pratica ti ci perdi...)
Svantaggi di delphi
come in pascal devi mettere ";" alla fine delle righe ( x alcuni è uno
svantaggio: non x me)
molto tipizzato ( x alcuni è uno svantaggio: non x me)
devi liberare a mano le risorse allocate ( x alcuni è uno svantaggio: non x
me)
Bye
A
Jax
> l'ide di delphi è telepatica
Ma rotfl
--
Jax
Journeying Artificial Xenomorph
Lis
> Difetti di vb vb5/6
> l'ambiente di sviluppo è scomodo
Bah...qui penso sia questione di abitudine, non credi? Per il resto sono
sostanzialmente d'accordo e aggiungerei tra i difetti di VB che spesso ci
sono dei problemi di registrazioni di componenti e di versioni delle varie
dll, specie usando crystal report o l'accesso ai db
--
Lis
ICQ@Home #7317603sette ICQ@Work #16285702tre
Mercatino: http://lis77.bravepages.com (aggiornato *con foto*: 16/06/03)
Carmine Moleti
> Ho sempre utilizzato Delphi e mi trovo bene.
Ma va? :)
> Vorrei comunque sapere quali siano, secondo voi, attualmente,
> le differenze principali tra Delphi e Visual Basic/Visual C++.
- Entrambe utilizzano il paradigma ad oggetti
- C++ prevede l'ereditarietà multipla degli oggetti. Delphi solo delle
interfacce
- C++ consente l'overloading dei metodi e degli operatori. Delphi solo dei
metodi
- C++ gestisce i template. Delphi no
- C++ consente la definizione delle variabili in situ. Delphi ha una propria
sezione per la dichiarazione
- C++ gestisce l'inlining delle funzioni. Delphi no (?)
- C++ ha il preprocessore per le macro. Delphi no.
- C++ ha la possibilita di scrivere VXD. Con Delphi no (perchè?)
- C++ ha il ++. Delphi no
- C++ ha l'operatore ternario a ? b : c. Delphi no
- C++ ha una tipizzazione molto maggiore del C. Delphi è un mastino riguardo
la tipizzazione.
- C++ permette le assegnazioni multiple (anche se ogni tanto ci si può
incasinare). Delphi no
C++
int a=b=c=1974;
Delphi
a : integer = 1974;
b : integer = 1974;
c : integer = 1974;
Però in C++:
int *a,b,c;
definisce un puntatore ad intero(a) e 2 interi (b,c)
Delphi:
a,b,c : ^integer;
definisce 3 puntatori ad interi.
C++
for(int i=0;i<10;i++){
}
Delphi
Var
i : integer;
for i:=0 to 9 do
begin
end;
C++
#define PRINT(a) cout << #a "=" << a << endl;
int main(){
int i=0;
PRINT(i++);
return 0;
}
stampa: i++ = 1
Questa caratteristica è detta "stringizing"
Inoltre il preprocessore delle macro ha un'altra caratteristica simpatica:
#define Campo(a) char* a##_string; int a##_intero
int main(){
Campo(uno);
Campo(due);
return 0;
}
Campo(uno) definisce due variabili un puntatore a carattere ed un intero.
char *uno_string;
int uno_intero;
Questo è chiamato "Token Pasting".
In C++, per ragioni di compatibilità con il C è consentita una cosa del
genere:
char* c = "Pippo";
Il che produce un array costante di caratteri, e ti permette di modificarne
(non in tutti i compilatori)
il contenuto!
La scrittura precedente rispettando le regole del C++, dovrebbe essere:
char c[] = "Pippo";
In Delphi sei responsabile per la creazione e la distruzione di un oggetto.
In C++ il distruttore viene chiamato automaticamente al momento in cui
l'oggetto va fuori dallo scope.
Un'altra cosa che in C++ può essere fonte di confusione è l'uso delle
costanti in un classe.
Se in una calsse dichiariamo una costante per mezzo di "const", il C++
cade vittima di una crisi di identità e si comporta come in C.
"const" finisce col significare che la costante è tale solo per la durata
dell'istanza della classe.
Infatti, alla dichiarazione della costante, non possiamo associare
anche una definizione.
Il valore iniziale della costante deve essere definito nel costruttore!
Ciò si traduce nel fatto che ogni istanza della classe può avere
un valore differente per la costante!!!
Inoltre, all'interno del costruttore nessuno ci vieta di cambiare il
valore della costante, e persino di lasciarla indefinita per un pò di tempo.
Per ovviare a questo inconveniente, in C++ si utilizza la "constructor
initialization list". Essa è, appunto, una lista che precede la definizione
del costruttore.
Es:
class Pippo{
const int costante;
public:
Pippo();
};
Pippo::Pippo(): costante(1974) {
... codice del costruttore...
}
In Delphi, non mi risulta sia possibile definire una costante in una classe.
C/C++ ha una diffusione più ampia rispetto al ns beneamato Delphi.
Delphi ha una curva di apprendimento meno ripida rispetto a C/C++.
Delphi ha un IDE...un IDE...ha L'IDE.
Non so valutare Visual C++ perchè non l'ho mai visto, contrariamente
al C++ Builder.
Spero di non aver scritto troppe fesserie. :)
(Aka: Ho perso un'occasione per starmene zitto :) )
> Non voglio una flame!!!
Che ne dici delle lame rotanti? ;)
Saluti,
Carmine
Max T.
> sono dei problemi di registrazioni di componenti e di versioni delle varie
> dll, specie usando crystal report o l'accesso ai db
... SACROSANT-ISSIMO, LIS!
Però diciamolo, una volta per tutte: VB è una vera schifezza.
Io l'ho appena abbandonando, dopo aver passato uno degli anni più "bui" dei
miei 18 di programmazione sw gestionale in totale.
Per me va bene solo a chi non ha avuto modo di provare nient'altro.
Oppure a chi fa il programmatore a tempo perso, come ce ne sono tanti.
Io invece lo faccio per guadagnarmi il pane quotidiano, e se andassi ancora
avanti con VB per sviluppare applicazioni che DEVONO funzionare mi sa che
sarei costretto a cambiare lavoro.
Dico solo questo: ci metti un giorno per fare una cosa, e poi ce ne metti
altri tre per mettere a punto la corretta procedura di installazione della
cosetta che hai fatto che funzioni di sicuro sulle varie versioni di
Windows!!
E quando vai ad installare dal cliente ti può uscir fuori la sorpresina per
cui non riesci comunque ad intallare!!
Microsoft probabilmente ancora non ha capito che in Italia ci sono molte
meno persone a perder tempo, capelli e testa per "collaudare" quello che fa
di quante ce ne siano in realtà negli USA.
Su Delphi ancora non dico nulla: inizio ora.
MA temo che non possa essere sicuramente peggio di VB!!
Max T.
P.S.: Scusate lo sfogo, ma.... veramente sono ink.....issimo!
--------------------------------
Inviato via http://usenet.libero.it
a2rg14
news:Xns939F517DE7BDCpa...@193.70.192.192...
> Vorrei comunque sapere quali siano, secondo voi, attualmente,
> le differenze principali tra Delphi e Visual Basic/Visual C++.
tecnicamente un confronto tra VB e (delphi & VC++) non credo sia
sostenibile, in quanto vb č un linguaggio di programmazione di alto livello
mentre delphi e c++ sono linguaggi di medio livello.
fatta la premessa sul vb, dunque il confronto č sostenibile tra Delphi e
VC++
a livello di linguaggi di programmazione credo che tolte le differenze della
semantica del linguaggio, siano tutti e due dei gran linguaggi per certi
versi molto simili.(ci vorrebbe un libro per spiegare le differenze dei due)
a livello d'ambienti di sviluppo...
tanti anni fa in una galassia molto lontana.... ;))programmavo con i
compilatori borland (sto parlando di dos e win 16) in Turbo c/c++ a quei
tempi, pensavo se fosse cosi impossibile avere un ambiente di sviluppo tipo
delphi.
Ovvero "non perdere tempo" nella costruzione di maschere & C.
delphi ha realizzato questo in pieno, č un vero ambiente RAD. quindi per chi
lavora in gestionali e compagnia bella č una manna dal cielo, in quanto di
devi concentrare *solo* sulla logica del tuo applicativo. e questo in
termini economici vuol dire molto, anzi di questi tempi č tutto. (almeno per
me)
sempre a livello di ambienti, tralasciamo la tecnologia che ci sta sotto, ho
trovato che visual studio per certi versi sia perfino migliore di delphi,
sopratutto nella gestione di progetti di medie e grandi dimensioni.
ma ho sentito dire (o letto da qualche parte) che tale ambiente sia nato
dalla collaborazione con Borland, qualcuno sa qualcosa di piů?
ciao a tutti!
roberto
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
Lis
> Per me va bene solo a chi non ha avuto modo di provare nient'altro.
> Oppure a chi fa il programmatore a tempo perso, come ce ne sono tanti.
> Io invece lo faccio per guadagnarmi il pane quotidiano, e se andassi ancora
> avanti con VB per sviluppare applicazioni che DEVONO funzionare mi sa che
> sarei costretto a cambiare lavoro.
Sono d'accordo che ha parecchi punti deboli (e infatti ho cercato in tutti i
modi di liberarmene) ma è talmete richiesto che temo andrà avanti ancora per
parecchi anni. Ora fortunatamente sono riuscito anche io a passare a Delphi
e speriamo che, sul lungo periodo, si riveli veramente migliore
Morde
wrote:
>- Entrambe utilizzano il paradigma ad oggetti
>- C++ prevede l'ereditarietà multipla degli oggetti. Delphi solo delle
>interfacce
Premetto che provengo dal c++.
Qui si potrebbe aprire una lunghissima discussione sulla teoria dell'OOP, mi
avevano sempre detto che non e' corretto ereditare da piu' classi
contemporaneamente, poi quando ho conosciuto java mi sono reso conto di cosa
significasse questa affermazione.
>- C++ gestisce i template. Delphi no
A me i template li hanno sempre sconsigliati: hanno il difetto di papparsi
molta memoria e generare obj grossissimi.
>- C++ ha il preprocessore per le macro. Delphi no.
Gia', questo mi manca.
>- C++ ha il ++. Delphi no
ROTFL !!!! :-))
>- C++ ha l'operatore ternario a ? b : c. Delphi no
In passato venni assalito dal "mitico" Laforgia per essermi lamentato di
questa mancanza :-)
>- C++ ha una tipizzazione molto maggiore del C. Delphi è un mastino riguardo
>la tipizzazione.
RRROOOOOOOOAAAARRRR (dovrebbe sembrare un ruggito....)
>- C++ permette le assegnazioni multiple (anche se ogni tanto ci si può
>incasinare). Delphi no
Mi manca anche questa comodita'.
>C/C++ ha una diffusione più ampia rispetto al ns beneamato Delphi.
>Delphi ha una curva di apprendimento meno ripida rispetto a C/C++.
Sottoscrivo.
>Delphi ha un IDE...un IDE...ha L'IDE.
Sottoscrivo energicamente.
>Che ne dici delle lame rotanti? ;)
Lame rotanti? eh eh he....
Per restare nell'OT :) evocherei la mitica alabarda spaziale.
Nulla fu piu' sconvolgente per la mia mente di fanciullo che vedere goldrake
brandire quella mitica arma da samurai tecnologico. (fu in quel periodo felice
della mia vita che decidetti di imparare le arti marziali)
>
>Saluti,
>Carmine
>
Ciao carminie' (per dirla alla Salvati)
--
Morde.
(morde at programmer dot net)
Carmine Moleti
> >- C++ prevede l'ereditarietà multipla degli oggetti. Delphi solo delle
> >interfacce
> Premetto che provengo dal c++.
Io sto cercando di avvicinarmici :) (questioni psicologiche)
> Qui si potrebbe aprire una lunghissima discussione sulla teoria dell'OOP,
mi
> avevano sempre detto che non e' corretto ereditare da piu' classi
> contemporaneamente, poi quando ho conosciuto java mi sono reso conto di
cosa
> significasse questa affermazione.
Spiega, spiega :) (non conosco Java)
Personalmente, non ho ancora ben chiaro da quale parte schierarmi :)
Potrebbe far comodo ereditare da più genitori, premettendo che non mi
ci sono mai applicato più di tanto, non riesco a trovare un esempio
per cui possa essere necessario un simile strumento.
> >- C++ gestisce i template. Delphi no
> A me i template li hanno sempre sconsigliati: hanno il difetto di papparsi
> molta memoria e generare obj grossissimi.
Interessante. Magari li si può relegare alla fase di "prototipazione".
> >- C++ ha il preprocessore per le macro. Delphi no.
> Gia', questo mi manca.
> >- C++ ha l'operatore ternario a ? b : c. Delphi no
> In passato venni assalito dal "mitico" Laforgia per essermi lamentato di
> questa mancanza :-)
Eh si, conosco le diatribe e le lotte feroci tra i sostenitori del "?" ed i
detrattori.
Chi è a favore, cita in primis la sinteticità ed il potere espressivo.
Chi è contro, ribatte che non ci si capisce (spesso) una mazda.
ecc...
> >- C++ ha una tipizzazione molto maggiore del C. Delphi è un mastino
riguardo
> >la tipizzazione.
> RRROOOOOOOOAAAARRRR (dovrebbe sembrare un ruggito....)
Santa, santa santissima cosa.
> >- C++ permette le assegnazioni multiple (anche se ogni tanto ci si può
> >incasinare). Delphi no
> Mi manca anche questa comodita'.
Fondiamo il club per i diritti delle assegnazioni multiple?
> >C/C++ ha una diffusione più ampia rispetto al ns beneamato Delphi.
> >Delphi ha una curva di apprendimento meno ripida rispetto a C/C++.
> Sottoscrivo.
Mah, forse il Pascal soffre della sindrome dello scolaretto.
Mi sono spesso sentito dire che il Pascal è preferibile per questioni
didattiche...e poi ci catapultano in un mondo di C++
Pensa che al terzo anno, feci i salti mortali per trovarmi
in una sezione dove si studiasse il C (era il 1990), e quell'anno
passarono al Pascal/Fortran/Basic/Assembly :))
> >Delphi ha un IDE...un IDE...ha L'IDE.
> Sottoscrivo energicamente.
> >Che ne dici delle lame rotanti? ;)
> Lame rotanti? eh eh he....
> Per restare nell'OT :) evocherei la mitica alabarda spaziale.
<OT>
Disintegratori paralleli, no?? Eh, no?
Atlas Ufo Robot Grandizer, per gli amici Glodrake, è stato uno dei
primi robot a funzionare ad energia solare!
> Nulla fu piu' sconvolgente per la mia mente di fanciullo che vedere
goldrake
> brandire quella mitica arma da samurai tecnologico. (fu in quel periodo
felice
> della mia vita che decidetti di imparare le arti marziali)
Diciamo che quello, anche per me, è stato un punto di partenza.
Mi appassionai al Giappone, ed è inevitabile approdare a quei lidi.
Vai di shotokan ecc...
</OT>
Saluti spaziali,
Carmine
guastatore
> tecnicamente un confronto tra VB e (delphi & VC++) non credo sia
> sostenibile, in quanto vb è un linguaggio di programmazione di alto
> livello mentre delphi e c++ sono linguaggi di medio livello.
Potresti spiegarmi, cortesemente, il significato di "alto livello" e
"medio livello" ?
> Ovvero "non perdere tempo" nella costruzione di maschere & C.
> delphi ha realizzato questo in pieno, è un vero ambiente RAD. quindi
> per chi lavora in gestionali e compagnia bella è una manna dal cielo,
> in quanto di devi concentrare solo sulla logica del tuo applicativo.
> e questo in termini economici vuol dire molto, anzi di questi tempi è
> tutto. (almeno per me)
Non solo è un RAD, ma un RAD completamente orientato agli oggetti.
Lascia spazio praticamente ad ogni tipo di iniziativa, per esempio
usare il RAD per la prototipizzazione e puntare invece sulle Business
Classes per lo sviluppo del BOM.
Su libero.database si sta sviluppando un thread interessante proprio
sugli OPF (Object Persistence Framework); Delphi ti consente di fare
questo e anche di più (anche il C++ suppongo, ma non amo molto la sua
sintassi e la poca chiarezza del codice, parere personale).
> sempre a livello di ambienti, tralasciamo la tecnologia che ci sta
> sotto, ho trovato che visual studio per certi versi sia perfino
> migliore di delphi, sopratutto nella gestione di progetti di medie e
> grandi dimensioni.
Non so quanto possa essere vero. Ci sono cose che probabilmente Delphi
non riesce a fare, dato che costituisce un solo ambiente. Ma a me è
sembrato sempre un ambiente piuttosto completo, considerato anche che
il linguaggio da imparare rimane sempre e solo uno, insomma una
specializzazione non può che far risparmiare del tempo.
Ciao
Antonio
Morde
wrote:
>
>Spiega, spiega :) (non conosco Java)
>
>Personalmente, non ho ancora ben chiaro da quale parte schierarmi :)
Non e' facile spiegare senza inoltrarsi in discorsi difficili, a volte
capziosi, ma voglio evitare di aprire un thread dal sapore accademico e
fortemente annoying. Ci sono in rete molti riferimenti a questa disputa.
Inoltre, onestamente, non mi ritengo all'altezza di trattare certe
argomentazioni complesse.
Ti diro' solamente che tutto puo' essere usato, purche' sia tutto controllato
dal buonsenso.
In c++ puoi scrivere questo codice:
class CBuyTitle : public IFrameWindow,
public ICommandHandler,
public ICnrHandler,
public ICnrEditHandler,
public ISelectHandler
In java, che e' come delphi, sarebbe un errore: e' ammesso ereditare solo da
una classe per volta, mentre puoi ereditare da piu' interfacce.
Questione, imho, di sapere *cosa* si vuole fare: da qui, trovare il *come* e'
solo questione di tempo e di possibilita' che si hanno.
>Pensa che al terzo anno, feci i salti mortali per trovarmi
>in una sezione dove si studiasse il C (era il 1990), e quell'anno
>passarono al Pascal/Fortran/Basic/Assembly :))
In quei mitici periodi avevo realizzato un prototipo di chat collegando 2
msx,e programmandone gli z80 in assembler con lo ZEN della KUMA. te lo
ricordi?
Passavo delle ore a scrivere programmi in assembler, centinaia e centinaia di
righe, mi divertivo un mondo a ricostruire mentalmente il flusso del
programma.
(forse e' per questo che oggi sono conciato cosi' :-D )
Ciao
Alberto Salvati
>
> Bah...qui penso sia questione di abitudine, non credi?
Solo in parte.
Ad esempio, non credo che il tool di vb pe rla creazione dei menu possa
risultare per qualcuno + comodo di quello previsto dall'ide di delphi.
> Per il resto sono
> sostanzialmente d'accordo e aggiungerei tra i difetti di VB che spesso ci
> sono dei problemi di registrazioni di componenti e di versioni delle varie
> dll, specie usando crystal report o l'accesso ai db
Mea culpa, nel mio post ho tralasciato questa importante sottolineatura,
dimenticando che ci sono persone che non hanno tozzato contro i casini degli
activex.
Tnx
A
Alberto Salvati
template?? :((
> - C++ consente la definizione delle variabili in situ. Delphi ha una
propria
> sezione per la dichiarazione
ottimizzi ma paghi in leggibilità del codice.
> - C++ ha il preprocessore per le macro. Delphi no.
Chi viene da clipper sa. cosa si puo fare con le mcro del preprocessore ..
:))
> - C++ ha la possibilita di scrivere VXD. Con Delphi no (perchè?)
Mi pare se ne fosse gia parlato di 'sta cosa, ma ora non ricordo.
A
Carmine Moleti
> capziosi, ma voglio evitare di aprire un thread dal sapore accademico e
> fortemente annoying. Ci sono in rete molti riferimenti a questa disputa.
> Inoltre, onestamente, non mi ritengo all'altezza di trattare certe
> argomentazioni complesse.
> Ti diro' solamente che tutto puo' essere usato, purche' sia tutto
controllato
> dal buonsenso.
Fondamentale, direi.
[...Cut Esempio...]
> In java, che e' come delphi, sarebbe un errore: e' ammesso ereditare solo
da
> una classe per volta, mentre puoi ereditare da piu' interfacce.
> Questione, imho, di sapere *cosa* si vuole fare: da qui, trovare il *come*
e'
> solo questione di tempo e di possibilita' che si hanno.
Mi ci vorrà del tempo e qualche approfondimento sull'ereditarietà multipla
per comprenderne l'utilizzo nella pratica di programmazione.
Let's go...
> >Pensa che al terzo anno, feci i salti mortali per trovarmi
> >in una sezione dove si studiasse il C (era il 1990), e quell'anno
> >passarono al Pascal/Fortran/Basic/Assembly :))
> In quei mitici periodi avevo realizzato un prototipo di chat collegando 2
> msx,e programmandone gli z80 in assembler con lo ZEN della KUMA. te lo
> ricordi?
Fino alle superiori, ero dall'altra parte della barricata (leggi: Commodore
64, 6502 ecc...).
Poi, a laboratorio di elettronica e sistemi ci hanno fatto sciroppare lo
Z80.
Ho imparato ad apprezzarlo di più.
Dopo qualche periodo siamo zompati sul 68000...gaudio e giubilo comunitario
al seguito.
All'epoca possedevo un'Amiga 500 (con ben 1MB Fast Ram).
> Passavo delle ore a scrivere programmi in assembler, centinaia e centinaia
di
> righe, mi divertivo un mondo a ricostruire mentalmente il flusso del
> programma.
Ho ancora conservati i dischetti con il frame work in assembly che avevo
scritto
per realizzare un video game.
Giornate passate a scrivere/provare il tutto. Alla fine avevo realizzato
(involontariamente, visto che non avevo la benchè minima nozione di OOP)
una serie di classi per la gestione di:
- Sprite
- B.OB
- Eventi
- Suoni
Fino a qualche tempo fa, ero in cerca di qualcuno nei paraggi che mi
potesse aiutare a recuperare i sorgenti dal dischetto in formato 1.68
comune all'epoca degli Amiga 1200/3000/4000 ecc...
> (forse e' per questo che oggi sono conciato cosi' :-D )
...circa un mese fa, ho cercato di spiegare alla mia ragazza
il funzionamento delle reti neurali...(scopro il fianco a
battute di ogni genere, lo so :) )
Visto che la mia è completamente andata, sto cercando
di farmene una decente e funzionante.
Salumi,
Carmine
Alberto Salvati
mi
> avevano sempre detto che non e' corretto ereditare da piu' classi
> contemporaneamente, poi quando ho conosciuto java mi sono reso conto di
cosa
> significasse questa affermazione.
Io la metterei in quella lista di cose che vanno usate proprio se non esiste
alcuna alternativa etc.
Tipo ultima chanche....
> >- C++ gestisce i template. Delphi no
> A me i template li hanno sempre sconsigliati: hanno il difetto di papparsi
> molta memoria e generare obj grossissimi.
Aridaglie!
Che sono 'sti template?
> >- C++ permette le assegnazioni multiple (anche se ogni tanto ci si può
> >incasinare). Delphi no
> Mi manca anche questa comodita'.
Azz! Nuon vuo' fa proprio niente, tu?? ;))))
A
Alberto Salvati
livello
> mentre delphi e c++ sono linguaggi di medio livello.
Io so che il c++ è a medio livello, delphi invece no.
> sempre a livello di ambienti, tralasciamo la tecnologia che ci sta sotto,
ho
> trovato che visual studio per certi versi sia perfino migliore di delphi,
Domanda da 10cents di euro: in cosa?
A
Morde
wrote:
>Che sono 'sti template?
Ho trovato questa definizione, la piu' semplice, spero ti possa aiutare:
(fonte: http://www.fgasoftware.com/cppelements.html#templates )
"I template, che sono ormai supportati da tutti i compilatori moderni,
permettono di parametrizzare i tipi di dati gestiti da classi e funzioni.
Tutte le volte che vi trovate a riscrivere codice che differisce solo per il
tipo di dati manipolato, quasi sicuramente avreste potuto risolvere il
problema con un template."
Comunque io chiudo qui il thread, ormai siamo IT per it.comp.lang.c++ e OT per
il nostro ng.
a2rg14
news:ewgIa.111682$pR3.2...@news1.tin.it...
ciao
> Potresti spiegarmi, cortesemente, il significato di "alto livello" e
> "medio livello" ?
distinguere un linguaggio
dall'altro posizionando questi su degli strati (livelli) virtuali.
questi strati sono tre e sono posti tra la macchina e il programmatore
basso
medio
e alto livello
lo strato "basso" è lo strato più vicino alla macchina, ovvero, proviamo a
metterla cosi... un linguaggio di basso livello parla quasi la lingua della
macchina, ed è molto lontano dal linguaggio del programmatore.
viceversa lo strato "alto" è lontano dalla macchina, pertanto un linguaggio
di alto livello è molto vicino al programmatore ma lontano dalla macchina.
ma tutto questo per dire cosa in sostanza?
prendiamo visual basic per esempio, o il basic in generale, esso è nato per
dare la possibilità a non programmatori, ma utenti evoluti, di imparare la
scienda della programmazione o dell'informatica.
un linguaggio simile, deve essere tradotto fino al livello più basso per
poter essere capito dalla macchina, ecco perchè a volte si tende a dire....
"vb è lento vb è un cesso ecc.. ecc." in realtà a volte sfugge il vero
motivo perchè succede questo. chiaro che se M$ (sempre per esempio) inventa
un prodotto che di chiama VB/qBASIC ecc. quel prodotto è tecnologicamente
molto complesso, molto ma molto più complesso di un linguaggio assembler (o
assembly che si dica), perfino più complesso del C e del pascal, Quindi
tanto le cose sono complesse, e tanto è più facile è incontrare errori.
Però! non bisogna dimenticare che quella cosa complessa non è nata per i
programmatori.
delphi in particolare come il c ed altri linguaggi, sono stati creati da
programmatori per i programmatori. essi sono posti nello strato medio perchè
hanno sia le potenzialità di un linguaggio di basso livello che le facilità
di un linguaggio di alto livello.
> Su libero.database si sta sviluppando un thread interessante proprio
> sugli OPF (Object Persistence Framework);
cosa sono gli OPF? una sorta di strato di applicazione?
>Ma a me è
> sembrato sempre un ambiente piuttosto completo, considerato anche che
> il linguaggio da imparare rimane sempre e solo uno, insomma una
> specializzazione non può che far risparmiare del tempo.
sono d'accordo in parte, nel senso che comunque non è bello essere legati ad
un solo ambiente, nel mondo del lavoro non si sa mai. se puoi cerca di
diversificare.
ma questo è solo un mio parere.
ciao
Carmine Moleti
> > - C++ gestisce i template. Delphi no
> template?? :((
Supponiamo che tu abbia realizzato una classe Stack che
ti permetta di gestirne, appunto, uno.
In Delphi, per slegare tale implementazione dal tipo di dati,
dovresti far ricorso ad esempio, a puntatori per gestirli.
In alternativa dovresti dichiararti una classe base, per
poi definirne una specializzata per il tipo di dati da
trattare.
In C++ esiste la possibilità di definire template (originariamente
voluti per svincolarsi dai problemi legati all'ereditarietà
multipla).
Detti template consentono di utilizzare la stessa implementazione
del codice per diversi tipi di dati (sono un meccanismo
di code substitution).
Posto qui un esempio di una classe template per gestire array con
tipo base diverso.
template <class T>
class Array{
enum {dimensione = 100};
T contenuto[dimensione];
public:
T& operator[](int indice){
if((indice>=0) && (indice<dimensione)){
return contenuto[indice];
}
}
};
Nella definizione precedente "T" rappresenta il tipo generico da utilizzare.
C'è un esempio di overloading di operatore, nel caso specifico, l'operatore
è "[]".
In una funzione mi è possibile definire degli array di un tipo generico
semplicemente con:
Array<int> array_intero;
Array<float> array_float;
Array<mio_tipo> array_user_type;
E' comod, no?
> > - C++ consente la definizione delle variabili in situ. Delphi ha una
> propria
> > sezione per la dichiarazione
>
> ottimizzi ma paghi in leggibilità del codice.
Se parli con un programmatore C/C++ ti verrà risposto, spesso, che
non è molto comodo definire tutte le variabili in un posto, e poi
magari dover scorrere avanti ed indietro nel sorgente per cercarle.
Inoltre, può capitare che ci siano sezioni di codice che sono
racchiuse da strutture di controllo, e che richiedano
strutture dati voluminose.
Dichiarando il tutto in un unico blocco, forzi all'ingresso di una
funzione ad allocare un bel pò di memoria e, si spera che
essa venga anche deallocata :)
La possibilità di dichiarare e definire dove ti pare, alleggerisce
la cosa in questo caso.
Altri ti diranno che è utile per legare al contesto l'uso della
variabile stessa.
Altri, ancora, perchè fa sentire più onnipotenti.
Altri ti diranno che sei un anarchico insurrezionalista
e pure blasfemo. :)
Il programmatore Delphi/Pascal, obietterà dicendo che se
hai definito tutte le variabili in un unico posto, molto probabilmente
avrai progettato in maniera più accurata il tuo codice.
Indi non è necessario definire al volo :)
Forse, la questione della leggibilità è più di forma mentis e, quindi,
di abitudine.
> > - C++ ha il preprocessore per le macro. Delphi no.
> Chi viene da clipper sa. cosa si puo fare con le mcro del preprocessore ..
> :))
Non conosco il Clipper, explain please. :)
> > - C++ ha la possibilita di scrivere VXD. Con Delphi no (perchè?)
> Mi pare se ne fosse gia parlato di 'sta cosa, ma ora non ricordo.
Forse mi è sfuggito, ci sono dei periodi in cui latito dal newsgroup
perchè temporaneamente innamorato di qualche altra cosa :)
Salumi,
Carmine
P.S.:
W la birra!!
Morde
>quando si parla di linguaggi di solito (almeno hai miei tempi) tende a
^^^
[Warning] Message-ID: <bcsgkm$cb6$1...@lacerta.tiscalinet.it>: Grammatical error,
word 'hai' should be 'ai'.
Carlo Bertuccini
> > - C++ ha la possibilita di scrivere VXD. Con Delphi no (perchč?)
> Mi pare se ne fosse gia parlato di 'sta cosa, ma ora non ricordo.
Semplicemente perchč a Borland non interessa quel tipo di utenza. Un
ambiente RAD non puň essere adatto alla scrittura di Device Driver.
--
- Carlo -
guastatore
> questi strati sono tre e sono posti tra la macchina e il programmatore
> basso
> medio
> e alto livello
Ho capito. Li conoscevo però come generazioni.
- Linguaggi di prima generazione: Codice binario - Completamente
orientato alla macchina
- Linguaggi di seconda generazione: Assembler - Sempre orientato alla
macchina ma un bel salto, rispetto al codice binario
- Linguaggi di terza generazione: Basic, Pascal, ecc.. - Orientati
all'uomo
- Linguaggi di quarta generazione: Orientati alla problematica
Il C lo inquadravano come un linguaggio di seconda generazione e mezza.
Direi che in quanto ad orientamente Pascal e Basic sono alla stessa
stregua.
> a dire.... "vb è lento vb è un cesso ecc.. ecc." in realtà a volte
> sfugge il vero motivo perchè succede questo. chiaro che se M$ (sempre
> per esempio) inventa un prodotto che di chiama VB/qBASIC ecc. quel
> prodotto è tecnologicamente molto complesso, molto ma molto più
> complesso di un linguaggio assembler (o assembly che si dica),
> perfino più complesso del C e del pascal, Quindi tanto le cose sono
> complesse, e tanto è più facile è incontrare errori. Però! non
> bisogna dimenticare che quella cosa complessa non è nata per i
> programmatori.
Non sono d'accordo con quanto affermi. Non capisco cosa tu intenda
quando parli di complessità.
> cosa sono gli OPF? una sorta di strato di applicazione?
Gli OPF sono dei framework che consentono di mappare la classi e gli
oggetti che istanzi da esse, direttamente ad un db relazionale. In
questo modo, anche un'applicazione di business, può essere sviluppata
con tecniche di analisi e design (e di implementazione ) completamente
OO.
> sono d'accordo in parte, nel senso che comunque non è bello essere
> legati ad un solo ambiente, nel mondo del lavoro non si sa mai. se
> puoi cerca di diversificare.
> ma questo è solo un mio parere.
Certo, sono d'accordo con te riguardo la diversificazione.
Occorre altresì dire, che se diventi padrone assoluto di un ambiente
come Delphi, non solo del RAD ovviamente ma anche della progettualità
che riesce a darti, imparare un altro ambiente non è poi così difficile.
Ciao
Antonio
Alberto Salvati
> > Chi viene da clipper sa. cosa si puo fare con le mcro del preprocessore
..
> > :))
>
> Non conosco il Clipper, explain please. :)
Il vecchio clipper eredita molte cose dal linguaggio c.
Una di queste è il preprocessore che è una vera libidine se usata con
attenzione.
Ad esempio, io avevo scritto delle macro lunghe anche 30/40 righe.
Questo permetteva di:
nascondere dettagli di implementazione
evitare la digitazione di blocchi di codice ripetitivi con conseguente
ridondanza che rompe non poco se poi becchi un errore e ti tocca ti fare la
correzione in 50 punti diversi della tua app.
Inoltre, il compilatore ha una opzione che si limita a generare dei file (mi
pare .ppo..) che altro non erano che i tuoi sorgenti "esplosi"
Molti sviluppatori clipper hanno smanettato con 'sta roba.
Se becco un esempio te lo invio cosi ti rendi conto.
Birra, e sai cosa bevi, eh??? ;)))
Urbock 23
GuldenDraak
Leffe
Delirium Tremens
....
Bye
A
a2rg14
> a2rg14 wrote:
> Non sono d'accordo con quanto affermi. Non capisco cosa tu intenda
> quando parli di complessità.
ho espresso in malamente quello che volevo dire;)
non intendo dire che il prodotto è tecnologicamente migliore di un altro, ma
volevo dire che un codice visual basic deve fare più strada per arrivare al
linguaggio macchina, mentre un linguaggio come il C deve essere tradotto di
meno. e visto che deve essere tradotto meno è un sistema meno complesso.
e un sistema meno complesso genera meno errori di uno complesso
credo che esista anche una teoria o tecnica a proposito di sviluppo
software, una volta me l'avevano spiegata, ma non la ricordo più! :(
comunque dimostrava che con un software più complesso/grande(non ricordo) il
tempo di debug aumentava in modo quasi esponenziale, anzi se te o qualcuno
ne sapesse qualcosa a riguardo, potrebbe essere un argomento da
approfondire.
premetto che comunque non sono un esperto di queste cose, sono cose che ho
sentito dire o che ho letto quà e là.
ma se non sbaglio, mi pare ad esempio che un programma vb debba avere nella
directory di windows o system il run-time per poter funzionare. (un pezzo in
più)
>
> > cosa sono gli OPF? una sorta di strato di applicazione?
>
> Gli OPF sono dei framework che consentono di mappare la classi e gli
> oggetti che istanzi da esse, direttamente ad un db relazionale. In
> questo modo, anche un'applicazione di business, può essere sviluppata
> con tecniche di analisi e design (e di implementazione ) completamente
> OO.
Ah! ok! ho comprato un componente che si chiama InstantObjects (vedi
www.seleqt.com) che fa qualcosa del genere non male. anche se alcune cose,
specialmente sul db non mi piacciono molto.
> Certo, sono d'accordo con te riguardo la diversificazione.
> Occorre altresì dire, che se diventi padrone assoluto di un ambiente
> come Delphi, non solo del RAD ovviamente ma anche della progettualità
> che riesce a darti, imparare un altro ambiente non è poi così difficile.
difficile no! ma devi sempre studiare.
io ho iniziato da poco con delphi, e trovo che sia un bel ambiente e una
scheggia di compilatore che (fa paura!) ctrl+f9 e in pochi istanti è fatta!
MAx T.
ma
> volevo dire che un codice visual basic deve fare piů strada per arrivare
al
> linguaggio macchina, mentre un linguaggio come il C deve essere tradotto
di
> e un sistema meno complesso genera meno errori di uno complesso
Ecco, fermati qui. Non andare oltre, perché altrimenti cadi nel "male
cronico" di tutti noi programmatori: cercare qualche giustificazione per
qualsiasi cosa che NON VA.
E invece dovremmo imparare tutti (io per primo) ad essere molto piů
selettivi: VA? Ok, magari cerchiamo qualche miglioria, perň in linea di
massima siamo a posto. NON VA? Ok, facciamo qualche tentativo e
documentiamoci al massimo, ma ad un certo punto se ancora NON VA,
ABBANDONIAMO. (e, scusate se rafforzo un po' il concetto: MANDIAMO A
CAG...!)
Quanto dici infatti č + che sufficente per dedurre:
SISTEMA MENO COMPLESSO = MIGLIORE (se non altro xché genera "meno errori",
scusa se č poco!!).
Quindi per deduzione, siccome Visual Basic č PIU' complesso (quindi genera +
errori), allora meglio DELPHI.
Semplice e lineare, no?
Poi uno qui puň far notte su cosa č meglio e cosa no da una parte e
dall'altra, ma stringi stringi.... la giusta conclusione č questa.
> comunque dimostrava che con un software piů complesso/grande(non ricordo)
il
> tempo di debug aumentava in modo quasi esponenziale, anzi se te o qualcuno
> ne sapesse qualcosa a riguardo, potrebbe essere un argomento da
> approfondire.
... e che c'č da approfondire? ... e, soprattutto, CHI vuole approfondire?
Quel che dici mi sembra una cosa scontata.
Comunque se c'č qualche masochista che vuol provare faccia pure.... VB lo
attende.
Ciao.
Max T.
a2rg14
news:bcsed3$24dj$1...@newsreader1.mclink.it...
> > sempre a livello di ambienti, tralasciamo la tecnologia che ci sta
sotto,
> ho
> > trovato che visual studio per certi versi sia perfino migliore di
delphi,
>
> Domanda da 10cents di euro: in cosa?
possibilità di vederti il db in una finestra o l'anteprima di alcuni dati,
ed ho trovato molto utile la finestra del debug contiene molte info o la
finestra delle proprietà, dove si aprono altre finestre o procedure per
semplificare l'impostazione di alcuni dati (vedi un datagrid ad esempio)
ciao
roberto
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 17/06/2003
a2rg14
news:bcsed3$24dj$1...@newsreader1.mclink.it...
> Io so che il c++ è a medio livello, delphi invece no.
scusa mi era scappata questa riga...
il codice sotto ti sembra un tipico linguaggio di alto livello? io direi di
no.
con delphi puoi accedere direttamente all'hardware e queste sono
caratteristiche di un linguaggio di medio livello, cmq la letteratura a
proposito è molto vasta e i pareri non sono tutti concordi.
ciao
roby
procedure ScriviPorta(indirizzoPorta, dati: word)
begin
dati := (dati * 256) + dati;
asm
Mov ax, dati
Mov dx, indirizzoPorta
Out dx, ax
end;
end;
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 17/06/2003
a2rg14
news:81Z211Z186Z67Y...@usenet.libero.it...
> > comunque dimostrava che con un software piů complesso/grande(non
ricordo)
> il
> > tempo di debug aumentava in modo quasi esponenziale, anzi se te o
qualcuno
> > ne sapesse qualcosa a riguardo, potrebbe essere un argomento da
> > approfondire.
>
> ... e che c'č da approfondire? ... e, soprattutto, CHI vuole approfondire?
> Quel che dici mi sembra una cosa scontata.
io ho semplicemente lanciato un appello in questo thread, non si sembrava il
caso di aprire un [OT], probabilmente non č neanche il luogo piů adatto.
da approfondire c'č veramente tanto, invece per quanto riguarda il *CHI* ci
sono io. scusa se č poco
ciao
roberto
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 17/06/2003
Lis
>
> Domanda da 10cents di euro: in cosa?
Una cosa secondo del linguaggio/IDE (è un pò la combinazione delle 2) di vb
secondo me è stra-mega-utile: l'istruzione debug.print
Alberto Salvati
quando lavoravo in quickbasic 4.5 per dos (1991 circa...) accedevo
direttamente all'hardware via gli interrupt del bios. Quindi, qb45 è un
linguaggio di medio livello?
Non credo.
ma la questione in fondo non è molto rilevante, no? ;))
A
Alberto Salvati
io non la userei mai, ma potrebbe risultare utile, questo si.
> possibilità di vederti il db in una finestra o l'anteprima di alcuni dati,
Non è compito dell'ambiente di sviluppo, imho.
> ed ho trovato molto utile la finestra del debug contiene molte info
Ad esempio?
Call stack, watch,evalutate/modify, breakpoint condizionali, object
inspector a runtime su classi e tipi records e lista dei threads in
esecuzione da cui scegliere quel che vuoi vedere non ti bastano?
> o la
> finestra delle proprietà, dove si aprono altre finestre o procedure per
> semplificare l'impostazione di alcuni dati (vedi un datagrid ad esempio)
Su questo non mi pronuncio: sono oramai 4 anni che non vedo vb (x
fortuna..!).
A
Marco Breveglieri
> niente di particolare, piccole cose, tipo l'indentazione automatica la
> possibilità di vederti il db in una finestra o l'anteprima di alcuni
> dati, ed ho trovato molto utile la finestra del debug contiene molte
> info o la finestra delle proprietà, dove si aprono altre finestre o
> procedure per semplificare l'impostazione di alcuni dati (vedi un
> datagrid ad esempio) ciao
L'indentazione automatica c'è anche in Delphi. Per quanto riguarda il
DB, esiste l'ormai datato "Database Explorer" (SQL Explorer) per
visualizzare le strutture, ma solo relative al motore BDE.
E' comunque sempre possibile associare a *designtime* una griglia ad una
tabella ed aprire quest'ultima per visualizzare automaticamente i
dati...subito!
Sulla finestra di debug (in italiano, "Immediata"...traduzione orrenda)
posso darti ragione: è veramente un ottimo strumento, ma
fondamentalmente esiste solo poichè il VB non è un linguaggio compilato
ma interpretato.
--
Marco Breveglieri <ma...@abls.it>
ABLS Team Snc <www.abls.it>
Via De Gasperi, 14 - 42019
Scandiano (Reggio Emilia)
Paolo Arosio
...
> Una cosa secondo del linguaggio/IDE (è un pò la combinazione delle 2)
> di vb secondo me è stra-mega-utile: l'istruzione debug.print
Non e' cosi' complicato fare un wrapper di OutputDebugString;
Saluti
Paolo Arosio
Lis
>
> Non e' cosi' complicato fare un wrapper di OutputDebugString;
"di là" però è già fatto :)
a2rg14
e vogliamo mica inchiodarci su questa cosa ;)
ciao
roby
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
Gabriele Boccone
"Paolo" <pa...@nospam.com> ha scritto nel messaggio
news:Xns939F517DE7BDCpa...@193.70.192.192...
> Una domanda per voi.
> Ho sempre utilizzato Delphi e mi trovo bene.
>
> Vorrei comunque sapere quali siano, secondo voi, attualmente,
> le differenze principali tra Delphi e Visual Basic/Visual C++.
Io ho usato parecchio Visual Studio, prima di passare a Delphi
definitivamente.
Visual C++ e' molto complicato, ma necessario per fare tutto cio' che Visual
Basic non fa. Delphi e' il giusto compromesso tra i 2.
Per esempio: un controllo in una finestra creata con Visual C++ non e' un
oggetto, ma solo un handle. L'oggetto lo devi associare a parte, e devi
usare una procedura di "scambio" per cambiare le proprieta' dell'oggetto
quando cambiano quelle del controllo, o viceversa.
Usare uno 'splitter' in Visual C++ e' una delle cose piu' complicate che mi
sia mai capitato di fare. Alla fine ho dovuto usare un pannello e rispondere
agli eventi del mouse spostandolo e cambiando le dimensioni delle parti
della finestra.
Per contro in Visual Basic sei limitato dagli oggetti che hai a
disposizione, e tutto e' Variant... secondo me la mancanza di un controllo
sul tipo di dato e' male, e se vuoi fare qualcosa di piu' devi cercare
componenti di terze parti, oppure farli in C++. Non mi e' mai sembrato
adatto a progetti medio-grandi, ma molto usabile per risolvere velocemente
piccoli problemi.
Delphi da solo fa entrambe le cose...
Paolo Arosio
>> Non e' cosi' complicato fare un wrapper di OutputDebugString;
>
> "di là" però è già fatto :)
O' capi', ma di qui hai altro (ad esempio la finestra CPU); inoltre,
sono confidente (questi anglicismi) che nelle JCL esiste la funzione che
fa quel che vuoi.
Saluti
Paolo Arosio
Paolo Arosio
...
> Visual C++ e' molto complicato, ma necessario per fare tutto cio' che
> Visual Basic non fa. Delphi e' il giusto compromesso tra i 2.
...
> Usare uno 'splitter' in Visual C++ e' una delle cose piu' complicate
> che mi sia mai capitato di fare. Alla fine ho dovuto usare un
Io da 2 settimane mi sto scontrando con eVC++. Per cambiare il colore
del testo o del backgroung di una label sono dolori (per non parlare di
cose come il font, o anche solo la dimensione del font: occorre
crearselo!).
Eterne grazie ai creatori della VCL.
Saluti
Paolo Arosio
Andrea Laforgia
<carmine...@AskMe.com> wrote:
>- C++ gestisce i template. Delphi no
Questo dipende, comunque, dal modello ad oggetti dei due linguaggi.
Il C++ prevede istanze statiche delle classi, Delphi no.
Quindi un confronto da questo punto di vista è come dire: la berlina
ha il tetto, la spider no. Non che abbia molto senso, se si prescinde
dagli intenti con cui un qualcosa viene costruito.
>- C++ ha la possibilita di scrivere VXD. Con Delphi no (perchè?)
Attenzione, però. Quando si parla di "C++", si parla di un linguaggio
_standard_, per il quale sono previste infinite implementazioni, più o
meno integrate con i sistemi operativi. Ci sono ambienti C++ che
consentono di scrivere driver e ambienti che potrebbero benissimo non
consentirlo. Il tutto nella piena regola dello standard del
linguaggio, che non richiede alle implementazioni del linguaggio di
integrarsi ad un livello così basso col sistema.
>- C++ ha il ++. Delphi no
Già, per la solita serie "potente e pericoloso".
>- C++ ha l'operatore ternario a ? b : c. Delphi no
Già, per la solita serie "potente e pericoloso".
>C++
>#define PRINT(a) cout << #a "=" << a << endl;
>
>int main(){
> int i=0;
> PRINT(i++);
> return 0;
>}
Spero che nessuno usi mai seriamente del codice del genere.
L'uso delle macro, in C++, è sconsigliabile. Le macro sono fuori dal
controllo del compilatore, vengono tradotte implicitamente in un passo
della compilazione (che è appunto la pre-compilazione) e sul quale il
programmatore non ha alcun potere. Uno dei motivi che ha portato ad
introdurre le costanti con keyword "const", le funzioni inline e
quant'altro è proprio la voglia di abbandonare le macro.
>char* c = "Pippo";
>
>Il che produce un array costante di caratteri, e ti permette di modificarne
>(non in tutti i compilatori)
>il contenuto!
Non si dovrebbe mai cercare di modificare la memoria puntata da un
puntatore definito in questo modo. Per lo standard ISO del C++,
l'r-value è un array di caratteri costanti. Diverso è il caso di:
char c[] = "Pippo";
>La scrittura precedente rispettando le regole del C++, dovrebbe essere:
>char c[] = "Pippo";
Esatto.
>In Delphi sei responsabile per la creazione e la distruzione di un oggetto.
>In C++ il distruttore viene chiamato automaticamente al momento in cui
>l'oggetto va fuori dallo scope.
Per le differenze del modello a oggetti dei due linguaggi.
La mancanza di oggetti allocabili staticamente si sente molto, dal mio
punto di vista (e conduce, di conseguenza, a tante altre differenze,
come la mancanza dell'overloading degli operatori).
Andrea Laforgia
>A me i template li hanno sempre sconsigliati: hanno il difetto di papparsi
>molta memoria e generare obj grossissimi.
I template hanno una grande utilità in molti casi. In C++ la libreria
standard ne fa uso massiccio (nonché la boost che è una gran cosa).
Il difetto di "papparsi" la memoria non dipende certo dalla natura
template di una classe (o funzione). L'istanza del template fa in
modo che, alla fine, la classe/funzione sia del tutto identica a una
classe/funzione definita con un tipo esplicito. Anche sulla
dimensione del prodotto della compilazione, non ci sono motivi per
credere che debba essere così enorme.
>>- C++ ha l'operatore ternario a ? b : c. Delphi no
>In passato venni assalito dal "mitico" Laforgia per essermi lamentato di
>questa mancanza :-)
Il problema è che l'uso dell'operatore ternario non va consigliato.
Delphi comunque dispone di un surrogato malriuscito (vedi la funzione
IfThen di D6). Può portare a scrivere codice molto incomprensibile, a
mio avviso.
Max T.
> > ... e che c'è da approfondire? ... e, soprattutto, CHI vuole
approfondire?
> > Quel che dici mi sembra una cosa scontata.
> io ho semplicemente lanciato un appello in questo thread, non si sembrava
il
>
> da approfondire c'è veramente tanto, invece per quanto riguarda il *CHI*
ci
> sono io. scusa se è poco
Scusami Roberto, non volevo certo "stuzzicarti", in alcun modo.
Il tuo "coraggio" ad approfondire questi temi è lodevole.
E il mio era solamente uno sfogo proveniente da chi oggi VUOLE SOLO ED
ESCLUSIVAMENTE usare dei linguaggi di programmazione che FUNZIONINO, come
requisito fondamentale.
Perché devo guadagnarci su, per vivere.
Talmente fondamentale che oggi, ti dirò, è quasi diventato l' *UNICO*
requisito richiesto. E questo, lo so, non va bene perché nel nostro lavoro
occorre sempre "approfondire", come dici tu. Ma per quanto mi riguarda non
ne posso più di approfondire, dopo anni. E per me è un dato di fatto.
Tutto qui.
E poi, per piacere, non tagliare della mia risposta di venti righe tutto
lasciando solo le due righe che ti hanno "solleticato". Non è giusto, e non
è costruttivo per la discussione.
A me (e agli altri, se qualcuno ci legge) sarebbe interessata di più una
risposta alle altre 18 righe che ho scritto. Sarebbe stata più costruttiva,
non pensi?
E comunque scusami ancora per le altre due.
a2rg14
news:81Z211Z182Z228Y...@usenet.libero.it...
> Il 20 Giu 2003, 02:50, "a2rg14" <a2r...@lycos.it> ha scritto:
> Scusami Roberto, non volevo certo "stuzzicarti", in alcun modo.
non c'č problema, anzi scusa te lo chiedo io, forse non avevo bene inteso,e
il caldo di questi giorni ha fatto il resto.
> A me (e agli altri, se qualcuno ci legge) sarebbe interessata di piů una
> risposta alle altre 18 righe che ho scritto. Sarebbe stata piů
costruttiva,
> non pensi?
[..]
anche qui, non ho risposto perchč la discussione mi sembrava avesse preso
una "piega" dal sapore polemico.... e come si sa le polemiche non sono
costruttive e degenerano in questioni non puramente tecniche.
lo faccio adesso.
decisamente trovo che delphi sia un buon linguaggio di programmazione, non
volevo tenere le parti di visual basic, ma semplicemente capire dal punto di
vista tecnico, il motivo per cui vb č cosi. tutto qua.
poi come dici te, anch'io mi devo guadagnar la pagnotta tutti i giorni e
diventa sempre piů difficile ;)
e delphi in questo senso inizia a darmi una mano.
quindi capisco perfettamente il tuo punto di vista! anzi e chi avrebbe
voglia di pensare ancora al vecchio e obsoleto vb6.
una calorosa stretta di mano e buon lavoro
ciao
roberto
Morde
>Delphi comunque dispone di un surrogato malriuscito (vedi la funzione
>IfThen di D6). Può portare a scrivere codice molto incomprensibile, a
>mio avviso.
Su questo ti do' pienamente ragione.