Newsgroup: it.comp.lang.vo-clipper
Titolo: sono affascinato dal Clipper.. chi mi aiuta.."a conoscerlo" meglio?

Qualche anno fa mi stavo appassionando al "vecchio" Clipper e per impegni di
lavoro ho dovuto accantonare questa grande passione.
Adesso che posso, "voglio" approfondirlo.
C'è qualcuno in grado di aiutarmi.. consigliandomi dei libri o dispense
(magari reperibili su Internet) per iniziare, da capo, a scoprire questo
affascinante mondo?
Sono disponibile anche all'acquisto ma vorrei, per adesso, che fossero di
facile comprensibilità (linguaggio per .."non esperti")
Mi farebbe piacere avere anche copia di listati, possibilmente commentati,
per sperimentare sul campo le varie possibilità di applicazione (chissà
coloro che sono passati a linguaggi più evoluti quanti nel hanno buttati nei
propri cassetti!!).
Grazie per l'aiuto che potrete darmi

affascinante mondo?
Qui trovi parecchio materiale (librerie, sorgenti, documentazione) su
Clipper: 
http://www.the-oasis.net/
Questo e' un altro sito interessante:
http://www.davep.org/
ciao, acc.   
a...@libero.it

Sono un ex programmatore Clipper, non posso che vantare i numerosi
pregi che tale linguaggio possiede nella programmazione in ambiente dos.
Sono lieto che vi siano ancora sostenitori. Tuttavia i tempi cambiano e
le esigenze e gli standard pure.
In bocca al lupo.
Toni

 le esigenze e gli standard pure.
Attenzione a non farsi abbindolare dalla pubblicità e dalle mode.
L'informatica è una cosa diversa.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

EMG
Concordo, non facciamoci abbindolare dalle mode.
Ribadisco di essere un sostenitore di Clipper.
Tuttavia perchè fare in due ore ciò che adesso posso fare in 10 minuti.
I tempi di lavoro sono costi.
E poi il committente ha spesso la meglio.
Piccolo aneddoto:
Realizzai alcuni anni addietro un gestionale, in clipper, per un villaggio
turistico.
Due anni dopo mi venne chiesta una versione, come dire, visuale; più vicina
a windows.
Ma non ero pronto. Così cercai di far notare che la qualità di un programma
non
va di pari passo con l'estetica e gli effetti special.
Morale:
Il villaggio si è  rivolto ad una software house della mia città che gli ha
realizzato un programma
in visual basic.
Il programma è stato consegnato al villaggio dopo un anno esatto dalla
richiesta,
e comunque non ancora terminato.
Il mio caro ex cliente mi faceva notare, durante una mia visita di cortesia,
di non essere molto soddisfatto del risultato e mi chiese
di modificare il programma e terminarlo velocemente.
Ero sufficientemente incazzato: risposi di NO!
Ad ogni modo.
Oggi sono sempre più le aziende che per motivi più o meno validi passano
a programmi visuali. Non possiamo farci nulla.
Cordialità.
Toni

 a programmi visuali. Non possiamo farci nulla.
Vero. Infatti io č dal 1994 che uso il Visual Basic (dalla versione 3) e
non riesco a mandarlo al diavolo proprio perché richiestissimo...


non riesco a mandarlo al diavolo proprio perché richiestissimo...
Cordialità.
Toni

 Parlo di linguaggi ad oggetti, come delphi che attualmente utilizzo.
Hai appena introdotto un terzo termine con un significato ancora
diverso. Linguaggio ad oggetti significa che supporta il paradigma della
programmazione orientata agli oggetti, che è cosa ben diversa dagli
strumenti visuali. Senza offesa, forse hai un pochino di confusione in
testa. Purtroppo questo è l'effetto, molto diffuso, del lavaggio del
cervello della pubblicità...


cervello della pubblicità...
(paradigma?)
La programmazione ad oggetti (comunque da te non definita) non coincide
sempre
con la programmazione visuale. Oggi, per coloro che hanno l'esigenza
di soddisfare le pressanti richieste della clientela, la programmazione ad
oggetti e in ambiente
windows è necessaria.
A volte capita, non me ne vogliano i professionisti presenti in questo ng,
che i tradizionalisti non hanno in realtà le capacità di cambiare.
Credetemi ci vuole più coraggio ad affrontare i cambiamenti
che a restare fermi con lo stesso linguaggio per sempre.
Ma per ogni scelta c'è sempre un valido motivo.
Scusatemi, ho messo da parte la mia diplomazia e mi sono lasciato un po'
andare.
Cordialità.
Toni

 andare.
