Член указатель

@Igor3D · Регистрация: 01.10.2012

Студворк — интернет-сервис помощи студентам

Добрый день

Очень простая конструкция

C++
1
2
3
4
5
struct SomeObject {
...
 SomeData * m_data;
...
};

Как минимум возникают заботы с сохранностью/валидностью m_data, но не только
Как лучше? Слышал такое

1) "Лучше иметь m_data членом, а не указателем". Это владение, а оно не всегда нужно/допустимо. В большинстве случаев SomeObject просто использует SomeData для чтения/записи, но SomeData остается вполне самостоятельным объектом что может существовать и без SomeObject

2) "Необходимо использовать вумный указатель! Вообще "голые" указатели (как в примере выше) - это зло, их быть вообще не должно!"

А Вы что предложите?

Спасибо

@Igor3D · 13.07.2024, 19:25 **[ТС]**

Сообщение от Алексей1153

либо запретить удаление, если на объект есть ссылка, либо Light2 будет использовать дефолты

Сообщение от zayats80888

Архитектурно напрашивается, что параметры это ресурс, т.е. подсчет ссылок актуален.

В любом случае Light1 должен знать что на него есть ссылка(и), причем только факт/число ссылок явно недостаточно - "запрет удаления" вряд ли устроит.

Сообщение от zayats80888

А каким боком вы сюда undo приплели?

Почему "приплел"?

Удаляется элемент/объект сцены, обеспечить undo обязан. Да, факт/действие установки ссылки конечно был, но

С Ларисой я действительно пил вино, но это было на пасху

Очевидно просто так "хранить указатель" нехорошо, нужно расширять структуры данных. Каким образом?

@zayats80888 · 13.07.2024, 19:48

Сообщение от Igor3D

В любом случае Light1 должен знать что на него есть ссылка(и), причем только факт/число ссылок явно недостаточно - "запрет удаления" вряд ли устроит.

Ничего не понял... Короче, давайте выясним, зачем вы сделали "параметры" указателем и зачем другой объект ссылается на те же параметры.
Я вижу только две причины - комплексное редактирование и снижение зтарат памяти (например, снижение траффика данных на gpu).
Ответьте на пару вопросов:
1) кто владеет "параметрами"? (очевидно владение разделяемое, т.е. подсчет ссылок актуален)
2) что происходит при редактировании "параметров" и через что они редактируются? (очевидно они меняются для всех владельцев, если нужно независимо, то редактор должен предоставлять возможность сделать ресурс уникальным, т.е. редактируется ресурс, а не владелец)
3) зачем одному объекту знать, кто и сколько еще используют тот же ресурс? (я не вижу в этом смысла, т.е. даже количество ссылок самому объекту знать не нужно)

Сообщение от Igor3D

Почему "приплел"? Удаляется элемент/объект сцены, обеспечить undo обязан.

Эм... обеспечить восстановление удаленного объекта? Не вижу проблемы и не вижу как с этим связан "член указатель".
На всякий случай напомню, что undo - это отмена последнего действия, т.е. удалить Light1 через undo не затрагивая Light2 нельзя, грубо говоря, отменяться будут все действия, выполненные после создания Light1.

Сообщение от Igor3D

Очевидно просто так "хранить указатель" нехорошо, нужно расширять структуры данных. Каким образом?

Я не знаю, что вам там очевидно, вы пока ни одного обоснования, что хранить голый указатель "нехорошо" не привели, только никак не связанные и с потолка взятые "примеры" без деталей (поэтому я и говорю - высосано из пальца).

@Igor3D · 13.07.2024, 22:32 **[ТС]**

Сообщение от zayats80888

Ничего не понял... Короче, давайте выясним, зачем вы сделали "параметры" указателем и зачем другой объект ссылается на те же параметры.
Я вижу только две причины - комплексное редактирование и снижение зтарат памяти (например, снижение траффика данных на gpu).
Ответьте на пару вопросов:
1) кто владеет "параметрами"? (очевидно владение разделяемое, т.е. подсчет ссылок актуален)
2) что происходит при редактировании "параметров" и через что они редактируются? (очевидно они меняются для всех владельцев, если нужно независимо, то редактор должен предоставлять возможность сделать ресурс уникальным, т.е. редактируется ресурс, а не владелец)

