Newsgroup: it.comp.lang.c++
Titolo: Longevità del C++

Penso che un dubbio che si trovi di fronte a tutti coloro che vogliono
intraprendere il mestiere di programmatore sia: su quale linguaggio
concentrarsi? Se per esempio dieci anni fa mi fossi concentrato sul
Pascal, oggi dovrei impararmi C++ o Java o (peggio) VB. Secondo voi
che prospettive di durata ha il C++ commercialmente parlando?
 
              Col. Aureliano Buendia
-._.-._.-._.-._.-._.-._.-._.-._.-._.-._._.-._.-._.-._.-._
Dammi la forza di tollerare le cose che non posso cambiare
Dammi la forza di cambiare le cose che non posso tollerare
Dammi la forza di distinguere le une dalle altre                 
-._.-._.-._.-._.-._._.-._.-._.-._.-._._.-._.-._.-._.-._._.

Pascal, oggi dovrei impararmi C++ o Java o (peggio) VB.
Pascal è nato come linguaggio didattico mi sembra che il successo che
ha ancora oggi al di fuori dalle scuole grazie a Delphi sia
imprevisto.
VB è molto cambiato e molto vecchio codice ne risentirà molto quindi
forse potrebbe un po' soffrirne.
Java non lo conosco quindi non so ma potrebbe subire un duro colpo
dalle strategie Microsoft.
-- 
                    Marco Barisione (ICQ 84277092)
Se sei interessato alla creazione di un newsgroup generico in cui si
possa parlare di quei linguaggi di programmazione senza un gruppo
apposito vota per it.comp.lang su it.news.votazioni.

che prospettive di durata ha il C++ commercialmente parlando?
Secondo me il C++ ha ormai la massa critica per restare in
circolazione per un bel po' di tempo. Inoltre (diversamente
da cose come VB, Delphi o Java) si tratta di un *linguaggio*
e non di un prodotto commerciale; questo lo rende piu' lento
come evoluzione ma (leggendo questa lentezza in altro modo)
molto piu' affidabile come investimento a lungo termine.
Personalmente credo che se ne sentira' parlare per un sacco
di tempo.
Andrea

che prospettive di durata ha il C++ commercialmente parlando?
Non c'é sicuramente da temere per quanto riguarda la longevità di
linguaggi come il C o il C++. Questi ultimi sono ormai considerati
degli standard de facto, sono i linguaggi più usati per la
progettazione di librerie, driver, linguaggi di programmazione,
sistemi operativi, grandi progetti in generale, e continueranno ad
esserlo per un bel pezzo.
Penso che a nessuno sia mai venuta in mente la pazza idea di inventare
un nuovo linguaggio adatto ai grossi progetti che si ponga l'obiettivo
di sostituire il C o il C++, perché ciò vorrebbe dire scontrarsi
contro dei muri insormontabili ed andare incontro a fallimento certo.
Oltretutto uno dei vantaggi più grossi di questi linguaggi é il fatto
di avere uno standard e di garantire quindi un alta portabilità fra
piattaforme diverse, cosa che ben pochi linguaggi possono permettersi.
Casomai coloro che dovrebbero porsi il tuo quesito sono quelli che
utilizzano i cosiddetti linguaggi-prodotto-ambiente di sviluppo,
questi essendo progettati per risolvere fasce di problemi ben precisi
ed adattarsi a piattaforme ben precise sono sicuramente i più soggetti
a grosse rivoluzioni, ridimensionamenti o addirittura all'abbandono
totale(la cosa può anche avvenire gradualmente, ma il risultato in
ogni modo non cambierebbe).
Se la Microsoft un giorno si svegliasse dicendo che il VB non é più il
linguaggio più semplice/versatile per Windows e proponesse chessò un
Visual DDT+- quei 4 milioni di programmatori che hanno investito gran
pare del loro tempo nell'apprendere a fondo il linguaggio si
troverebbero di punto in bianco con l'esigenza di ricominciare daccapo
la loro esperienza, imparare nuovi sistemi di sviluppo, buttare via
tutti i loro sorgenti e riscriverli dall'inizio.
Il Ghenio
---------
These are my parting words to you:
those who give up are doomed!

 che prospettive di durata ha il C++ commercialmente parlando?
Se conosci il C++ tutto il resto lo impari in una settimana.... Io il 
mese scorso, dopo 2 giorni, ero già in grado di scrivere script Perl di 
discrete dimensioni senza mai aver visto prima il linguaggio (e reputando 
la sua sintassi OSCENA)...
-- 
Luc.

 e proponesse chessò un Visual DDT+-
