Newsgroup: it.comp.lang.delphi
Titolo: Funzione generica ridimensionamento array dinamici di record (per i guru)

Utilizzo spesso, al posto delle liste degli array dinamici di tipo record:
TPippo = record
  cognome: string;
  nome: string;
  ecc..
end;
var Pippopoli: array of TPippo;
L'inconveniente di questi array è che il ridimensionamento teoricamente è
lento, quindi è bene farlo il meno possibile. Se poi non si sa a priori
quale è la dimensione finale dell'array la cosa diventa un po' incasinata.
Di solito, inizalizzo l'array con un numero di elementi x, quando l'ho
riempito tutto, lo incremento a blocchi di x.
Questo mi porta a dover inserire dentro ai cicli che di solito utilizzo per
popolare gli array continui
L := Length(Pippopoli);
if  L < i then
begin
  L := L + x;
  SetLength(Pippopoli, L);
end;
Vorrei buttare il tutto dentro ad una funzione, che però sia indipendente
dal tipo di record, oggi ho a che fare con TPippo, domani con TTopolino ecc.
Ma non ci riesco, in quanto non riesco a dichiarare la funzione che accetti
un tipo di dati "array dinamico" senza specificare di che tipo. Se utilizzo
gli untyped parameter, allora si incavola il compilatore sulla SetLength.
Come posso fare? Qualche idea?
Grazie.

 riempito tutto, lo incremento a blocchi di x.
perchè scervellarsi coi blocchi le cui dimensioni cambiano a seconda
del tipo record trattato?
perchè non preferire un Lista.Add( TMiaClasse.Create )?
AS

 perchè non preferire un Lista.Add( TMiaClasse.Create )?
In System ho trovato DynArraySetLength, provo a darci un'occhiata...
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Scelgo quello che al momento mi sembra il male minore
Ovviamente nessuno puo sindacare su questo.
Non volevo attaccare la tua posizione, attenzione.
Volevo solo darti una diversa prospettiva del problema che hai davanti.
Personalmente, dopo aver lavorato in OOP, la semplice idea di tornare a
usare tipi record etc mi dai i brividi... BRRRRR!
AS

 turbo pascal 5, salvo che 6 su windows..
Forse mi sono spiegato male. Il mio dubbio nell'usare gli oggetti è 
che se scrivo il programma io so quando me li creo e me li distruggo e 
me lo organizzo come mi pare. Se devo iniziare un programma, poi perché
non c'è tempo ci mettono le mani altri, e non ho il tempo di
ricontrollare
quello che hanno scritto, sapendo come scrivono il codice, preferisco
non
dargli in mano gli oggetti.
Tutto qui.
Grazie


 cliente, compilato in debug andava, in release no.
In questo il c rompe. E' il prezzo da pagare x una potenza che, IN
ALCUNI CASI, è necessaria, MA NON SEMPRE.
AS

 dichiarare metodi astratti a tua discrezione.
Alberto, programmare con le interfacce ha senso quando queste realmente
servono. Abusarne, invece, può portare a codice caotico e qui sono
d'accordo con te quando asserisci che può essere più comodo (e
rigoroso) usare le classi abstract di Delphi, imho.
Ma il concetto delle interfacce va oltre all'avere dei metodi astratti
da implementare, e costituisce il fondamento della programmazione per
contratto ;)
-- 
guastatore
ICLDweb: 
http://www2.samatel.com/icld/

 ad
[CUT]
Generalmente anche io. Ci sono delle ovvie eccezioni, e dipende da cosa
devi realizzare. Per esempio, VirtualTreeView è fondato pesantemente
sui record per avere genericità nell'accogliere qualsiasi tipo di
oggetto nelle sue liste e per avere maggior velocità rispetto alle
classi.


 contratto ;)
Sorry, sono stato troppo semplicistico nella mia definizione.
Mi sono fermato al caso specifico del post iniziale di questo th.
Personalmente, prima di usare c# e salvo quelle "OBBLIGATORIE" in
delphi (type library e quant'altro..) in delphi le ho usate poco.

 devi realizzare.
quoto.
Se devi usare qualche api di winsozz delle classi non sai che fartene.
Ma se devi gestire liste di elementi xche arrovellarsi?
xche non approfittare del polimorfismo e scrivere codice
riutilizzabile, motivo per il quale si lavora in OOP?
Riguardo le prestazioni, la prospettiva va cambiata.
La OOP, imho, non nasce tanto per la VELOCITA' quanto per la
semplicità, la riutilizzabilita'  e robustezza del codice.
Prendi classi come TLIst e TObjectList...
In quanti contesti DIVERSI le hai utilizzate? 
AS
AS

 Credi a Babbo Natale, tu?
No, soltanto che nel 98 internet c'era solo al lavoro e usabile solo dai
"vecchi" dopo l'accordo con il sistemista, non avendo altri punti di
riferimento, a quei tempi pensavo ingenuamente che uno che avesse
programmato per più di diversi anni la dentro e che doveva farmi da "tutore"
almeno il linguaggio lo conoscesse..., invece ho scoperto solo più tardi il
motto che circolava la dentro "Nulla si crea, nulla si distrugge, tutto si
copia!"
P.S.: Ritornando a parlare di lavoro, sto facendo un programma che fa dei
calcoli di produzione e già adesso che sono agli inizi e manca roba è lento.
Si pensava di avere un programma principale che splittava il lavoro su n
client in modo da avere una elaborazione distribuita. Il metodo più semplice
per condividere i risultati intermedi sembrava quello di buttarli su una
tabella senza impazzire a scriversi protocolli e comunicare direttamente con
i socket, solo che guardando le prestazioni mi ritrovo che il server sql è
già impegnato al 75% mentre il client intorno al 20%. Il mio collo di
bottiglia è l'accesso al database. Se ovvio a questo buttando su tabelle in
memoria (memtable), gli altri client non riescono a vederle.
Qualche idea?
Grazie ancora.

 In quanti contesti DIVERSI le hai utilizzate? 
Questa domanda non la capisco. Cosa significa ? Sono classi
specializzate a far quello per cui non vedo molti campi di
applicazione. Come esempio di polimorfismo, tuttavia, non è dei
migliori. Miglior scelta sarebbe stata TStrings, ad esempio, imho. ;)


 interfacce rappresentano uno dei modi per gestire l'abstract.
E' vero, anche se una classe può essere considerata astratta a
prescindere dal fatto che uno o più dei suoi metodi vengono dichiarati
"abstract". Semplicemente, dichiarare un metodo virtual e lasciarlo
vuoto, ovvero senza codice ma solo un begin..end, può costituire un
buon esempio di classe abstract.
