m
Всем привет!)
Может, кто-то сможет помочь?https://www.sql.ru/forum/1331518/vsem-privet-pomogite-reshit-zadanie?hl=
Size: a a a
2020 December 05
AS
S
Всем привет!)
Может, кто-то сможет помочь?https://www.sql.ru/forum/1331518/vsem-privet-pomogite-reshit-zadanie?hl=
Может, кто-то сможет помочь?https://www.sql.ru/forum/1331518/vsem-privet-pomogite-reshit-zadanie?hl=
AS
Спасибо
AN
Хмм flatbuffers выглядит занятно. Интереснее protobufs, даже вроде для Dart есть(просто предполагается взаимодействие между системами на разных языках) Правда я так понял он тоже использует описания структур(схемы), которые компилятся в код? Усложняет процесс сборки немного.
h
@Antervis вы там спорить начали, а я ушёл.
К чему всё-таки пришли?
Я не хочу сишный вариант, а на плюсах пишу, зачем мне ваш ассемблер))
Я немного не понял, чем такой вариант со статиком плох, если для внутренностей плюсов это не имеет большой разницы, а для меня это понятная структура, когда вместо глобального скоупа, я помещаю методы создания объекта в сам объект, то же, что и namespace создать.
К чему всё-таки пришли?
Я не хочу сишный вариант, а на плюсах пишу, зачем мне ваш ассемблер))
Я немного не понял, чем такой вариант со статиком плох, если для внутренностей плюсов это не имеет большой разницы, а для меня это понятная структура, когда вместо глобального скоупа, я помещаю методы создания объекта в сам объект, то же, что и namespace создать.
АР
@Antervis вы там спорить начали, а я ушёл.
К чему всё-таки пришли?
Я не хочу сишный вариант, а на плюсах пишу, зачем мне ваш ассемблер))
Я немного не понял, чем такой вариант со статиком плох, если для внутренностей плюсов это не имеет большой разницы, а для меня это понятная структура, когда вместо глобального скоупа, я помещаю методы создания объекта в сам объект, то же, что и namespace создать.
К чему всё-таки пришли?
Я не хочу сишный вариант, а на плюсах пишу, зачем мне ваш ассемблер))
Я немного не понял, чем такой вариант со статиком плох, если для внутренностей плюсов это не имеет большой разницы, а для меня это понятная структура, когда вместо глобального скоупа, я помещаю методы создания объекта в сам объект, то же, что и namespace создать.
это не совсем то же самое. Обсуждали малех другое уже, споры ж эволюционируют )
АР
а так классика жанра - делай как больше нравится. Но делать тонкую обертку над make_shared или подобное смысла нет
h
это не совсем то же самое. Обсуждали малех другое уже, споры ж эволюционируют )
ну. почему не то же самое.
Единственная проблема, что это не совсем правильно с точки зрения "идей ооп". Ведь я в объект помещаю что-то, что не описывает его, а относится к нему косвенно, это да
Единственная проблема, что это не совсем правильно с точки зрения "идей ооп". Ведь я в объект помещаю что-то, что не описывает его, а относится к нему косвенно, это да
h
а так классика жанра - делай как больше нравится. Но делать тонкую обертку над make_shared или подобное смысла нет
я делаю эту обертку, чтоб синглтоны создавать.
Я пишу компилятор, и это — классы типов. Для многих типов это действительно тупо обертка.
Но для Int в будущем sized типы буду создавать, и тогда функция
Я пишу компилятор, и это — классы типов. Для многих типов это действительно тупо обертка.
Но для Int в будущем sized типы буду создавать, и тогда функция
Int::make(int size) будет инициализировать разные синглитоны.m
Я правильно понимаю, что не существует string + string_view?
https://stackoverflow.com/a/47735624/2018010
мда. До такой причины я бы не додумался.
мда. До такой причины я бы не додумался.
ПК
я делаю эту обертку, чтоб синглтоны создавать.
Я пишу компилятор, и это — классы типов. Для многих типов это действительно тупо обертка.
Но для Int в будущем sized типы буду создавать, и тогда функция
Я пишу компилятор, и это — классы типов. Для многих типов это действительно тупо обертка.
Но для Int в будущем sized типы буду создавать, и тогда функция
Int::make(int size) будет инициализировать разные синглитоны.для синглтона не нужен shared_ptr
h
для синглтона не нужен shared_ptr
да ту речь вообще не о shared_ptr
тут не паттерн синглтон. тут Тип — Синглтон. С точки зрения объекта в япе
тут не паттерн синглтон. тут Тип — Синглтон. С точки зрения объекта в япе
h
для синглтона не нужен shared_ptr
то есть. это не синглтон для плюсового юзабилити, а синглтон на уровне структуры япа, который описывается. вотс
m
то есть. это не синглтон для плюсового юзабилити, а синглтон на уровне структуры япа, который описывается. вотс
static std::shared_ptr гарантирует что объект будет жить до конца работы программы, поэтому не имеет смысла считать ссылки на объект. Вместо этого можно возвращать raw pointer и хранить объект с помощью static std::unique_ptr. Я допускаю что по каким-то причинам дальше удобнее работать с shared_ptr, но это может означать что проблема в архитектуре.ПК
static std::shared_ptr гарантирует что объект будет жить до конца работы программы, поэтому не имеет смысла считать ссылки на объект. Вместо этого можно возвращать raw pointer и хранить объект с помощью static std::unique_ptr. Я допускаю что по каким-то причинам дальше удобнее работать с shared_ptr, но это может означать что проблема в архитектуре.Да можно просто хранить по значению и возвращать ссылку
D
Да можно просто хранить по значению и возвращать ссылку
Ссылка неудобна, что если мы сделаем так:
auto element = get_singleton();То у нас будет копия
@N
static std::shared_ptr гарантирует что объект будет жить до конца работы программы, поэтому не имеет смысла считать ссылки на объект. Вместо этого можно возвращать raw pointer и хранить объект с помощью static std::unique_ptr. Я допускаю что по каким-то причинам дальше удобнее работать с shared_ptr, но это может означать что проблема в архитектуре.Неверно. Статик может лежать в динамической библиотеке, и деструктор будет вызван при выгрузке библиотеки
ПК
Ссылка неудобна, что если мы сделаем так:
auto element = get_singleton();То у нас будет копия
Будет ошибка компиляции скорее
D
Будет ошибка компиляции скорее
Ну если операции копирования удалены — да