Non è del tutto cretina. Lo ha chiamato 
VB.NET
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

Non è del tutto cretina. Lo ha chiamato 
VB.NET
Ne ero già a conoscenza. ma non l'ho nomitato perché non so se sia
compatibile o meno con il vecchio VB.


 compatibile o meno con il vecchio VB.
Lo è ... in piccola parte. Proprio per questo praticamente lo si puù
considerare quasi un nuovo linguaggio e considerare morto il VB. D'altro
lato ... sempre su una base VB è costruito, quindi molti sosterranno che
sempre di VB si tratta.
Quei molti a cui mi piacerebbe pagare uno stipendio di 10.000.000 al
giorno, con penali di 5.000.000 per ogni giorno di ritardo, e fargli
compilare (dandogli un paio di giorni di tempo per il porting) una bella
applicazione VB da un paio di centinaia di migliaia di linee di codice.
Tanto sempre del mega linguaggio che fa tutto e funzione sempre si
tratta.


la sua sintassi OSCENA)...
Il Perl non è molto difficile ma hai proprio ragione, ha una sintassi
veramente oscena ^_^
----
Lawrence "Rhymes" Oluyede
rhy...@myself.com

 che prospettive di durata ha il C++ commercialmente parlando?
C'è gente che sostiene che la maggior quantità di codice funzionanate é 
scritto in cobol ...

applicazione VB da un paio di centinaia di migliaia di linee di codice.
Non ho capito bene questa frase, me la rispieghi?


proprio codice per tenersi aggiornato con le tecnologie Microsoft.
Beh potremmo sempre intentare causa alla M$ magari noi o Cossiga ce la
faremo :-)
----
Lawrence "Rhymes" Oluyede
rhy...@myself.com
"Quando un uomo siede un'ora in compagnia di una bella ragazza,
sembra sia passato un minuto. Ma fatelo sedere su una stufa
per un minuto e gli sembrerà più lungo di qualsiasi ora.
Questa è la relatività".
Albert Einstein

 contro dei muri insormontabili ed andare incontro a fallimento certo.
