Какова базовая причина неспособности поместить массивы указателей в небезопасных структурах в C#?
Если можно было бы поместить массив указателей на дочерние структуры в небезопасных структурах в C# как, каждый мог в C, создавание сложных структур данных без издержек наличия одного объекта на узел будет намного легче и меньше приемника времени, а также синтаксически инструмента для очистки и намного более читаемым.
Существует ли глубокая архитектурная причина, почему фиксированным массивам в небезопасных структурах только позволяют состоять из "типов значения" и не указателей?
Я принимаю только явно называвший указатели в структурах, должно быть преднамеренное решение ослабить язык, но я не могу найти документацию о том, почему это так, или обоснование для того, чтобы не позволять массивы указателей в структурах, так как я предположил бы, что сборщик "мусора" не должен заботиться о том, что продолжается в структурах, отмеченных как небезопасное.
D цифрового Марса обрабатывает структуры и указатели изящно в сравнении, и я избегаю не быть способным быстро разрабатывать сжатые структуры данных; путем создания ссылочного краткого обзора в C# много питания, кажется, было удалено из языка, даже при том, что указатели находятся все еще там, по крайней мере, в маркетинговом смысле.
Возможно, я неправ ожидать, что языки станут более мощными при представлении сложных структур данных эффективно со временем.
3 ответа
Я просто догадываюсь, но это может быть связано с разными размерами указателей для разных целевых платформ. Похоже, что компилятор C # использует размер элементов непосредственно для расчета индекса (т.е. нет поддержки CLR для вычисления индексов буферов фиксированного размера ...)
В любом случае вы можете использовать массив из ulong s и привести к нему указатели:
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];
}
Одна очень простая причина: в dotNET есть сжимающий сборщик мусора. Он перемещает вещи. Так что даже если бы вы могли создавать подобные массивы, вам пришлось бы закреплять каждый выделенный блок, и вы бы увидели, что система замедляется до ползания.
Но вы пытаетесь оптимизировать, основываясь на предположении. Размещение и очистка объектов в dotNET сильно оптимизированы. Поэтому сначала напишите рабочую программу, а затем используйте профилировщик, чтобы найти узкие места. Скорее всего, это будет не размещение ваших объектов.
Отредактируйте, чтобы ответить на последнюю часть:
Возможно, я ошибаюсь, ожидая, что языки станут более мощными в представлении сложных структур данных с течением времени.
Я думаю, что C # (или любой другой управляемый язык) гораздо более эффективен при представлении сложных структур данных (эффективно). Путем перехода от указателей низкого уровня к ссылкам со сборщиком мусора.
Помещение фиксированного массива указателей в структуру быстро сделало бы ее плохим кандидатом для структуры. Рекомендуемый предел размера для структуры составляет 16 байтов, поэтому в системе x64 вы сможете разместить только два указателя в массиве, что довольно бессмысленно.
Вы должны использовать классы для сложных структур данных, если вы используете структуры, их использование становится очень ограниченным. Например, вы не сможете создать структуру данных в методе и вернуть ее, поскольку тогда она будет содержать указатели на структуры, которые больше не существуют, поскольку они были выделены в кадре стека метода.