LINUX.ORG.RU

История изменений

Исправление thunar, (текущая версия) :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется в python). Конкретный хранимый им вариант зависит от размерности аргуммента config_t, что передаётся в config_holder'е. Тот вариант, что data_holder в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB. Если это корректно, то наверное я просто напишу подробное пояснение — всё равно я ко всем исходникам пишу описание в LaTeX'е...

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется в python). Конкретный хранимый им вариант зависит от размерности аргуммента config_t, что передаётся в config_holder'е. Тот вариант, что data_holder в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB. Если это корректно, то наверное я просто напишу подробное пояснение — всё равно я ко всем исходникам пишу описание в LaTeX'е...

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется в python). Конкретный хранимый им вариант зависит от размерности аргуммента config_t, что передаётся в config_holder'е. Тот вариант, что data_holder в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB. Если это корректно, то наверное я просто напишу подробное пояснение -- всё равно я ко всем исходникам пишу описание в LaTeX'е...

[quote]Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.[br][/quote]Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется в python). А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB. Если это корректно, то наверное я просто напишу подробное пояснение — всё равно я ко всем исходникам пишу описание в LaTeX'е...

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется python). А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB. Если это корректно, то наверное я просто напишу подробное пояснение — всё равно я ко всем исходникам пишу описание в LaTeX'е...

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя (экспортируется python). А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB.

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя. А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB.

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holder'ы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя. А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB.

Простая функция-фабрика, без всяких фокусов с конструкторами и наследованием.

Ну вот тут возвращаются голые классы, а мне нужно упакованные в *_holderы.

Исправление thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя. А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB.

Исходная версия thunar, :

зачем из него делать еще и config_holder

Так я же писал:

варианты хранятся в холдере где для них делается выделение памяти, инициализация и пр

Т.е. это верхний слой, который осуществляет RAII и единственный доступный со стороны пользователя. А то что он в себе хранит потом биндится к функциям из бекэнда (которых over 9000 в зависимости от типа численной схемы). Я, поначалу, думал сделать это через композицию, но тогда, получается, нужно дописывать ещё и conversion method. Т.е. ещё более громоздко получается.

То что я написал, вроде, работает. Мне главное понять, всё ли там синтаксически и семантически корректно и нет ли UB.