Quelle est la raison sous-jacente pour ne pas être en mesure de mettre des tableaux de pointeurs dans des structures dangereuses en C#?

Question

Si l'on pouvait placer un tableau de pointeurs sur les structures enfants dans des structures dangereuses en C# comme on le ferait en C, construire des structures de données complexes sans avoir un objet par nœud serait beaucoup plus facile et moins rapide. ainsi que syntaxiquement plus propre et beaucoup plus lisible.

Existe-t-il une raison architecturale profonde pour laquelle les tableaux fixes à l'intérieur de structures dangereuses ne peuvent être composés que de «types de valeur» et non de pointeurs? Je suppose que seuls les pointeurs explicitement nommés à l'intérieur des structs doivent être une décision délibérée d'affaiblir le langage, mais je ne trouve aucune documentation expliquant pourquoi c'est le cas, ou le raisonnement pour ne pas autoriser les tableaux de pointeurs dans les structures, car je supposerait que le ramasse-miettes ne devrait pas se préoccuper de ce qui se passe dans les structures marquées comme dangereuses. Digital Mars 'D gère élégamment les structures et les pointeurs en comparaison, et il me manque de ne pas pouvoir développer rapidement des structures de données succinctes; en faisant des références abstraites en C#, beaucoup de pouvoir semble avoir été retiré du langage, même si les pointeurs sont toujours là au moins dans un sens marketing. Peut-être que je me trompe à l'idée que les langues soient plus puissantes pour représenter efficacement des structures de données complexes au fil du temps.

Answer 1

Je ne fais que deviner, mais cela peut avoir à faire avec différentes tailles de pointeurs pour différentes plates-formes cibles. Il semble que le compilateur C# utilise directement la taille des éléments pour les calculs d'index (c'est-à-dire qu'il n'y a pas de support CLR pour calculer les indices de tampons de taille fixe ...)

vous pouvez utiliser En tout cas un tableau de ulong s et jeter les pointeurs vers elle:

unsafe struct s1 
{ 
    public int a; 
    public int b; 
} 

unsafe struct s 
{ 
    public fixed ulong otherStruct[100]; 
} 

unsafe void f() { 
    var S = new s(); 
    var S1 = new s1(); 
    S.otherStruct[4] = (ulong)&S1; 
    var S2 = (s1*)S.otherStruct[4]; 
} 

Answer 2

Une raison très simple: dotNET a un compacteur garbage collector. Cela fait bouger les choses. Donc, même si vous pouviez créer des tableaux comme ça, vous auriez broche chaque bloc alloué et vous verriez le système ralentir à une analyse.

Mais vous essayez d'optimiser en fonction d'une hypothèse. L'allocation et le nettoyage des objets dans dotNET sont hautement optimisés. Écrivez donc d'abord un programme de travail, puis utilisez un profileur pour trouver vos goulots d'étranglement. Ce ne sera probablement pas l'allocation de vos objets.

Modifier, pour répondre à la dernière partie:

Peut-être que je me trompe d'attendre langues à devenir plus puissant à représenter structures de données complexes efficacement au fil du temps.

Je pense que C# (ou toute autre langue gérée) est beaucoup plus puissant à représenter structures de données complexes (efficace). En passant des pointeurs de bas niveau aux références récupérées. Mettre un tableau fixe de pointeurs dans une structure en ferait rapidement un mauvais candidat pour une struct.

Answer 3

La limite de taille recommandée pour une structure est de 16 octets. Par conséquent, sur un système x64, vous ne pouvez insérer que deux pointeurs dans le tableau, ce qui est inutile.

Vous devez utiliser des classes pour les structures de données complexes, si vous utilisez des structures, leur utilisation est très limitée. Vous ne pourriez pas, par exemple, créer une structure de données dans une méthode et la renvoyer, car elle contiendrait alors des pointeurs vers des structures qui n'existent plus puisqu'elles étaient allouées dans le cadre de la pile de la méthode.