Newsgroup: it.comp.programmare
Titolo: Delphi vs. FreePascal

Immaginiamo che io andassi a comprarmi un manuale su Delphi.
Quanto di quello che imparo mi torna buono su FreePascal?[0]
Uno di questi manuali? Posso anche farmi venire il tutto da Amazon, ma
confesso che siccome č un puro sfizio andare in libreria e accattarlo
avrebbe un suo perchč.
------
[0] delle gui me ne impippa -12, visto che non lavoro su windows, 
    ergo con le GUI 'standard' di Delphi me ne farei pochino
[1] come da punto 0 non userei Delphi, da cui mi interessa sapere 
    quanto mi viene buono per FP. In rete trovo tutorial vecchiotti
    su Pascal, o non fatti particolarmente bene o non li so trovare
    io. :)
[2] si, io sono ancora 0 based.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 Quanto di quello che imparo mi torna buono su FreePascal?[0]
Immagino che i manuali su Delphi siano praticamente tutti molto 
orientati all'ambiente di sviluppo e alla libreria VCL. In fin dei conti 
l'approccio RAD e sempre stato il cardine di Delphi fin dalla sua nascita.
Credo che invece dovresti cercare un manuale sul linguaggio Object 
Pascal (se ne esistono...), praticamente identico in Delphi e FreePascal.
-- 
news:it-alt.comp.software.openoffice : Il newsgroup dedicato a
OpenOffice.org, la suite open source di applicazioni per ufficio.
Saluti, VITRIOL

 Pascal (se ne esistono...)
PS
Ad esempio. puoi iniziare dalla fonte :-)
http://www.freepascal.org/docs/ref.pdf


 avrebbe un suo perchč.
In delphi e' possibile scrivere dei programmi per console in puro e 
semplice pascal.
program hello;
begin
	WriteLn('Hello, World');
end;
ed ottenere un eseguibile HELLO.EXE
Cio' premesso, usare Delphi per fare cio' mi pare un tantinello uno spreco.

 Cio' premesso, usare Delphi per fare cio' mi pare un tantinello uno spreco.
Io comunque non ho delphi. Non ho manco windows, se  č per questo.
Mi interessavo ai manuali di Delphi chiedendomi quanto potessi
riutilizzare per free pascal (che č quello che mi interessa ora).


 
http://www.freepascal.org/docs/ref.pdf
Si, questi li ho chiaramente già trovati. Ma c'è una differenza sottile
(e nemmeno tanto) fra un reference e un manuale. Li mi mette 'in ordine'
tutto quello che si fa in free pascal.
Cioè gli statements li fa a pagina 90 (ora questo non è un problema,
voglio dire quel poco di pascal lo so pure io che non ci ho mai
programmato). 
Ma segue un ordine non didattico. 
E sopratutto non mi da la *pragmatica* del linguaggio. Come si programma
in Pascal 'correttamente' oltre il livello sintattico/semantico.


 avrebbe un suo perchè.
Io compro tutto da Amazon e per un solo motivo: l'usato. Ormai non compro
più i testi nuovi; Finora ho ordinato molti libri da loro e quando dicono
"usato" o "come nuovo" significa praticamente intonso. Su tre libri che ho
ordinato recentemente, ho risparmiato circa il 45% su ognuno.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Per quanto leggo mi danno pure l'artimetica dei puntatori, per dire.
Per curiosità, dove l'hai letto?


> ObjectPascal
Aggiungo il link a una risorsa: 
http://www.marcocantu.com/epascal/
Si tratta di "Essential Pascal", una guida scritta da Cantù e scaricabile
gratuitamente.


> ObjectPascal
Aggiungo il link a una risorsa: 
http://www.marcocantu.com/epascal/
Si tratta di "Essential Pascal", una guida scritta da Cantù e scaricabile
gratuitamente. C'è anche "Essential Delphi".


 Per curiosità, dove l'hai letto?
Sul manuale di FreePascal. Si, non ho reso esplicito che stavo parlando
di FreePascal.
Per dire, questo programma compila e funziona. Come puoi ben vedere,
nella 'print_array' si fa proprio aritmetica *bruta* dei puntatori.
BTW, se poi sbaglio il valore di max, mi scrive monnezza proprio come in
C.
program pointers;
const
  MAX = 10;
var
  index   : integer;
  a_pint  : pinteger;
  a       : array [0..MAX-1] of integer;
procedure print_array(p : pinteger; max: integer);
var
  index : integer;