Тут все просто. Те же источники света. Нормально, по умолчанию это объекты одного типа, они предъявляются в UI, юзер открывает окно и меняет параметры конкретного лайта, напр цвет/интенсивность. Никаких шаред, ничего, параметрами владеет объект "источник света", они просто его члены. Теперь юзер установил отношение master/slave. Никакие данные не меняются, но slave использует параметры (напр тот же цвет) мастера, напр при отрисовке сцены. Резоны очевидны - редактируем один объект вместо каждого из многих. Если юзер разорвал зависимость - используются собственные параметры.

Если такой пример не нравится - можно другой. Хотя бы скины. Полигонный объект управляется бонами, но никакими другими отношениями/владениями они не связаны. И опять-таки нельзя просто так, безболезненно удалить бону.

Сообщение от zayats80888

На всякий случай напомню, что undo - это отмена последнего действия, т.е. удалить Light1 через undo не затрагивая Light2 нельзя, грубо говоря, отменяться будут все действия, выполненные после создания Light1.

Та ну.. В лучшем случае - undo для текущей сессии (от момента старта приложения). А то и меньше. Вот Вы работаете в каком-то IDE/редакторе текста. Он умеет undo для того что Вы набирали/редактировали вчера? Наверно только если не выключали машину и не выходили из приложения

Алексей1153 · 13.07.2024, 22:37

Сообщение от Igor3D

Наверно только если не выключали машину и не выходили из приложения

никто не мешает сохранять журнал событий вместе с проектом. Но обычно это не делается

@zayats80888 · 13.07.2024, 22:40

Сообщение от Igor3D

Теперь юзер установил отношение master/slave. Никакие данные не меняются, но slave использует параметры (напр тот же цвет) мастера, напр при отрисовке сцены.

Это где это вы такое видели для источников света? Ну и покажите, как это реализовано в коде.

Сообщение от Igor3D

Если такой пример не нравится - можно другой.

Вы мне лучше премер реально решаемой вами задачи приведите, чтоб разговор предметный был, а не "высасывайте из пальца".

Сообщение от Igor3D

Полигонный объект управляется бонами, но никакими другими отношениями/владениями они не связаны. И опять-таки нельзя просто так, безболезненно удалить бону.

Это какие-то байки, код приведите.

Сообщение от Igor3D

В лучшем случае - undo для текущей сессии (от момента старта приложения). А то и меньше.

Так об этом и речь (кстати, после перзапуска в востановленной сессии могут сохраняться команды и кое-где это реализовано).
Вот я и спрашиваю, к чему вы упоминаете undo и с чем у вас там проблемы?

@Shamil1 · 14.07.2024, 01:02

Сообщение от Igor3D

Тот же тест/пример: undo. Как "восстановить переписку"?

Все действия - через Команды. Хранить список Команд.

@Igor3D · 14.07.2024, 01:36 **[ТС]**

Сообщение от zayats80888

Это где это вы такое видели для источников света? Ну и покажите, как это реализовано в коде.

Это выглядит так

C++
1
2
3
4
5
6
7
8
9
10
11
struct Light {
 float m_intensity;
 ...
 Light * masterLight;
 ...
};
 
float Light::GetIntensity( void ) const
{
 return masterLight ? masterLight->GetIntensity() : m_intensity;
}

Подобных/аналогичных ситуаций, когда один объект использует/ссылается на другой, в моем проекте больше 20, точно не помню.

Сообщение от zayats80888

Вот я и спрашиваю, к чему вы упоминаете undo и с чем у вас там проблемы?

К тому что возникает необходимость знать какие объекты ссылаются на данный, отвертеться не удается.

Добавлено через 2 минуты

Сообщение от Shamil1

Все действия - через Команды. Хранить список Команд

Он может быть неприемлемо велик

@zayats80888 · 14.07.2024, 02:31

Сообщение от Igor3D

