Newsgroup: it.comp.lang.vo-clipper
Titolo: Vo e Xbase++

Salve, 
Ho visitato il sito 
www.xbase.it
 in cui si consiglia l'uso di XBAse++
per la migrazione diretta degli applicativi in Clipper. 
Io ho ancora diversi applicativi scritti in Clipper e il problema
della migrazione è un problema che comunque và tenuto in
considerazione.
Come si colloca Xbase++ rispetto a Vo chi è effettivamente l'erede del
Clipper ?
Grazie per chi vorrà rispondere in base a sue esperienze personali.
Ciao 
Annibale
 
 
http://users.iol.it/fredaannibale
http://utenti.tripod.it/fredaannibale
http://www.smscash.it/?907949
http://www.smsclub.it/mediabanner.asp?mediauser=59474
a.freda[NOSPAM]@
libero.it
 . togliere [NOSPAM] per comunicare in e-mail

 Clipper ?
Ma perché far morire Clipper per forza quando esiste un ottimo strumento
che permette di continuare ad utilizzarlo? Parlo delle librerie Fivewin
(
www.fivetech.com
).
EMG

Predichi bene ma razzoli male eh... Enrico !!!
comunque è bene che si provino tutti e due i prodotti .
VO 2.5 puoi scricarlo dal sito 
www.cavo.com
  della cA
eè una versione trial del prodotto.
sinceramente all'inizio è un pò ostico ma dopo un pò di sofferenze (dovute
alla OOP , windows ecc...) si lavora molto bene.  VO è un sistema di
sviluppo completo, si va dall'interfacciamento  con i vari grandi DBMS (come
tutti) fino alla creazione dei Report di stampa professionali.
Gran parte del codice Clipper  viene recuperato ma chiaramente si hanno
delle applicazioni "ibride" che non sfruttano le grandi potenzialità dell'
object oriented e dei nuovi comandi di VO, compresa naturalmente la grafica
delle finestre che va riscritta.
Vedi un pò tu !!!
se hai bisogno di chiarimenti telefonami  03394487682
Enio Donci

Un ambiente di sviluppo sotto Windows non può essere l'erede di Clipper;
VO non ha nulla a che vedere con Clipper se si vuole usarlo nel migliore dei
modi; bisogna cambiare completamente mentalità passando da Clipper a VO,
l'approccio deve essere differente.
Personalmente ho buttato via tutto del Clipper: passando a VO mi ha
ovviamente
agevolato la familiarità con i dbf e con alcuni costrutti sintattici rimasti
simili
(ma a pensarci bene simili a tanti altri linguaggi).
Ho reinvantato da zero l'ambiente di sviluppo ragionando a oggetti, in rete,
a più finestre ecc.
Qualche funzione, parti di logica di alcuni programmi sono state "tradotte"
velocemente forse, ma tutto qui.
Se si è decisi a portare una applicazione così com'è sotto VO, secondo me
è meglio tenersela in Clipper e investire del tempo in un cambiamento
radicale.
Ciao, Antonio Calogiuri
"Annibale" <"a.freda??????????? ha scritto nel messaggio
news:3ad56c36...@NEWS.IOL.IT...


 Predichi bene ma razzoli male eh... Enrico !!!
Che diavolo dici? Io sono solo un semplice programmatore soddisfatto di
utilizzare le Fivewin. Non le vendo mica! Se uno chiede qual'è lo
strumento migliore per passare da Clipper a Windows conservando il
know-how io ho tutto il diritto di consigliare Fivewin.
EMG



Una domanda in argomento: la libreria "DBF", che garantiva la
compatibilita con i comandi di clipper, non è più fornita con VO 2.5?
Sono andato a cercarla per un uso occasionale... ma non l'ho trovata
tra quelle installate dal compilatore.
L'help invece ad ogni comando ex clipper (tipo USE etc.) fa continuo
riferimento a questa libreria. Qualcuno sa dirmi se è un mio problema
oppure le cose stanno così?
Grazie, Marino

 know-how io ho tutto il diritto di consigliare Fivewin.
Sono daccordo ... ma allo stesso modo anche io ho diritto di sponsorizzare
il prodotto che uso perché ne sono soddisfatto, invece tu caro mio non
manchi mai di bacchettarmi quando lo faccio
Va bè.... Enrico lasciamo perdere vai !!!
Ciao e buona pasqua

 manchi mai di bacchettarmi quando lo faccio