begin
  for index := 0 to max do
  begin
    write((p+index)^);
    if index <> max then
      write(', ');
  end;
  writeln;
end;
begin
  for index := low(a) to high(a) do
  begin
    a[index] := index;
  end;
  a_pint := a;
  print_array(a_pint, high(a));
end.
Perchè sono contento che ci sia l'aritmetica dei puntatori? Perchè so
usarla e so quando non usarla. Ovvero esattamente come so programmare in
C, averla in pascal non mi rende un pericolo. 
Tuttavia le funzioni di gestione di stringhe, array e matrici mi paiono
nettamente più comode. A partire dal fatto che uno stronzissimo array
(perdonami il francesismo) possa essere interrogato sulla sua
dimensione.
Ecco, no, una procedura come la print_array ovviamente non la scriverei
così. :) solo facevo vedere che in effetti in FreePascal l'aritmetica
dei puntatori esiste. BTW, lo ho visto fare anche in gnu pascal e loro
dicono che viene dal Borland Pascal. Ergo *potrebbe* funzionare pure in
Delphi. 
Suppongo che tu possa rispondermi meglio delle mie supposizioni. :)


 Delphi.
Delphi (e prima di esso il Borland Pascal e ancor prima il Turbo Pascal)
non ha mai supportato l'aritmetica dei puntatori e non la supporta ancora
oggi. Difatti la compilazione di quel codice tira fuori un "operator not
applicable to this operand type" sull'operazione aritmetica col puntatore
e, all'atto d'assegnare il nome di un array al puntatore (nome dell'array
che, al contrario del C, in Pascal non decade in puntatore al primo
elemento), solleva un "incompatible types: 'Array' and 'PInteger'".
Dal mio punto di vista, aggiungere l'aritmetica dei puntatori al Pascal č
solo un modo per estendere le possibilitą d'errore ad un linguaggio che le
aveva accuratamente (e saggiamente) scansate. L'uso esplicito dei
puntatori poteva aver senso fino a 15 anni fa; ormai ci sono innumerevoli
modi per scansarli, grazie al cielo. Spero, in sostanza, che Delphi non
aggiunga mai una feature del genere.


 aggiunga mai una feature del genere.
Quand'anche l'aggiungesse in futuro, a te che cosa cambia?
Nessuno ti impone di farne uso se non ti piacciono.

 Nessuno ti impone di farne uso se non ti piacciono.
Ci mancherebbe che qualcuno mi "imponga" alcunché. Tuttavia, io sono
libero di sperare quello che voglio, anche che uno dei linguaggi che uso
conservi una "purezza" di base. I linguaggi hanno delle filosofie di base
di fondo, che vorrei venissero rispettate. Se ad un linguaggio vengono
aggiunte delle feature, ci sarà sempre chi le userà in modo errato.
L'aritmetica dei puntatori è solo syntactic sugar, qualcosa di non
indispensabile e che offre una forte instabilità potenziale. Non
costituisce un'evoluzione di nulla. Meglio non averla.


 scalare o la differenza tra puntatori.
"ma NON le addizioni..."


 oggi.
Bene. Allora fpc si e Delphi no. Ribadisco, a me piace l'idea di averla
li. Condivido l'idea che sia positivo il fatto che Pascal sia stato
pensato senza. 
Questo vuole dire che il linguaggio è ugualmente usabile senza. 
Tuttavia ritengo anche positivo che per quelli che hanno disperato
bisogno di farsi male (tipo il sottoscritto) la feature sia li.
In effetti il problema dell'aritmetica dei puntatori in C è
*soprattutto* il fatto che:
1. l'analisi statica è indietro (e so precisamente *quanto* indietro)
2. sono *troppo* frequenti. il programmatore è rilassato e lo vede
normale, ergo presta meno attenzione. Se invece è una cosa limitata e
circoscritta è possibile prestare la sufficiente attenzione.


 Nessuno ti impone di farne uso se non ti piacciono.
Guarda, io sono un pythonista. E' *importante* che un linguaggio sia
coerente, quanto più possibile minimale e che indirizzi verso le
pratiche giuste. 
Per cui capisco la posizione. Resta anche il fatto che per me Pascal è
comunque un linguaggio di livello abbastanza basso (comparabile a C++,
per dire). Da cui non mi fa onco avere i puntatori. Alla fine è comunque
un linguaggio che mi fa vedere sotto la memoria sottostante, anche se a
livello leggermente più alto del C.


 nei bottoni).
