[C# 2.0] inserire stringhe in posizione {0}

[RaouL_BennetH]

Originariamente inviato da sneeze

Scusa riguardando l'originale ho visto che i due int sono dichiarati fuori dal metodo. magnifico..... questa sì che è rpogrammazione.... a quando le variabili static e i global per aggiornare una label??? eheheheheheh

Ciao

Innanzitutto, grazie anche a te per il contributo, per aver condiviso parte della tua esperienza e per l'aver dedicato parte del tuo tempo nel suggerirmi una buona soluzione al problema.

Gli inesperti (in questo caso io) chiedono aiuto/consiglio proprio ai più esperti. L'uso di un forum tecnico non credo che servirebbe a molto se fossimo già tutti la in cima e se nessuno avesse bisogno di aiuto.

Ci sono molti esperti qui che, fortunatamente per me (e per tutti quelli inesperti come me), hanno contribuito e contribuiscono con la loro conoscenza, la loro esperienza e non ultima la loro pazienza, a condividere il loro sapere senza guardarci dall'alto in basso.ò

Aggiungo, e chiudo, che dalla parte del "basso" ci si passa tutti, ma non tutti hanno la capacità di ricordarselo

RaouL.

[sneeze]

Originariamente inviato da RaouL_BennetH

Ciao

Innanzitutto, grazie anche a te per il contributo, per aver condiviso parte della tua esperienza e per l'aver dedicato parte del tuo tempo nel suggerirmi una buona soluzione al problema.

Gli inesperti (in questo caso io) chiedono aiuto/consiglio proprio ai più esperti. L'uso di un forum tecnico non credo che servirebbe a molto se fossimo già tutti la in cima e se nessuno avesse bisogno di aiuto.

Ci sono molti esperti qui che, fortunatamente per me (e per tutti quelli inesperti come me), hanno contribuito e contribuiscono con la loro conoscenza, la loro esperienza e non ultima la loro pazienza, a condividere il loro sapere senza guardarci dall'alto in basso.ò

Aggiungo, e chiudo, che dalla parte del "basso" ci si passa tutti, ma non tutti hanno la capacità di ricordarselo

RaouL.

Ma certo, ci mancherebbe. Abbiamo tutti da imparare, io per primo. Quando posso cerco di dare una mano a te che magari non sai una cosa, domani tu darai una mano a me che non ne so un altra. Questo mi sembra il modo giusto di sfruttare un forum.
Per quanto riguarda l'inciso che hai quotato non voleva assolutamente apparire un insegnamento (dio mi salvi da chi ha la pretesa di insegnare) voleva essere uno spunto ironico su cui riflettere dell'opportunità di utilizzare variabili "globali" quando magari non servono.
Detto questo, ripeto, ho anche io ancora da imparare molto nonostante tutti gli anni di programmazione che ho alle spalle, nonostante le certificazioni che ho conseguito e nonostante tutti i corsi e libri che ho letto quindi figurati se ho intenzione di venire quì a insegnare.

[gugoXX]

Originariamente inviato da sneeze

Ripeto che dichiarare variabili inutili è indice di scarsa programmazione, scarsa ottimizzazione del codice e scarsa leggibilità futura.

Dissento.
Variabili di questo tipo , ovvero gli shortcut di valori gia' esistenti, sono inseiriti spesso proprio per la loro leggibilita'.
L'ottimizzazione non viene inficiata, dato che se una di quelle variabili viene usata anche solo 2 volte, allora e' meglio l'esistenza dello shortcut stesso piuttosto che la sua assenza.
Quando invece dovesse venire usata 1 volta sola, come in questo caso, il compilatore la bypassa direttamente e non viene effettivamente allocata alcuna variabile a runtime.
Quindi tutto tranne che scarsa programmazione.

è vero che finiscono in garbage collection, ma è anche vero che la garbage del .net le pulisce ad ogni ciclo di garbage e non subito, quindi è un dispendio enorme di risorse per aggiornare una label. follia.
Non vedere che quelle 3 variabili in realtà ne generano a runtime quintali è un altro classico esempio di inesperienza.

Dissento anche qui.
Le variabili locali del tipo qui trattato, ovvero gli shortcut, risiedono nello stack, e non nell'heap.
E per questo non partecipano al garbage collector, e il loro eventuale spazio usato viene rilasciato immediatamente durante il codice di ritorno del metodo.

[sneeze]

parlavo dei 2 int e dello stringbuilder. Francamente non credo che risiedano nello stack, Anzi sono abbastanza certo che finiscano nell'heap.
Forse l'unica che rimane in stack sarebbe proprio la famosa hti, se fosse vero quello che dici allora chiamare 3 volte il metodo hittest oppure dichiarare una variabile che il compilatore userebbe solo come shortcut non farebbe alcuna differenza, francamente anche su questo sono molto dubbioso.
Ad ogni modo prendo per buone le tue affermazioni perchè purtroppo non ho tempo adesso di approfondire.
Magari se avrò tempo darò una controllata.

[sneeze]

Anzi. lo stringBuilder finisce senza dubbio nell'heap. è un oggetto complesso non un valuetype e per sua natura non può risiedere nello stack. per quando riguarda i due int se fossero stati definiti all'interno del metodo probabilmente sarebbero rimasti e morti con lo stack ma sono stati dichiarati fuori e valorizzati nel metodo, quindi anch'essi necessitano di fare riferimento all'heap.
l'hitTestInfo anch'esso finisce dritto nell'heap non essendo neanche lui un value type. Sostanzialmente sono finite tutte nell'heap e partecipano alla grande alla garbage collection.

[gugoXX]

Originariamente inviato da sneeze

parlavo dei 2 int e dello stringbuilder. Francamente non credo che risiedano nello stack, Anzi sono abbastanza certo che finiscano nell'heap.

Quei 2 int finirebbero nello stack. Sicuro.
Basta dichiararli dentro e non fuori.

Forse l'unica che rimane in stack sarebbe proprio la famosa hti, se fosse vero quello che dici allora chiamare 3 volte il metodo hittest oppure dichiarare una variabile che il compilatore userebbe solo come shortcut non farebbe alcuna differenza, francamente anche su questo sono molto dubbioso.

Assolutamente no. Ho detto l'opposto.
Quando un metodo dovesse venire usato 2 o piu' volte, allora conviene prenderne riferimento come shortcut, come nel caso della famosa hti.

[sneeze]

Quindi, come gìà ho scritto, finisco tutte nell'heap così come era il codice....
a questo punto non capisco cosa c'entra il tuo discorso......

hti non è uno shortcut, è un oggetto e come tale non può stare nello stack.

[gugoXX]

Originariamente inviato da sneeze

Quindi, come gìà ho scritto, finisco tutte nell'heap così come era il codice....
a questo punto non capisco cosa c'entra il tuo discorso......

Allora, lo Stringbuilder l'abbiamo gia' ucciso al quarto post.
E sicuramente sarebbe stato nell'Heap, ma non perche' "E' un oggetto complesso", ma perche' finisce nell'Heap tutto e solo cio' che e' allocato mediante new.
Le 3 chiamate a kGrid.HitTest(e.X, e.Y) e' bene evitarle.
Bene farne una sola e tenerne il risultato in una variabile che risiedera' appunto nello stack.
Viceversa "sprecare" due interi per le coordinate, che risiederanno nello stack, e' fattibile e non peggiora le performance ne la leggibilita (anzi, la maggior parte delle volte la migliora).

hti non è uno shortcut, è un oggetto e come tale non può stare nello stack.

tutto in C# e' un oggetto e deriva da object. Questa frase non ha alcun senso.

[sneeze]

io continuo a parlare del codice originale e non di quello dopo n post.

cmq ti sbagli fortemente in .net i type si dividono in due gruppi;
i value types:
bool
byte
char
decimal
double
enum
float
int
long
sbyte
short
struct
uint
ulong
ushort

e i referce type

class
interface
delegate
object
string

i reference type risiedono sempre e solo nella heap, i value type invece possono stare anche solo nello stack e dipende dal loro utilizzo.
Stai facendo confusione con la system.Object che in questo caso non c'entra nulla. Per oggetto complesso si intende reference type, quindi classi, object, ecc ecc non quello che deriva dalla object. Tutto è riconducibile a object ma i value types derivano da System.ValueType. Per "castarli object" è necessaria una operazione di boxing e "guarda caso" appena lo fai il valuetype viene sparato immediatamente nella heap.


Inoltre non finisce nell'heap tutto ciò che è allocato mediante new, assolutamente no, finiscono nell'heap tutti i reference type obbligatoriamente. Non far confusione sul fatto che in genere i reference type sono proprio quelli che inizializzi con un new, non è proprio quello il punto. Mentre i value type tipende da dove sono definiti o se subiscono operazioni di boxing unboxing.....

Per finire continuo a dire che io parlavo del codice che ha aperto il 3d e lì di variabili che rimangono nello stack non ne vede neanche una, quindi il tuo primo intervento dove sostenevi che neanche una di quelle variabili sarebbe stata nell'heap era completamente errato, detto questo possono sbagliare tutti, io sono andato a rivedere prima di risponderti, di primo impatto ti ho dato ragione perchè non ero fresco sull'argomento. Però una volta che si certifica come stanno le cose è bene spiegarle anche per chi ci legge.

[sneeze]

[quote=gugoXX;32589934]ma perche' finisce nell'Heap tutto e solo cio' che e' allocato mediante new.[quote]
Mi sono accorto adesso di un secondo errore, non solo non è vero che finisce nell'hep tutto ciò che si inizializza mediante new (non ci finisce per questo motivo ma per la spiegazione che ti ho dato prima).
Ma non è vero neanche che ci finisce solo quello che è inizializzato mediante new.
Ad esempio:

int a = 5; //a meno di particolari utilizzi questa finisce in stack perchè è un valueType

var b = (object)a; //questa finisce in heap immediatamente(senza alcun new)

Non solo.
Se io dichiaro un valueType ma lo dichiaro dentro un refereceType finisce nell'heap di nuovo, senza nessun new ovviamente....

public class miaClasse
{
public int a = 5; //questo finisce dritto nell'heap
}

invece se io sono in un metodo

public int somma()
{
int a = 5; //rimane nello stack
int b = 6; //rimane nello stack
return a+b;
}

Spero di aver chiarito un pò come funziona, se volete approfondisco, mi pare che ci sia un pò di confusione.

[gugoXX]

Originariamente inviato da sneeze

io continuo a parlare del codice originale e non di quello dopo n post.

cmq ti sbagli fortemente in .net i type si dividono in due gruppi;
i value types:
bool
byte
char
decimal
double
enum
float
int
long
sbyte
short
struct
uint
ulong
ushort

e i referce type

class
interface
delegate
object
string

Guarda che mi e' chiarissimo, come anche a tanti altri che leggono qui.
Il problema e' che tu hai scritto solo
oggetto
E ancora, di nuovo, tutto in C# e' un oggetto.
oggetto = object = System.Object
Alcuni sono reference type, altri sono value type.
Ma sono tutti oggetti, e quando si sta proprio parlando delle loro differenze, scrivere solo "oggetto" non e' sufficiente.
Non ci credi?
Pova un po'

int t = 15;
if (t is object )
    Console.WriteLine("E' un oggetto");

var b = (object)a; //questa finisce in heap immediatamente(senza alcun new)

Se sai cos'e' il boxing, allora saprai anche che qui c'e' un "new" implicito.
Forse ti conviene ripassare la parte sull'allocazione, perche' mi sembra che tu abbia un po' di confusione.
Qualche post fa parlavi addirittura di garbage collection e 2 interi, e ti preoccupavi della loro crezione e distruzione.

[sneeze]

eheheheh, guarda che non ho detto io cose tipo che tutte quelle variabili risiedevano nello stack quando invece neanche una ci andava

oppure che finisce nell'heap tutto e solo ciò che si inizializza tramite new quando proprio non c'entra nulla

mi preoccupavo proprio perchè i due interi sono stati dichiarati all'interno della form, che un referenceType e di conseguenza finiscono dritti nell'heap e partecipano alla garbage. NOn c'è niente di strano

Inoltre non ho mai detto che non tutto in net è un oggetto, lo so bene, ma ci sono delle differenze che non coglievi e te le stavo spiegando.

[sneeze]

oh finalmente ho trovato la paginetta microsoft che spiega esattamente tutto quello che ho detto. ti spiega perchè il new non c'entra una mazza, ti spiega il perchè della divisione tra value type e tra reference type, ti spiega che sono i reference type che risiedono nell'heap.... e non perchè si inizializzano con un new..... e che i valueType finiscono anch'essi nell'heap in determinati casi e quindi partecipano alla garbage....


ooooooooooooooohhhhh, almeno se non credi a me a msdn crederai...

I tipi di dati sono distinti in tipi di valore e tipi di riferimento. I tipi di valore sono allocati sullo stack oppure inline in una struttura. I tipi di riferimento sono allocati sull'heap. Sia i tipi di valore che i tipi di riferimento sono derivati dalla classe base finale Object. Qualora fosse necessario che un tipo di valore presenti un comportamento simile a un oggetto, per fare in modo che il tipo di valore assuma la funzione di oggetto di riferimento viene allocato un wrapper all'heap, nel quale viene copiato il valore del tipo di valore. Il wrapper viene contrassegnato in modo che il tipo di valore in esso contenuto sia riconosciuto dal sistema. Questo processo è definito boxing, mentre il processo inverso è detto unboxing. Tramite questi due processi è possibile gestire qualsiasi tipo come oggetto.

http://msdn.microsoft.com/it-it/libr...pe(VS.80).aspx