Non mi pare affatto. La discussione mi sembra anzi molto garbata.


Ha ragione EMG, Delphi e VB usano strumenti di sviluppo moderni, ma il
linguaggio di programmazione è un'altra cosa !!! Delphi, anche se rivisto,
eè pur sempre il vecchio buon Pascal. VB idem con il vecchio Basic, che non
è certo nato per la OOP !!!
A proposito di "linguaggi moderni" hai mai provato Visual Objects. Questo è
un linguaggio NUOVO che utilizza gli strumenti di sviluppo moderni.
Vedi... io credo che oggi tutti i sistemi di sviluppo moderni si assomiglini
un pò. Abbbiamo i soliti strumenti per fare finestre, i soliti controlli,
possibilità di connesione ai DBMS tramite ODBC, gestione colori, icone
ecc....  Secondo me ciò che fa la differenza tra un sistema e l'altro è IL
LINGUAGGIO DI PROGRAMMAZIONE che viene usato per creare applicazioni. In
questo io credo che Visual Objects sia una spanna superiore a molti altri
(VB in testa) proprio perché essendo stato creato ex novo riunisce in sé, in
modo nativo, tutte le moderne tecniche di programmazione In primis la OOP e
una moltitudine di classi create in modo intelligente. Ad esempio la classe
Dataserver è una classe che si occupa di gestire i Database. da essa
derivano due altri classi : DBServer per gestire i file DBF e SqlServer per
gestire OGNI DATABASE CHE USI SQL !!!.  La classe DataServer possiede dei
metodi per gestire i database come Skip, delete, Append, ecc... e grazie
alla ereditarietà della OOP io posso usare GLI STESSI METODI per accedere ad
un file DBF ed un file ORACLE o MySql o ACCESS ecc...
Ho modificato una applicazione che gestisce in contemporanea dei file ORACLE
e file MySql.  In precedenza questa applicazione gestiva solo file DBF.
Ebbene ti giuro che ho cambiato solo alcune righe di programma ed aggiunto
le righe per la connesione ODBC. Ho riutilizzato esattamente i vari append()
skip ecc... come per i DBF
Non ti sembra buono questo ?
Ciao
Enio Donci

 un file DBF ed un file ORACLE o MySql o ACCESS ecc...
Però, a dire la verità, questo è fattibile con qualunque strumento
attuale (perfino col VB!). Quindi non lo porrei come caratteristica
peculiare di VO (che ha sicuramente altri pregi), non ti pare?



diciamo... che nella realta' non e' proprio cosi'. ....(sentito uno
sparo????)
la sintassi, pero',  è molto somigliante: compilare con VO 2.5 direttamente
codice clipper, non *ottimizzato* quindi,  praticamente non è possibile.
d'altra parte la curva di apprendimento e' molto rapida se si conosce il
Clipper e si hanno buone basi OOP.
francosignore
/*=================================*/
Scusate il disturbo.... ma gli spammers sono fastidiosi!
Sostituire * con s  x scrivermi.

 codice clipper, non *ottimizzato* quindi,  praticamente non è possibile.
Vorrei puntualizzare che questa affermazione non ha assolutamente un
carattere di valenza generale ma deve essere interpretata strettamente
nel contesto VO. Al di fuori non ha alcun significato. Dico questo in
quanto qualcuno, leggendo quanto sopra, potrebbe essere portato a
credere che, in qualche modo, del codice scritto in Clipper possa non
essere "ottimizzato" (termine dal significato alquanto vago) rispetto al
codice VO.
Solo per la precisione...


 incappare in errori dovuti alla miriade di "dialetti".
Appunto per questo la Microsoft ha creato gerarchie di oggetti come DAO,
ADO e ora quelli di .NET. Utilizzando, ad esempio, ADO si ottiene
l'indipendenza dai motori utilizzati che sopra attribuisci solamente a
VO. Metodi come Open(), Close(), MoveNext(), AddNew(), Delete(), etc.
servono proprio a questo. E ADO può essere utilizzato da qualunque
strumento di programmazione che abbia accesso a COM, OLE o ActiveX che
dir si voglia.


Si...  però questa soluzione di VO esisteva già dal lontano 1994. Comunque
ti ringrazio per le notizie, è proprio vero che non si finisce mai di
imparare. VO 2.6 avrà delle classi per gestire ADO, quindi dovrò correre a
documentarmi in proposito.
Enio Donci

 codice VO.