Это выглядит так

Т.е. я правильно понимаю, у вас там параметры не одной intensity ограничиваются и помимо естественной древовидной иерархии сцены parent/child вы еще добавили "горизонтальные/диагональные" связи master/slave, причем master не знает о своем slave?

Сообщение от Igor3D

Подобных/аналогичных ситуаций, когда один объект использует/ссылается на другой, в моем проекте больше 20, точно не помню.

Интересное архитектурное решение... Но давайте остановимся только на Light - обоснуйте такое архитектурное решение для него и его плюсы.
Я навскидку могу только назвать очевидные минусы:
1) с "собственными" параметрами у света композиция, а с "чужими" - агрегация, и это взаимоисключающе, т.е. либо одно, либо другое висит в объекте мертвым грузом.
2) дополнительные связи (да и еще односторонние) усложняют код, его понимание и изменение.
3) оптимизацию отправки этих данных на рендер я не вижу
4) общие параметры для, скажем, 10 источников - это односвязный список от slave к master и рекурсивный вызов GetIntensity?
5) не понятно, как организовано условное SetIntensity, slave редактирует данные master без его ведома? ("Что этот ни*ер себе позволяет?"©

)
Я вам сразу предложил параметры как разделяемый ресурс(Алексей1153 еще раньше) - нивелирует все вышеупомянутые минусы и снимает вопрос в заголовке темы.

Сообщение от Igor3D

К тому что возникает необходимость знать какие объекты ссылаются на данный, отвертеться не удается.

А зачем вы такие связи построили? Сами себе проблему создали и теперь "отвертеться" хотите.

Сообщение от Igor3D

Он может быть неприемлемо велик

Он может быть ограничен как по количеству команд, так и по объему занимаемой памяти. Интерфейс стека над циклическим буфером.

Добавлено через 11 минут
...

@Igor3D · 14.07.2024, 15:31 **[ТС]**

Сообщение от zayats80888

Интересное архитектурное решение... Но давайте остановимся только на Light - обоснуйте такое архитектурное решение для него и его плюсы.

Давайте

Хотя это и мимо темы - вместо обсуждения как сделать - обсуждается зачем (нужно ли) это делать. Но такие оффтопы всегда были и будут, иногда они полезны

1) Хотя "указатель на другой объект" используется довольно часто, но само использование уникально. Не могу припомнить ни одной такой же зависимости как "master light". Ну может "master material" как-то похож, но немного

2) Ничего я не придумывал, эта фича досталась мне по наследству. Никакого недовольства (ни моего ни юзера) она не вызывает. Да, есть мелкие проблемки, но рулить толпой лайтов актуально и удобно.

3) Детали. Там есть еще контрол

C++
1
2
3
4
5
float Light::GetIntensity( void ) const
{
 bool useMaster = masterLight && GetFlag(LIGHT_INHERIT_INTENSITY);
 return useMaster ? masterLight->GetIntensity() : m_intensity;
}

Не очень понял о какой рекурсии Вы говорите. Строить "иерархию лайтов" не запрещено, но нужды в ней не видно, одного уровня обычно достаточно. И конечно slave не меняет установки мастера - юзер должен открыть окно мастера и там редактировать. Конечно необходима поддержка UI (разные иконки для slave/master, показать что параметр ведомый, найти мастера или наоборот, всех slave и.т.п.), но никаких принципиальных трудностей нет.

Сообщение от zayats80888

Я вам сразу предложил параметры как разделяемый ресурс(Алексей1153 еще раньше) - нивелирует все вышеупомянутые минусы и снимает вопрос в заголовке темы.

Если это вумный указатель, то он решает только валидность указателя, да и то ценой навязывания shared_ptr

Сообщение от zayats80888

Он может быть ограничен как по количеству команд, так и по объему занимаемой памяти. Интерфейс стека над циклическим буфером.

Здесь я не понял, на всякий случай спрошу. Юзер работает с проектом длительное время. Год назад он создал лайт. Полгода назад сделал его мастером. Сегодня решил это лайт удалить. И что, undo должен помнить/хранить "от момента создания"? Или как?