Al tempo: i miei ultimi interventi "bacchettatori" non erano indirizzati
a te. Considero la tua attività nel newsgroup perfettamente corretta e
certamente utilissima agli utenti VO. Quello che mi dà fastidio non è
quando si parla bene del proprio strumento (anche se bisognerebbe sempre
essere obiettivi al massimo) ma quando si fa pubblicità alla propria
ditta. Tutto qui.
EMG

Concordo con te ! ma attenzione quella di windev non era una pubblicità.
Forse avrai seguito sul NG la storia dell'improvviso fallimento della ditta
(open team) che faceva da punto di appoggio per tutti i prodotti VO Clipper
e molto altro. Hai notato che panico è successo tra noi ?. Bene... la Ditta
che si è costituita in seguito ha semplicemente (sotto pressione di alcuni
di noi) tenuto ad informarci che era stata costituita e che rimetteva in
moto tutto il meccanismo (UG, vendita prodotti, supporto tecnico ecc...).
Non mi è sembrato che in quei comunicati facesse pubblicità e ti assicuro
non era nelle sue intenzioni, ha voluto dire solo quello che ti ho spiegato.
Tu che avresti fatto al posto loro ? D'altra parte il popolo VO  Clipperista
Xbase++ Fivewin ecc. penso che abbiano avuto piacere di sapere che potevano
tirare un sospiro di sollievo.... o No ?
Ciao

ovviamente
Concordo con quello che dici alla fine bisogna nel passaggio
dimenticarsi della vecchia applicazione e riscriverla di nuovo. A me
quello che ha sorpreso è l'affermazione che XBase ++ possa ricompilare
il vecchio sorgente Clipper e portarlo a 32 bit. E' possibile una cosa
di questo genere? Enrico con Five Win bisogna buttare l'applicazione
in Clipper e riscriverla o è possibile recuperarla come affermano i
produttori di XBase++. 
Penso che la differenza sia notevole....
Ciao a tutti e Buona Pasqua! :-))



Ok, basta che non diventi un'abitudine.
EMG

 produttori di XBase++.
Non è certo possibile prendere un'applicazione Clipper/DOS e
semplicemente ricompilarla per Windows (non penso possa esistere uno
strumento del genere). Però con le Fivewin è possibile conservare
veramente una altissima percentuale del codice (non solo quello di
elaborazione ma anche quello relativo alle maschere) in quanto Fivewin
non è uno strumento diverso ma una libreria per Clipper e quindi si
continua ad utilizzare il caro vecchio compilatore con tutti i suoi
comandi e funzioni. Se uno poi, come me, già scriveva i programmi
Clipper/DOS con un occhio all'interfaccia utente a finestre allora il
porting riesce liscio come l'olio.
EMG

 produttori di XBase++.
Posso assicurarti che e' vero, o meglio conservi il 97% del sorgente,
qualche piccola modifica la devi fare, ma solo interventi veramente minimi.
Naturalmente continuerai ad avere una applicazione text mode, ma a 32bit
con la possibilita' di interfacciarti a Windows direttamente ad esempio
chiamando DLL.
Io ho scelto Xbase++ e sto faticosamente portando avanti un progetto per
lo sviluppo di applicazioni GUI, in questo caso la parte da riscrivere e'
molta, riesco a conservare solo routine di elaborazione dati.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 chiamando DLL.
Vorrei rendere chiaro che Claudio sta parlando dell'XBase++. Con le
Fivewin conservi un'altissima parte del sorgente anche se stai passando
ad applicazioni GUI.
EMG

chiamando DLL.
Ma cosi' si puo' fare anche con VO2.5!
Basta riscrivere le schermate (ci vuole un minuto con l'editor). Con
VO1.0 in modo testo funziona tutto (a 16 bit ovviamente)
Ignazio GSS©
More than 90 HiRes images in my home page  
http://www.geocities.com/~puddu/
Oltre 200 Immagini di endoscopia digestiva
http://www.areamedica.com

 ha scritto nel messaggio
news:3AD5ABC7...@flashnet.it...


 ha scritto nel messaggio
news:3AD87DB4...@flashnet.it...


 Perchè sono a 16 bit, ossia incompatibili con windows xp
A parte che è tutto da dimostrare (si dice la stessa cosa da molte
versioni di Windows, anche per il DOS, e invece...) e io ho sentito di
gente che ha provato con XP senza riscontrare problemi, comunque c'è
sempre Harbour (
http://www.Harbour-Project.org
), che è a buon punto, e
la relativa versione delle Fivewin. Quindi, come vedi, Clipper non
muore. :-)
EMG