Non credo che sia questo il significato, credo intendesse dire che nel
codice VO si fa largo uso di parti del linguaggio incompatibili con
Clipper. In ogni caso ci si deve mettere d'accordo su cosa significa 
"ottimizzato", ad esempio se si chiede l'ottimizzazione della velocita'
di accesso ai DBF non credo che VO possa essere migliore di Clipper.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 ha scritto nel messaggio
news:3D6DC863...@libero.it...


beh,  *ottimizzato* non e' un *termine dal significato alquanto vago*, ma
tra virgolette; e significa appunto: tra virgolette.
non credevo sarebbe iniziato un 3ad su questo. traduco il mio msg
precedente: se qualcuno pensa che possa prendere del codice scritto con la
sintassi del clipper e lo possa compilare impunemente con VO si sbaglia...
se invece intende passare da Clipper a  VO ha buone possibilita' di farlo
rapidamente.
per cio' che riguarda la, pura, velocita' di accesso ai DBF sono d'accordo
con Claudio... del resto la velocita' (x definizione) non puo' mai essere
*ottimizzata*.


 ADO quindi bisognerà che mi documenti.
Lieto di esserti stato d'aiuto.


 di accesso ai DBF non credo che VO possa essere migliore di Clipper.
Credo anch'io.


 rapidamente.
Direi che le due frasi sono parecchio diverse, non ti pare? Questa
seconda č sicuramente piů corretta e mi trova perfettamente d'accordo.


Questa seconda è sicuramente più corretta e mi trova perfettamente
d'accordo.
dovresti dire su cosa sei d'accordo: hai forse acquistato in segreto VO ed
hai fatto delle prove di compilazione???


> di accesso ai DBF non credo che VO possa essere migliore di Clipper.
VO e' sicuramente piu' veloce di Clipper nell'accesso ai DBF e ai file
in generale, cio' e' probabilmente dovuto al fatto che VO chiama
direttamente routine di Windows piu' nuove e meglio ottimizzate per
interagire col sottosistema che gestisce il file-system.
ciao, acc.   
a...@libero.it

 interagire col sottosistema che gestisce il file-system.
E da quando le API di Windows sono "ottimizzate"? :-)


 hai fatto delle prove di compilazione???
No. Sono d'accordo sul fatto che del codice scritto in un linguaggio
difficilmente potrà essere compilato con un linguaggio diverso, e se ci
si riesce (grazie alla compatibilità) certo il risultato potrebbe non
essere ottimale.


 interagire col sottosistema che gestisce il file-system.
Sei proprio sicuro?
Tutte le prove che ho fatto io mi dicono il contrario.
Ho fatto delle prove in C di accesso a basso livello,
stesso programma compilato a 16 e a 32 bit, sulla stessa
macchina quello a 32 bit gira molto piu' lento, se non
ricordo male addirittura 4-5 volte piu' lento.
certo i sistemi operativi a 32 bit hanno l'accesso al disco
piu' veloce, ma di questo beneficiano anche i programmi a 16bit.


piu' veloce, ma di questo beneficiano anche i programmi a 16bit.
Ma come ?  Poco fa mi era sembrato di capire che i sistemi a 32 bit
fossero piu' lenti :-?
ciao, acc.   
a...@libero.it

E da quando le API di Windows sono "ottimizzate"? :-)
Da quando evitano di passare attraverso il DOS per eseguire funzioni a
basso livello con l'hd.
Ok, la faccina l'ho vista troppo tardi...  O:-)
ciao, acc.   
a...@libero.it

 piu' veloce, ma di questo beneficiano anche i programmi a 16bit.
Quindi tu pensi che al livello piů basso le funzioni siano le stesse per
16 e 32 bit, giusto? Ma č cosě? Secondo me no.


 fossero piu' lenti :-?
Allora cerco di spiegarmi meglio.
Prima di tutto dobbiamo distinguere tra Sistemi operativi a 32 bit
ed applicazioni a 32 bit.
I OS della MS a 32bit sono piu' veloci nell'accesso al disco perche' 
applicano l'accesso al disco a 32 bit ed IMO anche perche' con l'uso
della memoria virtuale si ottiene una cache piu' preformante, prova
infatti ad avviare Win98 in modalita' "Prompt con supporto di rete"
ed avviare un programma Clipper, ti accorgerai che molte volte piu'
lento dello stesso programma eseguito da dentro Windows.
Per quanto riguarda le applicazioni il discorso e' diverso, purtroppo
non riesco piu' a trovare il programma C che ho usato per fare i test,
ma usando solo comandi normali come fopen, fseek, fwrite ecc... ti posso
garantire che le prestazioni delle applicazioni a 32 bit sono nettamente
inferiori.


 16 e 32 bit, giusto? Ma č cosě? Secondo me no.
