Я — с достаточной точностью знаю. Например, класс для описания соединения с биржей со специальными для HFT финтифлюшками вряд ли будет использован на ESP32.
Обоснуйте. Я не вижу почему этот класс не может быть использован, например, на STM32F7 с гигабайтом PSRAM. Да и вообще на любом CPU без аппаратной поддержки виртуальной памяти.
Если я пишу код под условный gtk+boost+odbc, вряд-ли его сунут в esp32
Почему? Если на STM32F4 работает Qt, то что мешает там же запустить gtk? Да и на ESP32-P4 это технически вполне возможно, так же как и на RP2350.
Ну и "вряд-ли" и "никогда" - несколько разные понятия )))
в эмбеде С++ не то чтобы особо распространен (из экономии)
Вы отстали от жизни. С появлением в МК поддержки до 1 ГБ PSRAM (в STM32F7, для примера) экономия меняется. Тот же STM32CubeIDE C++ поддерживает из коробки.
Впрочем, даже Arduino IDE для восьмибитных MK вполне себе поддерживает C++, хоть и с рядом ограничений. Скетчей на C++ там немеряно.
Я лишь утверждаю, что при написании класса неизвестно, на какой платформе он будет использоваться в будущем. Вы утверждаете обратное. Я же лишь хочу выяснить, на чём основывается такое утверждение )))
С учётом того, что даже на STM32F4, не говоря уже о STM32F7, уже запускали графику под Qt, ситуация далеко не умозрительная.
Откуда это узнать? Вы провидец и точно знаете, какой класс может быть использован в будущем на ESP32 или каком-то ином МК со своими ограничениями, а какой нет?
Ещё раз для тугих. Например, в CH32V003 вообще нет watchpoints. А в ESP32 их только два. Или больше двух свойств/переменых Вам никогда не приходилось мониторить?
Ну если у Вас великолепные навыки пророка и Вы можете уверенно предсказывать будущее, то для Вас ничего не бывает внезапным )))
То есть все свойства надо обвешивать геттерами, на случай их обновления фазрй луны.
Не только. В жизни то 32-х битное целое нужно заменить на 64-битное, то float на decimal, то вообще переменную сделать вычисляемой из нескольких новых, или превратить в объект, поддерживающий NaN и +-Infinity.
Тоже самое. Сегодня это буфер своего кода, а завтра он может модифицироваться обычным DMA, чужим кодом с другого ядра, например, ESP-IDF, или автономным блоком, вроде PIO в RP2040.
Далеко не все МК это поддерживают, или их катастрофически мало. Например, ESP32 поддерживает всего два watchpoints. Тогда как программных breakpoints можно установить неограниченное количество.
А на практике, совсем не редко тупой сеттер превращается, например, в сеттер с семафором или спинлоком. Поэтому на Rust тоже предпочитаю сеттеры, а не прямой доступ к элементам структуры.
пространство локов одно на оба типа наборов аргументов, или они различны
Одно. И это нужно учитывать.
Пользуюсь advisory_lock, но с осторожностью. Для блокировки записей в таблице предпочитаю обходиться без них. В качестве альтернативы for update, использую два поля: время последней модификации записи и spid заблокировавшего процесса. То есть, если последнее поле заполнено и время старта процесса раньше значения первого поля, то запись заблокирована. Иначе - свободна.
Проблема ромба, исключения в рантайме и хрупкое наследование передают привет
Если для Вас это так, то Вы просто не умеете пользоваться OOП.
Каждый выбирает себе сам
Ну вот дайте пример кода so/dll на Rust, манипулирующий с какой-то структурой, который не пришлось бы переписывать при добавлении поля в эту структуру. Тогда как в случае ООП достаточно было бы просто перегрузить несколько методов.
Сравним и написание, и отладку обоих вариантов. Не против?
И какие вы трейты собрались переписывать, когда в трейтах нельзя получить доступ к полю структуры
Типаж это не только его описание, но так же и его имплементация. Они неотделимы.
это ничем не больше чем переписывать теже имплантации в любом ООП языке
За тем исключением, что в ООП можно унаследовать классы, а не переписывать как их, так и код, их использующий. Если в каких то методах класса иногда может потребоваться новый параметр, связанный с новым свойством (полем структуры в Rust), то достаточно перегрузить только эти методы.
Особенно ярко это проблема на Rust проявляется при динамическом связывании.
Почему-то автор рассматривает только написание кода, но не весь его жизненный цикл. ООП при всех его недостатках упрощает и удешевляет развитие программного продукта. А в Rust даже простое добавление нового поля в структуру может потребовать либо дублирования кода, либо массового переписывания трейтов.
Ну это ещё надо умудриться БПЛА всё же поймать направленный луч между домами, разглядеть за оконными стёклами антенны, а потом ещё суметь доказать, что это я не дочке WiFi через окно раздаю в снимаемую ей квартиру. Ну и автоматически гасить сигнал при обнаружении БПЛА за окном на линии сигнала - тоже технически легко реализуемая задача.
Что незаконного в установке WiFi антенны в консервной банке направленной на соседний дом в своей квартире за своим окном? Даже через стекло WiFi с такой антенной полкилометра легко бьёт в прямой видимости.
Коллега, годы опыта с Linux и FreeBSD, как и объём RAM, не имеют прямого отношения к надёжности HDD и SSD.
Как раз имеют. Я тут уже который раз пытаюсь донести мысль о том, что у меня есть вполне обоснованные подозрения, что срок службы SSD и HDD зависит от нагрузки, причем по разному. То есть, при высокой нагрузке, как в серверном профиле, SSD могут выиграть у HDD по сроку службы в разы, что я и наблюдаю в наших ЦОД. Но при низкой нагрузке, как при домашнем использовании, энтропия делает своё дело и на горизонте в десятки лет можем увидеть совсем другие соотношения.
Linux и FreeBSD позволяют из коробки существенно снизить нагрузку на дисковую подсистему, тогда как добиться того же в Windows домашнему пользователю намного сложнее. И тем более на эту нагрузку влияет объем RAM.
По поводу Backblaze: они как раз используют массовые модели дисков и их выборки на порядки больше наших.
При чём тут модели и выборки, если профиль использования дисков у них в ЦОД радикально отличается от профиля домашнего пользователя?
Ни мой ни ваш опыт личного использования сам по себе ни о чём не говорит, так просто сложились звёзды.
Как я уже писал дважды - будет говорить через 20 лет, когда накопится опыт использования так же хотя бы нескольких десятков SSD в течении 30 лет. А сейчас да, имеем возможность утверждать, что имеем десятки живых HDD с возрастом свыше 20 лет и несколько SSD возрастом менее 10 лет. Как это сравнивать, если многие производители заявляют, что срок службы их SSD как раз в пределах 10 лет?
Обоснуйте. Я не вижу почему этот класс не может быть использован, например, на STM32F7 с гигабайтом PSRAM. Да и вообще на любом CPU без аппаратной поддержки виртуальной памяти.
Почему? Если на STM32F4 работает Qt, то что мешает там же запустить gtk? Да и на ESP32-P4 это технически вполне возможно, так же как и на RP2350.
Ну и "вряд-ли" и "никогда" - несколько разные понятия )))
Вы отстали от жизни. С появлением в МК поддержки до 1 ГБ PSRAM (в STM32F7, для примера) экономия меняется. Тот же STM32CubeIDE C++ поддерживает из коробки.
Впрочем, даже Arduino IDE для восьмибитных MK вполне себе поддерживает C++, хоть и с рядом ограничений. Скетчей на C++ там немеряно.
Я лишь утверждаю, что при написании класса неизвестно, на какой платформе он будет использоваться в будущем. Вы утверждаете обратное. Я же лишь хочу выяснить, на чём основывается такое утверждение )))
С учётом того, что даже на STM32F4, не говоря уже о STM32F7, уже запускали графику под Qt, ситуация далеко не умозрительная.
В случае свойства - жду Ваших предложений.
В случае геттера, какой тип он возвращал, такой и будет возвращать, выполняя преобразование типов по наиболее подходящему в данном случае алгоритму.
Откуда это узнать? Вы провидец и точно знаете, какой класс может быть использован в будущем на ESP32 или каком-то ином МК со своими ограничениями, а какой нет?
Да, удобнее. Но не вместо одного свойства, а вместо 100500 мест, где к этому свойству обращались.
Ещё раз для тугих. Например, в CH32V003 вообще нет watchpoints. А в ESP32 их только два. Или больше двух свойств/переменых Вам никогда не приходилось мониторить?
Ну если у Вас великолепные навыки пророка и Вы можете уверенно предсказывать будущее, то для Вас ничего не бывает внезапным )))
Не только. В жизни то 32-х битное целое нужно заменить на 64-битное, то float на decimal, то вообще переменную сделать вычисляемой из нескольких новых, или превратить в объект, поддерживающий NaN и +-Infinity.
Тоже самое. Сегодня это буфер своего кода, а завтра он может модифицироваться обычным DMA, чужим кодом с другого ядра, например, ESP-IDF, или автономным блоком, вроде PIO в RP2040.
Далеко не все МК это поддерживают, или их катастрофически мало. Например, ESP32 поддерживает всего два watchpoints. Тогда как программных breakpoints можно установить неограниченное количество.
А на практике, совсем не редко тупой сеттер превращается, например, в сеттер с семафором или спинлоком. Поэтому на Rust тоже предпочитаю сеттеры, а не прямой доступ к элементам структуры.
Одно. И это нужно учитывать.
Пользуюсь advisory_lock, но с осторожностью. Для блокировки записей в таблице предпочитаю обходиться без них. В качестве альтернативы for update, использую два поля: время последней модификации записи и spid заблокировавшего процесса. То есть, если последнее поле заполнено и время старта процесса раньше значения первого поля, то запись заблокирована. Иначе - свободна.
Если для Вас это так, то Вы просто не умеете пользоваться OOП.
Ну вот дайте пример кода so/dll на Rust, манипулирующий с какой-то структурой, который не пришлось бы переписывать при добавлении поля в эту структуру. Тогда как в случае ООП достаточно было бы просто перегрузить несколько методов.
Сравним и написание, и отладку обоих вариантов. Не против?
Типаж это не только его описание, но так же и его имплементация. Они неотделимы.
За тем исключением, что в ООП можно унаследовать классы, а не переписывать как их, так и код, их использующий. Если в каких то методах класса иногда может потребоваться новый параметр, связанный с новым свойством (полем структуры в Rust), то достаточно перегрузить только эти методы.
Особенно ярко это проблема на Rust проявляется при динамическом связывании.
Почему-то автор рассматривает только написание кода, но не весь его жизненный цикл. ООП при всех его недостатках упрощает и удешевляет развитие программного продукта. А в Rust даже простое добавление нового поля в структуру может потребовать либо дублирования кода, либо массового переписывания трейтов.
Вы очень заблуждаетесь, считая не направленной антенну из консервных банок. Даже из одной.
На расстоянии в несколько десятков метров, для чего и потребуется БПЛА
С чего это вдруг?
Чего? Консервных банок или обычного WiFi роутера, продающегося на каждом углу?
Ну это ещё надо умудриться БПЛА всё же поймать направленный луч между домами, разглядеть за оконными стёклами антенны, а потом ещё суметь доказать, что это я не дочке WiFi через окно раздаю в снимаемую ей квартиру.
Ну и автоматически гасить сигнал при обнаружении БПЛА за окном на линии сигнала - тоже технически легко реализуемая задача.
Что незаконного в установке WiFi антенны в консервной банке направленной на соседний дом в своей квартире за своим окном? Даже через стекло WiFi с такой антенной полкилометра легко бьёт в прямой видимости.
А почему обязательно предпринимательство? Просто MESH сети с самым произвольным транспортом, как в Reticulum.
Просто свинцово-кислотные АКБ требуют обслуживания. А на халяву, и уксус сладкий )
Через шесть(!) лет они и часа уже не тянут, несмотря на ежегодную десульфатацию, но у меня следующие есть на подходе )
Как раз имеют. Я тут уже который раз пытаюсь донести мысль о том, что у меня есть вполне обоснованные подозрения, что срок службы SSD и HDD зависит от нагрузки, причем по разному. То есть, при высокой нагрузке, как в серверном профиле, SSD могут выиграть у HDD по сроку службы в разы, что я и наблюдаю в наших ЦОД. Но при низкой нагрузке, как при домашнем использовании, энтропия делает своё дело и на горизонте в десятки лет можем увидеть совсем другие соотношения.
Linux и FreeBSD позволяют из коробки существенно снизить нагрузку на дисковую подсистему, тогда как добиться того же в Windows домашнему пользователю намного сложнее. И тем более на эту нагрузку влияет объем RAM.
При чём тут модели и выборки, если профиль использования дисков у них в ЦОД радикально отличается от профиля домашнего пользователя?
Как я уже писал дважды - будет говорить через 20 лет, когда накопится опыт использования так же хотя бы нескольких десятков SSD в течении 30 лет. А сейчас да, имеем возможность утверждать, что имеем десятки живых HDD с возрастом свыше 20 лет и несколько SSD возрастом менее 10 лет. Как это сравнивать, если многие производители заявляют, что срок службы их SSD как раз в пределах 10 лет?