Classe non statica, ma poi la dichiaro.. cosa non capisco ?

di il
5 risposte

Classe non statica, ma poi la dichiaro.. cosa non capisco ?

Ho una classe normale:
public class C_NormaleClasse {
public string va1;
private string var2;
.....}
In App.xaml scrivo:
internal static C_NormaleClasse miaNormaleClasse; (nota 1)
miaNormaleClasse= new C_NormaleClasse  (); (nota2)
DOMANDA:
Considerando che:
- la Classe non è stata dichiarata Static.
- in (nota 1) dichiaro un oggetto (miaNormaleClasse) statico: (static C_NormaleClasse ), poi istanzio la Classe creando l'oggetto miaNormaleClasse (nota 2)
- e considerando che una classe statica non può essere istanziata, dichiarando in nota1 miaNormaleClasse statico, perché mi permette di creare un oggetto (nota 2) ?

Cosa mi sfugge ? Cosa non capisco ?

Grazie.

5 Risposte

  • Re: Classe non statica, ma poi la dichiaro.. cosa non capisco ?

    Non uso xaml, ma hai dichiarato static la variabile, non la classe. Stai dicendo al tuo puntatore statico di puntare a una nuova istanza di una classe dinamica
  • Re: Classe non statica, ma poi la dichiaro.. cosa non capisco ?

    Ciao Weierstrass,
    ok, sto procedendo nella direzione giusta.

    Per cui sto facendo la seguente:
    sto dichiarando una variabile statica, la quale (essendo una variabile statica) la posso vedere all'interno dell'assembly.
    Se non fosse static la vedrei solo nel corpo ove dichiarate .
    Giusto, no ?

    Info: App.xaml è l'equivalente di main(), cioè il punto di ingresso, ma per UWP.

    Comunque in questo modo ho ottenuto una istanza che vedo all'interno dell'assembly, e cosa importante per me viene istanziata UNA sola volta senza creare il cosidetto memory leak.

    Una ultima domanda: esiste un modo in Visual Studio per sapere quanti oggetti ho creato, o meglio, quante istanze di una determinata classe esistono ?
    Ok, ci pensa il Garbage Collection e posso anche invocarlo con System.GC.Collect (da utilizzare questo ultimo con un motivo ben valido..) ma sono puntiglioso.

    Grazie.
  • Re: Classe non statica, ma poi la dichiaro.. cosa non capisco ?

    Ti crei dentro la classe una variabile intera statica (= unica per tutte le istanze), inizializzata a zero, incrementata nel costruttore e decrementata nel distruttore.

    Da usare solo in debug però, altrimenti rallenti l'esecuzione in cambio di niente
  • Re: Classe non statica, ma poi la dichiaro.. cosa non capisco ?

    Alla vecchia maniera.. OK.

    Credevo che gli sviluppatori di Visual Studio avessero creato qualcosa del genere.. ma evidentemente no

    Grazie e a tutti.
  • Re: Classe non statica, ma poi la dichiaro.. cosa non capisco ?

    jockerfox ha scritto:


    Per cui sto facendo la seguente:
    sto dichiarando una variabile statica, la quale (essendo una variabile statica) la posso vedere all'interno dell'assembly.
    Se non fosse static la vedrei solo nel corpo ove dichiarate .
    Giusto, no ?
    A prescindere dal fatto che bisognerebbe capire cosa intendi per "la posso vedere all'interno dell'assembly", la visibilità di una variabile in un determinato scope dipende dal tipo di variabile (es. variabile locale, campo, proprietà, ecc.) e dalla visibilità assegnata alla stessa.

    La parola chiave static indica il suo modello di allocazione (per oggetto o per classe), non la visibilità.

    jockerfox ha scritto:


    Comunque in questo modo ho ottenuto una istanza che vedo all'interno dell'assembly, e cosa importante per me viene istanziata UNA sola volta senza creare il cosidetto memory leak.
    Il "memory leak" è un'altra cosa, e si riferisce alla mancata distruzione/liberazione di memoria quando essa non viene più utilizzata.
    Nell'ambito .NET, è il GC che tendenzialmente cerca di sopperire a questo problema, rilasciando in automatico la memoria quando non è più in uso e distruggendo gli oggetti quando non sono più referenziati.

    jockerfox ha scritto:


    Una ultima domanda: esiste un modo in Visual Studio per sapere quanti oggetti ho creato, o meglio, quante istanze di una determinata classe esistono ?
    Esistono dei tool appositi di monitoring, come i "profiler", che durante l'esecuzione del programma tengono traccia degli oggetti creati e della memoria allocata, allo scopo di evidenziare possibili problematiche.

    jockerfox ha scritto:


    Ok, ci pensa il Garbage Collection e posso anche invocarlo con System.GC.Collect (da utilizzare questo ultimo con un motivo ben valido..) ma sono puntiglioso.
    Se l'obiettivo è tenere traccia banalmente del numero di oggetti creati per una certa classe, basta appunto un campo statico.
    Non esiste un automatismo in questo senso perché nella maggior parte dei casi non serve (penso di averne avuto bisogno solo un paio di volte in 20 anni e a scopo dimostrativo).

    Ciao!
Devi accedere o registrarti per scrivere nel forum
5 risposte