Purtroppo ho visto sviluppare montagne di codice in questo modo pessimo
anche in Delphi. E' una questione di approccio mentale, di educazione
all'igiene e alla strutturazione del codice. Troppa gente, per esempio,
non sfrutta una delle caratteristiche migliori del C++ e cioè la
possibilità di applicare efficacemente l'idioma RAII; troppa gente non usa
il TDD (e poi mi chiedono come implementare astrusissimi giri di log per
capire perché un'applicazione non funziona); ecc..., ecc..., ecc... 


 Questo vuole dire che il linguaggio è ugualmente usabile senza. 
Be', ma se ci pensi bene, anche il C è ugualmente usabile senza.
E' solo che per come si è abituati a lavorare con esso (puntatori a
manetta), non avere l'aritmetica dei puntatori sembra un peccato grave.
Fa niente che poi la sua presenza giustifichi codice del tipo:
#include <stdio.h>
int main()
{
    int i;
    for (i=0; i["andrea"]; i++)
      putchar(i["andrea"]);
    printf("n");
}
:-)


 dicono che viene dal Borland Pascal.
Dato che stringhe, array e matrici sono indirizzabili comunque tramite 
indice, non vedo la necesita' dell'aritmetica dei puntatori.
Mi sapresti fare un esempio realistico (in Pascal) in cui l'uso 
dell'aritmetica dei puntatori migliora effettivamente il programma?
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 costituisce un'evoluzione di nulla. Meglio non averla.
Allora o non ho capito alcune cose di Pascal oppure stiamo usando il
termine zucchero sintattico in modo diverso.
Tipicamente io uso il termine (e mi pare un uso 'standard') 'zucchero
sintattico' quando parlo di una funzionalità di un linguaggio che (oltre
che chiaramente non aumentare la potenza del linguaggio -- ma questo ha
un qualche interesse solo nel caso dei linguaggi non turing completi
--[0]) semplicemente permette di esprimere una vecchia funzionalità con
una nuova sintassi.
Direi fra questi le list comprehensions di Python e Haskell. I
decoratori di Python (
@foo
def goo(...): ...
<=>
def goo(...): ...
goo = foo(goo)
).
Etc. A me risulta che nel Pascal classico non esista aritmetica dei
puntatori. E con *non esiste* vuole dire che non è che esiste un
costrutto valido e più (o meno) verboso di scrivere p + i dove p è
chiaramente un puntatore. Vuole dire che proprio quando ho un puntatore
non lo posso manipolare in modo da ottenere l'indirizzo dell'oggetto
successivo. 
L'unica cosa che mi viene in mente sarebbe usare cast molto pesanti a
livello logico di 'reinterpret_cast' del C++ (nb, livello logico).
Ovvero prendo il 'numero' che è contenuto dentro il puntatore e gli
sommo qualcosa, poi forzo il tutto a ridiventare un puntatore. Ammesso
che si possa.
Io questo però non lo considererei zucchero sintattico. I cast IMHO sono
in se e per se una funzione sospetta (che la dice lunga sul fatto che
alle volte i linguaggi imperativi avrebbero bisogno di ripensare il
concetto di tipizzazione statica). E tipicamente un cast a livello
logico di reinterpret cast non è una funzione 'completamente' lecita: è
scavalcare bellamente le strutture di controllo del linguaggio (bella
forza poi che si possa fare il tutto). Questo chiaramente nell'ipotesi
che si possa fare quanto descritto nel paragrafo successivo. Sono
abbastanza convinto che la prima parte si  possa fare (ovvero convertire
in numero un'indirizzo, questa è *sempre* un'operazione sicura, per
esempio per stamparla). Non sono altrettanto convinto che un linguaggio
debba sensatamente supportare il cast di un numero ad indirizzo tipato
(ovvero quello che si intende comunemente con puntatore). Io purtroppo
non posso provare, come ci siamo ben resi conto la mia implementazione
di Pascal si è un po' imbastardita...
Tornando a noi, immagino che nemmeno i pointer (ovvero i puntatori non
tipati) ammettano aritmetica ovvero incremento (abbastanza
divertentemente i puntatori non tipati, leggi void*, non ammetterebbero
aritmetica dei puntatori in C++, per lo meno da standard, anche se le
implementazioni fanno la cosa ovvia). E immagino anche che se dai
risposta negativa alla precedente frase allora sia quello che intendi
con 'zucchero sintattico'. 


 capire perché un'applicazione non funziona); ecc..., ecc..., ecc... 
