Вам в конструктуре было бы неплохо узнать — а какой, собственно, будет размер «внутренностей» у вашего окна
я может быть туплю, но мне показалось, что вы хотите вызвать в конструкторе виртуальные методы объектов-агрегатов. В этом случае — никаких ограничений. А вот вызов виртуального метода самого объекта из конструктора противоречит просто здравому смыслу, так как предполагает выполнение кода потомка до вызова его конструктора
Использование фабрик и RAII — вещи не конкурирующие, а дополняющие друг друга.
Ну и позволю себе чуток уточнить по вашим пунктам)
1. На самом деле нельзя) Если вы хотите вызвать из конструктора/деструктора виртуальный метод, то вы хотите странного.
2. Альтернатива — предусмотреть неинициализированное состояние объекта и перед использованием проверять, прям как в C. Исключение — удобный механизм, но производительность — соглашусь, хреновая. Но на то оно и исключение, что это именно что исключительная ситуация. А кинете вы исключение из конструктора или из фабрики — не суть важно, в любом случае все недоинициализированное придется так или иначе подчистить.
3. Полностью согласен, если Destroy вызывается не из деструктора какого-нибудь объекта в каком-нибудь фреймворке)
4. Если объект — готовое сетевое соединение, то он собственно уже готов, его осталось обернуть в RAII. Переделать код с синхронного на асинхронный — это все равно все к чертям переписать, и RAII там тоже нужен, но по-другому)
Компиляции тоже нужны, тем более эта выполнена качественно. Мне бы эта статья лет этак 8 назад весьма бы подсократила мой (ныне оставленный) путь C++ программиста
а где тут «ужасающая неэффективность алгоритмов STL» и почему-таки их нельзя использовать? Вижу задачу пересечь 2 несортированных последовательности, и стенания по поводу того, что std::set_intersection эту проблему не решает, но это не является признаком того, что std::set_intersection плох. Возьмите boost::multiindex, ну или std::map+std::list, в конце концов, и std::set_intersection сработает на ура
Уже 7 лет как не рекомендуется почти что официально, и не рекомендовалось долгое время и до того
ага, в плюсах RAII — это, в общем-то, наше все. Кто в плюсах напишет явно delete (ну кроме очень узкого количества случаев), тот, в общем, нехорошо сделает
Вкратце ответ — кому как. Я напишу на баше и уволюсь, придете вы и скажете, что это все г**но и надо на питоне, перепишете на питоне, уволитесь, придет условный Ваня и скажет, что питон г**но и надо на баше, и так далее. И это — нормально.
Кто как хочет — тот так и доставляет себе радость и удовольствие.
Тем более задача — написать, чтоб работало сейчас — обычно более приоритетна надо задачей — чтобы было всем легко читать потом.
Вообще, это скорее повод следующему админу таки раскурить баш. А то мало ли, вдруг воинствующий джавист придет сопроводжать. Давайте для него версию на java напишем, с GOF-ом и интерфейсами.
Так и на баше не rocket science. Ну и по опыту, на баше такие штуки пишутся гораздо быстрее, получаются гораздо короче и оказываются гораздо более надежными. Меньше кода — меньше багов (с). Проще поставить пайп, чем написать лишний if или фильтр/замену по регекспу. Если брать support, то да, код write-only, но он таким и задумывался — решить задачу наименьшими силами и забить.
1. Да, относится. Код показывает, как с помощью простой Future построить эти 2 сущности, с помощью которых был написан пример про виджет.
2. Future выполняют задачу отложенного предоставления результата вычислений. FState позволяет писать асинхронные псевдоалгоритмы с состоянием. AsyncStream позволяет формировать асинхронные последовательности значений.
3. Без Future будет плохо) Без вот этих конкретных FState и AsyncStream мы как-то живем и сейчас
насчет back-pressure, буферизации и прочих нужных вещей не заморачивался, тут чисто построение показано и минимальный api. Предполагается, что тот, кому это нужно, реализует все это в функции-генераторе gen:
def genAsyncStream[S,A](start: S)(gen: S => Future[(A, S)]): AsyncStream[A]
на reactive streams с первого взгляда вроде не очень похоже, akka streams — вроде да)
Только тут не только стримы, еще и stateful async computation до кучи, ну и в связке это все показано
вот это для меня — новость. Пойду гуглить) У нас (сейчас я на scala) хоть и параллелится и асинхронится все влет, но автоматических средств нема
я может быть туплю, но мне показалось, что вы хотите вызвать в конструкторе виртуальные методы объектов-агрегатов. В этом случае — никаких ограничений. А вот вызов виртуального метода самого объекта из конструктора противоречит просто здравому смыслу, так как предполагает выполнение кода потомка до вызова его конструктора
Ну и позволю себе чуток уточнить по вашим пунктам)
1. На самом деле нельзя) Если вы хотите вызвать из конструктора/деструктора виртуальный метод, то вы хотите странного.
2. Альтернатива — предусмотреть неинициализированное состояние объекта и перед использованием проверять, прям как в C. Исключение — удобный механизм, но производительность — соглашусь, хреновая. Но на то оно и исключение, что это именно что исключительная ситуация. А кинете вы исключение из конструктора или из фабрики — не суть важно, в любом случае все недоинициализированное придется так или иначе подчистить.
3. Полностью согласен, если Destroy вызывается не из деструктора какого-нибудь объекта в каком-нибудь фреймворке)
4. Если объект — готовое сетевое соединение, то он собственно уже готов, его осталось обернуть в RAII. Переделать код с синхронного на асинхронный — это все равно все к чертям переписать, и RAII там тоже нужен, но по-другому)
Как-то так)
ага, в плюсах RAII — это, в общем-то, наше все. Кто в плюсах напишет явно delete (ну кроме очень узкого количества случаев), тот, в общем, нехорошо сделает
да тоже то еще счастье)
А не сравнивали ваш подход с бинарным возведением в степень? Там число операций умножения не более чем в 2 раза больше числа бит в m.
Кто как хочет — тот так и доставляет себе радость и удовольствие.
Тем более задача — написать, чтоб работало сейчас — обычно более приоритетна надо задачей — чтобы было всем легко читать потом.
2. Future выполняют задачу отложенного предоставления результата вычислений. FState позволяет писать асинхронные псевдоалгоритмы с состоянием. AsyncStream позволяет формировать асинхронные последовательности значений.
3. Без Future будет плохо) Без вот этих конкретных FState и AsyncStream мы как-то живем и сейчас
Только тут не только стримы, еще и stateful async computation до кучи, ну и в связке это все показано