Sono quasi sicuro che e' cosi, non credo che ci siano sotto win funzioni
piu' veloci di fopen, fwrite, fseek ecc... 


 a cercarlo.
Intanto ho scritto il seguente piccolo test:
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define INFILE "C:\\TC\\TCC.EXE"
#define OUTFILE "C:\\TC\\XXXXX.EXE"
int main()
{
    FILE *in, *out;
    int i, c;
    long sec = time( 0 );
    for ( i = 0; i < 1000; ++i )
    {
        in  = fopen( INFILE, "rb" );
        out = fopen( OUTFILE, "wb" );
        while ( ( c = fgetc( in ) ) != EOF ) fputc( c, out );
        fclose( in );
        fclose( out );
    }
    printf( "%ld\n", time( 0 ) - sec );
    return 0;
}
Compilato con Borland TurboC++ 1.01 a 16 bit ci mette, sulla mia
macchina, 40 secondi mentre compilato con Borland C++ 5.5.1 a 32 bit ci
mette esattamente il doppio (80 secondi). Perň continuo a pensare che ci
sia un errore di fondo in questi test. Qualcuno puň fare luce sulla
questione? Magari sarebbe interessante ritrovare il vecchissimo thread
in cui se ne parlň. Dopo lo cerco...


 ha scritto nel messaggio
news:0nib9.23691$ub2.3...@news1.tin.it...


inferiori.
I programmi che girano sui sistemi m$ possono invocare l'accesso al
disco in diversi modi:
- Usando le API di windows
- Usando le funzioni DOS
Molto semplicemente, le API di windows hanno un colloquio piu' diretto
con i driver del filesystem, le funzioni DOS no.  Ne consegue che
queste ultime risultano rallentate.  In genere le funzioni fopen,
fseek, fwrite ecc.. dei compilatori C usano chiamate DOS.  C'e' anche
da tenere presente che in molti casi esiste un certo "overhead",
dovuto alla necessita' di dover commutare da Protected Mode a Real
Mode e viceversa.
NB: non sto sostenendo che le API di windows sono particolarmente
"ottimizzate", ma le funzioni DOS sotto windows sono senz'altro
handicappate.
Lo stesso programma compilato usando chiamate "windows", fornira'
risultati diversi.
ciao, acc.   
a...@libero.it

 risultati diversi.
Ok, puo' essere. 


 mi aiuta.. "a conoscerlo meglio?" :))
Credo non ci sia altro da fare che leggersi il manuale e sperimentare
tenendo le Norton Guide a portata di mano.


 risultati diversi.
Sembra che sia proprio così. Ecco due test, uno a 16 bit DOS e uno a 32
bit API che dovrebbero essere analoghi (se trovate errori ditemelo):
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#define INFILE "C:\\TC\\TCC.EXE"
#define OUTFILE "C:\\TC\\XXXXX.EXE"
#define CHUNK 10000
int main()
{
    FILE *in, *out;
    char c[ CHUNK ];
    int n;
    long i;
    long sec = time( 0 );
    for ( i = 0; i < 1000; ++i )
    {
        in  = fopen( INFILE, "rb" );
        out = fopen( OUTFILE, "wb" );
        while( ( n = fread( c, 1, CHUNK, in ) ) > 0 ) fwrite( c, 1, n,
out );
        fclose( in );
        fclose( out );
    }
    printf( "%ld\n", time( 0 ) - sec );
    return 0;
}
#define STRICT
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <time.h>
#define INFILE "C:\\TC\\TCC.EXE"
#define OUTFILE "C:\\TC\\XXXXX.EXE"
#define CHUNK 10000
void ShowLong( LONG num )
{
    char buf[ 11 ];
    wsprintf( buf, "%ld", num );
    MessageBox( 0, buf, "Attenzione", MB_OK | MB_ICONINFORMATION ) );
}
int main()
{
    HANDLE in, out;
    char c[ CHUNK ];
    long i;
    DWORD n, w;
    long sec = time( 0 );
    for ( i = 0; i < 1000; ++i )
    {
        in  = CreateFile( INFILE, GENERIC_READ, 0, 0, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, 0 );
        out = CreateFile( OUTFILE, GENERIC_WRITE, 0, 0, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL, 0 );
        while( ReadFile( in, c, CHUNK, &n, 0 ) && n > 0 ) WriteFile(
out, c, n, &w, 0 );
        CloseHandle( in );
        CloseHandle( out );
    }
    ShowLong( time( 0 ) - sec );
    return 0;
}
Il primo (DOS) ci mette cinque volte tanto rispetto al secondo (API)!
Che ne pensate?