(
www.fivetech.com
).
Ci sono casi in cui Clipper va'  ancora bene, ma esistono situazioni
in cui cominciano ad affiorarne i limiti (eh l'eta'...). Ad esempio,
io ho bisogno di:
- accesso alle API di Windows (quelle a 32 bit)
- accesso a tutte le funzioni di Networking (vedi sopra)
- possibilita' di utilizzare nomi lunghi (anche su Win2k)
- interazione con codice C (con chiamate alle API di win)
- gestione client/server
- IPC (magari *sigh*)
ciao, acc.   
a...@libero.it

 - IPC (magari *sigh*)
Attualmente l'unico limite di Clipper/Fivewin sono le funzioni che
coinvolgono il multithreading, al quale, a quanto pare, non si può
accedere da applicazioni a 16 bit (limite facilmente superato compilando
con Harbour, non mi stancherò mai di dirlo, che da questo punto di vista
sembra sia già perfettamente utilizzabile). Tutte le altre non
comportano particolari problemi.
EMG

 ad applicazioni GUI.
A questo mondo tutto e' relativo, dipende da come vuoi strutturare 
l'applicazione GUI, un solo esempio: se vuoi aprire piu' volte la stessa
tabella con Clipper devi assegnare alias diversi ed in ogni caso mi pare
che era una pratica sconsigliata, con Xbase++ puoi far girare le due tabelle 
in due thread separati.
Secondo me il livello di portabilita' di un sorgente dipende da come
era strutturato il sorgente di partenza e da come vuoi che sia strutturato
il sorgente di arrivo.


 Clipper.
Forse c'e' una piccola differenza tra il Basic del Commodore 64 ed
il Visual Basic.NET, non che il secondo mi piaccia molto, ma con il
primo non credo che riesci a far girare programmi in multithreading.
A livello di linguaggio su Clipper niente da dire, anche secondo me
e' il migliore esistente per la soluzione delle problematiche gestionali.
Il problema e' che non esiste una implementazione ottimale per Win a 32
bit, tutto qui.
A mio giudizio tutte le soluzioni sono imperfette e tra queste cito
Clipper+FiveWin, Harbour+FiveWin, CA-VO e Xbase++.


 Clipper+FiveWin, Harbour+FiveWin, CA-VO e Xbase++.
Mah, dovresti precisare meglio cosa intendi per "imperfette". Ma forse
anche per "soluzioni". Un linguaggio di programmazione non è una
soluzione ma uno strumento per sviluppare soluzioni.
EMG

 il sorgente di arrivo.
E' vero. Ma se lo strumento che usi è lo stesso di prima (Clipper)
l'organizzazione del sorgente influisce molto poco.
EMG

 soluzione ma uno strumento per sviluppare soluzioni.
Un linguaggio e' uno strumento per programmatori e quindi e' la
"soluzione" che permette al programmatore di lavorare, quanto ad 
"imperfette" e' un guidizio personale che ho dato agli strumenti che
ho citato, la soluzione perfetta per me sarebbe stata un Clipper+FiveWin
a 32bit sviluppato da CA con un po' di strumenti visuali ed una browse
GUI all'altezza della TBrowse, insomma quello che doveva essere il
progetto Aspen.
Non venirmi a dire che tutto questo c'e' gia con FiveWin, perche'
quando le ho esaminate, purtroppo non soddisfavano alcuni dei
requisiti, (sempre secondo il mio giudizio).


 problemi applicativi. :-)))
"Io spero che me la cavo" anche con quelli. :-)
comunque e' una questione di astrazione, se chiamo due volte la stessa
procedura per la gestione interattiva di una tabella, preferisco avere
un solo alias, poi la soluzione si trova a tutto, si puo' anche fare
una cosa del genere: (cMyAlias)->MyField, ma in ogni caso era solo un
esempio.


 requisiti, (sempre secondo il mio giudizio).
E quali sarebbero questi requisiti? Penso che allora neanche la TBrowse
li soddisfacesse, giusto?
EMG

 quelle offerte dalle Fivewin.