@zayats80888 · 14.07.2024, 16:50

Сообщение от Igor3D

Хотя это и мимо темы

Не мимо, а в точку. Ошибка архитектуры и поставила перед вами вопрос темы. Вместо исправления этой ошибки вы хотите вставлять костыли.

Сообщение от Igor3D

1)

Не вижу тут ни обоснования, ни плюсов. Я надеюсь "само использование уникально" это не оно

Сообщение от Igor3D

2)

Ок, наследство приемлемое обоснование. А вот про "рулить толпой лайтов удобно" не понял. Насколько я понял, рулите вы параметрами, а зависимости между лайтами прямые. Как раз не "удобно" и проблемки не "мелкие".

Сообщение от Igor3D

Если это вумный указатель, то он решает только валидность указателя, да и то ценой навязывания shared_ptr

Я говорил только про подсчет ссылок, (валидность и shared_ptr опциональны):

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//Например:
 
class RefCounted {
  // ref, unref
};
 
class Resource : public RefCounted {
  // make_unique/clone, ResourceManger::get_by_id, ...
};
 
class LightParams : public Resource {
  Type a, b, c;
  // set_value_.../get_value_...
};
 
class Light : public Object {
  LightParams *m_params;
  ...
};

И нет никаких master/slave, управление параметрами - это управление параметрами а не зависимостями.

Короче, кроме наследия я обоснований не увидел (а плюсов вообще нет).
Констатируем кривой дизайн и вытекающие из этого проблемы - лечится (если это возможно) "выпрямлением" дизайна, а не костылями.

Сообщение от Igor3D

Год назад он создал лайт. Полгода назад сделал его мастером. Сегодня решил это лайт удалить. И что, undo должен помнить/хранить "от момента создания"?

Нет, undo как раз вероятно не сможет отменить действие полугодовалой давности (хотя ключевое тут не время, а количество выполненных команд, так-то и за полчаса работы можно потерять команды, с которых начинали).
Только не понимаю, как этот ваш вопрос связан с процитированным вами.

З.Ы. Ну и честно говоря, я не вижу смыла для лайтов использовать даже подход с разделяемыми ресурсами, если речь идет о том, чтоб удобно было "рулить группами" в редакторе. Лайтов как правило не много и параметры не "тяжелые" объекты (разве что текстура с проекционным изображением, но её можно и нужно в ресурсы определять). В редакторе групповое редактирование параметров удобнее сделать через паттерн "прототип" или добавить отдельную сущность группы/группового выделения.

Добавлено через 20 минут
Ну а если вы не намерены исправлять дизайн, то, как уже было упомянуто в этой теме, вам нужно для slave объектов организовать подписку на событие удаление master объекта из сцены, в том или ином виде (зависит от того, как у вас там вообще взаимодействие между объектами организованно). А для реализации undo/redo в обработчике такого события сериализовать команду "расцепления" каждого slave с master (идентификацию объектов при сериализации/десериализации удобно делать через глобальный id, а не через указатель, если вы не управляете менеджером памяти).

@Igor3D · 14.07.2024, 18:07 **[ТС]**

Сообщение от zayats80888

Не мимо, а в точку. Ошибка архитектуры и поставила перед вами вопрос темы. Вместо исправления этой ошибки вы хотите вставлять костыли.

Думаю что никому еще не удавалось так быстро/бегло решать вопросы архитектуры

Это вещь на порядок(ки) более сложная чем изложена в стартовом посте. Даже вопросы типа "а как/где это юзается в проекте?" могут потребовать много дней - даже при том что я (пусть не один) много работал с проектом. Что несравнимо затратнее чем начальная задача. Нужно относиться спокойнее/лояльнее и в дебри не лезть. В данном случае.

- что он (я) хочет? Знать какие объекты ссылаются на данный. Это разумный запрос/задача? Безусловно, во всяком случае не полный идиотизм. В каком-то случае можно этой задачи избежать? Может и можно, но стоит ли? Это минимум спорно. Ну и давайте эту задачу решать, не все здесь великие архитекторы

