Newsgroup: it.comp.lang.delphi
Titolo: da win32 a dotNet

Sto sscrivendo un applicazione in win32 (per richiesta del cliente), ma 
mi sto lasciando aperta la porta nel caso si dovesse passare a dontnet.
Mi chiedevo cosa bisogna crecare di evitare in delphi per avere una 
buona compatibilita' in particolare non so come gestire le liste di record
PMyRecord = ^TMyRecord;
TMyRecord = record
  A: Integer;
  B: Integer;
end;
TMyClass = class(TList)
   procedure AddRecord(A: TMyRecord)
end;
procedure TMyClass.AddRecord(A: TMyRecord)
var
   LRecordRef: PMyRecord;
begin
   New(LRecordRef);
   LRecordRef^ := A;
   Add(LRecordRef);
end;
La prima cosa che ho pensato e' usare solo Oggetti, come instanze di 
classi, ma a volte per oggetti piccoli e' comunque comodo avere un 
record (che puo' essere passato per valore) e non un instanza di una classe.
Una cosa genere in Delphi .Net come si puo' tradurre.
Grazie a chi mi risponde.
Giuseppe

 buona compatibilita' in particolare non so come gestire le liste di record
Per prima cosa, non usare le liste di record :-)
Esistono le TList, le TObjectList, le TCollection e compagnia cantante.
Se devi dichiarare un record e un puntatore al tipo, per poi usare le
istanze dinamiche, tanto vale istanziare una classe. Non vedo grandi
vantaggi nell'usare i record, che purtroppo non sono equilvalenti alle
struct del C++ (ovvero classi con scope implicito inverso rispetto alle
classi vere).
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 mi sto lasciando aperta la porta nel caso si dovesse passare a dontnet.
Vi sono valide ragioni per le quali si potrebbe decidere di passare
a .Net?
E, sopratutto, chi decide, tu, il cliente o un tuo capo?
A.

Alberto Salvati ha scritto:

diciamo che e' una decisione a meta' strada... la speranza (perche' di 
pura speranza si tratta, almeno per il momento) e quella di poter avere 
un applicativo che gira sia su Win32 che su Linux + Mono.....
G.

 
Comprendo il tuo punto di vista. ho fatto una prova e con l'ausilio 
della TObjectList amio parare si semplifica anche il codice.
Caerto se si vuole avere comunque un record quando si lavora bisogna 
passare (come ho fatto io) per una classe adapter
TMyRecordObj = class
  private
  FData: TMyRecord;
  public
  constructor Create(ARec: TMyRecord);
end;
implementation
constructor TMyRecordObj.Create(ARec: TMyRecord);
begin
  FData := ARec;
end;
In questo contesto mi mancano *** MOLTISSIMO *** i template/generics 
(quando unsavo il C++ non ne avevo compreso appieno la potenza)
sarebbe molto bello poter scrivere una sola volta (la sintassi la invento)
interface
type
TRecordBoxing<type T> = class
   private
   FData: T;
   public
   constructor Create(ARec: T);
end
implementation
constructor TRecordBoxing<T>.Create(ARec: T)
begin
   FData: ARec;
end;
e poter usar il tutto in questo modo
MyRecordObj := TRecordBoxing<TMyRecord>.Create(MyRec);
speriamo in Highlander e successivi ;-)
Giuseppe

 end
Questo a mio parere è un uso errato dei template. A che pro, in questo
contesto, inventare un nuovo tipo? A te serve solo contenere degli
oggetti, quindi usa un container.


 un applicativo che gira sia su Win32 che su Linux + Mono.....
personalmente, il semplice fatto che ci sia in ballo la questione mi
spingerebbe a partire direttamente su .Net.
A.

 un applicativo che gira sia su Win32 che su Linux + Mono.....
Secondo me si tratta di una decisione un po' rischiosa: la libreria 
VCL.NET
 è comunque dipendente - per il momento - dalle funzioni API di 
Windows ed è quindi utilizzabile solo su questa piattaforma, come recita 
il warning che appare quando effetti il "build" di un'applicazione.
Potrebbe nascere in futuro un interesse di CodeGear verso Mono (ci sono 
accenni di studio a lungo termine sul "multipiattaforma" nella roadmap, 
se non ricordo male), ma non ne hai la garanzia. Se ciò non avvenisse, 
la tua applicazione non potrebbe approdare sulla piattaforma che intendi 
indirizzare; ti mancano, in sostanza, le garanzie (anche se future) che 
si vada a supportare Linux tramite Mono.
Tuttavia, è anche vero che un sorgente "amico" di entrambe le 
architetture può essere facilmente portabile in una qualsiasi delle 
piattaforme che CodeGear intendesse supportare, ammesso che la VCL per 
tali piattaforme sia poi "source compatibile" con quelle esistenti, come 
lo è tendenzialmente la libreria 
VCL.NET
 rispetto alla controparte Win32.
Io mantengo abitualmente un package di componenti aziendali, sviluppati 
proprio per poter funzionare sia su Win32 che su .NET, senza fare uso di 
troppi blocchi di {$IFDEF...} inframezzati qua e là nel codice; ho letto 
di questo approccio in un "white paper" relativo ai componenti Indy che, 
però, non ricordo più dove sia pubblicato.
Se individuo nuovamente la pagina, te la segnalo. :-)
Ciao,
   Marco.
-- 
MARCO BREVEGLIERI
  (
http://www.marco.breveglieri.name
)