Drasticita' estrema e, a mio avviso, ingiustificata.
Io sono dell'idea che il C e il C++ siano come tutti gli altri 
linguaggi: adatti al proprio ambito.
Che poi questo ambito di applicazione sia molto ampio, e' un
altro discorso.  Io utilizzo quotidianamente sia il C, sia il C++,
sia cio' che voi chiamate "linguaggi-prodotto-ambiente di sviluppo"
(Delphi, per la precisione) e che destinate, da qui a poco, a morte
certa.  Io posso assicurare che per lo sviluppo di gestionali,
per esempio e, comunque, per applicazioni che non devono arrivare
a vedere di che colore porta le mutandine il processore, questi
"linguaggi-prodotto-ambiente di sviluppo" moribondi, sono una 
manna dal cielo.  E, dal punto di vista della sicurezza dei linguaggi
alla base, sono insostituibili.
Io credo che siano ben pochi a mettersi in testa di scrivere un 
gestionale (e' un esempio di tipologia di applicazione molto diffusa) 
in C++, o peggio, in C, quando esistono ambienti che aiutano molto
nella realizzazione di queste applicazioni.
Giusto per ribadire l'ennesimo trito concetto: ci sono linguaggi e 
linguaggi, ambienti e ambienti, cose che vanno bene per un ambito 
e cose che vanno bene per l'altro.  
Il C++ durera' ancora a lungo, giusto per tornare in tema col topic, 
ma questo non vuol necessariamente dire che tutto cio' che gli sta 
intorno verra' inghiottito dalle viscere della Terra.  
Il C++ e' un bel cannone, ma molto spesso basta una semplice pistola, 
che e' piu' facile da maneggiare e meno pericolosa.
-- 
Posted from  [80.105.34.80] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG



Sono perfettamente daccordo e sottolineo: viva Delphi ^_^


che e' piu' facile da maneggiare e meno pericolosa.
Penso che nessuno qui lo metta in dubbio visto che spesso per certe
operazioni viene suggerito di usare altri linguaggi più semplici.


 operazioni viene suggerito di usare altri linguaggi più semplici.
Mi e' sembrato di leggere che se a qualcuno viene in mente
di inventare un nuovo linguaggio adatto a grandi progetti,
in grado di sostituire C e C++, allora quel qualcuno e'
destinato a morire miseramente nelle pene dell'inferno.
Be', Borland ha inventato Object Pascal e l'ha dotato di
una corazza chiamata Delphi.  Un linguaggio + un ambiente
di sviluppo che per grandi progetti puo' sostituire 
benissimo l'uso del C++, tant'e' vero che nella mia azienda
molti grossi progetti anticamente scritti in C++ sono
stati riscritti in Delphi.  E senza risentire di alcunche'.
Con questo non sto gettando fango sul C++, ci mancherebbe.
Il C++ ha una potenza inaudita, ineguagliata a tutt'oggi.
Ma ci sono casi in cui tutta questa potenza non serve e puo' 
essere addirittura pericolosa.


benissimo l'uso del C++
Con il pericolo che un domani la Borland potrà abbandonare Delphi
rendendo spazzatura tutti i programmi scritti in Delphi.


rendendo spazzatura tutti i programmi scritti in Delphi.
Sciocchezza (ammettilo: detta giusto per dirla ;) e senza
alcun fondamento concreto.  
Borland, al contrario di MS, non ha mai dato segno di
"abbandonare" nessuno dei suoi prodotti (e se lo fa, ti
avvisa in largo anticipo, buttandoti comunque un
salvagente).  Tant'e' vero che Delphi e' ancora compatibile
al 90% con il Turbo Pascal (!) ed e' classificato come
Borland Pascal v. 14.  Borland e' arrivata a sviluppare la
quattordicesima versione del proprio compilatore Pascal e un
bel giorno decide di non supportarlo piu' (fa pure le tue
conclusioni).
I segni che sta dando Borland, oggigiorno, portano a credere
l'esatto contrario, tanto piu' che Delphi sta diventando,
orgogliosamente, cross-platform e sta raccogliendo proseliti
anche sotto Linux.
Tutto fa pensare che il futuro di Delphi sia piu' che roseo
e tutto fa pensare che le varie sibille annunciatrici di
morte, in realta', siano solo degli scarsi conoscitori della
materia.
E' tutto da dimostrare, poi, che lo sforzo fatto per
scrivere un programma in C++ con un certo compilatore C++,
sia del tutto recuperabile, quando un prodotto come VC++
viene, un bel giorno, ahime', a mancare (se ne vanno sempre
i peggiori).  Sfido a dimostrare che lo sforzo fatto per la
scrittura di un progetto medio-grande, con un particolare
compilatore, per una particolare piattaforma, non sia in
realta' meno arduo che la riscrittura del progetto con un
altro linguaggio.

"abbandonare" nessuno dei suoi prodotti
Ma di fallire sě.
Comunque io non ho assolutamente niente contro Delphi che non conosco
ma reputo un ottimo ambiente per realizzare GUI velocemente.
Direi di finire il discorso che č sempre + OT.


 conclusioni).
Cosa avresti detto tornando indietro nel tempo, sul
futuro del micro-channel di IBM ? Devi ammettere
comunque che borland puo vendere il suo progetto Delphi
a qualcuno che lo compra per farlo morire.
Ti ricordi di Watcom ? Sai perche' e' sparito e chi lo ha
fatto sparire?
PS. Date un'occhiata a 
http://www.openwatcom.org/
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


ma reputo un ottimo ambiente per realizzare GUI velocemente.
Delphi e' molto piu' di questo.
Concludo anch'io, non e' di Delphi che si sta parlando.

a qualcuno che lo compra per farlo morire.
E gia', insomma Delphi deve morire a tutti i costi.
Non capisco perche' Borland dovrebbe vendere il suo prodotto
di punta, non lo capisco proprio, e non capisco perche'
dovrebbe venderlo a qualcuno che lo compra per farlo
necessariamente morire.  Hai mai utilizzato Delphi per
progetti seri ? evidentemente no.

 E gia', insomma Delphi deve morire a tutti i costi.
No potrebbe rompere le scatole a qualcuno e subire
un acquisto.
Non mi hai risposto a proposito del Watcom.


 Non ho capito bene questa frase, me la rispieghi?
Parlavo di quelli che sostrranno che 
VB.NET
 è VB. Se è VB il porting è
praticamente una ricompilazione e al limite cambiare qualche settaggio
della command line. Quindi due giorni di lavoro al massimo.
Ma dato che per portare un progetto di quelle dimensioni (ammesso che
esistano dei matti che lo hanno sviluppato in VB) da VB a 
VB.NET
 bisogna
di fatto riscriverne una buona fetta ... prima che finiscano io sono
miliardario grazie alle penali!


 > contro dei muri insormontabili ed andare incontro a fallimento