E' probabile, ma considera che la scelta di un sistema di sviluppo molte
volte e' un atto di fede, infatti per conoscere a fondo un linguaggio ed
arrivare a produrre ci vogliono mesi, ho perso qualche giorno su FiveWin e
qualche giorno su CA-VO, non posso dire di conoscerli ma non mi
trasmettevono un buon feeling. Probabilmente ho fatto l'errore piu' 
madornale della mia vita, ma ormai la scelta e' fatta.



Dipende come è stato scritto il sistema operativo.
BE è diverso da Windows 2000.
Alessandro Zambonin

 madornale della mia vita, ma ormai la scelta e' fatta.
E qual'è lo strumento che poi hai scelto?
EMG

 E qual'è lo strumento che poi hai scelto?
Xbase++


 Xbase++
E allora perché non provare le Fivewin per Xbase++?
EMG


Io penso che sia proprio questo il problema. Alla fine comunque
l'applicazione per essere compatibile al 100% con l'ambiente Windows
bisogna necessariamente riscriverla. Penso che su questo concetto, da
quanto si è scritto,  non ci piova. Il problema è che si scrive troppo
spesso di un prodotto come se con un colpo di bacchetta magica riesca
a risolvere tutti i problemi di un programmatore alle prese con
migliaia di righe di codice da convertire. Si la conversione avviene
al 97 % come scrive Claudio ma a mio avviso è qualcosa di diverso da
quello che è un applicativo effettivamente Windows. 
La mia sensazione è che sono passati prodotti ottimali per questo tipo
di conversione dal Dos a Windows ma che purtroppo vi sono state troppe
aspettative su Vo che, essendo in mano a CA, le ha tradite spostando
la massa dei programmatori Clipper su diverse strade.
Io penso che il progetto Fivewin sia valido anche perché viene ripreso
anche in ambiente XBase++ e questa non può essere certamente una pura
coincidenza. E' una mia sensazione anche se ho preso una strada
completamente diversa e del quale comunque sono soddisfatto. 
Resto comunque dell'idea che l'ambiente Windows soffre di instabilità
croniche dovute alla tipologia di sistema operativo che come concetto
di base prevede la condivisione di risorse da parte di più applicativi
installati sullo stesso computer. Un gestionale in Clipper sicuramente
fà dormire sonni più tranquilli ad un programmatore. Ma tant'è il
mondo và avanti ed in qualche maniera anche noi dobbiamo seguire una
certa strada volenti o nolenti.
Certo è che comunque ho la sensazione che sono stati buttati diversi
anni in cui si è mosso poco e quel poco che si è mosso si è mosso male
ed in una sola direzione.
Purtroppo nella vita passano tanti treni ed ognuno di noi spera di
montare su quello giusto. Non è sempre così ma è quello che io auguro
a tutti Voi.
Ciao 


 E allora perché non provare le Fivewin per Xbase++?
Al momento c'e' un po di maretta tra Linares e quelli
di Alaska Software, nel loro ng sono volate parole grosse,
comunque a parte questo Xbase++ dispone gia' di una libreria 
GUI OOP, certo non e' a livello di quella di Delphi ad esempio,
ma e' abbastanza semplice da usare e abbastanza stabile.
Le FiveWin per Xbase++ potrebbero essere utili a chi gia
le usa con Clipper e vuole passare ai 32bit senza aspettare
Harbour.


 ed in una sola direzione.
Parole sante.


fare VO
Bah, io VO 2.5 lo trovo fantastico. Non tornerei al clipper+chissacosa
per nulla al mondo.


 a tutti Voi.
Secondo me un programmatore con una buona cultura informatica di base
non ha nessun problema a cambiare treno al momento giusto o anche a
prendere più di uno.
EMG

 Harbour.
Senza dubbio. Ma anche per la intrinseca validità del framework, per la
sua struttura logica ed intuitiva e per la sua alta compatibilità con le
classi standard del Clipper.
EMG

 per nulla al mondo.
Il mondo e' bello perche' e vario. Io di VO non apprezzo il sistema di
gestione dei database con classi interfacciate ad ODBC relegando in
un angolino il paradigma standard dei DBF, avrei apprezzato molto di
piu' un potenziamento dei DBF verso il Client/Server sullo stile di
Advantage.
PS: Molto belle le tue foto, ora fanno bella mostra di se nella mia
    collezzione di Wallpaper.


    collezzione di Wallpaper.
Grazie :-)


EMG