>un applicativo che gira sia su Win32 che su Linux + Mono.....
Se lo scrivi in Delphi, la vedo molto dura. È possibile scrivere in 
Delphi del codice che sia compilabile sia sotto Delphi Win32 che 
Delphi .NET, ma renderla compatibile con Mono è un'altro paio di 
maniche, perché Mono reimplementa la parte MS di .NET, non quella di 
Delphi.
E non è detto che gli assembly di Delphi funzionino su Mono, ad esempio 
quelli come 
VCL.NET
 che chiamano alla fine API di Windows.
Poiché CodeGear ha deciso di abbandonare WinForms a partire dalla 
prossima versione, la possibilità di usare Mono è ancora minore, a meno 
che CodeGear non supporti esplicitamente Mono mettendo a disposizione 
gli assembly necessari.
Tra l'altro il modo migliore di usare Mono senza brutte sorprese è 
scrivere codice per Mono anche su Windows.
--- posted by geoForum on 
http://www.delphiedintorni.it

Continuiamo a parlare di vcl etc, ma una app non e' fatta solo di
gui...
ado vs 
ado.net
, com/dcom vs remoting...
imho, nel tuo caso stare su win32 equivale a infognarsi.
A.

 
Ok. Potresti aver ragione, tuttavia non ho ancora trovato un modo per 
avere un oggetto delphi che che si passa per valore.
I record sono comodi perche sono allocati sullo stack. Se lavori solo 
con gli elementi della lista a facile ma se per qualche motivo devi 
lasciare in giro degli oggetti temporanei (qui mi riferisco solo a win 
32, in .net non ci sono questi problemi) dove li deallochi.
da qualche parte ho visto un sistema di refernce counting con create 
metti a 1 un contatore poi ogni volta che passi l'oggetto da  un'altra 
parte fai 'AddRef' e quando hai finito di usarlo al posto di Free fai 
'Release'. Quando il contatore arriva a zero l'oggetto si cancella davvero
Ultima consierazione: i record hanno l'operator overloading che e' 
sconsigliato nelle classi.
A questo punto viene da chiedersi perche' tutte queste differenze tra 
record e oggetti, in C++ una struttura e' esattamente come una classe, 
solamente non si possono dichiarare membri privati.....
G.

 solamente non si possono dichiarare membri privati.....
Non mi ricordo che cosa dica esattamente lo standard ISO a riguardo, ma
almeno col gcc, il seguente codice è legale:
#include <iostream>
struct pippo {
public:
      void public_ciao() { private_ciao(); }  
private:
      void private_ciao() { std::cout << "ciao!" << std::endl; }
};
int main()
{
    pippo P;
    P.public_ciao();


 Chi ti ha detto che è sconsigliato per le classi?
In Delphi.NET dovrebbe essere supportato per i record, se non sbaglio.


 In Delphi.NET dovrebbe essere supportato per i record, se non sbaglio.
Ah ecco, non conosco Delphi.NET. 
Mi rimane il dubbio del perché debba essere sconsigliato :-)


 Mi rimane il dubbio del perché debba essere sconsigliato :-)
Nell'ambito di Delphi Win32, credo che l'overload degli operatori per le 
classi non sia stato reso disponibile in quanto le operazioni che 
includono gli operatori dovrebbero dare luogo ad una nuova istanza della 
classe a tutti gli effetti, ma rimarrebbe il problema di distruggere 
tale classe (poiché non esiste un GC).
Non che sia un problema in senso assoluto, in quanto sarebbe sufficiente 
scrivere un codice simile a questo, suppongo:
   A := B + C;
   try
     A.DoSomething();
   finally
     A.Free;
   end;
per quanto, in effetti, la scrittura normalmente applicata a variabili 
di tipo "valore", quindi allocate sullo stack, potrebbe trarre in 
inganno o costringere a pensare o a determinare i casi in cui il 
risultato dell'operazione va distrutto (cioè quando si lavora con 
l'istanza di una classe), oppure no (quando si tratta di un record).


 inganno [...]
No, aspetta, l'operator overloading ha un senso se si lavora con istanze
statiche, altrimenti può diventare di una pericolosità troppo elevata.
Io non avevo inteso che si stava parlando dell'eventuale operator
overloading di Delphi e quindi mi riferivo a questa funzionalità in altri
linguaggi (e nei quali è tutt'altro che sconsigliata).


 
Ho citato l'operator overloading perche' l' visto sulla "grade guida" di 
Cantu. Pare che sia implementato ind delphi per .Net da Delphi 2005 e 
sia stato poi portato su Delphi per Win32 a partire da Delphi 2006.
per la cronaca cito anche le variabili di classe (cha da quanto ho 
capito prima non esistevano)
in delphi 2006 posso scrivere
TMyClass = class
   protected
   class var
   { variabili di classe }
     FIstanza: TMyClass;
     ....
   var
   { variabili di instanza }
   ...
End;
In questo modo anche il pattern Singleton risulta piu' facile da 
implementare ed il codice IMHO risulta piu' leggibile.
Da quanto ho visto il compilatore di delphi per Win32 in Delphi 2006 ha 
subito notevoli modifiche. La maggior parte di tali modifiche sono il 
"porting" (se cosi si puo' dire) di features del linguaggio Delphi. Net 
a delphi Win 32
Congiglio la lettura della "Grande Guida" di Cantu (Edizione 2006), io 
mi sono trovato abbastanza bene.
G.

 capito prima non esistevano)
Non esistevano infatti. In altri linguaggi vengono implementate mediante
keyword "static".
