Newsgroup: it.comp.lang.vo-clipper
Titolo: Tutto à valido

Vorrei confermare all'ottimo Enrico la stima e la riconoscenza che ho per i
consigli che spesso ho seguito, pur non essendo lui un cultore di VO.
Ma lui continua ad insistere su FiveWin, e dall'ultima lettera sembra che il
trappasso da dos a windows sia quanto di più semplice.
Io ricordo FiveWin ai tempi in cui vi era un distrubutore italiano. a
Bolazono, se non ricordo male, e non si poteva certo dire che la grafica
fosse windows.
Prima di protestare, riconosco subito che nel corso di questi anni i
miglioramenti sono stati sicuramente notevoli, e riconosco anche che,
seguendo la filosofia clipper, tutto e semplice e lineare.
Ma io sto programmando in VO e continuo a programmare in clipper. Ti posso
assicurare che VO ò nettamente superiore, sia perchà si ragiona ad oggetti,
sia perchè l'accesso alle procedure windows è diretto.
Scusa la tendenza a diventare grafomane.
Francesco

 sia perchè l'accesso alle procedure windows è diretto.
Con le FW non puoi scrivere direttamente in C (ma puoi facilmente, come
si è sempre fatto, creare e linkare moduli C) ma puoi utilizzare i
moltissimi wrapper messi a disposizione oppure chiamare direttamente le
funzioni all'interno delle DLL utilizzando una semplice dichiarazione.
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

 ha scritto nel messaggio
news:BWb98.52352$3J1.1...@news2.tin.it...


 Questa č la vera continuity a clipper
Fivewin esiste anche per Xbase++ (compatibile 100% con le altre
versioni). Expres++ non lo conosco. Di che si tratta?


Questa è la vera continuity a clipper
Chi offre di piu'? ;-))))))
Ad essere pignoli, sarebbe strano se (parlando di automobili)
arrivassero quelli della HYUNDAY dicendo che la loro coupè
è *la vera continuity* alla FERRARI GTO (i marchi sono a titolo di
esempio).
Non si discute la qualità dei prodotti, pero' la continuazione di una
Ferrari è un'altra Ferrari.
Così come per Clipper (CA) puo' esserlo ritenuto *solo* un altro
prodotto CA.
Ripeto, ad essere pignoli :-))
===============================================
Antonello Negrone - Biella - Italy
anto...@anc-software.it
www.anc-software.it

 prodotto CA.
Questa è una cavolata, è come dire che la Marea è l'evoluzione della
Panda, il fatto di essere prodotte entrambe dalla Fiat le accomuna
ben poco.
VO è im prodotto completamente diverso da Clipper, pensato ex novo 
con una certa compatibilità con Clipper, invece uno dei cardini di 
Xbase++ è la compatibilità di tutte le funzioni e le classi Clipper
con l'aggiunta di tutto quello che può servire in ambiente Win.
Ciao...
Claudio Driussi
http://www.swit.net/csoft
mailto:
cldr...@swit.net

 con l'aggiunta di tutto quello che può servire in ambiente Win.
Guarda che la stessa cosa vale anche per il VO. Solo che se vuoi un codice
robusto, e veloce quasi quanto il C / C++ occorre scrivere in codice VO
nativo.
Ciao,
    Fabrizio Malaguti


con l'aggiunta di tutto quello che può servire in ambiente Win.
VB e Delphi sono completamente diversi dal Clipper, VO è l'evoluzione
ufficiale di Clipper. Per *ufficiale* intendo prodotto dalla CA.
Inoltre credo sia anche ovvio che l'evoluzione di un prodotto, ad un
certo punto, si distingua dal progenitore per nuove caratteristiche e
funzionalità, con un piccolo prezzo da pagare in termini di
compatibilità.
Io lo reputo un fatto normalissimo e, vista l'esperienza, neanche
troppo oneroso. Personalmente la difficoltà maggiore che ho trovato è
stata la comprensione della logica OOP.
Ciao


 ha scritto nel messaggio
