Discussione:
Interfacciare un programma c++ in win
(troppo vecchio per rispondere)
Luca
2004-08-18 06:14:45 UTC
Permalink
Ciao a tutti,
io scivo dei codici che eseguo con un compilatore c++;
vorrei sapere come faccio ad interfacciare graficamente in windows questi
programmi scritti da me.
Grazie a tutti
Ciao

Luca
Paolo Ferraresi
2004-08-18 13:56:58 UTC
Permalink
Post by Luca
Ciao a tutti,
io scivo dei codici che eseguo con un compilatore c++;
vorrei sapere come faccio ad interfacciare graficamente in windows questi
programmi scritti da me.
Grazie a tutti
Ciao
Luca
Ciao, ora sei nel NG appropriato.
La differenza sostanziale fra un software per Windows ed un programma in
standard C++ (che pur gira sotto Windows ma in una shell di caratteri) non
sta tanto nell'evidente finestra grafica, nei menu e nei controlli (testo,
bottoni, etc.) bensì nel modo in cui il flusso del programma è gestito.
Nel programma standard C++ il flusso delle operazioni segue le tue
indicazioni fedelmente, mentre un programma per Windows ha determinati
momenti (in cui devi compiere operazioni specifiche) ed il resto del flusso
del programma è sostanzialmente guidato da eventi (messaggi fra le varie
componenti software).
Questa è la prima cosa da capire.

Poiché la programmazione Win32 in ambiente GUI è tutt'altro che semplice,
esistono ottimi libri sullo sviluppo uno è ad esempio "Programmare Windows"
di Charles Petzold e numerosi tutorial in rete, anche se meno esaustivi dei
libri di solito.
Un sito dove puoi vedere alcuni, semplici, programmi in Win32 è
http://www.relisoft.com/win32/ , ma ti renderai conto che è un modo di
programmare piuttosto macchinoso, per quanto efficiente.

Molti programmatori, la maggior parte, preferiscono pagare qualcosa in
termini di efficienza (ma non è sempre così) e affidarsi all'uso di
framework (che sono dei wrapper alle funzioni API Win32).
I più famosi sono per Windows sono MFC (di propietà di Microsoft, sta per
Microsoft Foundation Classes) , VCL & CLX (di Borland, quest'ultimo
multipiattaforma) e sta crescendo bene anche wxWindows (licenza GPL,
multipiattaforma "simile" come costruzione a MFC).
MFC è distribuita con Visual Studio, VCL con il Borland C++ Builder (CLX con
le versioni professional e entrprise se non error) e wxWindows funziona bene
sia con Visual C++, che con il Borland e meglio ancora con il Dev-C++
compiler.
La stesura di codice con questi framework (ma ce ne sono altri) è fortemente
semplificata (e in C++, mentre le API di Windows furono scritte in C e
assembly), soprattutto è semplice con VCL dato che il Borland C++ builder è
effettivamente un ambiente di sviluppo RAID (dove puoi costruire finestre e
controlli con il solo mouse).

La migliore guida per le MFC penso che sia la Microsoft MSDN, per quanto
riguarda VCL bisogna acquistare il Borland e dentro c'è un ottimo help in
linea (che oltre alla VCL tratta anche il C++ standard ed il C) mentre per
wxWindows, il sito di riferimento è http://www.wxwindows.org .

Quindi, se vuoi sapere come fare per vedere i tuoi programmi sulla GUI, devi
innanzitutto decidere quale strada intendi seguire (tra quelle che ti ho
indicato io ed altre che magari altri t'indicheranno) e poi approfondirla.
Te l'avevo detto che il discorso non era semplice...
Comunque io uso wxWindows e mi trovo benissimo, ho anche il Borland C++
Builder e VCL è veramente comodo (a mio a vviso il modo più semplice per
programmare Windows in C++), però preferisco sempre wxWindows (che mi pare
che anche Borland alla fine abbia sposato).

saluti,
Paolo Ferraresi.
Gerolamo
2004-08-19 07:46:06 UTC
Permalink
"Paolo Ferraresi" ha
Post by Paolo Ferraresi
MFC è distribuita con Visual Studio, VCL con il Borland C++ Builder
(CLX con le versioni professional e entrprise se non error) e
wxWindows funziona bene sia con Visual C++, che con il Borland
e meglio ancora con il Dev-C++ compiler.
Ne manca uno molto impoortante, IMHO, ovvero tutte le
windows.form del framework .NET
http://www.windowsforms.net/
--
Gerolamo
Paolo Ferraresi
2004-08-19 09:47:30 UTC
Permalink
Post by Gerolamo
Ne manca uno molto impoortante, IMHO, ovvero tutte le
Vero. Io me lo scordo perché non mi piace .net ma è una realtà.
Hai fatto bene a puntualizzare.
ciao.
Gerolamo
2004-08-19 11:30:47 UTC
Permalink
"Paolo Ferraresi" ha scritto
Post by Paolo Ferraresi
Vero. Io me lo scordo perché non mi piace .net ma è una realtà.
Per curiosità, perchè non ti piace?

Io non è che abbia questa grande esperienza con la programmazione
Windows, ma con C# e Sharpdevelop mi sto trovando abbastanza
bene...
--
Gerolamo
Stefano 'HappyMan'
2004-08-19 13:36:23 UTC
Permalink
Post by Gerolamo
"Paolo Ferraresi" ha scritto
Post by Paolo Ferraresi
Vero. Io me lo scordo perché non mi piace .net ma è una realtà.
Per curiosità, perchè non ti piace?
Io non è che abbia questa grande esperienza con la programmazione
Windows, ma con C# e Sharpdevelop mi sto trovando abbastanza
bene...
Posso intervenire ? :-)

Microsoft per .Net ha fatto un notevole lavoro di riordino in ottica OOP
delle proprie API (non è concettualmente corretto ma lo dico per
semplificare, alla base di .Net su Windows ci sono comunque le Win32), io
che lavoro in VB.Net lo trovo comodo e veloce, ma per mia esperienza .Net
soffre di un grandissimo tallone d'Achille: le prestazioni e richiesta di
risorse.

Far girare un programma .Net su una macchina non adeguatamente aggiornata è
un suicidio, io come sviluppatore/sistemista che dai propri clienti vede
ancora macchine con un PII a 233 MHz, 64 MB con Windows 98 penso che questo
sia un grosso problema, tanto da farmi scegliere ancora VB6 (o il C++)
quando il parco macchine del cliente è una incognita.