Сообщение от zayats80888

А для реализации undo/redo в обработчике такого события сериализовать команду "расцепления" каждого slave с master

Я об этом и говорю. Но тогда мастер должен знать своих slaves. Как это сделать? Кстати как это решается сейчас (никто не спросил). Тупо, в лоб, просматриваются ВСЕ объекты SomeObjet. Это работает и скорость не такая уж проблема (ну не мульены объектов в сцене), но это коряво. Как лучше?

@zayats80888 · 14.07.2024, 18:43

Сообщение от Igor3D

Думаю что никому еще не удавалось так быстро/бегло решать вопросы архитектуры

Быстро сделать "хорошо" трудно, а бысто понять, что "плохо" легче. Ну а на форуме такие вопросы вообще не решаются.
Я исхожу только из тредоставленной вами ограниченной информации, которую еще и клещами вытаскивать приходится.

Сообщение от Igor3D

Но тогда мастер должен знать своих slaves.

Не знаю, должен ли. Вот вы с Qt знакомы, скажите, соединение сигнал Object::aboutToBeDestroyed() - слот Light::onMasterDestroyed() это разве можно назвать "знанием о slaves"? Нет.

Сообщение от Igor3D

Кстати как это решается сейчас (никто не спросил).

Простите, мы виноваты, master

@Igor3D · 14.07.2024, 20:44 **[ТС]**

Сообщение от zayats80888

которую еще и клещами вытаскивать приходится.

Не то чтобы "я скрываю/утаиваю", но "вдаваться в подробности" совершенно ни к чему. Всякий может рассказывать часами о своем проекте, я не исключение. Ну нагружу (перегружу) я Вас инфой, что с того? В конце-концов вникать в чужую работу никто не обязан. Вопросы/любопытство иссякают, а обсуждение остается бесплодным и глохнет.

Сообщение от zayats80888

Не знаю, должен ли. Вот вы с Qt знакомы, скажите, соединение сигнал Object::aboutToBeDestroyed() - слот Light::onMasterDestroyed() это разве можно назвать "знанием о slaves"? Нет.

Нет, мастер по-прежнему "не в курсе". Но это соединение решает лишь зачистку невалидного указателя при удалении. Маловато будет.

Меня удивляет почему не предлагается самое простое (очевидное, напрашивающееся и.т.п.) решение? Кстати недавно создавал тему "куда ставить ногу" - то же самое. Неужели никто его не видит? Не может такого быть! Или все уже заранее знают что оно плохо? (я нет). Объясните этот эффект

@zayats80888 · 14.07.2024, 21:14

Сообщение от Igor3D

Маловато будет.

А что еще надо? Или эта информация из категории

Сообщение от Igor3D

"вдаваться в подробности" совершенно ни к чему

?
Ну добавьте еще указатель на функцию форматирования диска, "маловато" не покажется

Сообщение от Igor3D

Меня удивляет почему не предлагается самое простое (очевидное, напрашивающееся и.т.п.) решение?

Решение какой проблемы? Самые очевидные и простые решения проблемы в стартовом посте уже предложили.
А для меня лучшее решение проблемы - не создавать проблему вообще.

@Igor3D · 14.07.2024, 21:41 **[ТС]**

Сообщение от zayats80888

Решение какой проблемы? Самые очевидные и простые решения проблемы в стартовом посте уже предложили.

Ну хорошо, а почему не так?

C++
1
2
3
4
5
struct SomeData {
...
 std::vector<SomeObject *> m_clients;
...
};

Хотели знать кто ссылается - ну давайте просто хранить/отслеживать их. Разве это так плохо что не достойно даже упоминания?

@zayats80888 · 14.07.2024, 21:54

Сообщение от Igor3D

Разве это так плохо что не достойно даже упоминания?

Т.е. мы добавляем еще мертвый груз к объекту (slaves его использовать не будут).
Появляется новая проблема отслеживания валидности уже этих указателей.
Т.е. ради всего одной сомнительной фичи "группового руления лайтами" мы параллельно одной иерархии parent/child поддерживаем еще одну кривую(почти полноценную) иерархию master/slave с непонятными взаимоотношениями.
Да, это плохо и не достойно упоминания. Лучше вообще избавится от этих взаимосвязей в реализации объектов.
Если нужно, делайте опосредованно (через общий ресурс) или "над" объкетами.

