Discussion :

[sneakysponge]

hello,

j'aimerais savoir quelle est la manière la plus performante pour caster un objet d'un type vers un autre sachant que le cast n'échouera jamais.

voici typiquement ce que je fais sur list qui est une instance de List<T>

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
lock (((ICollection)list).SyncRoot)
{
...
}

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
lock ((list as ICollection).SyncRoot)
{
...
}

j'aurais eu tendance à dire que l'opérateur de conversion explicite (le C-style cast) était plus rapide que le dynamic_cast, malheureusement, un message sur un forum datant de 2003 disait le contraire ; cependant, ce message concernait .net 1...

Qu'en est-il pour .net >= 2 ?

merci d'avance

[Philippe Vialatte]

personnellement, j'aurais tendance a dire qu'on s'en moque...

ca ressemble a de la micro-optimisation, a vue de nez, a moins d'appeler 1 000 000 de fois le lock, tu ne gagneras rien a faire l'un ou l'autre...

enfin, c'est mon avis a moi, et je le partage avec moi-meme...

[toxycyty]

Salut,

il y a apperement quelques differences detaillees dans cet article: (en anglais)

http://gen5.info/q/2008/06/13/prefix...-casting-in-c/

A+

[sneakysponge]

personnellement, j'aurais tendance a dire qu'on s'en moque...

Je préfère connaitre les mécanismes du langage correctement.

ca ressemble a de la micro-optimisation, a vue de nez, a moins d'appeler 1 000 000 de fois le lock, tu ne gagneras rien a faire l'un ou l'autre...

Oui et non, c'est une zone du code qui pourrait potentiellement être invoquée 1 000 000 de fois.

[sneakysponge]

Salut,

il y a apperement quelques differences detaillees dans cet article: (en anglais)

http://gen5.info/q/2008/06/13/prefix...-casting-in-c/

A+

je suis bon pour changer tous mes casts, le dynamic_cast étant 5 fois plus rapide que la conversion explicite.
Encore merci pour vos réponses et cet article qui met fin à cette discussion.

yohan

[Philippe Vialatte]

je suis bon pour changer tous mes casts, le dynamic_cast étant 5 fois plus rapide que la conversion explicite.
Encore merci pour vos réponses et cet article qui met fin à cette discussion.

Nyet, pas d'accord, ce que je soulevais rete valide...

Si tu lis l'article, tu vois que sur 29 millions de cast, tu as une différence de 600 millisecondes...si c'est ce qui te ralentit le plus, tu as une sacrée chance

Ça reste de la micro-optimisation, j'insiste

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

Je préfère connaitre les mécanismes du langage correctement.

Pour ca, par contre, ok, mais la difference est plus "fonctionelle" que une question de perfs...et en plus, l'article cite sur gen5 a a peu pres cette conclusion, utiliser les cast prefixes...

En terme de bonne pratique, les exceptions doivent être remontées le plus tôt possible

[sneakysponge]

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

list est une instance de List<T>, par réflexion, tu verras que List<T> implémente explicitement ICollection, donc le seul moyen d'accéder à son SyncRoot, sauf erreur de ma part, c'est le cast.

[Skalp]

En plus, j'avais lu en travers, mais, dans ton exemple, si ta liste implémente ICollection, le cast est, en plus, inutile...vu que justement, l'intérêt d'utiliser une interface, c'est de s'assurer que les classes implémentant l'interface remplissent le contrat défini par ton interface...ou sinon, j'ai loupe un train...

list est une instance de List<T>, par réflexion, tu verras que List<T> implémente explicitement ICollection, donc le seul moyen d'accéder à son SyncRoot, sauf erreur de ma part, c'est le cast.

Vous avez tous les deux raison :

- Si List<T> implémente ICollection, elle devrait présenter la propriété SyncRoot. Mais ce n'est pas le cas, l'implémentation de ICollection par List<T> cache cette propriété.
Ne me demandez pas pourquoi, je me pose moi-même déjà cette question !
- Dans le cas de List<T>, comme cette propriété est cachée par l'implémentation, il faut passer par un cast.


@sneakysponge : si ta liste ne manipule que des string, je te propose StringCollection qui présente publiquement la propriété SyncRoot (il n'y aurait donc pas besoin de caster dans ce cas).

[Philippe Vialatte]

arf, le boulet, comme je te voyais caster sur une ICollection, j'avais pense a une arraylist...

Ceci dit, je crois me rappeler que microsoft avait une raison pour ne pas utiliser SyncRoot dans le framework v2.0....faudra que je cherche

[Skalp]

Ceci dit, je crois me rappeler que microsoft avait une raison pour ne pas utiliser SyncRoot dans le framework v2.0....faudra que je cherche

Ca m'intéresse !

[Philippe Vialatte]

J'ai trouve

http://blogs.msdn.com/bclteam/archiv...15/396399.aspx

Le but étant de laisser aux développeurs la possibilité de gérer leur propre synchronisation a un niveau plus élevé...