news:3c67ff48...@news.aruba.it...


questo NG.
Scusa Francesco, vorrei ricordarti che questo NG si chiama
it.comp.lang.vo-clipper, quindi e' perfettamente legittimo parlare di
VO ma e' altrettanto legittimo parlare di Clipper in tutte le sue
release e delle sue librerie.
E poi io trovo che un po' di sana polemica faccia bene, anche perche'
se non ci si confronta non si arriva da nessuna parte.
Anch'io mi trovo benissimo con VO e trovo sinceramente eccessive le
critiche che sento qui contro VO, critiche rivolte spesso da chi non
lo ha mai usato, ma si tratta pur sempre di pareri a mio avviso
autorevoli e aappassionati. Del resto non credo affatto che VO sia
perfetto e sicuramente ci sono tante cose da migliorare. Sicuramente
dopo averne provato tanti e' l'unico linguaggio che mi ha consentito
di fare bene e facilmente cio' che volevo, ossia il porting verso
windows di una enorme applicazione scritta in clipper, con grafica
audio e video e un database con una enorme mole di dati, mantenendo la
piena compatibilita' con gli archivi precedenti.
VO e' stato l'unico linguaggio che mi ha permesso di farlo in tempi
umani e prima avevo provato VB, Delphi, Visual FoxPro, Clip4Win,
quell'altro coso che faceva la CA propagandandolo come compatibile
100% col clipper (maddeche', non leggeva neppure i DBF fatti con
clipper, se appena non erano rigidamente in formato DBIII) di cui non
ricordo il nome. Non ho provato le 5Win, che da quanto dice EMG devono
essere eccezionali. Certo se ci fosse una versione Try&Buy magari...
Con VO sono riuscito nel mio intento bene e in breve tempo, con gli
altri mi sono dovuto arrendere per scogli piu' o meno grandi.
Che devo dire? Lunga vita a VO, e lunga vita al Clipper :-)

 ha scritto nel messaggio
news:qbag6ugd8p9mgtfa7...@4ax.com...


 compatibilità.
Dipende, se la perdita di compatibilità tocca punti irrinunciabili
il prodotto viene invalidato. Ad esempio io ho rifiutato VO anche
perché non ha una browse assimilabile alla TBrowse di Clipper,
invece Xbase++ ha la XbpBrowse che funziona praticamente allo
stesso modo.


 questo NG.
Non ho detto che VO è una cavolata, ho solo detto che è una cavolata
sceglere VO sulla base del fatto che è prodotto dalla stessa casa
che ha prodotto Clipper. Anche se in realtà non è proprio così visto
che la CA ha solo comprato la ditta che produceva Clipper ed ha
stravolto i piani produttivi della stessa.
Non ho neanche detto che VO non è un buon prodotto, solamente
non va bene per me.
Senza nessuna polemica.


 sostenitori di Xbase.
Il vero Clipper resta quello che era. Se proprio vogliamo cercarne
un'evoluzione allora forse Harbour mi sembra il candidato migliore.
Clipper non è solo un linguaggio, è anche una filosofia. E Harbour l'ha
pienamente colta, conservata e ci ha costruito sopra.


 Che devo dire? Lunga vita a VO, e lunga vita al Clipper :-)
Giusto!


stesso modo.
Beh, ognuno ha le proprie esigenze secondo le quali farà le proprie
scelte. 
Per me la databrowser non è stata così critica. Ok, ammetto che non
sia il massimo della vita (per di più non è scritta in VO, ma alla CA
hanno pensato di appoggiarsi a terzi, mah...), pero' nel mio caso
fa il lavoro che le chiedo.
Se poi voglio funzionalità avanzate, che vanno ben oltre anche alle
capacità della Tbrowse del Clipper, ci sono ottimi prodotti scritti in
VO che la sostituiscono alla grande (vedi bBrowser).
Una grande mossa per la CA sarebbe di integrare Report Pro e bBrowser,
magari....


 magari....