И, кстати, вам этот вариант предлагали(не напрямую в коде, а через "подписаться на событие", ну и посмотрите типичную реализацию паттерна "наблюдатель"). И если у вас в проекте до сих пор нет механизма взаимодействия между объектами, то в обобщенном виде такую реализацию можно и прикрутить.

Добавлено через 2 минуты
З.Ы. Ну и что там по поводу "маловато"? Будете и дальше "скрывать" чего вам не хватает?

@Igor3D · 15.07.2024, 04:46 **[ТС]**

Сообщение от zayats80888

З.Ы. Ну и что там по поводу "маловато"? Будете и дальше "скрывать" чего вам не хватает?

Если есть контейнер тех кто ссылается на объект - всего хватает

C++
1
2
3
4
5
6
7
8
void Write2Undo( UndoStream & stream, Light * theLight )
{
 ...
 stream.WriteCount(theLight->SlaveCount());
 for (auto * slave : theLight->m_slaves)
   stream.WriteID(slave->GetUniqueID()); 
 ...
}

C++
1
2
3
4
5
6
7
8
9
10
Light::~Light( void )
{ 
 ...
 for (auto * slave : m_slaves)
   slave->SetMaster(nullptr); 
 
 if (masterLight)
  masterLight->RemoveSlave(this);
  ...
}

Не вижу как достичь того же сигналами

Сообщение от zayats80888

делайте опосредованно (через общий ресурс)

А как это?

Сообщение от zayats80888

И если у вас в проекте до сих пор нет механизма взаимодействия между
объектами

Наверное до сих пор нет, т.к. не знаю что за механизм имеется ввиду. Не навязываю своего мнения, но я считаю это "зависимостями" (а не взаимодействиями)

Сообщение от zayats80888

мы параллельно одной иерархии parent/child поддерживаем еще одну кривую(почти полноценную) иерархию master/slave

Не только, там еще с пяток иерархических зависимостей. И что в этом плохого?

@zayats80888 · 15.07.2024, 08:52

Igor3D,

Не вижу как достичь того же сигналами

Не вижу ничего сложного. В любом случае, это не относится к теме и вам надо надо пойти в соответствующий раздел, создать тему по всем правилам, приложить код и спросить "научите сделать то-то".

А как это?

Пьем таблетки от деменции и перечитываем тему, повторяться я смысла не вижу.

Наверное до сих пор нет, т.к. не знаю что за механизм имеется ввиду.

Ну вы же наверняка на qt пишете, там уже все есть, очень мощная и гибкая реализация паттерна наблюдатель в виде сигналов/слотов.

Не только, там еще с пяток иерархических зависимостей. И что в этом плохого?

В иерархиях нет ничего плохого. Плохо то, что вы зашиваете не базовый функционал в реализацию обьекта. Я вам так объясню: например, вы хотите выбирать в редакторе группу объектов и мышкой двигать все вместе, и реализуете это через назначение на время выполнения одной операции одного главного объекта и всех остальных подчинёнными, следующими за главным. И делаете это вот так, как вы делаете - добавлением данных-указателей и логики, которая не имеет отношения к назначению объекта, а призвана решать задачи уровня сцены/проекта/редактора. При том, что у вас уже есть инструменты и механизмы, позволяющие это реализовать не через ж*пу. Если для вас это нормально, то и на здоровье.

Не по теме:

Лишний раз убеждаюсь, что это очередная ваша тема пофлудить.

@Igor3D · 15.07.2024, 19:34 **[ТС]**

Заметим что есть и др подход

C++
1
2
3
4
5
6
// using TUniqueID = uint32;
struct Light {
..
 TUniqueID masterID;
..
};

Ну и получать указатель по/от masterID. Для удаленного мастера вернется null, после выполнения undo мастер опять валиден. Кажется очень заманчивым, но тут свои минусы.

