Discussion :

[Yoshio]

Bonjour,

J'aimerais savoir quel est la meilleure solution; utiliser un type primitif (int) ou utiliser un type du CTS (Int32).

Quels sont les avantages / inconvénients ?


Yoshio

[SirJulio]

Salut,

c'est la meme chose. =)

Extract du standard :

C# provides a set of predefined struct types called the simple types. The simple types are identified through reserved words, but these reserved words are simply aliases for predefined struct types in the System namespace, as described in the table below.

Idem pour string (System.String) et object (System.Object).

[Yoshio]

Je ne pense pas qu'un int prenne la même place en mémoire qu'un Int32.

[The_badger_man]

int est un alias pour System.Int32 (tout comme bool l'est pour Boolean, long pour Int64, etc.).

int i;
System.Int32 i;

ces 2 déclarations sont identiques (au niveau rapidité, execution, espace mémoire occupé). La diférence est que la 2eme est moins utilisée car plus longue à écrire...

Cela correspond dans les deux cas à une variable entière codée sur 32bits.

[_skip]

En général je dirai la chose suivante : si vous avez à tout prix besoin de vous assurer qu'un int fait bien 32 bits, utilisez Int32 (cas d'une correspondance avec une colonne de base de données).

Sans cette contrainte, utilisez un int. Pourquoi en fait? Et bien pour le moment int map vers Int32, je ne suis pas sûr que lorsque les systèmes 64 bits se seront imposés ce int ne sera pas tout d'un coup un Int64 pour des raisons de performances.

Il y a eu des exemples de ce genre de choses en C++ avec le passage de 16 à 32bits, d'ou l'utilisation massive de typedef dans certains frameworks.

[Chubyone]

Non, Non, Non...

Int32 = int
"Int32" est I-DEN-TI-QUE à "int" en processeur 32 / 64 / 1024 bits...

Int32 = int
C'est un allias, lors de la compil int devient Int32 et fera TOU-JOURS 32 bits...
Tout comme long sera toujours un Int64...

Je comprend pas pourquoi certains cherche tant la complexité...

Vous pensiez quand même pas que Microsoft allait laisser cette histoire de 32 bits passé en 64 en fonction de la plateforme cible?...
Ils ont définit les types et les allias ainsi, ils ne vont pas changer à l'avenir par pur craprice...

Surtout que le framework entier est définit ainsi :

public static int Parse(string s)
Member of System.Int32

Summary:
Converts the string representation of a number to its 32-bit signed integer equivalent.

[_skip]

Vous pensiez quand même pas que Microsoft allait laisser cette histoire de 32 bits passé en 64 en fonction de la plateforme cible?...
Ils ont définit les types et les allias ainsi, ils ne vont pas changer à l'avenir par pur craprice...