PS.
Nel tempo libero sto portando avanti lo sviluppo di un minuscolo framework
in C++ che incapsula in ottica OOP i controlli di Windows, sul sito in
firma trovare l'url. Manca quasi completamente di manuale ma con gli esempi
si può comunque utilizzarlo. Richiede l'inclusione di due soli files
(windev.h e windev.cpp) nei vostri progetti.

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Atom
2004-08-19 15:09:08 UTC
Permalink
Post by Stefano 'HappyMan'
PS.
Nel tempo libero sto portando avanti lo sviluppo di un minuscolo framework
in C++ che incapsula in ottica OOP i controlli di Windows, sul sito in
firma trovare l'url. Manca quasi completamente di manuale ma con gli esempi
si può comunque utilizzarlo. Richiede l'inclusione di due soli files
(windev.h e windev.cpp) nei vostri progetti.
Ho visitato il tuo sito, ed è molto interessante: mi piace curiosare nei
siti di altri programmatori, oltrettutto spesso si trovano degli ottimi
programmi, :-) e tra poco svilupperò anche io il mio sitarello.
Ma tornando al tuo framework, non capisco una cosa: perché bisogna
includere anche windev.cpp? Di solito un programma in C++ è strutturato in
maniera tale che tutti gli #include includono solo headers.
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Stefano 'HappyMan'
2004-08-19 15:31:47 UTC
Permalink
Post by Atom
Post by Stefano 'HappyMan'
PS.
Nel tempo libero sto portando avanti lo sviluppo di un minuscolo framework
in C++ che incapsula in ottica OOP i controlli di Windows, sul sito in
firma trovare l'url. Manca quasi completamente di manuale ma con gli esempi
si può comunque utilizzarlo. Richiede l'inclusione di due soli files
(windev.h e windev.cpp) nei vostri progetti.
Ho visitato il tuo sito, ed è molto interessante: mi piace curiosare nei
siti di altri programmatori, oltrettutto spesso si trovano degli ottimi
programmi, :-) e tra poco svilupperò anche io il mio sitarello.
Ma tornando al tuo framework, non capisco una cosa: perché bisogna
includere anche windev.cpp? Di solito un programma in C++ è strutturato in
maniera tale che tutti gli #include includono solo headers.
Thx :-)

Dunque devi includere windev.cpp perchè li dentro è sviluppato tutto il
framework, mentre in windev.h ci sono le dichiarazioni delle classi.

Nel caso di un programma composto da diversi file .cpp li metti tutti nel
progetto, crei un unico header che include tutti quelli che sono richiamati
altrove. Il file windev.zip scaricabile dal mio sito dovrebbe essere
esaustivo :-)

