Size: a a a

2020 May 25

YM

Yaroslav M in pro.cxx
Artöm Bakri Al-Sarmini
Не вижу проблемы этого кода
сомнения в том, что когда подкласс передаешь в аргумент типа базового, всё в порядке
но не соображу что происходит если возвращать значения типа сабкласса
+ непонятно это override метода будет, если так обходиться с типом возвращаемого, или же это так же легально как и с типом аргумента
источник

АК

Александр Караев... in pro.cxx
Dr Zlo
А принимать AbstractDisplay в кач-ве аргумента как?
сделать ещё один уровень наследования, если нужен нешаблонный интерфейс
источник

AB

Artöm Bakri Al-Sarmi... in pro.cxx
Yaroslav M
сомнения в том, что когда подкласс передаешь в аргумент типа базового, всё в порядке
но не соображу что происходит если возвращать значения типа сабкласса
+ непонятно это override метода будет, если так обходиться с типом возвращаемого, или же это так же легально как и с типом аргумента
Делать базу абстрактной, что в плюсах, что в питоне
источник

D

Dr Zlo in pro.cxx
Danya
Через шаблон
Можно пример? Я только разбираюсь во всем этом.
источник

YM

Yaroslav M in pro.cxx
ребят спасибо, теперь разобрался
источник

АК

Александр Караев... in pro.cxx
Dr Zlo
мне нужно чтобы итоговый массив лёг в bss, а не в heap
зачем?
источник

D

Danya in pro.cxx
Блин, ну аналогично:
template <typename D>
void foo(D display) {
static_assert(std::is_base_of<AbstractDisplay<D::width, D::height>, D>::value);
....
}
источник

D

Dr Zlo in pro.cxx
Микроконроллеры.
источник

D

Danya in pro.cxx
Dr Zlo
Можно пример? Я только разбираюсь во всем этом.
В принципе, если все реализовывать всё на шаблонах, то тебе не нужно даже делать класс полиморфным — что сделает работу с твоими дисплеями быстрее, потому что не будет лишнего пропрыга по vtable
источник

D

Danya in pro.cxx
Минус у такого подхода в том, что код становится скорее сложнее
И скорее всего сгенерится больше байтиков, потому что для каждого варианта дисплея будет генериться новый код (но только если он используется)
источник

АК

Александр Караев... in pro.cxx
Dr Zlo
Микроконроллеры.
тогда решать проблему нужно на абсолютно ином уровне - на уровне аллокаторов
источник

D

Danya in pro.cxx
Danya
В принципе, если все реализовывать всё на шаблонах, то тебе не нужно даже делать класс полиморфным — что сделает работу с твоими дисплеями быстрее, потому что не будет лишнего пропрыга по vtable
Но тип ты должен знать на этапе компиляции, то есть (например) не получится создать дисплей из аргументов командной строки и потом его использовать в шаблонном коде
источник

DS

Dolphin Soft in pro.cxx
Александр Караев
тогда решать проблему нужно на абсолютно ином уровне - на уровне аллокаторов
при чем тут аллокаторы, когда ему конфиги нужно определять на этапе компиляции?
источник

АК

Александр Караев... in pro.cxx
Dolphin Soft
при чем тут аллокаторы, когда ему конфиги нужно определять на этапе компиляции?
скорее всего это первая необходимость в динамической памяти, за ней последует вторая, третья.. и отнюдь не везде можно будет обойтись конфигами на этапе компиляции.
нет смысла городить шаблоны на шаблонах, если можно решить сразу все проблемы аллокатором, который ходит в bss сам
источник

DS

Dolphin Soft in pro.cxx
Тебе же говорят, нужно держать в программной памяти
источник

DS

Dolphin Soft in pro.cxx
в прошивке, а не в SRAM
источник

АК

Александр Караев... in pro.cxx
Dolphin Soft
в прошивке, а не в SRAM
я об этом и говорю.
заранее выделить пул памяти на этапе компиляции + сделать аллокатор на ней
источник

D

Dr Zlo in pro.cxx
Danya
В принципе, если все реализовывать всё на шаблонах, то тебе не нужно даже делать класс полиморфным — что сделает работу с твоими дисплеями быстрее, потому что не будет лишнего пропрыга по vtable
Да, мне уже сложно и не нравится как выглядит код.
источник

D

Dr Zlo in pro.cxx
Dolphin Soft
в прошивке, а не в SRAM
в SRAM, просто не в куче
источник

D

Dr Zlo in pro.cxx
но я уже свыкся с мыслью что либо красиво и в куче, либо некрасиво и в bss
источник