Allez dire ça à ceux qui ont fait du C++ et qui se demandent pourquoi un long fait seulement 4 octets (taille d'un int). Et oui, un beau jour, un int fut ce qui est aujourd'hui un short, et un long fut ce qui est aujourd'hui un int.

Me méfier de ce genre de chose est une habitude et une précaution que j'ai prise depuis cette époque, navré si cela vous choque à ce point.

[smyley]

Allez dire ça à ceux qui ont fait du C++ et qui se demandent pourquoi un long fait seulement 4 octets (taille d'un int). Et oui, un beau jour, un int fut ce qui est aujourd'hui un short, et un long fut ce qui est aujourd'hui un int.

Justement en C++ un int est défini en fonction du bon vouloir de la platforme sur laquelle il tourne. Il pourra donc avoir une taille variable si on change de platforme, et c'est justement pour celà qu'avec le framework un int a été définis comme un entier signé de 32 bits, point barre. Ce choix est donc lié à tous les problèmes qu'il y a eu avec la taille des nombres en C++ et donc les gars de Microsoft ne sont pas prêt d'en changer ... un int en C# fait la même taille sur Windows ( .NET Framework ), Linux ( Mono ) et Mac ( Mono ? ) quelque soit l'architecture des procésseurs utilisés.

[Yoshio]

Je vous posait cette question car mon prof m'a dit que un int n'était pas tout à fait pareille qu'un Int32. Me demandez plus ce qu'il a dit j'en sais plus rien.

Mais bon j'ai fait quelque recherche sur le net et ils disent tous la même chose, un int est pareille qu'un Int32.

[_skip]

Si il a dit que le int était un type primitif et le Int32 un type objet (ou boxé), c'est faux.
Et c'est une erreur qu'on voit souvent de la part de ceux qui viennent du monde java dans lequel il existe un int et une classe Integer qui sont effectivement des choses différentes.

[Yoshio]

Non il ne m'a pas sépcialement dit ca, la c'est moi qui cherchait 2 appellations différentes pour les différencier.

[tomlev]

mon prof m'a dit que un int n'était pas tout à fait pareille qu'un Int32

Change de prof
En C# c'est exactement la même chose. En C++/CLI (ou C++ managé) je pense que ça correspond à l'int "natif", de taille variable selon la plateforme. Mais sous Windows c'est toujours 32 bits je pense...

[smyley]

Mais sous Windows c'est toujours 32 bits je pense...

En C++ ? Sur Windows 32 bits ou 64 bits ?

[tomlev]

les 2 je crois...

For 32-bit and 64-bit compilers, Microsoft Visual C++ recognizes the types shown in the table below. Note that the following type also have unsigned forms:

int (unsigned int)
__int8 (unsigned __int8)
__int16 (unsigned __int16)
__int32 (unsigned __int32)
__int64 (unsigned __int64)
short (unsigned short)
long (unsigned long)
long long (unsigned longlong)

Type Name.....Bytes
int................4
...

[smyley]

Ouai bon, même si on ne fait pas du C++ :
http://msdn.microsoft.com/library/fr...o64bitcode.asp
En C++ sur Windows un int et un long font tous les deux 32 bits alors qu'en C# un int c'est 32 et un long 64 ... il faut être fou pour faire du C++

[_skip]

Si vous osez parier que dans 10 ans le int de base fera toujours 32bits, j'envie votre confiance.

[Guulh]

Si vous osez parier que dans 10 ans le int de base fera toujours 32bits, j'envie votre confiance.

Je comprends ta crainte, mais si C++ pour des raisons historique (langage proche de la machine destiné à être très portable, contraintes issues du C) a des définitions imprécises des types de base, C# connait précisément la machine sur laquelle il tourne : la CLR. Donc j'imagine mal moi aussi le int changer de taille à moyen terme. Un Int128 ou Int256 apparaîtra peut être un jour, mais les alias n'ont pas de raison de changer. (byte, short, int, long, supralong, petralong ?)
Mais bon le propre des tuiles imprévisbles est justement d'arriver sans prévenir, restons méfiants

[TSalm]

Ouai bon, même si on ne fait pas du C++ :
http://msdn.microsoft.com/library/fr...o64bitcode.asp
En C++ sur Windows un int et un long font tous les deux 32 bits alors qu'en C# un int c'est 32 et un long 64 ... il faut être fou pour faire du C++

"être fou de faire du C++ est discutable" Les pgms C++ seront toujours plus rapides que des pgm équivalent en C# Et ceci parce que les développeurs C++ seront toujours plus proche de la machine que les C#istes. Il reste qu'il y a des bibs C++ qui gérent très bien les types portables. Et puis, au moins, C++ a plus de chance d'être portable que C#.net si on fait un petit effort non mais hé (je ne parle évidemment pas du C++ CLI...)

[smyley]

"être fou de faire du C++ est discutable"

Je précise que je trouve les programmeurs C++ fous mais que je les respecte comme des Dieux

Les pgms C++ seront toujours plus rapides que des pgm équivalent en C#

Ce que tu dit n'est pas forcément vrai, il arrive parfois que le C# valle le C++ surtout grâce au JIT. En même temps en programmant en C++ on est aussi plus proche des crash et autres erreurs de pointeurs. Donc le développement d'une application en C# prend globallement moins de temps que la même en C++, même si le C++ reste puissant par sa possibilité d'atteindre toutes les parties de la machine sans restriction. Pour ce qui est de la vitesse pure, c'est le C qui est roi.

Et puis, au moins, C++ a plus de chance d'être portable que C#.net si on fait un petit effort non mais hé (je ne parle évidemment pas du C++ CLI...)

Tu connais Mono ? tu peut faire du C#, utiliser "un peut" les WinForms ou faire du GTK# et ton programme compilé sur Windows ou Linux s'exécute sur Windows et Linux ...

[tomlev]

Pour ce qui est de la vitesse pure, c'est le C qui est roi.

Si on va par là, ce serait plutôt l'assembleur le roi