Ma guarda, sono d'accordo su tutto. Resta il fatto che complessivamente
penso che un linguaggio/ambiente siano da lodare se *strutturalmente*
scoraggiono cattive pratiche.


 Be', ma se ci pensi bene, anche il C è ugualmente usabile senza.
Salvo non potere esprimere algoritmi sulle stringhe. In definitiva senza
aritmetica dei puntatori non puoi manipolare le stringhe. Il che è
notevolmente scomodo.
In un linguaggio di programmazione gp le stringhe sono fra i tipi più
importanti in assoluto. In le stringhe sono rappresentabili in due modi:
come array di caratteri, come puntatori a carattere (e buffer di
memoria).
Gli array non li passi nemmeno alle funzioni. :) E comunque nella
maggior parte dei casi interessanti decadono a puntatore. 
A questo punto abbiamo il problema che possiamo manipolare i caratteri
solo ad uno ad uno. Certo, ci sono le funzioni di libreria. Ma esse non
coprono *tutto* quello che uno vuole fare. Se vuoi scrivere una funzione
che manipola una stringa, sei facilmente in presenza della necessità di
aritmetica dei puntatori. 


 dell'aritmetica dei puntatori migliora effettivamente il programma?
No. Non sui due piedi di sicuro. Il linguaggio č stato pensato per
essere comodo *senza*, mi aspetto che il 98% delle cose siano comode
cosě. Per andare a prendere una cosa (in Pascal) che si farebbe meglio
con i puntatori dovrei avere decisamente piů esperienza in Pascal (cosa
che chiaramente non ho, e probabilmente non avrň mai, visto che non vedo
probbabile la sua adozione per quello che devo fare, ma non si sa mai).
Per dire in Python non ho mai avuto il desiderio di fare aritmetica sui
puntatori. 


 aritmetica dei puntatori. 
Ma non è vero! Che c'entra l'*aritmetica* dei puntatori con la gestione
delle stringhe? Mi fai un esempio di codice C in cui sia *indispensabile*
l'aritmetica dei puntatori?


 che si possa.
Si può, ma non ti serve fare neanche questo. Il problema di molti
programmatori è quello di voler usare certi linguaggi, seguendo lo stesso
paradigma di altri, di più basso livello. Se ti serve il C, usa il C. Il C
non è un "high level language" ma da tutti è riconosciuto come un
"intermediate level language"; il Pascal è un linguaggio di alto livello,
che offre costrutti (come le stringhe predefinite) che ti sollevano dal
preoccuparti di certi aspetti.
Quando parlo di zucchero sintattico, poi, intendo proprio questo. Se in C
scrivo *(p+i) non aggiungo nulla di più potente ad un semplice p[i].
Certo, se si evitasse di avere l'aritmetica dei puntatori esplicita, si
eviterebbero anche le assurdità che, siccome *("andrea"+i) è la traduzione
di "andrea"[i] e siccome *("andrea"+i) = *(i+"andrea"), la scrittura
i["andrea"] diviene lecita. Questa è pura e semplice follia.


 l'aritmetica dei puntatori?
Scrivere una funzione che ritorna il quinto elemento di un array che le
viene 'passato'.


 è  codice valido. Perfettamente valido.
Direi di no, non si compila... forse intendevi
char *pc = &c;
-- 
Stefano Frosio
www.esse-effe.com

 costituisce un'evoluzione di nulla. Meglio non averla.
Io dico: meglio avere questo e altro! Piu' possibilita' offre un 
linguaggio, piu' questo e' potente.

 i["andrea"] diviene lecita. Questa è pura e semplice follia.
Tu la chiami follia, ma questi sono semplici giochetti che si fanno col 
C per illustrare il concetto dei puntatori in fase di apprendimento.
Difficile trovare del codice scritto in questo modo, se non per una 
voluta provocazione da parte dell'autore.
Anche se io ricordo di aver fatto qualcosa del genere nel secolo scorso
in una funzione che trascodificava un numero in una lettera.
C'era un assurda cascata di if, che in prima battuta riscrissi con uno 
switch, e in seconda battuta con un semplice
	return "QWERTY"[n];
/* non era QWERTY, ma il concetto era quello */
Ad ogni modo queste cose si fanno solo con le stringhe.
Non ha senso (o non credo che neppure sia possibile) farlo con array di 
altri tipi di oggetti.

 char *pc = &c;
of course. :)


