C# et pointeurs

Version imprimable

C# et pointeurs

Bonjour,

je suis en train de bosser un bouquin sur les pointeurs et il y a un truc qui m' l'air tout bête mais que je n'arrive pas à comprendre :

voici le code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 unsafe public static void Modif(int * pi) { *pi = 500; pi++; *pi = 2000; } unsafe static void Main(string[] args) { int i=1, j=100, k = 20; Modif(&j); Console.ReadKey(); }
Le fait de faire pi++ fait pointer pi non plus sur j, mais sur i... Pourquoi n'est pas sur k ? Pourquoi le fait d'incrémenter pi le fait pointer sur la variable déclarée AVANT et non après ?

Merci de vos explications !

08/06/2012, 00h58
tomlev

Citation:

Envoyé par grinder59

Le fait de faire pi++ fait pointer pi non plus sur j, mais sur i... Pourquoi n'est pas sur k ?

C'est ce que tu as observé, ou ce que dit le bouquin ?

Je viens de tester, chez moi ça pointe sur k... l'état des variables à la fin est le suivant :

i = 1
j = 500
k = 2000

après ça dépend peut-être de la version du runtime, et du fait d'être en 32 ou 64 bits (j'ai testé dans LinqPad, .NET 4.0 64 bits)

c'est ce que dit le bouquin et ce que j'ai observé...

j'ai donc refait le test suivant :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
        unsafe public static void Modif(int* pi)
        {
            *pi = 500; pi++; *pi = 2000;
        }
 
        unsafe static void Main(string[] args)
        {
 
            int i = 1, j = 100, k = 20;
            Console.WriteLine("avant : i = " + i + ", j = " + j + ", k = " + k);
            Modif(&j);
            Console.WriteLine("après : i = " + i + ", j = " + j + ", k = " + k);
 
            Console.ReadKey();
        }

voici un copier coller de ce qui est affiché sur la console :

Code:

1
2
3
 
avant : i = 1, j = 100, k = 20
après : i = 2000, j = 500, k = 20

c'est donc i qui est modifié par l'opération pi++...

mais pourquoi ?
J'ai testé avec VS2010 express / 64 bits

08/06/2012, 08h01
BenoitM

Euh pour moi ce code ne devrait pas marcher

Rien ne dit que la réservation des int se fait de manièere consécutive, pour moi il aurait fallu déclaré un tableau d'int
08/06/2012, 09h22
antoine.debyser

Bonjour,

Citation:

Envoyé par BenoitM

Euh pour moi ce code ne devrait pas marcher

Rien ne dit que la réservation des int se fait de manièere consécutive, pour moi il aurait fallu déclaré un tableau d'int

Exact, Sauf que la déclaration des variables local par le compilateur sur la pile (IL) se fait de manière consécutive.
Par contre rien n'oblige le compilateur à conserver le même ordre.

En fait cette exemple ne marche que parce que i,j,k ont la même taille.
08/06/2012, 10h20
tomlev

Citation:

Envoyé par grinder59

mais pourquoi ?
J'ai testé avec VS2010 express / 64 bits

Comme je le disais, ça dépend du runtime... J'ai refait le test au boulot ce matin (Win XP 32 bits, .NET 4.0), et ni i ni k n'est modifié, seulement j. Par contre ça plante sur le retour de Main, parce que ça a dû foutre la zone en modifiant autre chose sur la pile. Par contre en désactivant les optimisations du compilateur, ça passe, et c'est i qui est modifié...

Citation:

Envoyé par BenoitM

Euh pour moi ce code ne devrait pas marcher

Bah en fait ça depend... ça fonctionne dans des cas particuliers. Bonne illustration de pourquoi le code "unsafe" s'appelle comme ça ;)
08/06/2012, 10h25
mich35

Citation:

Envoyé par antoine.debyser

Bonjour,

Exact, Sauf que la déclaration des variables local par le compilateur sur la pile (IL) se fait de manière consécutive.
Par contre rien n'oblige le compilateur à conserver le même ordre.

En fait cette exemple ne marche que parce que i,j,k ont la même taille.

Je pense que l'ordre dans la pile est l'ordre d'utilisation des variables et non pas l'ordre de declaration (meme si ici les 2 sont identiques) mais ca depend sans doute de chaque compilo
08/06/2012, 10h44
grinder59

En gros, si je comprends bien, c'est le compilateur qui gère sa mémoire... et ce code peut ou pas marcher en fonction de différents paramètres (type des variables, ordre de déclaration, ordre d'utilisation, version du framework, âge du capitaine)...

La seule chose que j'ai compris c'est que les pointeurs sont à manipuler avec une grand prudence...

Merci à tous pour vos réactions en tous cas...
08/06/2012, 11h02
Er3van