certo.
Faccio il reply a Huckleberry perchè mi era sfuggito il post del Ghenio.
Linguaggi per sostituire il C++ per grossi progetti ce ne sono (e in
molti casi lo hanno anche sostituito).
Semmai è per sostituirlo in progetti in cui conta molto
l'interfacciamento con l'HW e il controllo a basso livello (sistemi
operativi, SW di sistema, sistemi real-time, embedded systems etc.) che
al momento non si vede molto di nuovo all'orizzonte.


 altro linguaggio.
Proprio per questo i progetti di dimensione medio-grandi tendono ad
essere ingegnerizzati in modo da avere una buona percentuale del codice
riutilizzabile in quanto aderente allo standard ANSI/ISO e tutto ciò che
è system o comunque platform dependent è ben separato dal resto (spesso
addirittura un altro progetto-nel-progetto).


Non mi hai risposto a proposito del Watcom.
Perche' dovrei farlo ? 
Non sei tu che vanti il vantaggio di usare il C++ rispetto
ai "prodotti-ambienti" ?  La verita' e' che per come e'
strutturata la maggior parte dei progetti scritti in C++,
oggigiorno, quando muore il prodotto basato sul C++,
l'impatto e' lo stesso che si avrebbe con un prodotto non
basato sul C++.  Gli unici progetti che possono riuscire a
sopravvivere alla catastrofe, sono quelli strutturati in
visione di un simile evento.  E non sono in tanti a
programmare in questo modo, anche perche' e' molto
difficile.  Ricostruire un progetto scritto per un
compilatore particolare e' dispendioso tanto quanto
riscriverlo interamente.

al momento non si vede molto di nuovo all'orizzonte.
E io cos' avevo detto?
"i linguaggi più usati per la progettazione di librerie, driver,
linguaggi di programmazione,sistemi operativi, grandi progetti in
generale"
Non stavo assolutamente parlando di gestionali o cose di questo tipo
per i quali forse ci sono soluzioni più semplici e produttive.


 ponga l'obiettivo di sostituire il C o il C++
Quindi, almeno per come l'avev posta, sembrava che tu parlassi di
alternative per lo sviluppo di "grandi progetti" e "grossi progetti".
E di alternative al C++ ce ne sono molte. Al punto che il C++ è persino
sconsigliato per lo sviluppo di progetti estremamente grossi o
complessi. A meno che non ci sia una necessità di interfacciamento con
l'HW o di controllo fine del tempo di esecuzione (nota che controllo
fine del tempo di esecuzione non significa che il programma deve
eseguire più velocemente ma piuttosto che deve eseguire in un tempo
prevedibile in maniera sufficientemente precisa).
L'eccezione legata all'accesso all'HW porta nel dominio del C++ i driver
e i sistemi operativi. Per le librerie ... solo quelle legate all'HW, ai
driver, ai sistemi operativi e, naturalmente, quelle da usare con il C++
stesso. Ma le librerie di altri linguaggi non è detto che siano
sviluppate in C++.
Riguardo allo sviluppo dei linguaggi stessi ... non darei per scontato
che convenga farlo in C++. Conviene farlo in C (e in minor parte in C++)
quando c'è il discorso della portabilità. Ma allora non parliamo più di
sviluppo ma bensì di implementazione finale. La fase di ricerca e
sviluppo ... non giurerei che sia in C++.


 Perche' dovrei farlo ? 
Perche' ti farebbe riflettere su come potrebbero andare le cose.
Ti ricordi di DR Dos ?


 progetti seri ? evidentemente no.
L'ha gia' fatto con prodotti che sono stati leader di mercato, quando il
mercato e' girato. Qualcuno ricorda Turbo Prolog? O anche senza bisogno
di venderli, cambiando tecnologia. Anche dell'OWL ci siamo dimenticati?
Il problema di utilizzare Delphi per un progetto destinato a durare nel
tempo e' che se Delphi scompare devi riscriverlo *tutto*. Con qualunque
compilatore C++ hai perlomeno la possibilita' di scegliere di quanta
parte del tuo progetto vincolare alla tecnologia proprietaria del tuo
fornitore.
Come ti e' gia' stato detto e' diventata prassi comune acquisire aziende
per eliminare dal mercato prodotti concorrenti, o per acquisire un solo
prodotto al'interno di una gamma, e lasciar perdere gli altri. Oltre a
Watcom e' successo di recente a Forte e NextStep/OpenStep.
Buona fortuna!
Ciao,
Nicola

 Watcom e' successo di recente a Forte e NextStep/OpenStep.