Ciao

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Atom
2004-08-19 15:39:01 UTC
Permalink
Post by Stefano 'HappyMan'
Thx :-)
Dunque devi includere windev.cpp perchè li dentro è sviluppato tutto il
framework, mentre in windev.h ci sono le dichiarazioni delle classi.
Nel caso di un programma composto da diversi file .cpp li metti tutti nel
progetto, crei un unico header che include tutti quelli che sono richiamati
altrove.
Io di solito faccio diversamente: ad ogni file .cpp che creo, gli associo
un file .h #includendolo dal .cpp; poi tutti i files (sia cpp sia h) li
includo nel progetto da compilare, in modo tale che vengano schiaffati
tutti al compilatore; il compilatore incomincia a mangiarsi tutti i files,
e genera un file .obj per ogni accoppiata cpp/h, quindi penso che se io
scaricassi il tuo fw e includessi il .h dove voglio, ma lasciassi a se
stante il .cpp, dovrebbe funzionare (ovviamente il .cpp dovrebbe comunque
essere incluso tra i file da compilare).
--
questo articolo e` stato inviato via web dal servizio gratuito
http://www.newsland.it/news segnala gli abusi ad ***@newsland.it
Stefano 'HappyMan'
2004-08-19 16:29:57 UTC
Permalink
In data Thu, 19 Aug 2004 17:39:01 +0200, Atom ha scritto:

[cut]

Non sono stato chiaro, anch'io faccio come te, se ho tre classi Frm001,
Frm002 e Frm003 ho i file frm001.cpp, frm002.cpp e frm003.cpp per le classi
vere e proprie, i file frm001.h, frm002.h e frm003.h per le definizioni.
Poi avrò un mioprg.h dove metto

#include "windev.h"
#include "frm001.h"
#include "frm002.h"
#include "frm003.h"

mettendo degli
#ifdef FRM00X
#endif

per evitare dichiarazioni ripetute.
Post by Atom
Io di solito faccio diversamente: ad ogni file .cpp che creo, gli associo
un file .h #includendolo dal .cpp; poi tutti i files (sia cpp sia h) li
includo nel progetto da compilare, in modo tale che vengano schiaffati
tutti al compilatore; il compilatore incomincia a mangiarsi tutti i files,
e genera un file .obj per ogni accoppiata cpp/h, quindi penso che se io
scaricassi il tuo fw e includessi il .h dove voglio, ma lasciassi a se
stante il .cpp, dovrebbe funzionare (ovviamente il .cpp dovrebbe comunque
essere incluso tra i file da compilare).
Beh prova :-)

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Danguard
2004-08-19 15:47:00 UTC
Permalink
In article <1m8o2shwgzs4u.1qu7dsdpiqb5p$***@40tude.net>, happyman69
@despammed.com says...
Post by Stefano 'HappyMan'
Microsoft per .Net ha fatto un notevole lavoro di riordino in ottica OOP
delle proprie API
Le classi del framework .NET mi paiono effettivamente ben progettate e
piu' "pulite" delle API Win32 (e' anche passato un po' di tempo da
allora, e la tecnologia e lo stile dei programmatori evolve :-)

...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??

Voglio dire: il framework .NET introduce un sacco di overhead rispetto
al C++; perche' non hanno ridisegnato le API in ottica OOP,
accompagnandole all'efficienza del C++? (Certo, meglio di quanto fatto
con MFC, senza tutte quelle macro :-)
Post by Stefano 'HappyMan'
io che lavoro in VB.Net lo trovo comodo e veloce,
Toglimi una curiosita', giacche' ci lavori e quindi lo conoserai bene: a
me pare che il VB.Net sia molto piu' vicino a linguaggi "complessi" come
Java o C#, piuttosto che al _semplice_ Visual Basic.
In altri termini, penso che sia piu' facile per un programmatore Java o
C# imparare VB.Net, di quanto lo sia per un programmatore VB6 ...o
sbaglio?

Se cosi' fosse, allora, tanto varrebbe anche per un programmatore VB6
investire tempo in C# (o Java), no?
Post by Stefano 'HappyMan'
ma per mia esperienza .Net
soffre di un grandissimo tallone d'Achille: le prestazioni e richiesta di
risorse.
Infatti!

Se avessero realizzato un bel framework di classi pulito stile .Net, ma
per C++, secondo me avrebbero fatto un gran cosa!!

Ciao,
Dan
Stefano 'HappyMan'
2004-08-19 16:26:42 UTC
Permalink
Post by Danguard
@despammed.com says...
Post by Stefano 'HappyMan'
Microsoft per .Net ha fatto un notevole lavoro di riordino in ottica OOP
delle proprie API
Le classi del framework .NET mi paiono effettivamente ben progettate e
piu' "pulite" delle API Win32 (e' anche passato un po' di tempo da
allora, e la tecnologia e lo stile dei programmatori evolve :-)
...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??
Me lo chiedo anch'io...Infatti per i miei programmi, esclusivamente per
quanto riguarda la GUI, mi son fatto il mio framework, "scopiazzando"
alcune cose carine del .Net
Post by Danguard
Toglimi una curiosita', giacche' ci lavori e quindi lo conoserai bene: a
me pare che il VB.Net sia molto piu' vicino a linguaggi "complessi" come
Java o C#, piuttosto che al _semplice_ Visual Basic.
In altri termini, penso che sia piu' facile per un programmatore Java o
C# imparare VB.Net, di quanto lo sia per un programmatore VB6 ...o
sbaglio?
No, non sbagli assolutamente.
VB.Net non è VB7, introduce molti concetti che i programmatori VB6 evoluti
aspettavano, ma che quelli più "tranquilli" ignoravano e che ora trovano
complicati (esempio: prima per mostrare un form facevi mioform.Show, ora
devi dichiarare una variabile pippo di tipo mioform che è diventata una
classe, instanziarla e solo ora fare pippo.show)
Post by Danguard
Se cosi' fosse, allora, tanto varrebbe anche per un programmatore VB6
investire tempo in C# (o Java), no?
Per il C# no, perchè il framework è lo stesso, il codice generato è lo
stesso sia che uso vb o c#. Però la stessa sintassi vb aiuta...
Post by Danguard
Se avessero realizzato un bel framework di classi pulito stile .Net, ma
per C++, secondo me avrebbero fatto un gran cosa!!
Sottoscrivo al 200%

Ciao

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Raffaele Rialdi
2004-08-20 07:22:54 UTC
Permalink
Post by Stefano 'HappyMan'
Post by Danguard
...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??
Me lo chiedo anch'io...Infatti per i miei programmi, esclusivamente
per quanto riguarda la GUI, mi son fatto il mio framework,
"scopiazzando" alcune cose carine del .Net
La risposta è semplice: lo hanno fatto :-)

È ancora in alpha e si chiama WinFX e sarà il nuovo subsytem di Longhorn, il
prossimo client (e poi server) Windows.
WinFX ha una tonnellata di nuove classi che non si basano più sulle Win32
che vengono abbandonate (conservate per compatibilità ma non più
progredite).
WinFX sarà accessibile solo dal mondo managed.

Lo schema delle nuove classi di WinFX si possono assaggiare in anteprima
qui:
http://longhorn.msdn.microsoft.com/
Ovviamente è una alpha quindi passibile di notevoli mutamenti così come è
già accaduto per Indigo da Ottobre scorso ad oggi.

Lo stesso C++ così come lo conosciamo ora verrà adeguato a supportare quelle
feature che non erano richieste quando era stato progettato. Il nuovo
C++/CLI (candidato ad essere standardizzato ISO) semplificherà notevolmente
l'attuale C++ managed extension (che verrà dismesso e potrà essere migrato
con un tool) ed ha la 'benedizione' di personaggi come Sutter e Slippman
(che lavorano anche in Microsoft) e dello stesso Stroustrup che, a detta di
Sutter (responsabile della commissione ISO di C++), è uno dei principali
supporter del nuovo standard C++/CLI.

In fondo al sistema operativo, a livello kernel, almeno per il momento le
cose rimangono molto simili a prima. Siamo in diversi a scommettere che ne
vedremo delle belle anche in kernel mode in futuro. D'altra parte Longhorn è
solo l'inizio ...
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Stefano 'HappyMan'
2004-08-20 07:47:59 UTC
Permalink
Post by Raffaele Rialdi
Post by Stefano 'HappyMan'
Post by Danguard
...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??
Me lo chiedo anch'io...Infatti per i miei programmi, esclusivamente
per quanto riguarda la GUI, mi son fatto il mio framework,
"scopiazzando" alcune cose carine del .Net
La risposta è semplice: lo hanno fatto :-)
È ancora in alpha e si chiama WinFX e sarà il nuovo subsytem di Longhorn, il
prossimo client (e poi server) Windows.
WinFX ha una tonnellata di nuove classi che non si basano più sulle Win32
che vengono abbandonate (conservate per compatibilità ma non più
progredite).
Si lo sapevo, e la cosa in tutta onestà mi terrorizza.

Già con il passaggio dalle varie versioni di Windows (basate sempre su
Win32) abbiamo avuto i nostri bei problemi a far girare applicazioni che su
una versione precedente andavano bene e su quella nuova invece no,
figuriamoci su un sistema che è basato su un subsystem graphico nuovo e che
è "compatibile" con le Win32...

Io purtroppo sono molto (troppo) pragmatico: .Net mi piace, Longhorn mi
piacerà (probabilmente) ancora di più, ma la scelta di quale ambiente di
sviluppo usare sarà sempre basata sulla velocità di diffusione di questi
nuovi sistemi/ambienti presso gli utenti finali (attualmente, almeno per i
miei clienti, molto bassa).

Ciao

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Raffaele Rialdi
2004-08-20 08:13:30 UTC
Permalink
Post by Stefano 'HappyMan'
Si lo sapevo, e la cosa in tutta onestà mi terrorizza.
Già con il passaggio dalle varie versioni di Windows (basate sempre su
Win32) abbiamo avuto i nostri bei problemi a far girare applicazioni
che su una versione precedente andavano bene e su quella nuova invece
no, figuriamoci su un sistema che è basato su un subsystem graphico
nuovo e che è "compatibile" con le Win32...
Non è proprio così. Windows è un OS realizzato a subsystem. Fin da NT hai
diversi subsystem oltre a Win32: OS/2, Win16, Posix, etc.
Le vere funzioni stanno nel kernel (quelle che iniziano per ZW) e la parte
di Win32 che usiamo dalle nostre applicazioni alla fine dei conti non
null'altro che un wrapper. Per esempio esistono dei subsystem Unix di terze
parti che permettono di far girare applicativi X-Windows.
Tra i subsystem forniti da MS ovviamente Win32 è quello più 'completo'.

WinFX non sarà altro che un nuovo subsystem che però lavorerà in modo
managed, perciò le vecchie applicazioni continueranno a lavorare con Win32
che ovviamente avrà funzionalità limitate perchè non sarà più evoluto nè
sviluppato. Win32 sarà la stessa che abbiamo oggi con XP (con eventuali
patch se saranno mai necessarie) ma nessuna evoluzione e pèrciò sarà
intrinsecamente 'sicura'.
Post by Stefano 'HappyMan'
Io purtroppo sono molto (troppo) pragmatico: .Net mi piace, Longhorn
mi piacerà (probabilmente) ancora di più, ma la scelta di quale
ambiente di sviluppo usare sarà sempre basata sulla velocità di
diffusione di questi nuovi sistemi/ambienti presso gli utenti finali
(attualmente, almeno per i miei clienti, molto bassa).
La mia opinione è diversa perchè la transizione sarà più appetibile e credo
che gli utenti lo vorranno fortemente.
La transizione Win16->Win32 è stata invisibile per molti utenti perchè a
tutti gli effetti le differenze sono nulle agli occhi dell'utente inesperto.
Non sarà così per Longhorn dove le applicazioni basate su Avalon attireranno
molto gli utenti finali, anche se di ufficio, perchè la UI è quella che
vende. Chi lo proverà dovrebbe rimanere abbagliato anche da WinFS che
elimina il concetto di file e folder, concetto che agli utenti nuovi non è
mai stato familiare e immediato. Ma credo che prima di sollevare discussioni
inutili su questo faremo meglio a provare una alpha o beta release tra
qualche tempo.

Ciao
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Stefano 'HappyMan'
2004-08-20 08:56:39 UTC
Permalink
In data Fri, 20 Aug 2004 10:13:30 +0200, Raffaele Rialdi ha scritto:

[cut]

Grazie delle info, molti dettagli li ignoravo :-)

Ciao

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Raffaele Rialdi
2004-08-20 09:17:53 UTC
Permalink
Post by Stefano 'HappyMan'
Grazie delle info, molti dettagli li ignoravo :-)
Prego :-)

Ciao
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Vincent Vega
2004-08-19 20:24:20 UTC
Permalink
Post by Danguard
...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??
Perchè le due cose non c'entrano nulla fra loro. La CLR non è una
astrazione delle API del sistema operativo, è ben di più (o di meno, a
seconda del punto di vista).
Per Microsoft era necessario sviluppare una evoluzione di COM e un
ambiente managed per una serie di ragioni, non ultima il fatto che
alcuni tipi di applicazioni lo richiedono a gran voce.
Post by Danguard
perche' non hanno ridisegnato le API in ottica OOP,
accompagnandole all'efficienza del C++? (Certo, meglio di quanto fatto
con MFC, senza tutte quelle macro :-)
Perchè esistono già le MFC anche se non piacciono, e se proprio non
piacciono si può dare un occhiata alle terze parti, un set di classi non
è un problema su cui fossilizzarsi. Come non c'è ragione di
fossilizzarsi nel cercare l'eleganza OOP "formale" e a tutti i costi, le
macro delle MFC hanno un loro senso di esistere.
Stefano 'HappyMan'
2004-08-20 07:41:08 UTC
Permalink
Post by Vincent Vega
Post by Danguard
...pero' quello che io mi chiedo e': perche' in Microsoft non hanno
fatto un lavoro simile di ridisegno e ripulitura di API realizzando
*classi C++*, piuttosto che spostarsi sul framework .NET e C#??
Perchè le due cose non c'entrano nulla fra loro. La CLR non è una
astrazione delle API del sistema operativo, è ben di più (o di meno, a
seconda del punto di vista).
Non sono d'accordo: l'esistenza della CLR è in funzione del framework.
Sono due concetti ben separati ma per come sono stati implementati
assolutamente indissolubili, a meno di vedere (e sarebbe una gran cosa) un
set di classi compatibili .Net ma usabile in C++ "unmanaged" senza la CLR
al di sotto.
Post by Vincent Vega
Per Microsoft era necessario sviluppare una evoluzione di COM e un
ambiente managed per una serie di ragioni, non ultima il fatto che
alcuni tipi di applicazioni lo richiedono a gran voce.
Che l'evoluzione di COM abbia portato ad una serie di problemi (quello che
viene definito "dll hell") è sotto gli occhi di tutti, ma è anche vero che
con un po' di sforzo in più tali problemi si possono/potevano evitare (i
miei programmi in VB6 girano dovunque e non sono mai stati incasinati da
problemi di dll e ocx).
La necessità di tempi rapidi di sviluppo è stata una esigenza per la quale
è stato sacrificato tutto il resto.

Secondo me il framework .Net ha una grandissima validità per il mondo web,
ma per le applicazioni windows form non vedo questa grande rivoluzione.
Anche ciò che viene fatto da ado.net si poteva fare (e io lo faccio in C++
e Win32) con odbc,rdo e ado senza troppi problemi.

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Danguard
2004-08-20 15:20:52 UTC
Permalink
In article <***@40tude.net>, happyman69
@despammed.com says...
Post by Stefano 'HappyMan'
Non sono d'accordo: l'esistenza della CLR è in funzione del framework.
Sono due concetti ben separati ma per come sono stati implementati
assolutamente indissolubili, a meno di vedere (e sarebbe una gran cosa) un
set di classi compatibili .Net ma usabile in C++ "unmanaged" senza la CLR
al di sotto.
Infatti!!
Vincent Vega
2004-08-20 19:16:07 UTC
Permalink
Post by Stefano 'HappyMan'
Non sono d'accordo: l'esistenza della CLR è in funzione del framework.
Sono due concetti ben separati ma per come sono stati implementati
assolutamente indissolubili, a meno di vedere (e sarebbe una gran cosa) un
set di classi compatibili .Net ma usabile in C++ "unmanaged" senza la CLR
al di sotto.
Forse non sono stato chiaro. Tu dici (insieme ad altri) che senti il
bisogno di una libreria di classi C++ che incapsuli le API, più "object
oriented" di quanto lo siano le MFC, sullo stile dei types di .Net. Fin
quì niente da dire anche se non sono d'accordo, a parte consigliare un
occhiata a librerie di terze parti anche free.
Quello che non mi è chiaro è cosa c'entra .Net in questo discorso.
Microsoft ha sviluppato .Net per una precisa esigenza, attualmente non
sostituisce lo sviluppo nativo e IMHO non lo sostituirà mai al 100%
(sebbene MS lo spingerà molto).
Post by Stefano 'HappyMan'
Secondo me il framework .Net ha una grandissima validità per il mondo web,
ma per le applicazioni windows form non vedo questa grande rivoluzione.
Premetto che in .Net non ho ancora fatto nulla di serio, penso che
nemmeno farò nulla di cui non tragga diretto vantaggio dal programmare
in ambiente managed (più o meno lo stesso ragionamento che faccio con
java).
Stefano 'HappyMan'
2004-08-21 13:25:29 UTC
Permalink
Post by Vincent Vega
Forse non sono stato chiaro. Tu dici (insieme ad altri) che senti il
bisogno di una libreria di classi C++ che incapsuli le API, più "object
oriented" di quanto lo siano le MFC, sullo stile dei types di .Net. Fin
quì niente da dire anche se non sono d'accordo, a parte consigliare un
occhiata a librerie di terze parti anche free.
Esistono molte librerie freeware o meno che incapsulano in modo OOP le
Win32, ma tranne la Borland (che peraltro si è avvicinata a .Net con
l'ultimo Delphi e non brilla per il supporto alle sue CLX) nessun fornitore
offre un prodotto simile a Visual Studio, con IDE, Help, MSDN, debugger,
etc etc
Post by Vincent Vega
Quello che non mi è chiaro è cosa c'entra .Net in questo discorso.
Microsoft ha realizzato una stupenda reimplementazione delle Win32 in
ottica OOP con il framework .Net, fornendo nello stesso tempo un ottimo
ambiente di sviluppo (pesante come pochi però) peccato che questo lavoro
sia destinato ad un uso "managed", con tutti i difetti elencati in altri
post.
Se il framework .Net fosse stato realizzato in modo tale da poter generare
exe puri, senza una macchina virtuale in mezzo (che da sola quando parte si
ciuccia una decina di mega), sarei stato un entusiasta.

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Raffaele Rialdi
2004-08-23 10:28:37 UTC
Permalink
Post by Vincent Vega
Forse non sono stato chiaro. Tu dici (insieme ad altri) che senti il
bisogno di una libreria di classi C++ che incapsuli le API, più
"object oriented" di quanto lo siano le MFC, sullo stile dei types di
.Net. Fin quì niente da dire anche se non sono d'accordo, a parte
consigliare un occhiata a librerie di terze parti anche free.
Dotnet a parte, in C++ unmanaged è da diversi anni che uso WTL (di
Microsoft) e mi sono sempre trovato benissimo.
WTL non è supportato ufficialmente da Microsoft ma esiste una vasta
community che la supporta e Microsoft stessa non nasconde (ufficiosamente)
di voler continuare ad evolvere i propri tool in modo che WTL continui a
poter essere usata.
http://sourceforge.net/projects/wtl

Oggi ritengo che non abbia più senso viste la disponibilità di dotnet.
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Danguard
2004-08-26 13:57:02 UTC
Permalink
In article <jGjWc.7$***@tornado.fastwebnet.it>, ***@n0spam_vevy.com
says...
Post by Raffaele Rialdi
Dotnet a parte, in C++ unmanaged è da diversi anni che uso WTL (di
Microsoft) e mi sono sempre trovato benissimo.
...per quel po' che ho visto, a me di WTL non piace proprio
quell'"abuso" dei template, oltre al fatto che mi pare che anche WTL non
scherzi con le varie #macro :(
Post by Raffaele Rialdi
WTL non è supportato ufficialmente da Microsoft ma esiste una vasta
community che la supporta e Microsoft stessa non nasconde (ufficiosamente)
di voler continuare ad evolvere i propri tool in modo che WTL continui a
poter essere usata.
http://sourceforge.net/projects/wtl
Oggi ritengo che non abbia più senso viste la disponibilità di dotnet.
Mah, non sono d'accordo. Per me l'ideale sarebbe se Microsoft facesse
una bella implementazione delle classi .NET pulita in C++ nativo
(wrappando le Win32), e per C++ nativo (senza roba "managed").

...anche se mi pare di capire che non se ne parla, dato che loro stanno
investendo molto su C# e .NET.
:(

Ciao
Dan
Raffaele Rialdi
2004-08-26 23:09:45 UTC
Permalink
Post by Danguard
...per quel po' che ho visto, a me di WTL non piace proprio
quell'"abuso" dei template, oltre al fatto che mi pare che anche WTL
non scherzi con le varie #macro :(
Questione di gusti ... a me piace proprio la flessibilità che ti danno i
template ... adoro ATL e WTL.
Per quanto riguarda le macro, con l'ultima versione vs.net, si può
finalmente vedere e risalire alle definizioni.
Le macro sono rognose ma hanno il grosso vantaggio di ottimizzare il codice
in modo molto potente.
L'uso che ATL/WTL fanno delle macro è comunque di gran lunga inferiore ai
suoi predecessori. Il più è fatto con template annidati che sono
estremamente potenti e rendono il codice supercompatto (con WTL puoi fare
un'applicazione con una UI simil-outlook in 40K, senza dipendenze di dll)
Post by Danguard
Mah, non sono d'accordo. Per me l'ideale sarebbe se Microsoft facesse
una bella implementazione delle classi .NET pulita in C++ nativo
(wrappando le Win32), e per C++ nativo (senza roba "managed").
Non avrebbe senso alle porte di Longhorn dove il suttosistema WinFX (che
scalzerà Win32) sarà sviluppato completamente managed, e quindi fruibile
solo da programmi managed.
Win32 sono molto datate e soffrono di molte scollature (vedi tutte le
integrazioni che sono finite per esempio nella Shell per una tonnellata di
buoni motivi ma che rendono il progetto poco pulito).
Post by Danguard
...anche se mi pare di capire che non se ne parla, dato che loro
stanno investendo molto su C# e .NET.
:(
Stanno investendo prima di tutto su .NET ma non solo C# ... non
dimentichiamo C++.
Le comunità di sviluppatori non hanno mai digerito (giustamente, anche io le
detesto) le managed extension di C++ e per questo sta per uscire con il fw
2.0 il nuovo linguaggio C++/CLI:
- espande il linguaggio C++ e sarà standardizzato ISO
- usa indifferentemente la parte managed e unmanaged in modo trasparente
- ha la benedizione di Stroustrup e in Microsoft ci lavora gente come Herb
Sutter (responsabile della ISO committee dell ISO C++), Stan Lippman (non ha
bisogno di presentazioni) e Brandon Bray.
- avrà template *e* generics
- avrà allocatori di memoria classici *e* managed
- avrà l'implementazione *automatica* del pattern dispose
... e tante altre belle cose...
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Danguard
2004-08-27 13:22:02 UTC
Permalink
Post by Raffaele Rialdi
(con WTL puoi fare
un'applicazione con una UI simil-outlook in 40K, senza dipendenze di dll)
Woow!!
Post by Raffaele Rialdi
Non avrebbe senso alle porte di Longhorn dove il suttosistema WinFX (che
scalzerà Win32) sarà sviluppato completamente managed, e quindi fruibile
solo da programmi managed.
Allora si'... peccato mi ero affezionato alle Win32 con i vari
H<qualcosa> :-) e struct con dwSize :)
Post by Raffaele Rialdi
Win32 sono molto datate e soffrono di molte scollature
E' vero...
Stefano 'HappyMan'
2004-08-27 14:19:11 UTC
Permalink
Post by Danguard
Post by Raffaele Rialdi
(con WTL puoi fare
un'applicazione con una UI simil-outlook in 40K, senza dipendenze di dll)
Woow!!
Post by Raffaele Rialdi
Non avrebbe senso alle porte di Longhorn dove il suttosistema WinFX (che
scalzerà Win32) sarà sviluppato completamente managed, e quindi fruibile
solo da programmi managed.
Allora si'... peccato mi ero affezionato alle Win32 con i vari
H<qualcosa> :-) e struct con dwSize :)
Tranquillo, continueremo a vederle ancora per molto, prima che Longhorn
sostituisca il parco macchina esistente...:-)

Stefano "HappyMan" (Lake Maggiore - Italy)
--
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) despammed.com
Danguard
2004-08-27 18:22:11 UTC
Permalink
In article <***@40tude.net>, happyman69
@despammed.com says...
Post by Stefano 'HappyMan'
Post by Danguard
Allora si'... peccato mi ero affezionato alle Win32 con i vari
H<qualcosa> :-) e struct con dwSize :)
Tranquillo, continueremo a vederle ancora per molto, prima che Longhorn
sostituisca il parco macchina esistente...:-)
:-))

...in effetti, poi alla fine conta l'hardware installato (che fa da
vincolo per il software che puo' girarci su!)

Dan
Raffaele Rialdi
2004-08-27 22:04:39 UTC
Permalink
Post by Danguard
...in effetti, poi alla fine conta l'hardware installato (che fa da
vincolo per il software che puo' girarci su!)
Beh l'attuale alfa di Longhorn è un po' pesantina ma tutta la grafica 3d è
gratis visto tutte le attuali schede grafiche hanno gli acceleratori ma
nessuno (giochi a parte) li usa.
E poi parliamo di un OS che girerà su PC del 2006/2007 ;-)
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Raffaele Rialdi
2004-08-27 22:59:51 UTC
Permalink
Post by Raffaele Rialdi
Post by Danguard
...in effetti, poi alla fine conta l'hardware installato (che fa da
vincolo per il software che puo' girarci su!)
Beh l'attuale alfa di Longhorn è un po' pesantina ma tutta la grafica
3d è gratis visto tutte le attuali schede grafiche hanno gli
acceleratori ma nessuno (giochi a parte) li usa.
E poi parliamo di un OS che girerà su PC del 2006/2007 ;-)
Correzione, avremo WinFx anche per su XP e W2K3:
http://www.microsoft.com/presspass/press/2004/Aug04/08-27Target2006PR.asp

... e questo servirà a scalzare Win32 più velocemente ...
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://www.ugidotnet.org/2082.blog
Bubuti Bauontico
2004-09-13 19:19:53 UTC
Permalink
Post by Raffaele Rialdi
Le comunità di sviluppatori non hanno mai digerito (giustamente,
anche io le detesto) le managed extension di C++ e per questo sta per
- espande il linguaggio C++ e sarà standardizzato ISO
[...]

ma soprattutto: sarà nel prossimo framework Visual C++ gratuito? se sì,
quando? senno', sarà tanto bellino, ma io non compro Visual Studio solo
per _un_ compilatore
--
< http://www.reactos.com/ > Open source clone of Windows NT. Current
Don't stand, REACT! version 0.2.4. C, C++ and ASM developers
and beta testers are welcome!
Raffaele Rialdi
2004-09-14 14:59:45 UTC
Permalink
Post by Bubuti Bauontico
ma soprattutto: sarà nel prossimo framework Visual C++ gratuito? se
sì, quando? senno', sarà tanto bellino, ma io non compro Visual
Studio solo per _un_ compilatore
Da un po' di tempo il compilatore C++ è gratuito con il famoso kit:
http://msdn.microsoft.com/visualc/vctoolkit2003/
A meno di colpi di scena, che personalmente ritengo estremamente
improbabili, lo sarà anche la prossima versione che includerà il nuovo
C++/CLI.


Inoltre sono già state annunciate le versioni Express di tutti i prodotti
visuali, quindi con un vero ambiente di sviluppo che puoi già provare in
beta:
http://lab.msdn.microsoft.com/express/visualc/default.aspx
Queste versioni sono orientate allo sviluppo amatoriale/studentesco e quindi
ad un costo veramente esiguo (adesso è in beta e quindi non si sa ancora di
preciso).

Per quanto riguarda Vs.net dipende da quello che ci vuoi fare. Se sviluppi
per professione ti assicuro che serve tutto quanto.
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele
Bubuti Bauontico
2004-09-14 20:21:27 UTC
Permalink
Post by Raffaele Rialdi
Post by Bubuti Bauontico
ma soprattutto: sarà nel prossimo framework Visual C++ gratuito?
se sì, quando? senno', sarà tanto bellino, ma io non compro
Visual Studio solo per _un_ compilatore
http://msdn.microsoft.com/visualc/vctoolkit2003/
ovviamente intendevo toolkit e non framework, scema me
Post by Raffaele Rialdi
A meno di colpi di scena, che personalmente ritengo estremamente
improbabili, lo sarà anche la prossima versione che includerà il
nuovo C++/CLI.
attendo con impazienza
Post by Raffaele Rialdi
Inoltre sono già state annunciate le versioni Express di tutti i
prodotti visuali, quindi con un vero ambiente di sviluppo che puoi
saranno mica quelle con il compilatore farlocco? perchè nel toolkit c'è
quello vero. E l'ambiente non mi serve
Post by Raffaele Rialdi
Se sviluppi per professione ti assicuro che serve tutto quanto.
fidati che non mi serve. Sarebbe molto bello se, ma non mi serve
--
< http://www.reactos.com/ > Open source clone of Windows NT. Current
Don't stand, REACT! version 0.2.4. C, C++ and ASM developers
and beta testers are welcome!
Raffaele Rialdi
2004-09-14 20:57:02 UTC
Permalink
Post by Bubuti Bauontico
saranno mica quelle con il compilatore farlocco? perchè nel toolkit
c'è quello vero. E l'ambiente non mi serve
Carina quella del farlocco, io uso vs.net e quindi non saprei.
Che cosa ci sarebbe di farlocco nel compilatore del kit?
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele
Bubuti Bauontico
2004-09-14 22:51:34 UTC
Permalink
Post by Raffaele Rialdi
Post by Bubuti Bauontico
saranno mica quelle con il compilatore farlocco? perchè nel toolkit
c'è quello vero. E l'ambiente non mi serve
Carina quella del farlocco, io uso vs.net e quindi non saprei.
Che cosa ci sarebbe di farlocco nel compilatore del kit?
Il compilatore farlocco ("Standard Compiler") è quello che non supporta
/O e famiglia
--
< http://www.reactos.com/ > Open source clone of Windows NT. Current
Don't stand, REACT! version 0.2.4. C, C++ and ASM developers
and beta testers are welcome!
Raffaele Rialdi
2004-09-15 10:41:44 UTC
Permalink
Post by Bubuti Bauontico
Il compilatore farlocco ("Standard Compiler") è quello che non
supporta /O e famiglia
Ripeto che non l'ho mai provato, ma a questo link (nelle Q&A) viene detto
che i compilatori sono identici:
http://msdn.microsoft.com/visualc/vctoolkit2003/

Possibile che tu abbia provato un kit molto più vecchio?
--
Raffaele Rialdi
Microsoft .NET MVP http://mvp.support.microsoft.com -
http://italy.mvps.org UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org Weblog: http://blogs.ugidotnet.org/raffaele
Paolo Ferraresi
2004-08-19 17:41:07 UTC
Permalink
Post by Gerolamo
"Paolo Ferraresi" ha scritto
Per curiosità, perchè non ti piace?
Io non è che abbia questa grande esperienza con la programmazione
Windows, ma con C# e Sharpdevelop mi sto trovando abbastanza
bene...
Che ti trovi bene, ne sono convinto...

Ti hanno risposto altri e hanno detto tutti cose che condivido...

Io programmavo in assembly già nel 1983 (6502) e ho lavorato su (alcuni)
computer che non facevano neanche 100.000 istruzioni al secondo... 20 anni
prima dei primi pentium e ci giravano pure dei gran bei programmi (ricordi
per caso Zilog Z80, 6502, Motorola 68000...68030, poi l'Intel 8086 e il
resto è cosa nota...).

Oggi abbiamo CPU da svariati GIPS.

La morale della favola è che il fatto d'avere computer con svariati GIPS
(per me) non è un buon motivo per scrivere codice poco efficiente (che
magari è il più bel software del mondo, questo è un'altro discorso...).

Ho abbandonato del tutto l'assembly nel 1990 (programmavo su di un Motorola
68030) e sono passato al C perché è un linguaggio efficientissimo e
potentissimo, il C++ è ancora più potente e rimane ancora molto efficiente
(conoscendolo bene) e per questo oggi il 99% di quello che realizzo è in C++
ed è in assoluto il mio linguaggio preferito.



Per questo motivo non mi piace: non sopporto un framework così pesante (sono
piuttosto per spendere qualcosa in più e chiamare le API di Windows, oppure,
al massimo usare altri framework "leggeri").



Ciao.

Paolo.
Gerolamo
2004-08-20 08:19:24 UTC
Permalink
"Paolo Ferraresi" ha scritto
Post by Paolo Ferraresi
Post by Gerolamo
Per curiosità, perchè non ti piace?
Io non è che abbia questa grande esperienza con la programmazione
Windows, ma con C# e Sharpdevelop mi sto trovando abbastanza
bene...
Che ti trovi bene, ne sono convinto...
Ti hanno risposto altri e hanno detto tutti cose che condivido...
Io programmavo in assembly già nel 1983 (6502) e ho lavorato su (alcuni)
computer che non facevano neanche 100.000 istruzioni al secondo... 20 anni
prima dei primi pentium e ci giravano pure dei gran bei programmi (ricordi
per caso Zilog Z80, 6502, Motorola 68000...68030, poi l'Intel 8086 e il
resto è cosa nota...).
Oggi abbiamo CPU da svariati GIPS.
Io ho programmato gli ultimi due anni principalmente su CPU sotto
i 30 Mhz, anche a 16 bit.

Questo non significa però che, se devo fare un gestionale su PC,
penso che il modo migliore sia di farlo in assembler.
Post by Paolo Ferraresi
La morale della favola è che il fatto d'avere computer con svariati GIPS
(per me) non è un buon motivo per scrivere codice poco efficiente (che
magari è il più bel software del mondo, questo è un'altro discorso...).
Io dico solo che l'efficienza è l'ultimo dei problemi per una grossa
percentuale di software e io, fedele al noto aforisma di Knuth, penso
che prima val la pena di occuparsi di altre cose, come una buona
progettazione (e un buon framework ti permette una buona progettazione,
un brutto framework ti mette i bastoni fra le ruote), la rapidità
di sviluppo, la facilità di debug.
Post by Paolo Ferraresi
Ho abbandonato del tutto l'assembly nel 1990 (programmavo su di
un Motorola 68030) e sono passato al C perché è un linguaggio
efficientissimo e potentissimo, il C++ è ancora più potente e rimane
ancora molto efficiente (conoscendolo bene) e per questo oggi
il 99% di quello che realizzo è in C++ ed è in assoluto il mio
linguaggio preferito.
Anche per me il C++ è un ottimo linguaggio (pur se troppo complesso)
e probabilmente quello che conosco meglio.
Ma la mia preferenza è data dall'espressività, dalla libertà di scelta
del paradigma di programmazione, dalla quantità di implementazioni,
e da altri fattori di gusto che comunque vengono prima della pura
efficienza (che per altro ina alcuni ambiti è fondamentale assieme
al più stretto determinismo temporale, ma questi sono altri discorsi...)

Comunque grazie per lo scambio di opinioni

ciaociao
--
Gerolamo
Paolo Ferraresi
2004-08-20 12:58:51 UTC
Permalink
Post by Gerolamo
"Paolo Ferraresi" ha scritto
Ciao Gerolamo.
Post by Gerolamo
Io ho programmato gli ultimi due anni principalmente su CPU sotto
i 30 Mhz, anche a 16 bit.
Embedded!?
Post by Gerolamo
Questo non significa però che, se devo fare un gestionale su PC,
penso che il modo migliore sia di farlo in assembler.
Sono assolutamente d'accordo con te. Mai detto il contrario.
Post by Gerolamo
Post by Paolo Ferraresi
La morale della favola è che il fatto d'avere computer con svariati GIPS
(per me) non è un buon motivo per scrivere codice poco efficiente (che
magari è il più bel software del mondo, questo è un'altro discorso...).
Io dico solo che l'efficienza è l'ultimo dei problemi per una grossa
percentuale di software e io, fedele al noto aforisma di Knuth, penso
che prima val la pena di occuparsi di altre cose, come una buona
progettazione (e un buon framework ti permette una buona progettazione,
un brutto framework ti mette i bastoni fra le ruote), la rapidità
di sviluppo, la facilità di debug.
Anche quì, assolutamente d'accordo, però è altresì vero che sebbene è
anacronistico scrivere un programma su PC in assembly nel 99% per cento dei
casi, non solo i programmi fatti con .net sono progettati bene!
Per progettare bene un software c'è bisogno di un team di persone
intelligenti (anche solo una), prima ancora di un buon linguaggio di
programmazione.
Ci sono ottimi programmi progettati bene in tutti i linguaggi, sebbene
linguaggi come il C++ aiutano a scrivere programmi migliori.
Tuttavia nel C++ standard c'è già tutto quello che serve a scrivere ottimi
programmi.

Quindi, se devi usare un framework, puoi comunque sceglierne uno leggero, se
invece hai buoni motivi per sceglierne altri, ovviamente non ci sono
problemi.
Io ne preferisco uno leggero per motivi culturali come ti ho spiagato (o
chiamale pure convinzioni mie, ovviamente opinabili e discutibili).
L'alternativa (dal mio punto di vista) non è fare un ottimo programma con
.net o viceversa fare una schifezza con wxWindows o perché no solo con il
C++ standard.
Io faccio quello che devo fare e se lo posso fare più "light" sto meglio, ma
come avevo detto fin da subito, è una questione puramente personale: niente
contro .net !
Spero di averti chiarito la mia personale opinione.
Post by Gerolamo
Anche per me il C++ è un ottimo linguaggio (pur se troppo complesso)
e probabilmente quello che conosco meglio.
Ma la mia preferenza è data dall'espressività, dalla libertà di scelta
del paradigma di programmazione, dalla quantità di implementazioni,
e da altri fattori di gusto che comunque vengono prima della pura
efficienza (che per altro ina alcuni ambiti è fondamentale assieme
al più stretto determinismo temporale, ma questi sono altri discorsi...)
Non è che per me sia fondamentale l'efficienza a tutti i costi e programmi
in C++ per questo.
E condivido il fatto che l'efficienza venga per ultima, però, in un prodotto
completo e finito a mio modo di vedere, forse non l'efficienza ma almeno
l'assenza di sprechi non dovrebbe essere un optional.
Ci sono programmi in C++ che fanno schifo e ottimi programmi in basic, non è
questo il problema.
Per me il C++ è solo una questione di gusto personale.
Riguardo al framework invece, potendo (e ribadisco potendo, non è detto che
sia sempre possibile) "vestire" i miei programmi, per continuare la
metafora, con una T-shirt invece che con un bel cappotto, mi piace farlo.
Fermo restando quindi che il C++ è sufficiente (come altre soluzioni) a
scrivere programmi efficaci ed efficienti (quando vi è necessità), se sei
d'accordo con me (mi fa piacere anche se non sei d'accordo con me), potremmo
dire che la scelta del framework è una questione legata ad altri fattori.

Potendo però scegliere fra diverse soluzioni (framework) che non inficiano
la bontà del tuo progetto in C++, si sa che alcune, saranno più "comode"
(ricche di classi) o più "essenziali" e minimaliste, altre di maggior
successo, o maggiormente sostenute da questa o da quell'altra comunità,
comunque a questo punto c'entra anche se è possibile (purtroppo non è sempre
così) il gusto personale ed aspetti culturali legati soprattutto
all'esperienza che ognuno di noi si è fatto.
Altri lo hanno detto, in particolare Stefano ha scritto : "Far girare un
programma .Net su una macchina non adeguatamente aggiornata è un suicidio",
io non posso dire che non è così!
Per la mia cultura informatica (che deriva dall'esperienza che mi sono
fatto) un programma deve poter andare anche si di un pentium da 100Mhz e se
è possibile anche su un 386, se è possibile.
Non mi piace dire che è impossibile, solo perché il mio software l'ho fatto
con .net.
Comunque voglio che sia chiaro che sono sicuramente d'accordo con te sul
fatto che non si parla di efficienza per un programma che funziona male o
non fa quello che deve fare, e che l'ottimizzazione prematura è la causa di
tanti problemi.
Post by Gerolamo
Comunque grazie per lo scambio di opinioni
Ma figurati, grazie a te e scusa se mi dilungo sempre.
Io ho sempre grande rispetto per le idee e per il lavoro degli altri, quindi
tieni conto che io dico sempre la mia e so che molte volte mi sbaglio e che
sono fissato su alcune cose.
Daltronte ho premesso che parlavo soltanto di gusti personale e che non ci
sono motivazioni tecniche per cui escludo di programmare con .net.
Se per un mio progetto ritenessi che è la scelta migliore non avrei nessun
problema a usarlo. E non sconsiglio nessuno a non usarlo, anzi, spero che
aiuti tutti a scrivere programmi migliori (anche se penso che chi non è in
grado di scrivere un buon programma in un linguaggio standard, non trarrà
grandi vantaggi dall'uso di un framework, per questo ritengo fondamentale
Post by Gerolamo
ciaociao
Ciao e buon lavoro!
Grazie anche a te per questi scambi di opinione, per me sono importanti e mi
fa piacere.
ri-ciao.
Gerolamo
2004-08-20 13:23:36 UTC
Permalink
"Paolo Ferraresi" ha scritto nel messaggio
Post by Paolo Ferraresi
Post by Gerolamo
Io ho programmato gli ultimi due anni principalmente su CPU sotto
i 30 Mhz, anche a 16 bit.
Embedded!?
Yep.
Prima su Hitachi (Renesas) H8S
16 bit, 20 Mhz, 4Kb di ram, 4Kb di eeprom.
Ci si fano miracoli su una cosa del genere...

Poi sono passato a fare controllo remoto con un linux embedded
su processore Motorola Dragonball a 32 bit (architettura 68000)
e 32 Mb di ram.
Su quella piattaforma ci fai veramente di tutto in 10 x 10 cm,
a patto di imparare a scrivere i driver ed avere un elettronico a
portata di mano.

<spot mode="freestyle">
Approposito, interessa a qualcuno?
Per motivi _non tecnologici_ attualmente quel bellissimo accrocchio
che ci è costato mesi di lavoro sta a prendere la polvere su un tavolo
di un ufficio...
Ethernet, GSM, GPRS, Bluethoot, GPS, 3 seriali (beh... 2 e mezza),
A/D, D/A, IO digitali, sensoristica varia, supporto a
TCP/HTTP/SOAP/Web Services... vabbè... se volete
info contattatemi. :-))
<\spot>
Post by Paolo Ferraresi
Tuttavia nel C++ standard c'è già tutto quello che serve a scrivere
ottimi programmi.
A livello di linguaggio, si.
Ma manca tutto l'aspetto GUI, connettività, DB...
E' per questo che ci sono i framework :-))
Post by Paolo Ferraresi
Spero di averti chiarito la mia personale opinione.
Si
E in realtà sono fondamentalmente d'accordo con te.
Poi, come dici tu, è questione di gusti.

ciaociao!

p.s.
prima o poi troverò il tempo di provare serialmente wxWindows...

p.s.
...e di usare il Python per lavoro. Ma questo non c'entra. :-)
--
Gerolamo
Loading...