Я сказал "интересная", а не "неправильная" ) Это скорее вопрос.
Ну вот смотрите, диспозиция такая, что у вас была проблема в том, чтобы совместить поудобнее парные вкладки - .h & .cpp, так? Причем это не разовая проблема, а частая, иначе не стали бы заморачиваться.
При этом смысл выноса в отдельные xxx.h & xxx.cpp в том, чтобы создать некие "библиотечные функции", чтобы один раз написать их тут, а потом подключать и использовать везде где надо, подключив xxx.h Ну, вроде так.
При этом .h - описание функций, констант, классов, структур, а .cpp - их реализация. Править сразу два файла - логично, понятно, когда делается реализация. Но тогда на кой черт открывать остальные файлы - это непонятно.
Вот реализация готова, вы подключаете в свой main.cpp библиотеку xxx.h, там какая-то хитрозамудренная функция в классе, которую хорошо бы видеть глазами чтобы ничего не перепутать с вызовом - тут тоже понятно. Но тогда на кой черт открывать xxx.cpp, если оно уже написано, проверено и работает?
Если это "вам так хочется" - это ваше дело, значит вам так хочется. Но вопрос про VS - выглядит так, как будто именно так и должна выглядеть работа: одновременно открытые разные модули, где человек пишет сразу и код библиотеки (xxx.h & xxx.cpp), и код, использующий эту библиотеку (main.cpp) и еще что-то сразу где-то. Может быть полезно для портирования кода, включая библиотеки, для поиска странных багов в кривых библиотеках, но зачем это для нормальной работы?
Причем, вам это поведение VS мешает - потому что парные файлы попадают неудобно из-за остальных, вон даже доработку пришлось сделать.
Вот это и есть вопрос: в VS все так работают? Это удобно (похоже - нет) или это "преодоление неудобств", потому что так здесь заведено?
Причина вроде бы в сети, но на самом деле не в сети: в интернете никто и никогда не гарантировал отсутствие проблем с сетью. По умолчанию проблемы с сетью обязательно есть!
А вот забота софта - их не замечать. Если проблема битых пакетов на роутере приводит к жору памяти браузером - это кривизна либо реализации браузера, либо кривизна логики работы ПО.
Шел примерно 1980 год. В журнале (не помню каком) была разгромная статья про современную молодежь, которая слушает музыку (отвратительную современную музыку, всякий там рок и диско!) в наушниках, из-за чего непременно глохнет, а заодно и отупеет.
2026 год. Современная молодежь слушает музыку в наушниках ... ( ну и далее по тексту )
Ну, конкретно голосовое управление лично я не люблю, все должно работать молча - но управление со смартфона - иногда штука нужная. Был такой период, когда включить свет кнопкой на телефоне было быстрее, проще и приятнее, чем пытаться достать до выключателя.
А так, конечно - и выключатель и смартфон должны работать. Та же esp прекрасно обработает и замыкание контактов, и команду по wifi-mqtt, и включит ssr типа omron на 2А - вполне достаточно для обычных ламп со светодиодами.
Ну или ещё лайфхак: если взять "умное реле" типа tuya с wifi (не ZigBee) - в нем сравнительно несложно заменить штатный модуль на esp8266, а ту в свою очередь прошить под свою прошивку. Получим сразу компактный размер, встроенный блок питания, встроенное реле и готовые контакты для дублирующего выключателя.
Перемычки бывает теряют гальванический контакт, да и двигать их со смартфона сложно. О чем и речь.
А насчёт моноколеса - это вообще надо в комплексе оценивать, потому что если на той же лиферной ячейке почему-то будет 4.25, неважно почему - это ненамного лучше чем мордой об асфальт, только не так резко.
Такое допускать нельзя вообще, и решается это не предохранителем-bms, а продумыванием конструкции в целом, включая вопрос "что делать если батарейка вдруг исчезла".
А вот тут мы его поругаем: gimp в однооконном режиме работает тормознее чем в многооконном.
Тот же самый gimp той же версии - это просто галочка в настройке - но в однооконном он ощутимо подтормаживает. Вот такой интересный баг.
А так, в общем-то, многооконность хоть и напоминает Дельфи, но не сильно мешает, особенно в двухмониторной конфигурации, когда можно все управление вынести в сторону. Но это да, на любителя
"доводит информацию в части касающейся" - вполне официальная формулировка, означающая что распоряжение до вас довели, а причины для служебного пользования.
Когда Фотошоп и Офис продаются вместе с ОС на одном диске за 60 рублей - они просто не могут не стать самыми распространенными и привычными инструментами.
Сейчас и вовсе на торрентах можно скачать нахаляву.
Там даже не в спеках дело. Если составить график заряда-разряда батареи или ячейки - на нем очень хорошо видно как раз вот эту плоскую полку и резкие "хвосты" вверх-вниз.
То есть, при заряде вы набираете условно 98% емкости - а потом напряжение прёт вверх, приходится ограничивать. При разряде наоборот, вы расходуете всю ёмкость, и в последний момент происходит резкое сваливание - ну можно вместо 12.7 разрядить до 11.2, но это даст дополнительно всего 1-2% заряда, это уже падающая ветка.
У лифера очень плоская рабочая "полка" - 3.3 на ячейку норм, 3.2 - почти разряжена. Верхний предел - 3.6, больше он портится.
Вот и считайте, 4 ячейки - 14.4, больше НЕ НАДО, может потечь или раздуться. За этим и должна BMS следить. 13.2 - вполне достаточно для заряда. 12.8 - можно уже выключать, там процентов 3-5 осталось от заряда.
Я сказал "интересная", а не "неправильная" )
Это скорее вопрос.
Ну вот смотрите, диспозиция такая, что у вас была проблема в том, чтобы совместить поудобнее парные вкладки - .h & .cpp, так?
Причем это не разовая проблема, а частая, иначе не стали бы заморачиваться.
При этом смысл выноса в отдельные xxx.h & xxx.cpp в том, чтобы создать некие "библиотечные функции", чтобы один раз написать их тут, а потом подключать и использовать везде где надо, подключив xxx.h
Ну, вроде так.
При этом .h - описание функций, констант, классов, структур, а .cpp - их реализация.
Править сразу два файла - логично, понятно, когда делается реализация.
Но тогда на кой черт открывать остальные файлы - это непонятно.
Вот реализация готова, вы подключаете в свой main.cpp библиотеку xxx.h, там какая-то хитрозамудренная функция в классе, которую хорошо бы видеть глазами чтобы ничего не перепутать с вызовом - тут тоже понятно.
Но тогда на кой черт открывать xxx.cpp, если оно уже написано, проверено и работает?
Если это "вам так хочется" - это ваше дело, значит вам так хочется.
Но вопрос про VS - выглядит так, как будто именно так и должна выглядеть работа: одновременно открытые разные модули, где человек пишет сразу и код библиотеки (xxx.h & xxx.cpp), и код, использующий эту библиотеку (main.cpp) и еще что-то сразу где-то.
Может быть полезно для портирования кода, включая библиотеки, для поиска странных багов в кривых библиотеках, но зачем это для нормальной работы?
Причем, вам это поведение VS мешает - потому что парные файлы попадают неудобно из-за остальных, вон даже доработку пришлось сделать.
Вот это и есть вопрос: в VS все так работают? Это удобно (похоже - нет) или это "преодоление неудобств", потому что так здесь заведено?
Некоторые считают важным, чтобы вовремя включать увлажнитель и доводить до "нормы".
Некоторым это даже реально помогает - а значит имеет право на жизнь
Интересная организация работы с кодом )
Это все так в VS делают?
Причина вроде бы в сети, но на самом деле не в сети: в интернете никто и никогда не гарантировал отсутствие проблем с сетью. По умолчанию проблемы с сетью обязательно есть!
А вот забота софта - их не замечать. Если проблема битых пакетов на роутере приводит к жору памяти браузером - это кривизна либо реализации браузера, либо кривизна логики работы ПО.
Как-то так
Шел примерно 1980 год. В журнале (не помню каком) была разгромная статья про современную молодежь, которая слушает музыку (отвратительную современную музыку, всякий там рок и диско!) в наушниках, из-за чего непременно глохнет, а заодно и отупеет.
2026 год. Современная молодежь слушает музыку в наушниках ... ( ну и далее по тексту )
Если с человеком не по пути - то пусть сразу и уходит.
А если по пути... У меня когда-то компьютер через скрытый динамик "отбивал" часы, звуком колокола из Hexen. Было встречено с пониманием.
Ну, конкретно голосовое управление лично я не люблю, все должно работать молча - но управление со смартфона - иногда штука нужная. Был такой период, когда включить свет кнопкой на телефоне было быстрее, проще и приятнее, чем пытаться достать до выключателя.
А так, конечно - и выключатель и смартфон должны работать. Та же esp прекрасно обработает и замыкание контактов, и команду по wifi-mqtt, и включит ssr типа omron на 2А - вполне достаточно для обычных ламп со светодиодами.
Ну или ещё лайфхак: если взять "умное реле" типа tuya с wifi (не ZigBee) - в нем сравнительно несложно заменить штатный модуль на esp8266, а ту в свою очередь прошить под свою прошивку. Получим сразу компактный размер, встроенный блок питания, встроенное реле и готовые контакты для дублирующего выключателя.
Больше напоминает прогрев аудитории перед полным переходом к белым спискам по иранской модели.
Обозначили проблему - окошмарили - предложили решение! Всё по учебнику. Ради защиты от хакеров, мошенников и безопасности детей.
А потом торговать местами в белом списке и доступом к "коммуникационной амбразуре" (кто помнит откуда это)
Допустим, а что это даст?
Ну "робот Вася", и что? Чем это лучше "ООО Важный звонок, предлагаем вам потратить деньги"?
Select - block user - OK
Перемычки бывает теряют гальванический контакт, да и двигать их со смартфона сложно. О чем и речь.
А насчёт моноколеса - это вообще надо в комплексе оценивать, потому что если на той же лиферной ячейке почему-то будет 4.25, неважно почему - это ненамного лучше чем мордой об асфальт, только не так резко.
Такое допускать нельзя вообще, и решается это не предохранителем-bms, а продумыванием конструкции в целом, включая вопрос "что делать если батарейка вдруг исчезла".
Боюсь, не пойдут ли они по пути других окологосударственных структур: если плохо будут брать - запретят дешёвые смартфоны без рекламы вообще.
Ну, какой-нибудь цифровой сбор тысяч на 40...
А вот тут мы его поругаем: gimp в однооконном режиме работает тормознее чем в многооконном.
Тот же самый gimp той же версии - это просто галочка в настройке - но в однооконном он ощутимо подтормаживает. Вот такой интересный баг.
А так, в общем-то, многооконность хоть и напоминает Дельфи, но не сильно мешает, особенно в двухмониторной конфигурации, когда можно все управление вынести в сторону. Но это да, на любителя
"доводит информацию в части касающейся" - вполне официальная формулировка, означающая что распоряжение до вас довели, а причины для служебного пользования.
Про авто - есть у меня сомнения про зиму...
Лифер не любит мороза, говорят.
А летом да, должно идеально подходить.
Когда Фотошоп и Офис продаются вместе с ОС на одном диске за 60 рублей - они просто не могут не стать самыми распространенными и привычными инструментами.
Сейчас и вовсе на торрентах можно скачать нахаляву.
А вы купите...
Там даже не в спеках дело.
Если составить график заряда-разряда батареи или ячейки - на нем очень хорошо видно как раз вот эту плоскую полку и резкие "хвосты" вверх-вниз.
То есть, при заряде вы набираете условно 98% емкости - а потом напряжение прёт вверх, приходится ограничивать.
При разряде наоборот, вы расходуете всю ёмкость, и в последний момент происходит резкое сваливание - ну можно вместо 12.7 разрядить до 11.2, но это даст дополнительно всего 1-2% заряда, это уже падающая ветка.
и глючил )
Я много чем пользуюсь, в Windows и половины этого нет
Есть кривые аналоги и глючные порты...
Выходит, под Windows просто нет софта, верно? /s
У лифера очень плоская рабочая "полка" - 3.3 на ячейку норм, 3.2 - почти разряжена.
Верхний предел - 3.6, больше он портится.
Вот и считайте, 4 ячейки - 14.4, больше НЕ НАДО, может потечь или раздуться. За этим и должна BMS следить.
13.2 - вполне достаточно для заряда.
12.8 - можно уже выключать, там процентов 3-5 осталось от заряда.
Он сейчас стоит так же как хороший "свинец". Хороший - это не из пыли с известкой, а нормальные тяговые.