Lorsque l'on d=E9clare une variable "str" de type string=20
sans l'initialiser elle prend null comme valeur par d=E9faut.
Lorsque l'on d=E9clare un objet "obj" quelconque sans=20
l'instancier il n'a pas de valeur par d=E9faut : <valeur non=20
d=E9finie> (visible dans la fen=EAtre espion de VS)
Si on fait : uneClasse obj =3D null;
et que l'on regarde =E0 nouveau dans l'espion sous VS obj ne=20
contient pas null mais toujours <valeur non d=E9finie>
peut être le boxing ? object étant la base de struct ou de classes...
sebastien981_nospam
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string
sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans
l'instancier il n'a pas de valeur par défaut : <valeur non
définie> (visible dans la fenêtre espion de VS)
Si on fait : uneClasse obj = null;
et que l'on regarde à nouveau dans l'espion sous VS obj ne
contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la
valeur de String.Empty mais pointe vers une adresse alors que uneclass
obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le
compilateur doit remplacer par string str=String.Empty topo la variable
pointe bien vers une adresse en mémoire qui contient null en fait "" ce
qui n'est pas le cas d'un objet
Sebastien
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Zazar
Bonjour,
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Il y a deux aspects différents à votre question :
1) L'aspect C# : Une variable membre d'une classe est toujours initialisée à sa valeur par défaut (null dans le cas de variables de type objet) qu'elle soit de type string ou autre chose. Une variable locale ne peut pas être utilisée (en lecture) tant qu'elle n'a pas été complétement initialisée par du code. En attendant qu'elle soit réellement initialisée, elle a sa valeur par défaut (<- ça c'est l'expérience qui le dit, je ne suis pas sûr que ce soit précisé quelque part et de toute façon ça n'aurait aucun intérêt en dehors de la valeur à afficher lors du débogage).
2) L'aspect VS.NET Par défaut quand on demande d'afficher le contenu d'une variable sur une seule ligne (par exemple en passant la souris dessus), VS.NET affiche le type de l'objet référencé par la variable entre accolades. Pour certains types (je suppose qu'il doit y avoir une liste prédéfinie stockée quelque part) comme int ou string, il n'affiche non pas le type, mais la valeur elle-même. Ce n'est donc pas la même routine d'affichage qui est utilisée dans les deux cas. Dans le premier cas, si l'obj vaut null alors le type de l'objet référencé n'a aucun sens et un "message d'erreur" est affiché, dans le second cas la valeur par défaut est affichée : null dans le cas des string.
-- Zazar
Bonjour,
Lorsque l'on déclare une variable "str" de type string
sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans
l'instancier il n'a pas de valeur par défaut : <valeur non
définie> (visible dans la fenêtre espion de VS)
Si on fait : uneClasse obj = null;
et que l'on regarde à nouveau dans l'espion sous VS obj ne
contient pas null mais toujours <valeur non définie>
Il y a deux aspects différents à votre question :
1) L'aspect C# :
Une variable membre d'une classe est toujours initialisée à sa valeur par
défaut (null dans le cas de variables de type objet) qu'elle soit de type
string ou autre chose.
Une variable locale ne peut pas être utilisée (en lecture) tant qu'elle n'a
pas été complétement initialisée par du code. En attendant qu'elle soit
réellement initialisée, elle a sa valeur par défaut (<- ça c'est
l'expérience qui le dit, je ne suis pas sûr que ce soit précisé quelque part
et de toute façon ça n'aurait aucun intérêt en dehors de la valeur à
afficher lors du débogage).
2) L'aspect VS.NET
Par défaut quand on demande d'afficher le contenu d'une variable sur une
seule ligne (par exemple en passant la souris dessus), VS.NET affiche le
type de l'objet référencé par la variable entre accolades. Pour certains
types (je suppose qu'il doit y avoir une liste prédéfinie stockée quelque
part) comme int ou string, il n'affiche non pas le type, mais la valeur
elle-même. Ce n'est donc pas la même routine d'affichage qui est utilisée
dans les deux cas. Dans le premier cas, si l'obj vaut null alors le type de
l'objet référencé n'a aucun sens et un "message d'erreur" est affiché, dans
le second cas la valeur par défaut est affichée : null dans le cas des
string.
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Il y a deux aspects différents à votre question :
1) L'aspect C# : Une variable membre d'une classe est toujours initialisée à sa valeur par défaut (null dans le cas de variables de type objet) qu'elle soit de type string ou autre chose. Une variable locale ne peut pas être utilisée (en lecture) tant qu'elle n'a pas été complétement initialisée par du code. En attendant qu'elle soit réellement initialisée, elle a sa valeur par défaut (<- ça c'est l'expérience qui le dit, je ne suis pas sûr que ce soit précisé quelque part et de toute façon ça n'aurait aucun intérêt en dehors de la valeur à afficher lors du débogage).
2) L'aspect VS.NET Par défaut quand on demande d'afficher le contenu d'une variable sur une seule ligne (par exemple en passant la souris dessus), VS.NET affiche le type de l'objet référencé par la variable entre accolades. Pour certains types (je suppose qu'il doit y avoir une liste prédéfinie stockée quelque part) comme int ou string, il n'affiche non pas le type, mais la valeur elle-même. Ce n'est donc pas la même routine d'affichage qui est utilisée dans les deux cas. Dans le premier cas, si l'obj vaut null alors le type de l'objet référencé n'a aucun sens et un "message d'erreur" est affiché, dans le second cas la valeur par défaut est affichée : null dans le cas des string.
-- Zazar
Paul Bacelar
wrote in message news:
Thierry a présenté l'énoncé suivant : > Lorsque l'on déclare une variable "str" de type string > sans l'initialiser elle prend null comme valeur par défaut. > > Lorsque l'on déclare un objet "obj" quelconque sans > l'instancier il n'a pas de valeur par défaut : <valeur non > définie> (visible dans la fenêtre espion de VS) > Si on fait : uneClasse obj = null; > et que l'on regarde à nouveau dans l'espion sous VS obj ne > contient pas null mais toujours <valeur non définie> > > Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas pareil :o)
Paul Bacelar
<sebastien981_nospam@hotmail.com> wrote in message
news:mn.cb6e7d48b71adc46.17356@hotmail.com...
Thierry a présenté l'énoncé suivant :
> Lorsque l'on déclare une variable "str" de type string
> sans l'initialiser elle prend null comme valeur par défaut.
>
> Lorsque l'on déclare un objet "obj" quelconque sans
> l'instancier il n'a pas de valeur par défaut : <valeur non
> définie> (visible dans la fenêtre espion de VS)
> Si on fait : uneClasse obj = null;
> et que l'on regarde à nouveau dans l'espion sous VS obj ne
> contient pas null mais toujours <valeur non définie>
>
> Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la
valeur de String.Empty mais pointe vers une adresse alors que uneclass
obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le
compilateur doit remplacer par string str=String.Empty topo la variable
pointe bien vers une adresse en mémoire qui contient null en fait "" ce
qui n'est pas le cas d'un objet
Sebastien
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas
pareil :o)
Thierry a présenté l'énoncé suivant : > Lorsque l'on déclare une variable "str" de type string > sans l'initialiser elle prend null comme valeur par défaut. > > Lorsque l'on déclare un objet "obj" quelconque sans > l'instancier il n'a pas de valeur par défaut : <valeur non > définie> (visible dans la fenêtre espion de VS) > Si on fait : uneClasse obj = null; > et que l'on regarde à nouveau dans l'espion sous VS obj ne > contient pas null mais toujours <valeur non définie> > > Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas pareil :o)
Paul Bacelar
sebastien981_nospam
Merci de l'info exacte j'ai fait un amalgame
Sebastien
Paul Bacelar a exposé le 25/08/2004 :
wrote in message news:
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas pareil :o)
Paul Bacelar
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Merci de l'info exacte j'ai fait un amalgame
Sebastien
Paul Bacelar a exposé le 25/08/2004 :
<sebastien981_nospam@hotmail.com> wrote in message
news:mn.cb6e7d48b71adc46.17356@hotmail.com...
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string
sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans
l'instancier il n'a pas de valeur par défaut : <valeur non
définie> (visible dans la fenêtre espion de VS)
Si on fait : uneClasse obj = null;
et que l'on regarde à nouveau dans l'espion sous VS obj ne
contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la
valeur de String.Empty mais pointe vers une adresse alors que uneclass
obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le
compilateur doit remplacer par string str=String.Empty topo la variable
pointe bien vers une adresse en mémoire qui contient null en fait "" ce
qui n'est pas le cas d'un objet
Sebastien
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas
pareil :o)
Paul Bacelar
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Il y a confusion entre une chaîne vide et une chaîne à null, c'est pas pareil :o)
Paul Bacelar
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Bruno Jouhier [MVP]
a écrit dans le message de news:
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
C'est juste une façon d'afficher la valeur spéciale null. Dans le débugger, <valeur non définie> veut dire <null>
Je pense que c'est une tentative pour essayer de rendre le système objet un peu plus "conceptuel" et de cacher le fait que null est impléménté comme une référence à zéro. Mais c'est à mon avis assez vain car le langage C# utilise le mot clé "null" et il vaudrait donc mieux afficher "null" que <valeur non définie>. C'est peut être aussi pour masquer les différences de langages (VB utilise Nothing au lieu de null).
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
NON, c'est complètement faux! null et String.Empty sont deux choses différentes. null est une référence nulle alors que String.Empty est une référence non nulle qui pointe sur la chaîne vide. Si on exécute str.Length, on obtient une exception dans le premier cas et 0 dans le second cas.
Bruno.
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
<sebastien981_nospam@hotmail.com> a écrit dans le message de news:
mn.cb6e7d48b71adc46.17356@hotmail.com...
Thierry a présenté l'énoncé suivant :
Lorsque l'on déclare une variable "str" de type string sans l'initialiser
elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a
pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre
espion de VS)
Si on fait : uneClasse obj = null;
et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas
null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
C'est juste une façon d'afficher la valeur spéciale null.
Dans le débugger, <valeur non définie> veut dire <null>
Je pense que c'est une tentative pour essayer de rendre le système objet un
peu plus "conceptuel" et de cacher le fait que null est impléménté comme une
référence à zéro. Mais c'est à mon avis assez vain car le langage C# utilise
le mot clé "null" et il vaudrait donc mieux afficher "null" que <valeur non
définie>. C'est peut être aussi pour masquer les différences de langages (VB
utilise Nothing au lieu de null).
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la
valeur de String.Empty mais pointe vers une adresse alors que uneclass
obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le
compilateur doit remplacer par string str=String.Empty topo la variable
pointe bien vers une adresse en mémoire qui contient null en fait "" ce
qui n'est pas le cas d'un objet
NON, c'est complètement faux! null et String.Empty sont deux choses
différentes. null est une référence nulle alors que String.Empty est une
référence non nulle qui pointe sur la chaîne vide. Si on exécute str.Length,
on obtient une exception dans le premier cas et 0 dans le second cas.
Bruno.
Sebastien
--
Ceci est une signature automatique de MesNews.
Site : http://mesnews.no-ip.com
Lorsque l'on déclare une variable "str" de type string sans l'initialiser elle prend null comme valeur par défaut.
Lorsque l'on déclare un objet "obj" quelconque sans l'instancier il n'a pas de valeur par défaut : <valeur non définie> (visible dans la fenêtre espion de VS) Si on fait : uneClasse obj = null; et que l'on regarde à nouveau dans l'espion sous VS obj ne contient pas null mais toujours <valeur non définie>
Quel est l'intérêt de cette distinction ?
C'est juste une façon d'afficher la valeur spéciale null. Dans le débugger, <valeur non définie> veut dire <null>
Je pense que c'est une tentative pour essayer de rendre le système objet un peu plus "conceptuel" et de cacher le fait que null est impléménté comme une référence à zéro. Mais c'est à mon avis assez vain car le langage C# utilise le mot clé "null" et il vaudrait donc mieux afficher "null" que <valeur non définie>. C'est peut être aussi pour masquer les différences de langages (VB utilise Nothing au lieu de null).
Bonjour,
je penses qu'en fait la chaine str de type string contient en fait la valeur de String.Empty mais pointe vers une adresse alors que uneclass obj=null ne pointe pas vers une adresse donc n'a pas de valeur définie
un string est un objet mais quand on écrit string str = null le compilateur doit remplacer par string str=String.Empty topo la variable pointe bien vers une adresse en mémoire qui contient null en fait "" ce qui n'est pas le cas d'un objet
NON, c'est complètement faux! null et String.Empty sont deux choses différentes. null est une référence nulle alors que String.Empty est une référence non nulle qui pointe sur la chaîne vide. Si on exécute str.Length, on obtient une exception dans le premier cas et 0 dans le second cas.
Bruno.
Sebastien
-- Ceci est une signature automatique de MesNews. Site : http://mesnews.no-ip.com
Benoît Celeyron
"Ambassadeur Kosh" a écrit
> Quel est l'intérêt de cette distinction ?
peut être le boxing ? object étant la base de struct ou de classes...
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
Benoît
"Ambassadeur Kosh" a écrit
> Quel est l'intérêt de cette distinction ?
peut être le boxing ? object étant la base de struct ou de classes...
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de
'struct' !
Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je
vérifierai ça quand même un de ces jours).
peut être le boxing ? object étant la base de struct ou de classes...
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
Benoît
Paul Bacelar
C'est tout vérifié ;-) -- Paul Bacelar Demandeur d'emploi
"Benoît Celeyron" wrote in message news:
"Ambassadeur Kosh" a écrit
> > Quel est l'intérêt de cette distinction ? > > peut être le boxing ? object étant la base de struct ou de classes... >
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
Benoît
C'est tout vérifié ;-)
--
Paul Bacelar
Demandeur d'emploi
"Benoît Celeyron" <benoit.celeyron@free.fr> wrote in message
news:ure5DsxlEHA.3816@TK2MSFTNGP14.phx.gbl...
"Ambassadeur Kosh" a écrit
> > Quel est l'intérêt de cette distinction ?
>
> peut être le boxing ? object étant la base de struct ou de classes...
>
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de
'struct' !
Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je
vérifierai ça quand même un de ces jours).
C'est tout vérifié ;-) -- Paul Bacelar Demandeur d'emploi
"Benoît Celeyron" wrote in message news:
"Ambassadeur Kosh" a écrit
> > Quel est l'intérêt de cette distinction ? > > peut être le boxing ? object étant la base de struct ou de classes... >
Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
Benoît
Ambassadeur Kosh
> Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
faudrait verifier alors :o)
> Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de
'struct' !
Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je
vérifierai ça quand même un de ces jours).
> Ah bon ? Je croyais me souvenir qu'Object était la base de tout SAUF de 'struct' ! Pas bien grave, peut-être ma mémoire est un peu vacillante ... (je vérifierai ça quand même un de ces jours).
faudrait verifier alors :o)
Benoît Celeyron
Paul Bacelar"
C'est tout vérifié ;-) --
"Ambassadeur Kosh"
faudrait verifier alors :o)
Bande de nazes, soyez charitables et arrêtez de vous gondoler!
Bon, je fais acte de contrition (ma confusion venait du fait que struct est un type valeur). Je suis stupide puisque j'utilise couramment des méthodes Object sur des structs ...
Grrrrrr !! :-((
Paul Bacelar"
C'est tout vérifié ;-)
--
"Ambassadeur Kosh"
faudrait verifier alors :o)
Bande de nazes,
soyez charitables et arrêtez de vous gondoler!
Bon, je fais acte de contrition (ma confusion venait du fait que struct est
un type valeur).
Je suis stupide puisque j'utilise couramment des méthodes Object sur des
structs ...
Bande de nazes, soyez charitables et arrêtez de vous gondoler!
Bon, je fais acte de contrition (ma confusion venait du fait que struct est un type valeur). Je suis stupide puisque j'utilise couramment des méthodes Object sur des structs ...
