Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Zoury
Salut! :O)
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array. // ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut } //***
Salut! :O)
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex :
//***
using System.Collection;
//blabla
private void test()
{
// je te présente la classe ArrayList() qui
// implémente la classe Array. Tous
// les tableaux en .NET sont des Array.
//
ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1);
al.Add(2);
al.Add(3);
al.Add(4);
// on peut tronquer ce qu'il y a de trop
al.TrimToSize();
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array. // ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut } //***
Zoury
oups c'est parti trop vite.. ;O)
j'ai compléter l'exemple
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array.
// on peut créer un "buffer" (50 ici) ou encore // laisser le tableau s'aggrandir automatiquement ArrayList al = New ArrayList(50)
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on continue...
// si on fonctionne avec un buffer, on peut // l'aggrandir au besoin comme ceci if (al.Count = al.Capacity) al.Capacity *= 2; // on double le buffer
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut même convertir le arraylist tableau standard Int32[] nums = (Int32[])al.ToArray(typeof(Int32));
} //***
Il existe d'autre classe qui pourrait être plus efficace dépendamment de tes besoins, comme la HashTable par exemple.
-- Cordialement Yanick MVP pour Visual Basic
oups c'est parti trop vite.. ;O)
j'ai compléter l'exemple
ex :
//***
using System.Collection;
//blabla
private void test()
{
// je te présente la classe ArrayList() qui
// implémente la classe Array. Tous
// les tableaux en .NET sont des Array.
// on peut créer un "buffer" (50 ici) ou encore
// laisser le tableau s'aggrandir automatiquement
ArrayList al = New ArrayList(50)
al.Add(1);
al.Add(2);
al.Add(3);
al.Add(4);
// on continue...
// si on fonctionne avec un buffer, on peut
// l'aggrandir au besoin comme ceci
if (al.Count = al.Capacity)
al.Capacity *= 2; // on double le buffer
// on peut tronquer ce qu'il y a de trop
al.TrimToSize();
//on peut même convertir le arraylist tableau standard
Int32[] nums = (Int32[])al.ToArray(typeof(Int32));
}
//***
Il existe d'autre classe qui pourrait être plus efficace dépendamment de tes
besoins, comme la HashTable par exemple.
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array.
// on peut créer un "buffer" (50 ici) ou encore // laisser le tableau s'aggrandir automatiquement ArrayList al = New ArrayList(50)
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on continue...
// si on fonctionne avec un buffer, on peut // l'aggrandir au besoin comme ceci if (al.Count = al.Capacity) al.Capacity *= 2; // on double le buffer
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut même convertir le arraylist tableau standard Int32[] nums = (Int32[])al.ToArray(typeof(Int32));
} //***
Il existe d'autre classe qui pourrait être plus efficace dépendamment de tes besoins, comme la HashTable par exemple.
-- Cordialement Yanick MVP pour Visual Basic
grome
Zoury a raison les arraylist c'est très très pratique. En plus je trouve qu'il sont pas très gourmand en ressources. Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on utilise des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé un peu en VB pour me faire la main aux technos Dot net, mais je suis passé très vite en C#, je dois dire que je n'ai pas été perturbé. Ont dit que le C# est un langage fortement typé, il faut prendre des habitudes de casting que l'on a pas forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans certains cas tout et n'importe quoi.
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news: %
Salut! :O)
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array. // ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut } //***
Zoury a raison les arraylist c'est très très pratique.
En plus je trouve qu'il sont pas très gourmand en ressources.
Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on
utilise
des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé un peu
en VB pour me faire
la main aux technos Dot net, mais je suis passé très vite en C#, je dois
dire que je n'ai pas été perturbé.
Ont dit que le C# est un langage fortement typé, il faut prendre des
habitudes de casting que l'on a pas
forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans
certains cas tout et n'importe quoi.
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news: %23BtDVV28EHA.2676@TK2MSFTNGP12.phx.gbl...
Salut! :O)
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex :
//***
using System.Collection;
//blabla
private void test()
{
// je te présente la classe ArrayList() qui
// implémente la classe Array. Tous
// les tableaux en .NET sont des Array.
//
ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1);
al.Add(2);
al.Add(3);
al.Add(4);
// on peut tronquer ce qu'il y a de trop
al.TrimToSize();
Zoury a raison les arraylist c'est très très pratique. En plus je trouve qu'il sont pas très gourmand en ressources. Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on utilise des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé un peu en VB pour me faire la main aux technos Dot net, mais je suis passé très vite en C#, je dois dire que je n'ai pas été perturbé. Ont dit que le C# est un langage fortement typé, il faut prendre des habitudes de casting que l'on a pas forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans certains cas tout et n'importe quoi.
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news: %
Salut! :O)
Pouvez-vous m'indiquer l'équivalent de VB Redim preserved en C#.
Tu ne devrais plus en avoir de besoin..
ex : //*** using System.Collection; //blabla private void test() { // je te présente la classe ArrayList() qui // implémente la classe Array. Tous // les tableaux en .NET sont des Array. // ArrayList al = New ArrayList(50) // créer un buffer de 50 "places"
al.Add(1); al.Add(2); al.Add(3); al.Add(4);
// on peut tronquer ce qu'il y a de trop al.TrimToSize();
//on peut } //***
Zoury
Hug! :O)
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que
l'on
utilise des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste d'objets quelconques. Si on ne sais pas d'avance combien d'élément la liste finale contiendra, on utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités du ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en paramètre, et que, sachant d'avance ce que nous allons passer, on batisse le Array à la volée. ex : /*** f(3, new object[] {myint}); /*** Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList n'aidera en rien à l'optimisation ;O)
-- Cordialement Yanick MVP pour Visual Basic
Hug! :O)
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que
l'on
utilise
des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui
lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste d'objets
quelconques.
Si on ne sais pas d'avance combien d'élément la liste finale contiendra, on
utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités du
ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un
type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en
paramètre, et que, sachant d'avance ce que nous allons passer, on batisse le
Array à la volée.
ex :
/***
f(3, new object[] {myint});
/***
Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList
n'aidera en rien à l'optimisation ;O)
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que
l'on
utilise des tableaux traditionnels à la place des arraylist ?
Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste d'objets quelconques. Si on ne sais pas d'avance combien d'élément la liste finale contiendra, on utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités du ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en paramètre, et que, sachant d'avance ce que nous allons passer, on batisse le Array à la volée. ex : /*** f(3, new object[] {myint}); /*** Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList n'aidera en rien à l'optimisation ;O)
-- Cordialement Yanick MVP pour Visual Basic
Esperanza
Merci beaucoup pour vos informations, C# me fait moins peur ...
Esperanza
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:%23vXxd2$
Hug! :O)
> D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on > utilise > des tableaux traditionnels à la place des arraylist ? > > Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste
d'objets
quelconques. Si on ne sais pas d'avance combien d'élément la liste finale contiendra,
on
utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités
du
ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en paramètre, et que, sachant d'avance ce que nous allons passer, on batisse
le
Array à la volée. ex : /*** f(3, new object[] {myint}); /*** Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList n'aidera en rien à l'optimisation ;O)
-- Cordialement Yanick MVP pour Visual Basic
Merci beaucoup pour vos informations,
C# me fait moins peur ...
Esperanza
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de
news:%23vXxd2$8EHA.2700@TK2MSFTNGP14.phx.gbl...
Hug! :O)
> D'ailleurs je me pose une question qu'est ce qui pourrait justifier que
l'on
> utilise
> des tableaux traditionnels à la place des arraylist ?
>
> Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui
lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste
d'objets
quelconques.
Si on ne sais pas d'avance combien d'élément la liste finale contiendra,
on
utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités
du
ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un
type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en
paramètre, et que, sachant d'avance ce que nous allons passer, on batisse
le
Array à la volée.
ex :
/***
f(3, new object[] {myint});
/***
Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList
n'aidera en rien à l'optimisation ;O)
Merci beaucoup pour vos informations, C# me fait moins peur ...
Esperanza
"Zoury" <yanick_lefebvre at hotmail dot com> a écrit dans le message de news:%23vXxd2$
Hug! :O)
> D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on > utilise > des tableaux traditionnels à la place des arraylist ? > > Zoury tu en penses quoi ?
J'imagine qu'un Array est moins gourmand en ressources qu'un ArrayList qui lui offre plus de méthodes.
Supposons maintenant le cas ou une méthode doit retourner une liste
d'objets
quelconques. Si on ne sais pas d'avance combien d'élément la liste finale contiendra,
on
utilisera possiblement un ArrayList pour bâtir cette liste.
Les méthodes appelant cette fonction n'ont pas besoin des fonctionnalités
du
ArrayList mais seulement de son contenu. C'est là un cas où le retour d'un type Array standard (string[] par exemple) serait préférable.
Il arrive aussi souvent qu'un Array de quelque chose soit demande en paramètre, et que, sachant d'avance ce que nous allons passer, on batisse
le
Array à la volée. ex : /*** f(3, new object[] {myint}); /*** Dans un cas comme celui ci, inutile de dire que de passer par un ArrayList n'aidera en rien à l'optimisation ;O)
-- Cordialement Yanick MVP pour Visual Basic
Zazar
Bonsoir,
Zoury a raison les arraylist c'est très très pratique. En plus je trouve qu'il sont pas très gourmand en ressources. Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on utilise des tableaux traditionnels à la place des arraylist ?
Le typage, le non boxing des types valeurs, les dimensions multiples, l'économie de mémoire par exemple. A noter que les génériques améliorent les deux premiers points pour l'ArrayList.
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé un peu en VB pour me faire la main aux technos Dot net, mais je suis passé très vite en C#, je dois dire que je n'ai pas été perturbé. Ont dit que le C# est un langage fortement typé, il faut prendre des habitudes de casting que l'on a pas forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans certains cas tout et n'importe quoi.
Justement, vu que le C# est un langage fortement typé, il faut prendre l'habitude de ne pas avoir à caster quand c'est possible:). A chaque fois que vous écrivez un cast dans votre code, dites vous bien que vous introduisez une possibilité d'erreur qui ne pourra être repérée qu'à l'exécution. L'utilisation d'un langage fortement typé tel que le C# permet d'écrire un code avec un maximum de vérifications à la compilation.
-- Zazar
Bonsoir,
Zoury a raison les arraylist c'est très très pratique.
En plus je trouve qu'il sont pas très gourmand en ressources.
Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier
que l'on utilise
des tableaux traditionnels à la place des arraylist ?
Le typage, le non boxing des types valeurs, les dimensions multiples,
l'économie de mémoire par exemple. A noter que les génériques améliorent les
deux premiers points pour l'ArrayList.
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé
un peu en VB pour me faire
la main aux technos Dot net, mais je suis passé très vite en C#, je
dois dire que je n'ai pas été perturbé.
Ont dit que le C# est un langage fortement typé, il faut prendre des
habitudes de casting que l'on a pas
forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans
certains cas tout et n'importe quoi.
Justement, vu que le C# est un langage fortement typé, il faut prendre
l'habitude de ne pas avoir à caster quand c'est possible:). A chaque fois
que vous écrivez un cast dans votre code, dites vous bien que vous
introduisez une possibilité d'erreur qui ne pourra être repérée qu'à
l'exécution. L'utilisation d'un langage fortement typé tel que le C# permet
d'écrire un code avec un maximum de vérifications à la compilation.
Zoury a raison les arraylist c'est très très pratique. En plus je trouve qu'il sont pas très gourmand en ressources. Pour manipuler des objets c'est pas mal aussi.
D'ailleurs je me pose une question qu'est ce qui pourrait justifier que l'on utilise des tableaux traditionnels à la place des arraylist ?
Le typage, le non boxing des types valeurs, les dimensions multiples, l'économie de mémoire par exemple. A noter que les génériques améliorent les deux premiers points pour l'ArrayList.
Sinon entre VB et C# je ne saurais dire. Je viens de VB6, j'ai codé un peu en VB pour me faire la main aux technos Dot net, mais je suis passé très vite en C#, je dois dire que je n'ai pas été perturbé. Ont dit que le C# est un langage fortement typé, il faut prendre des habitudes de casting que l'on a pas forcement qu'on a l'habitude de VB, étant donné que VB 6 permet, dans certains cas tout et n'importe quoi.
Justement, vu que le C# est un langage fortement typé, il faut prendre l'habitude de ne pas avoir à caster quand c'est possible:). A chaque fois que vous écrivez un cast dans votre code, dites vous bien que vous introduisez une possibilité d'erreur qui ne pourra être repérée qu'à l'exécution. L'utilisation d'un langage fortement typé tel que le C# permet d'écrire un code avec un maximum de vérifications à la compilation.
-- Zazar
grome
> Justement, vu que le C# est un langage fortement typé, il faut prendre l'habitude de ne pas avoir à caster quand c'est possible:).
Voilà c'est çà ;-)
A chaque fois que vous écrivez un cast dans votre code, dites vous bien que vous introduisez une possibilité d'erreur qui ne pourra être repérée qu'à l'exécution. L'utilisation d'un langage fortement typé tel que le C# permet d'écrire un code avec un maximum de vérifications à la compilation.
Voilà tout est dit. Justement j'ai un problème de casting a l'execution voir le fil "problème de casting" juste au dessus de celui là. Une idée ?
-- Zazar
> Justement, vu que le C# est un langage fortement typé, il faut prendre
l'habitude de ne pas avoir à caster quand c'est possible:).
Voilà c'est çà ;-)
A chaque fois
que vous écrivez un cast dans votre code, dites vous bien que vous
introduisez une possibilité d'erreur qui ne pourra être repérée qu'à
l'exécution. L'utilisation d'un langage fortement typé tel que le C#
permet
d'écrire un code avec un maximum de vérifications à la compilation.
Voilà tout est dit.
Justement j'ai un problème de casting a l'execution voir le fil "problème de
casting" juste au dessus de celui là.
Une idée ?
> Justement, vu que le C# est un langage fortement typé, il faut prendre l'habitude de ne pas avoir à caster quand c'est possible:).
Voilà c'est çà ;-)
A chaque fois que vous écrivez un cast dans votre code, dites vous bien que vous introduisez une possibilité d'erreur qui ne pourra être repérée qu'à l'exécution. L'utilisation d'un langage fortement typé tel que le C# permet d'écrire un code avec un maximum de vérifications à la compilation.
Voilà tout est dit. Justement j'ai un problème de casting a l'execution voir le fil "problème de casting" juste au dessus de celui là. Une idée ?
-- Zazar
Zazar
Bonsoir,
Justement j'ai un problème de casting a l'execution voir le fil "problème de casting" juste au dessus de celui là. Une idée ?
La réponse de Zoury concernant la valeur nulle me paraît bien. Pourquoi n'y répondez vous pas ?
-- Zazar
Bonsoir,
Justement j'ai un problème de casting a l'execution voir le fil
"problème de casting" juste au dessus de celui là.
Une idée ?
La réponse de Zoury concernant la valeur nulle me paraît bien. Pourquoi n'y
répondez vous pas ?