Esatto. E dato che Borland da tempo non è più un mostro di stabilità
economica non è per nulla impossibile che qualche big se la comperi allo
scopo di uccidere uno o più prodotti o di acquisire uno o più prodotti
lasciando morire gli altri.


 1) Non uso CString ma uso std::string
Cavoli tuoi... Se la portabilità non è necessaria la classe CString è 
molto più comoda è potente... 
-- 
Luc.


E che fara' mai di cosi' potente che std::string?
-- 
  _  _  >>Now at work<<  _     || ICQ number.................Non lo uso
 | \| |___ _____ ___ ___|_|___ || Home-Page ................Non ce l'ho
 | .` | -_|     | -_|_ -| |_ -||| E-Mail................Non l'avrai mai
 |_|\_|___|_|_|_|___|___|_|___||| Un Nemesis che ha pochi e-contatti ;)


Come fai a sapere a priori se e' necessaria o no ?
E poi mi fa girare le scatole che abbia l'operatore
di conversione a const char *


"Luc" <XXX...@katamail.comXXX> wrote in message
news:MPG.167821a39...@news.enter.it...

Salvo che la sua esistenza a lungo termine è già stata messa
parzialmente in dubbio nei NG MS.


 di conversione a const char *
Non funzionerebbe più metà windows se non lo facesse... 8)
-- 
Luc.

 parzialmente in dubbio nei NG MS.
E verrŕ rimossa a favore di std::string? NON credo proprio...
-- 
Luc.

 Non funzionerebbe più metà windows se non lo facesse... 8)
Be gia quella meta' di cui parli non funziona molto bene.


 fare un porting ?
Semplice, ma te lo spiego.
Se un mio progetto prevede l'uso di COM, DIRECTX, Interazioni con il s.o. 
ecc... saprò bene che NON avrò bisogno, in futuro, di portare il SW...
NB: anche io uso std::string quando devo fare un piccolo programmino, 
magari a linea di comando, che non usa MFC...
-- 
Luc.

molto più comoda è potente... 
La CString é per caso un specializzazione char della classe
basic_string?
La CString possiede un iteratore?
La CString consente di usare ostringstream e istringstream?
La CString é un wrapper per char* , per strcpy , strlen , ecc.ecc? 
In questo caso il suo codice é sicuramente ridondante.
Chi ti dice che sia più potente di std::string?


 ecc... saprò bene che NON avrò bisogno, in futuro, di portare il SW...
Io la vedo diversamente: Se in un progetto uso COM, DIRECTX etc
la domanda non e' "Dovro' ?" ma l'affermazione:  "Non potro'", quindi non le
uso.
Invece che DirectX uso OpenGL.
Invece che COM uso Corba.


 Chi ti dice che sia più potente di std::string?
Sicuramente è molto più comoda se si programma MFC. 
-- 
Luc.

 Invece che COM uso Corba.
Contento tu...
-- 
Luc.

 ecc... saprò bene che NON avrò bisogno, in futuro, di portare il SW...
Nel senso che sai che dovrai semplicemente riscriverlo quando la
piattaforma su cui si basa non esisterà più.
COM va in fadout, MFC va in fadeout, DirectX resta ma potrebbe
trasformarsi parecchio. Quando questo succederà non lo sappiamo. Ma è
già annunciato. Come quando nel '92 si parlava del fatto che
applicazioni DOS che accedevano direttamente all'HW avrebbero finito con
il non essere più supportate.
La differenza è che un utente è sempre stato libero di aggiornare il
sistema quando lo voleva lui e non quando lo diceva MS dato che la
licenza era a tempo indeterminato e che l'upgrade lo pagavi.
In futuro la politica MS sarà diversa: la licenza ha un costo annuo e
l'upgrade è gratuito. In altre parole o usi la piattaforma MS e la tieni
aggiornata o non la usi punto e basta.
Che ci riescano o meno non lo so. Ma l'idea è quella.


 Sicuramente è molto più comoda se si programma MFC.
Certo. Fa parte di MFC. Ma la storia prossima futura di MFC al momento è
delineata in questo modo: integrazione di MFC con la STL e nel contempo
forti incentivi alla migrazione verso il modello .NET e l'uso di
interfacce utente basate su HTML e sue estensioni.
Supporto al legacy code con nuovi e più potenti tools di sviluppo per le
nuove applicazioni e per la migrazione delle vecchie.
Il che tradotto dal microsoftese significa: MFC morirà, passate a .NET
al più presto. Il futuro è .NET e chi resta troppo indietro prima o poi
sono ca**i suoi.


 sono ca**i suoi.
Ovvio, ma la rivoluzione non sarà dolorosa... 8)
-- 
Luc.

 salvagente).
Se e' per quello Borland non ha ancora rilasciato una patch per il 
famoso "Runtime error 200" della unit crt sui processori con frequenza 
maggiore di 200 MHz e, da affezionato utente di TP, ne sono rimasto un 
po' deluso.
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

po' deluso.
Su questo sono daccordo ma il comportamento in questo caso verso i
programmatori non è molto meschino in confronto a certe politiche
della M$
----
Lawrence "Rhymes" Oluyede
rhy...@myself.com
"Quando un uomo siede un'ora in compagnia di una bella ragazza,
sembra sia passato un minuto. Ma fatelo sedere su una stufa
per un minuto e gli sembrerà più lungo di qualsiasi ora.
Questa è la relatività".
Albert Einstein

lasciando morire gli altri.
Ciò significherebbe buttare i miei ultimi due anni di lavoro solo
perchè mi piace il Delphi invece del C++? Non penso che Delphi morirà
ma se lo farà credo proprio che avremo una nascita di qualcosa
chiamato OpenDelphi...capite cosa intendo?


programmatori non è molto meno meschino in confronto a certe politiche


 chiamato OpenDelphi...capite cosa intendo?
Mi sembri che parti dal preconcetto che qui nel NG tutti siamo patiti
sfegatati di C++, bene sappi che non e' cosi', ma devi ammettere che
se Borland ( non sia mai ) decidesse di non portare piu' avanti  (per
qualsiasi motivo) Delphi le cose si metterebbero male.
Perche' non c'e' un OpenDelphi ? Forse perche' c'e' il copyright di
Borland? Potrebbe essere una mossa per scoragiare chi la vorra
acquisire visto che se morisse il "suo progetto Delphi" ci sarebbe
comunque un movimento parallelo che non si puo comprare. Che
faccia la stessa fine di Apple ?


faccia la stessa fine di Apple ?
Sono daccordo, ma non capisco perchè voi profeti non fate altro che
predirre la fine di Delphi, come se stesse già morendo...


 predirre la fine di Delphi, come se stesse già morendo...
Ma io non sono un profetta sto soltanto supponendo.
Allora mettiamola in un altro modo: imagina se domani M$ decidesse di
chiudere!


imagina se domani M$ decidesse di chiudere!
e menomale ^_^!!!


Sicuramente è molto più comoda se si programma MFC. 
Tempo fa mi ero messo in testa di studiare per bene le MFC convinto
che mi sarebbero state di grande aiuto nella realizzazione dei miei
programmi. Ebbene, ci ho rinunciato dopo pochi giorni quando mi sono
reso conto di quanto fosse scritte male(dal punto di vista OOP)e di
quanto male il loro uso si adattasse al mio modo di programmare in
C++.
Inoltre provo un odio viscerale verso gli wizard generatori di codice
incomprensibile.


 Borland?
Borland ha abbracciato da tempo la politica open source,
con Kylix, che e' il clone Delphi per Linux e con 
Interbase, un ottimo e potente DBMS.
Tuttora distribuisce gratuitamente le versioni Personal
dei suoi prodotti, che puoi liberamente scaricare dal
suo sito.
Tra l'altro, progetti paralleli a Delphi esistono, vedi:
http://www.lazarus.freepascal.org/
-- 
Posted from  [80.105.34.80] 


 chiudere!
Fare supposizioni assolute non serve a nulla: bisogna
ipotizzare con delle basi concrete, altrimenti si puo'
dire tutto e il contrario di tutto.
-- 
Posted from  [80.105.34.80] 


 po' deluso.
Faresti bene ad aggiornarti, caro Cuni.


 altrimenti si puo' dire tutto e il contrario di tutto.
Soltanto se si parte da un'ipotesi falsa.
Io sto partendo da un'ipotesi "plausibile" con probabilita' 
non nulla che per un motivo qualsiasi il progetto Delphi 
possa morire come possa vivere in eterno.
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 
Tu non stai parlando di Borland, stai parlando di
Microsoft, leggi il tuo messaggio precedente.
Non e' affatto plausibile che M$ chiuda da un giorno
all'altro e pertanto non e' plausibile credere che
i programmatori che utilizzano tool Microsoft si 
buttino tutti da un ponte.
Oggi, poi, non ci sono oggi ragioni plausibili per 
credere che Delphi possa morire.  Tutte le elucubrazioni 
che puoi fare sul misero destino di Delphi sono, a tutt'oggi,
immotivate, visto che e' un ambiente di sviluppo che
sta andando alla grande.
-- 
Posted from  [80.105.34.80] 


 sta andando alla grande.
Quali ipotesi avresti fatto il 10 Settembre circa la longevita'
delle torri gemelle?
Ciao
Gaetano
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 delle torri gemelle?
Hai appena detto una stupidaggine, del tutto fuori luogo.
Si fa una migliore figura, stando zitti.
-- 
Posted from  [80.105.34.80] 


 Si fa una migliore figura, stando zitti.
Potresti sottolineare che e' soltanto una tua modesta
opinione, considerando anche il fatto che non sto facendo
una gara di "migliori figure" con nessuno. 
Sei uno di quei bacchettoni per cui il "fattaccio" delle
torri gemelle non deve essere toccato per nessun motivo ?
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


 una gara di "migliori figure" con nessuno. 
Non si tratta di fare buona o cattiva figura,
ma di evitare di dire stupidaggini enormi.
Faresti un favore a tutti quanti.
Io sono una di quelle persone che la catastrofe delle
torri gemelle ha toccato particolarmente e che non 
paragonerebbe mai la morte di migliaia di persone
con la morte di un mucchietto di byte.
Per me la discussione e' chiusa, ma la prossima volta
abbi un po' di decenza e limitati a discutere di 
argomenti tecnici (sempre che ti rimanga qualche
argomento).
-- 
Posted from  [80.105.34.80] 


 argomento).
Perche' dovrebbero finirmi ?
Ciao
Gaetano.
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 


Di nuovo con queste stupidagini enormi. 
Riassumo la risposta, perche' la discussione sta diventando
stucchevole e comincia a stancarmi.
Chi ha le fette di prosciutto sugli occhi sei solo e
soltanto tu: hai detto una fesseria e non lo vuoi ammettere.
Non staro' qui ad insistere su un tema che c'entra poco con
la discussione tecnica.  Tu ancora non lo sai, ma gli
argomenti di discussione ti sono gia' finiti.
Statti bene.

E gia', insomma Delphi deve morire a tutti i costi.
E' una possibilita' da tenere in conto. 
Il C++ non puo' fallire perche' non e' di nessuno, anche pero' puo
cambiare cosi tanto da uno standard all'altro da rendere il codice
"antico" incompilabile.
Sai anche la mia banca puo' fallire, ma per fortuna non ho soldi in
BiPop/Fineco. Pochi mesi fa questo gruppo andava alla grande, oggi e'
investito da scandali non da ridere. Chi ha la palla di vetro magica?
Perche' Boland non potrebbe fallire? Infondo oggi non esiste piu' il
C++ di  Watcom (ma al suo posto esiste PowerBuild) e anche il
compilatre C++ Zortech, poi diventato Symantec, e' morto.
Kai C++ e' stata comprata da Intel, e mi sembra un doppione che Intel
venda anche il compilatore C++ ICL. Uno dei due muorira'?
-- 
Tieni per te il Papero giusto se vuoi la mia email
Sito Papero -> 
http://utenti.tripod.it/papero

 Statti bene.
Io sto gia bene.
Visto che io gli argomenti li ho finiti (se lo dici tu)
possiamo iniziare a parlare di TTable, TQuery, ADO, Sender,
INSERT, Interbase, VCL, BDE.
O che ne diresti di parlare di qualche pattern ?
Visto che fai anche il saputello (magari sei un che ne capisce
veramente tanto, ma confondersi tra C e C++ da te non me lo
sarei mai aspettato) vorrei che calcolassi il valore di binario
delle seguenti espressioni ( hai una probabilita' pari a 0.125 di 
sbagliarle tutte):
1 > P(Che la Microsoft chiuda) > 0
1 > P(Che Borland venda Delphi) > 0
1 > P(Che domani finisca il mondo) > 0
dove P e' la funzione di probabilita'.
PS. Vedi di fare qualcosa al tuo Forte Agent per fa si che non appenda
un RE: ogni volta che rispondi....  grazie.


 Statti bene.
Be di tecnico c'e' questo:
From: Huckleberry Finn (
huck...@libero.it
)
Subject: Re: Re: Longevità del C++
Newsgroups: it.comp.lang.c++
Date: 2001-12-06 23:47:55 PST
[SNIP]
--
Posted from  [80.105.34.80]
via Mailgate.ORG Server - 
http://www.Mailgate.ORG
Andrea Laforgia (
walkie...@libero.it
)
Subject: Re: Polimorfismo
Newsgroups: it.comp.lang.c++
Date: 2001-10-10 01:26:44 PST
[SNIP]
--
Posted from  [80.105.34.80]


 predirre la fine di Delphi, come se stesse già morendo...
Non ho mai inteso prevedere la morte di nessun tool. Ho però sempre
inteso sostenere che un progetto dovrebbe essere il meno possibile
dipendente da un cero tool.
Che il tool possa morire è solo una delle possibili ragioni. Un'altra è
che un SW indipendente dal tool ha un maggior valore intinseco. In
quanto maggiormente portabile su altre piattaforme o su altri tool della
stessa piattaforma.
Potrebbe essere la tua azienda a essere acquistata da un'altra. Una che
magari si occupa principalmente di SW per Unix. E la portabilità del tuo
SW diviene immediatamente un valore. Potrebbe persino significare la
sopravvivenza del progetto nella nuova azienda.


chiudere!
Una società non "decide di chiudere". Soprattutto se genera reddito. Al
massimo viene comperata da un concorrente più grosso e chiusa da questo.
Ma dubito che sia il caso per MS. MS non rischia di chiudere.
--
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15]
via Mailgate.ORG Server - 
http://www.Mailgate.ORG
--


 buttino tutti da un ponte.
Che MS chiuda non č plausibile. Ma che chi usa tool proprietari MS si
butti sotto un ponte invece č abbastanza plausibile. A meno che non sia
disposto a seguire MS fino in fondo e aggiornare il suo SW man mano che
si aggiornano i tool di MS.
Per esempio chi usa VB e sta gią da qualche mese rivedendo tutti i suoi
programmi per la tecnologia .NET non rischia. Gli altri, qualche cosa
si.


si.
Ci sara' qualcuno che ha investito qualche miliardo in
un progetto basato su VisualJ++ ? (intendevo dire "ci sara'
stato" ... chi lo ha fatto forse oggi non esiste piu')
Indipendentemente dalle ragioni (per MS problemi legali
per il suo quasi-java con Sun, per Borland i seri problemi
finanziari che hanno fatto rischiare il fallimento di una
delle principali ditte che hanno cambiato il significato
di "ambiente di sviluppo" su PC) un progetto proprietario
e' proprietario.
Secondo me scrivere codice perfettamente portabile e'
impossibile (a meno che uno speri di commercializzare
helloworld), e scrivere codice molto portabile costa un
po'. A volte vedo scrivere codice *inutilmente* non 
portabile (usando funzioni proprietarie per cui esiste
una alternativa portabile che non e' assolutamente
inferiore alla soluzione proprietaria) e a volte usare
un approccio portabile e' qualcosa di privo di senso.
Io non vedo nulla di male a scrivere una gestione
rubrica telefonica con Delphi o VB, anzi. Io ho scritto
cose basate su *macro di office* che hanno smesso di
funzionare al primo aggiornamento (e non me ne vergogno,
erano cose che mi sono costate mezz'ora spesa per lo
piu' a cercare di indovinare come era stato tradotto
"left" in italiano, e hanno fatto il loro - minuscolo -
lavoro egregiamente).
Secondo me il discorso cambia quando parli di un software
di gestione della produzione, oppure di un CAD/CAM.
Se speri di scrivere qualcosa che ha un bel po' di linee
di codice e che duri una decina di anni allora utilizzare
uno strumento che ne ha meno di due (e che, ovviamente,
e' destinato a cambiare il significato stesso di scrittura
programmi per sempre - come *tutte* le brochure dicono)
forse e' una scelta un po' azzardata.
Io credo che il C++ oggi abbia una maturita' sufficiente
anche per questo tipo di progetti. Ovviamente ci saranno
delle parti non portabili... ma con un po' di sforzo e'
possibile confinarle ad una percentuale ridotta del totale.
Ad esempio non sono ancora sicuro che questa maturita'
ci sia anche in Java...
Andrea

 
Tada! Colpo di scena :)
-- 
  _  _  >>Now at work<<  _     || ICQ number.................Non lo uso
 | \| |___ _____ ___ ___|_|___ || Home-Page ................Non ce l'ho
 | .` | -_|     | -_|_ -| |_ -||| E-Mail................Non l'avrai mai
 |_|\_|___|_|_|_|___|___|_|___||| Un Nemesis che ha pochi e-contatti ;)

 incomprensibile.
Codice incomprensibile? E' banale se ci perdi un po di tempo a capirlo...
-- 
Luc.