Non è detta l'ultima parola !!!


Però se FiveWin e Harbour sono un'estensione del clipper originale (essendo
librerie aggiuntive - mi par di aver capito ) significa che generano un
eseguibile di tipo Pcode e pertanto non paragonabile con VO che genera
codice eseguibile vero. La differenza in termini di velocità è quindi
notevole; Se Clipper è circa 170 volte più lento dell'assembler, il VO è
circa 3 volte più lento dell'assembler (quindi circa 60 volte più veloce del
Clipper), mentre il C è circa 2 volte più lento dell'assembler ( quindi
circa 80 volte più veloce del Clipper).
Quindi hai perfettamente ragione a dire che VO non è una semplice evoluzione
del Clipper, semmai ne ha mantenuto l'aspetto esteriore della sintassi e la
filosofia aperta che lo distingueva da altri linguaggi ad alto livello (IV
generazione).
Il VO per le sue caratteristiche è paragonabile al C /C++ /Delphi non certo
con VB/FiveWin/Harbour ecc.
Questo non toglie la bontà di questi ultimi due; in fondo se molti
Clipperisti una volta provate le estensioni GUI di FiveWin o Harbour e non
hanno più cambiato vuol dire che sono prodotti validi ( anzi probabilmente è
per questo motivo che VO non ha avuto la stessa diffusione del Clipper ).
Riguardo al fatto che fivewin e Harbour abbiano mantenuto la sintassi
Clipper al riguardo di comandi come @ SAY GET ( con estensioni GUI ) ha
certamente aiutato il programmatore a migrare in ambiente Windows; comunque
se uno volesse potrebbe benissimo farlo anche in VO creando un set di
comandi come si fa con il Clipper.
In definitiva, come ho più volte detto, la filosofia del VO è più simile al
C/C++ che al Clipper ( di quest'ultimo mantiene la sintassi, il garbage
collector, array dinamici, filosofia aperta, il preprocessore ecc ).
Ciao,
    Fabrizio Malaguti


 collector, array dinamici, filosofia aperta, il preprocessore ecc ).
La sola presenza di un garbage collector non disattivabile lo rende già
molto lontano dal C...
EMG


molto lontano dal C...
In VO esiste una funzione 
DynLock()
che, praticamente, disattiva il garbage collector.
Nella documentazione c'è anche scritto di fare molta attenzione,
poichè l'occupazione di memoria potrebbe aumentare fino a fare
decadere le prestazioni.



Rimando a quanto ha già scritto Antonello Negrone in risposta.
Comunque penso che non conosci tutte le potenzialità del VO. E' per quello
che ti ho invitato a provarlo.
Ciao,
    Fabrizio Malaguti


 decadere le prestazioni.
Infatti il problema non è solamente la presenza del garbage collector.
E' tutta la struttura dell'allocazione delle variabili che dovrebbe
essere rivista. Disattivando il GC non fai altro che impedire il
rilascio della memoria. Mentre in C e in C++ non esistono meccanismi del
genere. Tutta l'allocazione/deallocazione delle variabili avviene in
modo completamente sincrono con il flusso del programma. Le variabili
cosidette automatiche vengono rilasciate alla fine del blocco mentre
quelle allocate dinamicamente sono sotto il completo controllo del
programmatore che le rilascia nel momento esatto in cui non gli servono
più.


 che ti ho invitato a provarlo.
Da quello che vedo dai vostri esempi, ne faccio volentieri a meno. Io ho
trovato in Clipper/DOS prima e in Clipper/Fivewin poi uno strumento ad
alto livello che mi permettesse di concentrarmi sulla problematica del
cliente invece che su quella della programmazione spicciola. Ad esempio,
ho visto quante righe ci vogliono semplicemente per attivare un timer.
Si fa molto prima addirittura in C con le API nude e crude. Con le
Fivewin sono due righe di programma...


collector, array dinamici, filosofia aperta, il preprocessore ecc ).
In definitiva VO e' piu' simile al Clipper, le differenze rispetto a
C/C++ sono troppo marcate.
ciao, acc.   
a...@libero.it