girare sulle due macchine senza problemi
Ecco: questo e' l'enorme punto di forza di VO. Ho installato in nostro
programma (che tra l'altro e' abbastanza complicato e gravoso per il
sistema, utilizzando acquisizione diretta video e gestione grafica)
scritto in VO2.5 su CENTINAIA di computer e su nessun computer ho
avuto il minimo problema di compatibilita'. E' stato installato su
windows 95/98/98SE/ME/NT/2000Pro in varie lingue e a parte win95 che
ha avuto necessita' di aggiornare le directx e il mediaplayer con gli
altri MAI NESSUN PROBLEMA. Non e' una cosa da poco.



http://www.areamedica.com
http://users.iol.it/fredaannibale


 che non riescono ad arrivare in stazione perché deragliano prima...
Profondamente vero...
EMG


Infatti. Non capisco perche MS non supporti adeguatamente foxpro. 


 Ecco: questo e' l'enorme punto di forza di VO.
Solo che non è esclusivamente di VO. :-)
EMG

Solo che non è esclusivamente di VO. :-)
Vorrei pure vedere! :-)


 ha scritto nel messaggio
news:3ADEEC61...@libero.it...


comportano particolari problemi.
Il multithreading non mi interessa, cio' che manca e' la possibilita'
di accedere alle funzioni di win32.
ciao, acc.   
a...@libero.it

installati sullo stesso computer.
Linguaggi come Clipper, VO, Xbase ecc... secondo me non dovrebbero
'legarsi' ad un sistema operativo, ma essere indipendenti da esso.
ciao, acc.   
a...@libero.it

 un file.
Esiste ancora il concetto di workarea con i comandi classici xbase?
oppure bisogna comunque aprire un oggetto DBServer per collegarsi ai database?


oppure bisogna comunque aprire un oggetto DBServer per collegarsi ai database?
Assolutamente no.


 'legarsi' ad un sistema operativo, ma essere indipendenti da esso.
Esatto. Da qui il mio entusiasmo per il progetto Harbour
(
http://www.Harbour-Project.org
).
EMG

 di accedere alle funzioni di win32.
Scherzi? Io, con Clipper/Fivewin e il suo comando DLL32, sono sempre
riuscito ad accedere a tutte le API Win32 che mi sono servite e anche
alle DLL di produttori non Microsoft. Ti faccio una lista di quelle da
me personalmente utilizzate:
FindFirstFileA()
FindNextFileA()
FindClose()
CopyFileA()
MoveFileA()
DeleteFileA()
CreateDirectoryA()
RemoveDirectoryA()
GetDiskFreeSpaceExA()
SetCurrentDirectoryA()
GetShortPathNameA()
ShellExecuteA()
GetFileAttributesA()
SetFileAttributesA()
GetForegroundWindow()
GetDriveTypeA()
NViewLibLoad() dalla libreria freeware NViewLib
EMG

 > po' pesante) dall'IDE oppure, piů leggero,  costruire al volo un


EMG


esiste.
Esatto. Ma spiegami una cosa che non ho ancora capito. Secondo te cosa
farebbe Clipper+Fivewin che non puoi fare con VO2.5?
In cosa renderebbe piu' facile il porting dei programmi da DOSa
Windows? A parte GET e SAY, che sotto windows comunque servono a poco,
visto che puoi usare l'editor di finestre di VO che ti permette di
ottenere risultati infinitamente superiori, il 99% del codice che hai
scritto il clipper lo puoi utilizzare con VO, senza cambiare quasi
nulla. L'interfaccia utente la devi rifare in ogni caso se vuoi fare
un programma che ustilizzi lo stile di windows. Mi spieghi allora
perche' Clipper+ Fivewin e non VO2.5 in cui hai tutto gia pronto ed
omogeneo senza bisogno di altro (a parte forse il Report Pro)?
Io avevo una applicazione enorme sotto DOS (Clipper s87) e l'ho
portata senza problemi sotto VO2.0 (poi 2.5). All'inizio ho lasciato
le procedure come erano, poi piano piano me lo sono trasformato in
object-oriented 100%, ma ha funzionato da subito senza sforzo. L'unico
sforzo e' stato entrare nella filosofia della programmazione per
eventi/oggetti tipica di windows, ma quello lo devi fare con qualsiasi
linguaggio.


 omogeneo senza bisogno di altro (a parte forse il Report Pro)?
In Fivewin hai *anche* il generatore di report incorporato. Inoltre di
tutto il sistema (report compreso) sono forniti i sorgenti, una risorsa
documentativa niente male specialmente se si vuole operare in modo OO
(ma anche per rimediare eventuali bugs senza dover dipendere dai
produttori).
EMG

