1. Аргументы: тут соглашусь, распарсить и провалидировать их отдельно — всегда плюс.
2. Функциональное программирование: код, нарезанный на функции, не становится ФП. У фп есть строгое (математическое) определение. Для описанного случая есть другой термин — процедурное программирование.
Для этого, конечно, пришлось подключить DI.
«Конечно», «пришлось» — сфига ли? Можно и без
3. Логи
Ну и? Что изменилось-то? Со стороны пользователя — примерно ничего, а то, что реализация была кривая, так это другой вопрос. Более того, новый логгер тоже имеет свои (другие) проблемы (left as an exercise for the reader)
4. Универсальные классы
Да, это беда. Но итог кажется как «из огня да в полымя»: Стало: 200+ файлов, где единицы размером по 300+ строк.
Если из 200+ файлов только единицы содержат какое-то осознанное количество кода, то значит появилось 190+ файлов, в которых код нарезан на карпаччо, где каждый класс и его метод просто передаёт ответственность дальше.
5. Репозитории — ок
6. Асинхронность — ок
7. Исключения — ок
8. Предупреждения — не поспоришь
9. Провайдеры — ничего не скажу, надо смотреть код, может быть овер-абстракцией, а может и очень полезным.
10. Структура файлов — да, dynamic зло, и если нет схемы, то придётся жевать dictionary
11. Методы в классах — в целом да, у меня есть претензия, но она не к автору, а в целом к текущему подходу к POD-классам, так что тут всё ок.
12. Помощники и расширения — шило на мыло, вкусовщина
13. Константы: > Это очень плохо: занимает лишнюю память ШТА????!!!11 какую память и где?
Но подход с заменой магических строк на константы полезен с другой стороны — не будет ошибок, вызванных опечатками. И будет проще их потом менять.
14. Запросы к БД. Поля
А JOIN для кого сделан? В примере кошмар-какой SQL заменён на просто плохой SQL
15. Запросы к БД. Повторы
Если есть что-то очень константное, то оно должно быть или совсем константным, или его надо оставить на стороне SQL.
16. Запросы к БД. Существование
ШТОЯТОЛЬКОЧТОПРОЧИТАЛ???? Изучите хотя-бы одну книгу по работе с БД
17. Конкатенация строк — да, всё верно
18. Зависимости:
не вызывает проблем в функциональном подходе
в настоящем ФП как раз надо сильно постараться, чтобы получить циклические зависимости. Но как выше было написано, у вас тут не ФП
во-первых, давление с обеих сторон трубки будет одинаковое (см конструкцию батискафа), во-вторых, никто не заставляет делать их вертикально и получать реактивную тягу (хотя, если аккуратно посчитать гамильнониан, то её там не будет, это всё бред)
А как вариант, можно же через баки с бензином пропустить трубки теплообменника с внешней водой (опционально, ещё и с насосами)? Тогда и проблемы такой не будет...
1-wire это вполне определённый патентованный протокол DS. Там тоже передача по одному проводу, но протокол другой. Есть ещё лампочки с 4-мя проводами, там вполне православный SPI
рациональный компромисс — выбрали C++14, чтобы сохранить совместимость со старыми системами, которые до сих пор живут в корпоративных сетях
А в чём собственно проблема? Мы вот до сих пор собираем и запускаем бинарники под Ubuntu (прости господи) 14.04 (не спрашивайте), но используем свежий гцц и c++23. Проблем не было, кроме того, что гцц из исходников собрать пришлось.
Изучите, как работает CLR, удивитесь
Ну ок, по пунктам:
1. Аргументы: тут соглашусь, распарсить и провалидировать их отдельно — всегда плюс.
2. Функциональное программирование: код, нарезанный на функции, не становится ФП. У фп есть строгое (математическое) определение. Для описанного случая есть другой термин — процедурное программирование.
«Конечно», «пришлось» — сфига ли? Можно и без
3. Логи
Ну и? Что изменилось-то? Со стороны пользователя — примерно ничего, а то, что реализация была кривая, так это другой вопрос. Более того, новый логгер тоже имеет свои (другие) проблемы (left as an exercise for the reader)
4. Универсальные классы
Да, это беда. Но итог кажется как «из огня да в полымя»: Стало: 200+ файлов, где единицы размером по 300+ строк.
Если из 200+ файлов только единицы содержат какое-то осознанное количество кода, то значит появилось 190+ файлов, в которых код нарезан на карпаччо, где каждый класс и его метод просто передаёт ответственность дальше.
5. Репозитории — ок
6. Асинхронность — ок
7. Исключения — ок
8. Предупреждения — не поспоришь
9. Провайдеры — ничего не скажу, надо смотреть код, может быть овер-абстракцией, а может и очень полезным.
10. Структура файлов — да, dynamic зло, и если нет схемы, то придётся жевать dictionary
11. Методы в классах — в целом да, у меня есть претензия, но она не к автору, а в целом к текущему подходу к POD-классам, так что тут всё ок.
12. Помощники и расширения — шило на мыло, вкусовщина
13. Константы: > Это очень плохо: занимает лишнюю память
ШТА????!!!11 какую память и где?
Но подход с заменой магических строк на константы полезен с другой стороны — не будет ошибок, вызванных опечатками. И будет проще их потом менять.
14. Запросы к БД. Поля
А JOIN для кого сделан? В примере кошмар-какой SQL заменён на просто плохой SQL
15. Запросы к БД. Повторы
Если есть что-то очень константное, то оно должно быть или совсем константным, или его надо оставить на стороне SQL.
16. Запросы к БД. Существование
ШТОЯТОЛЬКОЧТОПРОЧИТАЛ???? Изучите хотя-бы одну книгу по работе с БД
17. Конкатенация строк — да, всё верно
18. Зависимости:
в настоящем ФП как раз надо сильно постараться, чтобы получить циклические зависимости. Но как выше было написано, у вас тут не ФП
Простите, конечно, за негатив. Но после прочтения статьи у меня сложилось мнение, что вы тоже не очень-то хорошо знаете этот язык :(
Я вот на 0.14 сижу и доволен ;) Ну либо автор написал код какое-то время назад, а статью только сейчас.
например, что курил автор
смотря какой фабрик, смотря сколько дитейлз
во-первых, давление с обеих сторон трубки будет одинаковое (см конструкцию батискафа), во-вторых, никто не заставляет делать их вертикально и получать реактивную тягу (хотя, если аккуратно посчитать гамильнониан, то её там не будет, это всё бред)
А как вариант, можно же через баки с бензином пропустить трубки теплообменника с внешней водой (опционально, ещё и с насосами)? Тогда и проблемы такой не будет...
А можете рассказать, что это такое? Я не очень понимаю, кажется, у меня неверные представления
Инсталлятор и будет тем самым одиноким exe, вы его запустите, а потом саму программу...
Их мечта "You will own nothing and be happy"
О да! Моя история начиналась ещё с советских паялок, потом переход на 900-ю серию был просто революционным прорывом!
Потом так же, Т12 стала новой эрой по сравнению с 900, а потом — с т12 на с245 снова шаг в новую эру.
Жду не дождусь, что ещё нового придумают, и когда мы шагнём в эту новую эпоху :)
P.S.: фен я всё-же предпочитаю в виде отдельного устройства...
massgrave.devА может знает кто-нибудь, что-то похожее для перенаправления голосовых звонков существует?
1-wire это вполне определённый патентованный протокол DS. Там тоже передача по одному проводу, но протокол другой. Есть ещё лампочки с 4-мя проводами, там вполне православный SPI
Можно, в гугловом есть экспорт, у микрософта тоже должен быть
Я его просто сразу в uBlock занёс, а то из-за этой кнопки небольшие блоки с кодом распирает, читать тяжело
А куда пропали ещё четыре «оператора» 0101, 1010, 1100 и 0011?
А в чём собственно проблема? Мы вот до сих пор собираем и запускаем бинарники под Ubuntu (прости господи) 14.04 (не спрашивайте), но используем свежий гцц и c++23. Проблем не было, кроме того, что гцц из исходников собрать пришлось.
там же видно, что не r-2r, а binary-weighted