qualche anno fa tra le due versioni).
Per fare un paragone serio e' necessario quantificare il guadagno
effettivo su funzionalita' proprie del linguaggio. Se in un ciclo
viene richiamata una funzione di I/O che a conti fatti incide per il
99.99% del tempo di elaborazione (e non sto affatto esagerando) non ha
senso a questo punto fare un paragone.
ciao, acc.   
a...@libero.it

piů.
Premetto che non conosco il C/C++, non so se si possono comparare i 
metodi di gestione della memoria fra i due, pero' quanto dici sembra 
coincidere con quanto fa VO, cioč gestire 2 tipi di "mappe" di
memoria: statica e dinamica.
Nel caso di VO, il GC agisce solo sulla dinamica, mentre la statica
non viene *toccata* ma gestita in automatico.


 questo caso e' da preferirsi a VO.
Veramente Fivewin è ormai uno strumento multi-compilatore nel senso che
esiste la versione per Clipper, quella per Alaska xBase++ e quella per
Harbour, tutte compatibili al 100% a livello di codice (basta una
semplice ricompilazione). Quindi i limiti di cui parli in realtà non
esistono, o meglio esistono solo se compili i tuoi sorgenti con
Clipper/Fivewin ma non se compili con xBase++/Fivewin o con
Harbour/Fivewin.
EMG


 non viene *toccata* ma gestita in automatico.
No, non è così. Le classi di allocazione per le variabili sono tre:
automatica, statica e dinamica.
La prima è quella basata generalmente su di uno stack nel quale vengono
allocate le variabili definite e dal quale vengono rilasciate, appunto
automaticamente, alla fine del loro scope (blocco). Tieni presente che
queste operazioni in uno stack sono estremamente efficienti (basta
spostare in avanti o indietro il puntatore alla cima dello stack).
L'allocazione statica è quella delle variabili definite static. Sono
variabili che vengono allocate al lancio dell'applicazione e rilasciate
solo al termine. Chiaramente per questo tipo di variabili l'efficienza
dell'allocazione/deallocazione non ha praticamente nessuna importanza.
L'allocazione dinamica, così come intesa in C/C++, è quella in cui è il
programmatore a decidere quando e quanta memoria allocare e quando
rilasciarla. Non c'è dietro alcun meccanismo automatico. Le richieste
vengono indirizzate direttamente ad un gestore di pool di memoria
disponibile (spesso il sistema operativo stesso), chiamato generalmente
heap, e non c'è alcun garbage collector che si occupi di rilasciare o
deframmentare i blocchi rilasciati (ce ne sarebbe la necessità ma il C e
il C++ sono linguaggi talmente ottimizzati che tale scelta è stata
considerata, almeno finora, inaccettabile).
Invece, ad esempio, in Clipper l'allocazione dinamica avviene sempre in
modo implicito (ad esempio quando definisco e uso un array) e il
rilascio è poi soggetto all'intervento asincrono (e quindi
imprevedibile, anche se ci sono dei metodi per forzarlo) del garbage
collector.


 ha scritto nel
messaggio news:3C6B99E1...@emagsoftware.it...