produttori).
Questa e' cosa ottima.


 Annibale


libreria *può* estendere il linguaggio e anzi nasce proprio per quello.
Breve premessa:
Programmo in Clipper da quando esiste, non l'ho mai abbandonato,
sicuramente devo molto a questo linguaggio e se ho ben capito mi pare
che anche tu sia dello stesso parere...
E allora perche' mi inviti a parlarne male ???  ;-)
Ma torniamo alle "mancanze di base":
Il formato interno piuttosto 'libertino' delle variabili introduce un
notevole overhead, non pretendo che Clipper sia veloce come il C ma
neanche che sia 500 volte piu' lento (e in certi casi anche di piu')
Volendo e' possibile migliorare la situazione usando funzioni C o ASM
salvo poi scontrarsi con l'overhead introdotto dal sistema di
interscambio dei parametri formali/valori ritornati.
Non esistono tipi di dati agglomerati (struct), gli array possono
memorizzare dati di diverso tipo, ma non e' la stessa cosa...
Funzioni di Networking piuttosto scarse...
Gestione della memoria obsoleta...
Architettura Client/server inesistente e non implementabile (almeno
non in Clipper)
Dimensione massima degli oggetti 64KB
Va detto, che la maggior parte delle limitazioni sono riconducibili
all'abbandono dello sviluppo del progetto e a carenze del sistema
operativo (DOS) ad ogni modo esistono e non sono piccolezze.
Sebbene Clipper fosse nato come compilatore per dBase, con tutti i
limiti imposti da questa scelta, l'evoluzione del prodotto (fino alla
ver. 5) e' sempre andata nella direzione di slegarsi dalle sue origini
fino ad assumere una propria identita'.
Come ho gia' detto in precedenza, credo che se Clipper fosse ancora un
prodotto Nantucket, sviluppato con lo stesso entusiasmo di qualche
tempo fa, oggi queste lacune non ci sarebbero.
Se oggi devo sviluppare un software che richiede certe caratteristiche
che in Clipper sono assenti, sono costretto ad usare un altro
linguaggio...
Non sono io che ho abbandonato Clipper, e lui che ha abbandonato me!
ciao, acc.   
a...@libero.it

 Non sono io che ho abbandonato Clipper, e lui che ha abbandonato me!
Come vedi invece sei tu che lo hai abbandonato, poverino! :-)
EMG

