Пример с платформами совсем неудачный. Там и бинарники по-разному собираются. Скорее всего, с базами данных пример лучше. Но опять же, так ли часто нужно работать в приделах одного приложения с разными базами?
ну, мне еще никогда не приходилось писать приложение, которое работает на таком зоопарке сразу. и даже пробовать не буду. тут одного андройда хватает, чтобы крышу снесло.
Вот с GUI делать что-то автоматически я бы точно не стал. Мне часто приходится писать приложения, которые должны обрабатывать много информации и что-то иногда выводить на экран пользователю. И, как правило, данные поставляет устройство (железка), которая может и отвалиться… И тут начинается. Возможно сейчас меня закидают помидорами (я готов это пережить), но чаще всего обновление экрана не нужно делать автоматически. Если данные появляются часто, то я обычно делаю для их вывода на экран таймер, который раз в несколько сотен миллисекунд просматривает, что можно обновить и обновляет.
Когда я писал комментарий выше, не надеялся на развернутый ответ. В чем тут развитие? Паттерн фабрики известен с начала 90-х. Было бы интересно, чем подход с использованием фабрик лучше просто передачи функции в качестве параметра? Может производительность системы от этого возрастет, или станет код проще поддерживать. По маленькому абстрактному примеру очень сложно понять — насколько оправдан этот подход. Есть ли у него недостатки? И да, синглтонами я тоже не пользуюсь. Знаю одно — что универсальные вещи плохо работают.
самый опасный инструмент — это тот, о который нельзя порезаться. значит он просто тупой. и травму получить им гораздо легче (хотя бы потому, что приходится прилагать больше усилий). в детстве пилил пилой (как на третьей картинке сверху) — это был просто ад.
давным-давно делали детектор бар кодов (причем без нейронных сетей). так самой большой проблемой был не поворот, а перспектива. даже не знаю, какие современный детекторы нормально работают при наклонном изображении.
Чем дальше улучшают язык с++, тем больше он становится языком для машин, а не для людей. К моему большому сожалению, текст программ на современных плюсах все сложнее читать.
когда программист пытается сравнить не сравнимые объекты.
Этот момент я не совсем понял. Т.е. компилятор не сможет понять, что в аргумент функции передан другой тип? Или проблема заключается в том, что класс-наследник может иметь отличные операции сравнения?
А почему нельзя сделать так, чтобы компилятор всегда по умолчанию генерировал код с дефолтным поведением для операций сравнения? Тогда строчка auto operator<=>(const Basics&) const = default; ненужна. А если нужно все-таки, чтобы сравнения были «нестандартными», то тогда и переопределять операции. Или в этом есть потаённый смысл?
сименс слишком большая компания и они могут себе это позволить. а вот небольшая компания вряд ли. пусть станок небольшой вместе с электроэнергией стоит что-нибудь около 500 млн. долларов. плюс работа токарей, шлифовка и т.д. за сколько времени даже диски окупятся?
а для печати такого специфичного продукта как турбины обойдется еще дороже. не забывайте, что у лазера очень маленький кпд. и печать затратит уйму времени. кроме этого установки надо часто обслуживать.
а кто вызывает doIt?
Этот момент я не совсем понял. Т.е. компилятор не сможет понять, что в аргумент функции передан другой тип? Или проблема заключается в том, что класс-наследник может иметь отличные операции сравнения?
а для печати такого специфичного продукта как турбины обойдется еще дороже. не забывайте, что у лазера очень маленький кпд. и печать затратит уйму времени. кроме этого установки надо часто обслуживать.