Tutto giusto. In VO comunque c'é l'allocazione statica / dinamica
(esattemente intesa come il C/C++ - infatti é possibile allocare e
deallocare memoria direttamente e riferirsi ad essa con i puntatori - Si, in
VO esiste l'algebra dei puntatori come il C ) e il garbage collector ciò che
mancherebbe sarebbe solo quella automatica ( o meglio per il momento non
sono a conoscenza che esista).
Ciao,
    Fabrizio Malaguti


[...]
molto interessante. 
L'automatica, come concetto, sembrerebbe una *dinamica* che utilizza
un sistema di allocazione piů efficiente ma meno flessibile, giusto?


 ciao, acc.   
a...@libero.it

 un sistema di allocazione più efficiente ma meno flessibile, giusto?
In pratica, sì. Le variabili locali dovrebbero essere allocate in questo
modo ma francamente non so se il Clipper le gestisca così o se siano
comunque sotto il controllo del garbage collector. Qualcuno lo sa per
certo?


 TO
E chi è che ha dichiarato il TO obsoleto? Ma per favore... Comunque non
ho capito il senso di quei test: c'è scritto Clipper Summer 87 ma sono
stati scritti in VO? Mah... Siamo in attesa di spiegazioni...


 certo?
Per certo no, ma per logica direi che sono tutte sotto il controllo del
GC, basta che vedi le convenzioni di passaggo di variabili dei moduli C
per clipper, vengono tutte estratte con le funzioni _par??() e la 
particolare struttura che hanno le variabili clipper.
D'altra parte anche in C/C++ quando allochi variabili dinamiche, poi
per passarle come parametro, passi i puntatori come variabili automatiche
sullo stack.



La TO è obsoleta in VO, sostituita dalle più efficenti UPTO e DOWNTO. In
Clipper rimane TO.
Il senso del test? Volevo dimostrare che utilizzare la sintassi VO nativo
(molto vicina al C/C++ ) è estremamente efficente.
Il test può essere ripetuto in Clipper ( limitandosi alle prime due FOR ) e
in C/c++ ( limitandosi alla 3° FOR ) e paragonare i tempi di risposta per
avere una analisi completa dell'efficenza tra Clipper - VO - C/C++. (io in
questo test mi sono limitato a verificarne quella del VO)
ciao,
    Fabrizio Malaguti


 questo test mi sono limitato a verificarne quella del VO)
Come ti ho già detto (in quanto ero praticamente certo che le tue
valutazioni le avresti fatte su loop del genere) questo tipo di
situazioni non sono assolutamente indicative. Comunque ho voluto, per
curiosità, fare ugualmente le prove in C e in Clipper/Fivewin (in
Clipper DOS non saprei come misurare i millisecondi). I risultati, sul
mio Pentium III 700 MHz, sono i seguenti:
Versione C: 38 mS
Versione Clipper/Fivewin: 21355 mS (21 secondi circa)
Una bella differenza, non c'è che dire. Ma, lo ripeto, queste non sono
situazioni reali. Questi sono i programmi da me utilizzati:
Versione C
#include <stdio.h>
#include <windows.h>
int main()
{
    long k = 0;
    long i;
    DWORD ms = GetTickCount();
    for ( i = 1; i <= 10000000L; ++i )
    {
        k = i;
        k++;
    }
    printf( "%ld\n", GetTickCount() - ms );
    return 0;
}
Versione Clipper/Fivewin
#include "Fivewin.ch"
FUNCTION MAIN()
    LOCAL k
    LOCAL i
    LOCAL ms := GETTICKCOUNT()
    FOR i = 1 TO 10000000
        k = i
        k++
    NEXT
    ? GETTICKCOUNT() - ms;
    RETURN NIL
DLL32 FUNCTION GETTICKCOUNT() AS DWORD;
      PASCAL FROM "GetTickCount" LIB "kernel32.dll"


 EMG
oK. IO li avevo fatti con un DURON 900
ciao,
    Fabrizio Malaguti

 Clipper.
Se apri un database (cosa che in un gestionale è praticamente
irrinunciabile), le prestazioni di un programma in C o in Clipper
tenderanno ad avvicinarsi molto. Se invece devi scrivere un programma
time-critical allora cose come il garbage collector sono inaccettabili.



Vero pero' in un pacchetto paghe vi sono migliaia di operazioni da fare
oltre che la lettura dei databases. Con il clipper avevamo la necessità di
creare un nucleo in C per fare i calcoli in VO non più.
Ciao,
    Fabrizio Malaguti
P.S.
Come vedi il VO assomiglia al C/C++ anche come filosofia. Non trovi?
A me piaceva molto il Clipper ma da quando ho provato VO è tutta un'altra
cosa:
potente quasi quanto il C facile quasi come il Clipper.


 potente quasi quanto il C facile quasi come il Clipper.
