- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
class Program
{
class A
{
//-----------------------------------------------------------------------
public static A CurrentRoot;
public static Dictionary<object, A> RootMap = new Dictionary<object, A>();
public static object Lock = new object();
//-----------------------------------------------------------------------
public int Test;
public A()
{
lock (Lock)
{
CurrentRoot = this;
b = new B();
}
}
internal class B
{
public B() { RootMap.Add(this, CurrentRoot); }
public A root { get { return RootMap[this]; } }
~B() { RootMap.Remove(this); }
}
public B b;
}
static void Main(string[] args)
{
A a1 = new A(); a1.Test = 555;
A a2 = new A(); a2.Test = 888;
Console.WriteLine(a1.b.root.Test); Console.WriteLine(a1.Test);
Console.WriteLine(a2.b.root.Test); Console.WriteLine(a2.Test);
Console.WriteLine(a1.b.root.b.root.b.root.b.root.b.root.Test);
}
Класс создан для того чтобы вложенные структуры имели доступ к структуре родителя. Safe thread support.
Follow us!
меня убивает что ни один язык/фрэймворк не позволяет этого сделать из коробки.
только не надо мне опять эти теории толкать что это "теоретически неправильно".
на практике бывает нужно, и доморощеные реализации часто обращаются в ГК монументального характера.
повседневные примеры тоже легко найти.
возьми любую GUI библиотеку. каждый раз когда ты создаешь контрол, ему параметром надо передать парент окно. теоретически, контролу парент в ж не нужен. но практически, контрол наследует бэкграунд от парента, рисует себя в контексте парента, и получает события от парента.
Пример не очень ИМХО, т.к. предок контрола рисует свой фон и контрол. А контрол просто уведомляет, что он "грязный" и его нужно перерисовать. Да и знать структуру родителя контролу тоже незачем.
Мне этот "доступ вложенной структуры к структуре родителя" напоминает сишный offsetof. Вроде, полезный, но хак.
и да и нет. проблема в том что бы вложеная структура могла узнать что (1) она вложеная, (2) и если она вложеная то во что.
offsetof() как раз и не работает, потому что нужно знать заранее что во что вложено. иначе не работает.
В шарпике мб через рефлексию можно что-то соорудить.
преимущество жабы (и шарпа?) здесь в том что объект есть всегда указатель. в крестах же есть еще грабли что у тебя вложеная структура может быть (1) частью родительского объекта, или (2) родитель может на нее иметь только указатель.
Почему бы просто не передать ссылку на родителя в конструктор?
`static StaticEntity static_entity;` - и у тебя все 50 полей проинициализированы нулями. не идеально - но работает.
теперь представь себе теперь добавление конструктора, и последующее добавление 50 инициализаторов для этих полей. и это все только что бы передать один гребаный параметр - который к слову компилеру известен.
1) Помечаем класс как "имеющий ссылку на его владельца". От этого у него внутри появляется неявный указатель некого типа, а у конструктора возникает неявный параметр.
2) Экземпляр данного класса нельзя использовать без владельца (т.е. размещение на стеке или через new запрещено (как вариант - разрешено, просто указатель будет null'ом, еще вариант - можно самому передать как параметр в new или конструктор).
3) Владелец, во время конструирования, передает туда указатель на себя. При этом, если тип владельца не кастуется в тип неявного указателя - возникает ошибка компиляции.
4) Теперь объект может юзать неявный указатель на владельца, при необходимости раскастовывая его во что нужно.
> все 50 полей проинициализированы нулями
Имхо, зависеть от способа создания объекта - ССЗБ. Сегодня он в статике, и там нули. Завтра его создали на стеке или в куче - и кровь-кишки-распидорасило. Я сразу бы написал 50 инициализаторов, чтобы спать спокойно.
в данной ситуации данный код отсасывает простому
Рут лежит в B, а идешь ты по массиву А.
И даже если бы шел по массиву B какая разница сколько полей если ты размер задаешь не руками а получаешь рефлексией?
Почему бы не юзать сериализацию?
Ты сам то понимаешь что ты говоришь? Сам себе противоречишь. Если ты имел ввиду что при создании сложных вложенных структур ты хочешь иметь к ним доступ, не прибегая к бесконечным итерациям по коллекциям, то юзай фабрику в которой будут храниться в каком то виде иерархия созданных объектов
Не знаю почему такую простую вещь до сих пор не организовали.