Ad ogni modo queste cose si fanno solo con le stringhe.
Non è vero, anche perché non esistono le stringhe in C: sono array di
caratteri per convenzione terminati da un valore nullo. Se ha senso
per questo tipo di array, *DEVE* avere senso per qualunque array di T
(con T variabile a piacere). E' ovvio.

linguaggio, piu' questo e' potente.
Non č cosě. La potenza non si misura su questi parametri, ma
sull'espressivitŕ di un linguaggio, sulla possibilitŕ di portarti a
fare compiti complessi con poco sforzo. Potente č il C++, potente č
Python e di certo un fattore che contribuisce alla loro potenza č il
fatto che consentono di scrivere codice sicuro, obiettivo che si
ottiene usando sempre meno (nel primo caso) e per nulla (nel secondo)
i puntatori, in maniera esplicita.

viene 'passato'.
int func(int a[])
{
    return a[4];                    
}
A me programmatore, non frega niente che il nome dell'array mascheri
un puntatore (i parametri formali delle funzioni di tipo array
decadono sempre in puntatori al primo elemento). Dentro la funzione
*NON* sto facendo aritmetica dei puntatori, anche se il sistema, a
livello più basso, preleverà l'indirizzo dell'array, vi sommerà
4*sizeof(int) e mi restituirà il valore.

 4*sizeof(int) e mi restituirà il valore.
Solo secondo la tua definizione. Tutto il resto del mondo, conscio
dell'assoluta equivalenza fra [] e *(+) (anzi, della *definizione* del
primo in termini del secondo, proprio a livello di C) direbbe che stai
facendo aritmetica 


Enrico, tu fai una confusione enorme e continui a fraintendere in modo
molto antipatico. Accusi gli altri di dire cose inesatte, quando l'unico a
dire delle inesattezze sei tu. Ti invito ad informarti meglio e sul C, e
sul Pascal. 
Che la scrittura a[i] sia equivalente ad *(a+i) nessuno avrebbe il
coraggio di negarlo e tantomeno io.
Quando si parla di "aritmetica dei puntatori", tuttavia, come già
specificato molte volte da me in questo thread, *NON* si sta parlando di
operazioni del tipo a[i]. E non è una mia definizione, "il resto del
mondo" la pensa esattamente così. 
Non è questo che si intende per "aritmetica dei puntatori", né in C, né in
C++.
Tu confondi tra ciò che è l'aritmetica dei puntatori (operazioni esplicite
"comandate" dal programatore) e operazioni di basso livello operate dal
sistema. Ti invito a leggere quanto riportato al seguente link (il sito è
quello su cui vengono pubblicate le FAQ di comp.lang.c):
http://www.eskimo.com/~scs/cclass/notes/sx10b.html
Quando si parla di "pointer arithmetic" si cita il caso specifico di
operazioni aritmetiche eseguite sui puntatori e *NON* di quanto avviene
under the hood. Ti sbagli grandemente quando dici che il compilatore non
fa più controlli con una sintassi, perché parlando del caso specifico del
Pascal (il C è scevro, per natura, da controlli), il range degli array è
controllato eccome. Cosa che non potresti evidentemente fare aggiungendo a
questo linguaggio l'aritmetica dei puntatori.


Enrico, tu fai una confusione enorme [...]
Dunque, ho riletto i tuoi messaggi a mente fresca e temo d'aver
frainteso io quello che vuoi dire, per cui ti chiedo scusa. Hai
ragione quando dici che, dato p puntatore, scrivere p[i] significa
scrivere sostanzialmente la stessa cosa *(p+i) e che quindi, in un
modo o nell'altro, si sta facendo aritmetica dei puntatori.
Effettivamente, fare il subscript di un puntatore è un'operazione
unica, consentita solo in C. Ovviamente questo non vale per un array.
Quello che frega del C è che le stringhe possono essere gestite in
modo diverso, quindi si applicano, di volta in volta, concetti
differenti.


Non so quanto possa essere utile questo link 
http://www.standardpascal.org/
Nella sezione faq c' č un elenco interessante di libri - con un poco di 
descrizione -
che trattano degli argomenti piů vari..:
da quello che tratta uno standard Pascal, a quello su come fare analisi 
numerica col Pascal,
a quello su come fare un compilatore usando il Pascal ecc.
Poi c' era un vecchio CD in allegato alla rivista Dev n 58.
Pare includa il Borland Delphi 1.0 completo e altro materiale su Delphi.