Soltanto uno slogan...



Ogni tanto mi ricordo di aver frequentato la facoltà di economia e commercio
e di aver dato l'esame di Marketing.
Ciao,
       Fabrizio Malaguti


 e di aver dato l'esame di Marketing.
:-)))




Vorrei fare alcune precisazioni riguardo all'allocazione in C e in
Clipper, ovviamente non rivolte a te Enrico, che ben sai come
funziona.
A differenza di altri linguaggi (es. pascal, basic), in C non esiste
alcuna gestione del pool stringhe (Heap), anzi a dire il vero non
esistono proprio le stringhe.
L'allocazione di memoria per una stringa, come pure il rilascio della
stessa, viene sempre fatta manualmente tramite una chiamata ad una
funzione di libreria (malloc()), che a sua volta richiama una funzione
del sistema operativo. Non c'e' alcuna garanzia che durante
l'allocazione e specialmente nel caso del rilascio non venga fatta una
garbage collection, questo e' naturalmente a discrezione del sistema
operativo.
Semplicemente si sa che utilizzando la malloc() si puo' andare in
contro a tale prospettiva.
Solitamente quindi, si tende ad allocare la memoria necessaria tenendo
presente la possibilita' di inserire dati di una certa dimensione, ad
esempio dovendo allocare spazio per una stringa che puo' essere al
massimo di 30 caratteri, la si allochera' direttamente di quella
misura. In ogni caso si cerca di evitare di dover "ridimensionare" lo
spazio allocato.
Per quanto riguarda Clipper, il sistema e' quello indicato da Enrico,
pero' c'e' anche un altro problema. In Clipper infatti e' presente un
gestore di memoria virtuale, che puo' utilizzare diversi sistemi per
"swappare" la memoria (EMS o disco o altri sistemi utilizzando ad es.
Blinker). Ad ogni modo il "gestore" di Clipper puo' introdurre tempi
morti relativamente lunghi nel caso di accesso a variabili che in quel
momento sono swappate.
Il problema puo' essere attenuato attraverso l'uso di variabili
locali, naturalmente in Clipper 5.xx, ma non puo' essere risolto
completamente.
Di fatto non esiste un linker che "sostituisca" il gestore di Clipper,
piuttosto ad es. nel caso di Blinker, questo intercetta le funzioni di
trasferimento dati per mapparle in XMS o DPMI.
In ogni caso i limiti di memoria di Clipper rimangono.
ciao, acc.   
a...@libero.it

 spazio allocato.
Si evita di ridimensionare la memoria allocata per cercare di ridurre al
minimo il fenomeno della frammentazione dei blocchi di memoria libera.
Il problema è molto simile a quello della frammentazione dei cluster
sull'hard disk, con la differenza che nel caso della memoria non si
possono utilizzare blocchi non contigui in quanto è richiesto che gli
elementi degli array siano, appunto, contigui.


 linguaggio filosoficamente simile al C o al C++.
Vero. Come a suo tempo dissi sotto il OS Windows tutti i linguaggi sono un
po' dei dialetti del C/C++ ( Se no come si farebbe ad invocare una funzione
delle API senza fare salti mortali?). Il VO è filosoficamente similile al
C/C++ per tante ragioni. Per esempio è possibile alloccare e dealloccare
memoria come il C e utilizzare l'algebra dei puntatori per accedere alla
memoria alloccata. Comunque ci vorrebbero decine di pagine per descrivere
tutte le similitudini tra C e VO. Mi fermo qui.
Ciao,
    Fabrizio Malaguti


 memoria alloccata.