Сообщение от zayats80888

И делаете это вот так, как вы делаете - добавлением данных-указателей и логики, которая не имеет отношения к назначению объекта, а призвана решать задачи уровня сцены/проекта/редактора.

Откуда предположения что я так делаю?

Я хочу обсудить как это лучше делать/сделать, Вы напрасно называете это флудом.

Да, ф-ционал "найти/иметь всех slaves" полезен, но он точно не имеет никакого отношения к классу/функционалу "источник света". Да и дублировать его для каждого из таких ситуаций (а их уже > 20) явно плохо. Кроме того, зависимостей может быть 2 и более (для одного класса). В общем, надо это куда-то "поселить", в классе Light ему точно не место

@zayats80888 · 15.07.2024, 19:54

Сообщение от Igor3D

Откуда предположения что я так делаю?

Эм, вы же сами это написали в 37 посте.

Сообщение от Igor3D

Я хочу обсудить как это лучше делать/сделать, Вы напрасно называете это флудом.

Нет, вы не читаете что вам пишут. Вы сами с собой общаетесь. Наглядно:

Сообщение от Igor3D

И что в этом плохого?

Сообщение от Igor3D

явно плохо

Вы можете дать ссылку на репозиторий с исходным кодом обсуждаемого проекта?

Добавлено через 5 минут
З.ы. Вопрос в заголовке темы давно исчерпан. Вы же продолжаете натягивать сову на глобус, искать какой-то дополнительный функционал... Код так не пишут, стараются придерживаться парадигмы "you aren't gonna need it".

Новые блоги и статьи Все статьи Все блоги /
Вангую, что это не пройдёт модерацию, и на неделе я запущу свой сервер. Hrethgir 19.07.2026 Эта публикация сейчас в песочнице и ждёт приглашения. https:/ / habr. com/ ru/ sandbox/ 295048/ начало и оглавление - Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование. . .	сукцессия 33. открытые вопросы от клауде anaschu 19.07.2026 "Что накопилось за эту часть А — тринадцать правок, из которых шесть пришли из ваших вопросов и каждая оказалась реальной ошибкой, а не калибровкой: односторонний симбиоз, отсутствующий листопад,. . .	32 сукцессия anaschu 19.07.2026 сукцессия 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не «подкручивает» сходимость —. . .	сукцессия 31: модель микоризы - это модель ещё нескольких явлений, социальных и экономических anaschu 18.07.2026 Теория «Всего»: апдейт v1. 1. 2 — 28‑мерное ядро стабилизировано Коллеги, фиксирую разбор инженерных правок и их изоморфную проекцию на экономику, меметику и половой отбор. Модель теперь не. . .
сукцессия 30. Массив проверяющих друг друга моделей anaschu 18.07.2026 Архитектура сети взаимопроверяющих моделей микоризной сукцессии (v2. 0) Развитие тензорного ОДУ-ядра и создание кросс-платформенного калибровочного полигона Уважаемые коллеги! В продолжение. . .	Грибы - это женщины, деревья - это мужчины. Анти инь янь для союза мужчины и женщины. anaschu 18.07.2026 ГЛАВНЫЙ НАУЧНО-ФИЛОСОФСКИЙ ВЫВОД: Сексуально-Репродуктивный Капитализм против Государства Моногамии Коллеги, мы вышли на финишную прямую 20-мерного ОДУ-моделирования вековой сукцессии (ветка. . .	Текстовый слайдер с нумерацией страниц и кроссбраузерность. russiannick 18.07.2026 Один мой друг написал текстовый слайдер с нумерацией страниц. Сегодня я расскажу как он умудрился подружить его с кроссбраузерностью. Очевидно сложно угодить с шириной каждому браузеру. Один крадет. . .	Грибы - это мемы, дерево - это человек. Применение микоризной модели к теории меметики Докинза. anaschu 18.07.2026 Меметический изоморфизм теории «всего»: Грибная сукцессия как модель эволюции идей Докинза Базовый код системы ОДУ микоризной сукцессии описывает не просто биологию, а универсальную. . .