possa fare un paragone.
Il confronto e' impari, ma rende l'idea
Buttato giu' in fretta e furia, non ho tempo e non sono Thomas Pabst
Spero mi possiate perdonare per la lunghezza...
NOTE:
- Il Clipper e' il 5.2d + RTlink (no debug)
- Il C e' ms 7.0 (no stack check, no debug, optimizations OFF), codice
per 286 RM
- I test in C vengono eseguiti 100.000 volte, quelli in Clipper solo
1.000 volte (ho soltanto un Athlon 800, non un Cray)
- Clipper lavora sempre in FP (tra l'altro senza poter usare FPU),
mentre il C usa gli integer, ho barato ? No ho semplicemente sfruttato
le caratteristiche del linguaggio, l'avevo detto che al Clipper
mancavano gli int...
Anyway...
Output di TESTC.EXE:
Sieve ( 1000 elem 100000 volte) -    5.005 sec
Sort  ( 1000 elem 100000 volte) -    3.300 sec
Totale                               8.305 sec (scusa se e' poco!)
Output di TESTCLIP.EXE:
Sieve ( 1000 elem   1000 volte) -    7.520 sec
Sort  ( 1000 elem   1000 volte) -  265.730 sec
Totale                             273.250 sec (Miii come sono lento!)
//////////////////////////////////////////////////////////////////////
// TESTC.C
#include <memory.h>
#include <stdio.h>
#include <stdlib.h>
enum boolean { FALSE, TRUE };
#define	S_SIZE		1000					// per
Sieve
#define S_ITER		100000L					// per
Sieve
#define	Q_SIZE		1000					// per
Qsort
#define Q_ITER		100000L					// per
Qsort
unsigned long far *RTC = (unsigned long far *)0x46CL;
char	Flags[S_SIZE+1];					// per
Sieve
int		Array[Q_SIZE];
// per Qsort
unsigned long StartRTC;
int Sieve(void) {
	register int k, prime;
	int j, count = 0;
	memset(Flags, TRUE, S_SIZE);
	for (j = 0 ; j <= S_SIZE ; j++) {
		if (Flags[j]) {
			prime = j + j + 3;
			k = j + prime;
			while (k <= S_SIZE) {
				Flags[k] = FALSE;
				k += prime;
			}
			count++;
		}
	}
	return count;
}
void Mk_array(void) {
	int	i;
	srand((unsigned)*RTC);
	for (i = 0; i < Q_SIZE; i++)
		Array[i] = rand();
}
int Cmp_ints(const void *i1, const void *i2) {
	return (*(int *)i1) - (*(int *)i2);
}
unsigned long CronStart(void) {
	unsigned long start, now;
	start = *RTC;
	while ((StartRTC = *RTC) == start)
		;
	return StartRTC;
}
double CronStop(void) {
	return (double)(*RTC - StartRTC) * 0.055;
}
void main(void) {
	long i;
	double sec, tot = 0.0;
	printf("Sieve (%5d elem %6ld volte) - ", S_SIZE, S_ITER);
	CronStart();
	for (i = 0 ; i < S_ITER; i++)
		Sieve();
	sec = CronStop();
	printf("%8.3f sec\n", sec);
	tot += sec;
	Mk_array();
	printf("Sort  (%5d elem %6ld volte) - ", Q_SIZE, Q_ITER);
	CronStart();
	for (i = 0 ; i < Q_ITER; i++)
		qsort(Array, Q_SIZE, sizeof(Array[0]), Cmp_ints);
	sec = CronStop();
	printf("%8.3f sec\n", sec);
	tot += sec;
	printf("Totale                            %8.3f sec (scusa se
e' poco!)\n", tot);
	exit(0);
}
//////////////////////////////////////////////////////////////////////
// TESTCLIP.PRG
#define	S_SIZE		1000					// per
Sieve
#define S_ITER		1000					// per
Sieve
#define	Q_SIZE		1000					// per
Sort
#define Q_ITER		1000					// per
Sort
static Flags
// per Sieve
static Array
// per Sort
static StartRTC
func main
	local i
	local sec, tot := 0
	Flags := array(S_SIZE+1)
	Array := array(Q_SIZE)
	? "Sieve ("+str(S_SIZE,5)+" elem "+str(S_ITER,6)+" volte) - "
	CronStart()
	for i = 1 to S_ITER
		Sieve()
	next
	sec = CronStop()
	?? str(sec, 8, 3)+" sec"
	tot += sec
	Mk_array()
	? "Sort  ("+str(Q_SIZE,5)+" elem "+str(Q_ITER,6)+" volte) - "
	CronStart()
	for i = 1 to Q_ITER
		asort(Array)
	next
	sec = CronStop()
	?? str(sec, 8, 3)+" sec"
	tot += sec
	? "Totale                            "+str(tot, 8, 3)+" sec
(Miii come sono lento!)"
return 0
static func Sieve
	local k, prime, j, count := 0
	afill(Flags, .T.)
	for j = 1 to S_SIZE
		if Flags[j]
			prime := j + j + 3
			k := j + prime
			while k <= S_SIZE
				Flags[k+1] := .F.
				k += prime
			enddo
			count++
		end
	next
return count
static proc Mk_array
	local	i
	for i = 1 to Q_SIZE
		Array[i] := Random(1000)
	next
return
func Random(max)
	static seed
	local m := 100000000, b := 31415621
	seed := if(seed == NIL, seconds(), seed)
	seed := (seed * b + 1) % m
return int(max * (seed / m))
static func CronStart
	local start := seconds()
	while (StartRTC := seconds()) == start
	enddo
return StartRTC
static func CronStop
return seconds() - StartRTC
ciao, acc.   
a...@libero.it

 void main(void) {
int main()
è la forma corretta.
EMG

 è la forma corretta.
In alcuni compilatori sono sinonimi, void ha un significato
rafforzativo che indica un parametro di cui non si ha bisogno.


 rafforzativo che indica un parametro di cui non si ha bisogno.
Leggiti lo standard. La forma
void main();
non esiste ed è errata. Molti compilatori la tollerano ma la
sostituiscono silenziosamente con
int main();
D'altronde la funzione main() è dichiarata dal compilatore stesso e le
uniche due dichiarazioni valide sono
int main();
e
int main( int argc, char *argv[] );
EMG