Mi dispiace ma neanche questo lo rende filosoficamente simile al C
(lasciamo perdere il C++ che è tutt'altra cosa...). E anzi, la presenza
dei puntatori, unita a quella di costrutti di livello molto più alto, lo
rende un linguaggio poco affidabile. D'altronde anche il C risulta poco
affidabile proprio a causa dei puntatori stessi, tanto è vero che il C++
ha cercato di ridurne l'utilizzo al minimo indispensabile.


   MEMVAR pKK
Una curiosità, come mai hai usato due MEMVAR?


DWORD GetTickCount(VOID)
E recita bene :-)
Però la funzione GetTickCountLow (notare "low") che permette di avere
una precisione di 1/10000 di secondo è interna a VO.
Anch'io la utilizzo spesso per verificare l'efficienza di  procedure e
simili. Devo ammettere che fino a 5 minuti fa' mi ricordavo fosse un
Win API.


 una precisione di 1/10000 di secondo è interna a VO.
L'unico modo che io conosca di ottenere una precisione del genere è di
utilizzare il cosidetto "high-resolution performance counter", un
dispositivo interno dei Pentium (disponibile non so esattamente da quale
modello). Ma dal nome non sembra che quella funzione lo utilizzi. Perché
altrimenti l'avrebbero chiamata in quel modo e non, ad esempio, come
l'API QueryPerformanceCounter() o qualcosa del genere?


 ha scritto nel messaggio
news:3c711e0...@news.aruba.it...

Volevo utilizzare due PRIVATE ma mi dava errori in compilazione.
Comunque era solo un test. Di solito uso le LOCAL tipizzate.
Ciao,
    Fabrizio Malaguti


Questo è un altro discorso. Più si scrive a basso livello più aumentano le
prestazioni ma aumentano anche le possibilità di creare codice meno robusto
e quindi è più facile che ci siano errori.
Comunque forse intendiamo la filosofia del C/C++ in modo diverso.
Ciao,
    Fabrizio Malaguti


 Volevo utilizzare due PRIVATE ma mi dava errori in compilazione.
Non so se per VO sia lo stesso che in Clipper, ma in quest'ultimo MEMVAR
e PRIVATE sono due cose molto diverse. La prima dichiara semplicemente
che da qualche altra parte la variabile è stata definita come PUBLIC o
PRIVATE mentre la seconda, appunto, definisce una variabile con scope
cosiddetto "dinamico" e cioè esteso dal punto di definizione a tutto il
sotto-albero delle funzioni da questo punto chiamate, fino alla fine
della funzione corrente.


 Comunque forse intendiamo la filosofia del C/C++ in modo diverso.
Probabile. La prima cosa da chiarire è che i due linguaggi C e C++ sono
profondamente diversi. Tanto per dirne una, il secondo è un linguaggio
multiparadigma (programmazione strutturata, programmazione orientata
agli oggetti e programmazione generica).



Da questo punto di vista hai perfettamente ragione. Comunque entrambi
mantengono una filosofia di programmazione a basso livello ( quindi per
utenti esperti ).
Ciao,
    Fabrizio Malaguti



Anche in VO. Probabilmente io ho ottimizzato il compilatore per la massima
efficenza (in pratica non ho probabilmente settato qualche opzione del
compilatore). Pertanto mi segnalava degli errori. Comunque non mi sono tanto
preoccupato in quanto io in VO non uso assolutamente PRIVATE / PUBLIC  ne
MEMVAR (a dire il vero questo vale anche per il CLIPPER 5.2)
Ciao,
    Fabrizio Malaguti


 utenti esperti ).
Vero, anche se il C++ cerca di elevare il livello di astrazione grazie
ai nuovi paradigmi. In realtà non ci riesce completamente e il risultato
è un linguaggio, secondo me, con uno spettro di astrazione ancora più
esteso.


 MEMVAR (a dire il vero questo vale anche per il CLIPPER 5.2)
E fai bene, in generale. Ma, secondo me, in questo modo si perdono
alcune interessanti possibilità. La più banale è quella di avere una
variabile con scope globale. In C e C++ basta definirla al di fuori di
ogni funzione e poi, dove serve, dichiararla extern. In Clipper, se non
utilizzi PUBLIC, come ottieni la stessa cosa?
EMG