Il y a surtout très peu de raisons d'utiliser des pointeurs en programmation objet, spécialement en C#... Quel est le but (autre que pédagogique) dans ton cas ?

Sauf si tu fais de l'embarqué avec mémoire limitée et que tu veux vraiment contrôler ces aspects, et encore...
08/06/2012, 11h03
grinder59

pour l'instant, en effet, pas d'autre but que de suivre l'enseignement du bouquin...
08/06/2012, 12h18
tomlev

Citation:

Envoyé par mich35

Je pense que l'ordre dans la pile est l'ordre d'utilisation des variables et non pas l'ordre de declaration (meme si ici les 2 sont identiques) mais ca depend sans doute de chaque compilo

En fait ça dépend surtout du runtime. Je crois que le runtime 32 bits remplit la pile à partir de la fin (par adresses décroissantes) alors que le runtime 64 bits la remplit à partir du début (par adresses croissantes). En tous cas ça expliquerait les différences observées.

Citation:

Envoyé par Er3van

Il y a surtout très peu de raisons d'utiliser des pointeurs en programmation objet, spécialement en C#...

Dans certains cas ça se justifie, quand un bout de code doit être très optimisé. Par exemple, beaucoup de méthodes de la classe String utilisent des pointeurs.
08/06/2012, 13h00
Er3van

Citation:

Envoyé par tomlev

Dans certains cas ça se justifie, quand un bout de code doit être très optimisé. Par exemple, beaucoup de méthodes de la classe String utilisent des pointeurs.

Je ne dis pas le contraire, je dis juste que c'est marginal.

Passer du temps là dessus se justifie dans un langage comme le C ou le C++, car cela relève des basiques, mais pour l'apprentissage du C# (ou .Net de manière générale) ne me parait pas forcément opportun, car à l'inverse, on est plus dans de l'expertise.
C'est, comme tu l'as dit, justifié par le unsafe : ne s'en servir que si on sait exactement ce que l'on fait.
08/06/2012, 13h13
grinder59

j'ai l'exam 70-536 en ligne de mire, donc autant que j'en sache un maximum, même si cela ne me servira pas pour la suite...
08/06/2012, 21h37
tomlev

Citation:

Envoyé par Er3van

Passer du temps là dessus se justifie dans un langage comme le C ou le C++, car cela relève des basiques, mais pour l'apprentissage du C# (ou .Net de manière générale) ne me parait pas forcément opportun, car à l'inverse, on est plus dans de l'expertise.

Effectivement, pour l'apprentissage c'est pas vraiment la priorité...

Citation:

Envoyé par grinder59

j'ai l'exam 70-536 en ligne de mire, donc autant que j'en sache un maximum, même si cela ne me servira pas pour la suite...

Je ne crois pas qu'il y ait quoi que ce soit sur les pointeurs dans cet exam. Ca porte essentiellement sur le framework, pas tellement sur le langage.
08/06/2012, 21h53
Obsidian

Bonjour,

Citation:

Envoyé par grinder59

Le fait de faire pi++ fait pointer pi non plus sur j, mais sur i... Pourquoi n'est pas sur k ? Pourquoi le fait d'incrémenter pi le fait pointer sur la variable déclarée AVANT et non après ?

Merci de vos explications !

Je ne pratique pas le C# et, donc, je ne peux pas être affirmatif en ce qui concerne ce langage précis, mais en C, bien qu'il ne s'agisse pas non plus d'un prérequis de la norme, tu observeras pratiquement toujours ce comportement.

Cela s'explique par le fait que sur tous les micro-processeurs avec lesquels j'ai travaillé, et en dehors de toute considération propre à tout langage autre que le langage machine, le pointeur de pile est décrémenté lors de l'empilement, puis la valeur stockée. À l'inverse, lors d'un dépilement, la valeur pointée est chargée dans le bon registre puis le pointeur de pile est incrémenté. Par conséquent, lorsque la pile est vide, le pointeur de pile pointe initialement la fin du segment de pile.

C'est dû au fait que, d'une part, il a bien fallu choisir un sens de fonctionnement et que, d'autre part, ceci permet de faire cohabiter le code et la pile dans le même segment de mémoire, chacun à son extrémité.

Par conséquent, les premières variables empilées sont les plus « lointaines » en mémoire et c'est pourquoi, en incrémentant ton pointeur, tu passes à la précédente. À noter toutefois qu'en C et C++, toujours, les tableaux déclarés avec « [ ] » sont réputés consécutifs en mémoire et dans le bon ordre, c'est-à-dire que deux tableaux distincts seront empilés comme expliqué précédemment, mais qu'à l'intérieur d'un de ces tableaux, les éléments sont bien rangés dans le sens croissant. Il est probable que le comportement soit le même en C#.