Страуструп говорил, что основной принцип доработок: чем не пользуемся за то не платим. Ну и лишнего старались не брать. При это сказать, что к 2003 году язык был очень сложным-- врядли. Мультипарадигменным это да. Вот современный c++ стал гораздо менее понятным. Вот это все move semantic, lambda не к месту применяемые, duck typing с аuto, очень мешает понимать код. Тк концентрирует внимание на несущественных в большинстве случаев деталях.
Зная с++ 2003 стандарта просто понимать и java и PHP и python, но понимать стандарт 20 это не помогает.
На тему истории c++ лучше всего прочитать "дизайн и эволюция языка c++". Те части этой статьи, которые касаются непосредственно компилятора, там есть. И много чего ещё.
А книга хорошо написана и переведена, читается на одном дыхании.
Я вообще так и писал, что ldo лучше pwm. А в некоторых случаях ещё лучше вообще без стабов. Я пробовал тоже pwm для своего устройства, и он меня не устроил.
Я обычно использовал 78xx или похожие. Не знал, что сейчас есть ldo на полевиках. Pwm то полно таких. Я же так и написал, что не видел rail-2-rail полевиков.
Да и остальное остаётся. Линейный стаб на то и линейный, что на нём рассеивается вся мощность. Поэтому я сомневаюсь, что с ним может быть эффективнее. Да и на работу самой микросхемы что-то тратиться. И сколько это на хз. Непонятно. Но на полевике, конечно, можно сделать что близкое к нулю.
Проблема преобразователей потеря 0.2-0.5 вольт, которые рассеиваются на стабилизаторе с мощностью dv*i. В общем то какая разница где мощность рассеется на стабе или на контроллере? А на напряжении близком к оптимальному не будет этого лишнего потребления. И в целом контроллер будет работать дольше. Я не видел rail-to-rail ldo, когда делал свой проект. Литиевая батарея нормально работает до 2.8 вольт. Атмега 328 настроенная на 8мгц устойчиво работает до тех же 3 вольт. Те из-за ldo она будет отрубаться сильно раньше. На stm 32 чуть хуже. Там очень важно иметь напряжение в районе 3.3. Но для чего то очень экономичного и без радио до сих пор atmega/attiny актуальны. А если радио, то я всегда думаю о чем то с zigbee.
Предсказуемое скольжение нужно в поворотах. Поэтому это актуально в кольцевых автогонках, где значительное время круга приходит на повороты. На шоссейных велогонках ты едешь прямо 50км и главное развлечение это подъемы в горку, спуски и драфт (слип стрим по автомобильному). Не бывает поворотов в с замедлением с 300 до 40 и с разгоном до 300. Вот автогонках, где бывает так, важно контролировать скольжение. А вот развитие скольжения именно в велоспорте, по крайней мере на мой взгляд неактуально. Важнее аэродинамика и вес. Из авто приемов более менее применим, на мой взгляд, шире зашёл и занёс побольше скорости в поворот, поэтому и дальше поехал быстрее. Этого достаточно. А для этого хватает и той резины, что есть сейчас. Очень сильно упарываться в состав, как это делают в автогонках не нужно.
В гравийных гонках сцепление гораздо важнее, там наверное это может понадобиться.
Все таки для шоссе не так важно контролируемо скользить, нагрузка на шину и момент более менее контролируемый, агрессивно оттормаживаться в поворотах, чтобы идеально пройти поворот и рано начать разгоняться сил не хватит. Ведь даже 1квт отдать очень тяжело. мне кажется, что и 600 ват могут ехать единицы, если речь идет о часе езды. Поэтому сцепные свойства шины не так важны, как аэродинамика и на подьемах в гору и ускорениях вес колеса.
Я имел в виду, что решение за куб, просто не имеет смысла, это просто замедленная версия решения с квадратом. Программист на с или Паскале скорее всего его бы даже не предложил, тк там нет функции sum
Я перешёл с canon d450 на sony a7cii. Разница больше 15 лет, дешёвый кроп против не самого дешёвого фф. На новом дорогущая оптика, но сказать что есть вов эффект на фото -- нет. Да неплохо. Да ИСО даже 6400 можно использовать, но при сьемке при хорошем свете разница небольшая. Вот по видео получше. Даже звук есть теперь.
Непонятно зачем людей злить. Ведь и так при продаже через Яндекс маркет есть нехилая наценка. Всегда пытаюсь посмотреть цену товара напрямую в магазине если что-то найду в Яндексе. И всегда напрямую купить дешевле и не на 20 рублей. Разница сильно больше.
Так в том то и дело, что похожие черты есть. В некоторых компаниях дикий набор. Многие компании пилят конкурирующий софт типа xdr. А емкость секурити, например, рынка в России не такая большая. Таким образом надуваются пузыри. Сейчас к счастью ковид закончился. Но похожего немало.
При этом в России, я думаю, этот же кризис будет чуть позже. Но с учетом того, что и емкость рынка меньше.
От этого страдают не только работники, но и работодатели, которые вынуждены откупаться 3-4 окладами, да и смотреть на то, чтобы найм был на задачу, а не про запас, как часто раньше было в топах западных фирм, что вело к миллионам долларов потерь.
Можно только пожелать российскоим работодателям тщательно рассчитывать свои потребности в людях.
А у обычного пользователя проблем и так минимум. И пользователю наплевать на тесты. Я пользуюсь года 4 наверное и проблем с мобильным приложением не было никогда.
Я бы поспорил с некоторыми решениями типа нового способа интеграции hacs это решение по ux явно сделано профессиональными програмистами.
Или например есть проблемы с ZigBee устройствами, которые частенько отваливаются. Но это проблема z2q , стиков и технологии вообще.
Есть недочёты при создании графиков, но при сравнении с другими они невероятно богаты и разнообразны
Мне также не нравится переход от редактирования сценариев и ui в yaml на визарды.
Да хороший язык паскаль. Я не знаю развивался ли он все это время, но 30 лет назад он для задач обучения не уступал c++. Писать на нем достаточно просто. А Delphi был сильно быстрее c++ builder, например при компиляции.
Не согласен с томсоном.
Страуструп говорил, что основной принцип доработок: чем не пользуемся за то не платим. Ну и лишнего старались не брать. При это сказать, что к 2003 году язык был очень сложным-- врядли. Мультипарадигменным это да. Вот современный c++ стал гораздо менее понятным. Вот это все move semantic, lambda не к месту применяемые, duck typing с аuto, очень мешает понимать код. Тк концентрирует внимание на несущественных в большинстве случаев деталях.
Зная с++ 2003 стандарта просто понимать и java и PHP и python, но понимать стандарт 20 это не помогает.
Ну вот для этого и нужен трекинг, готовые цели и прочая лабуда, чтобы объяснять тебе почему ты не достоин.
На тему истории c++ лучше всего прочитать "дизайн и эволюция языка c++". Те части этой статьи, которые касаются непосредственно компилятора, там есть. И много чего ещё.
А книга хорошо написана и переведена, читается на одном дыхании.
Я вообще так и писал, что ldo лучше pwm. А в некоторых случаях ещё лучше вообще без стабов. Я пробовал тоже pwm для своего устройства, и он меня не устроил.
Я обычно использовал 78xx или похожие. Не знал, что сейчас есть ldo на полевиках. Pwm то полно таких. Я же так и написал, что не видел rail-2-rail полевиков.
Да и остальное остаётся. Линейный стаб на то и линейный, что на нём рассеивается вся мощность. Поэтому я сомневаюсь, что с ним может быть эффективнее. Да и на работу самой микросхемы что-то тратиться. И сколько это на хз. Непонятно. Но на полевике, конечно, можно сделать что близкое к нулю.
Проблема преобразователей потеря 0.2-0.5 вольт, которые рассеиваются на стабилизаторе с мощностью dv*i. В общем то какая разница где мощность рассеется на стабе или на контроллере? А на напряжении близком к оптимальному не будет этого лишнего потребления. И в целом контроллер будет работать дольше. Я не видел rail-to-rail ldo, когда делал свой проект. Литиевая батарея нормально работает до 2.8 вольт. Атмега 328 настроенная на 8мгц устойчиво работает до тех же 3 вольт. Те из-за ldo она будет отрубаться сильно раньше. На stm 32 чуть хуже. Там очень важно иметь напряжение в районе 3.3. Но для чего то очень экономичного и без радио до сих пор atmega/attiny актуальны. А если радио, то я всегда думаю о чем то с zigbee.
Я пошел дальше. Просто убрал преобразователь. Это ещё больше экономит батарею. Но нужно искать толерантные к напряжению контроллеры.
Предсказуемое скольжение нужно в поворотах. Поэтому это актуально в кольцевых автогонках, где значительное время круга приходит на повороты. На шоссейных велогонках ты едешь прямо 50км и главное развлечение это подъемы в горку, спуски и драфт (слип стрим по автомобильному). Не бывает поворотов в с замедлением с 300 до 40 и с разгоном до 300. Вот автогонках, где бывает так, важно контролировать скольжение. А вот развитие скольжения именно в велоспорте, по крайней мере на мой взгляд неактуально. Важнее аэродинамика и вес. Из авто приемов более менее применим, на мой взгляд, шире зашёл и занёс побольше скорости в поворот, поэтому и дальше поехал быстрее. Этого достаточно. А для этого хватает и той резины, что есть сейчас. Очень сильно упарываться в состав, как это делают в автогонках не нужно.
В гравийных гонках сцепление гораздо важнее, там наверное это может понадобиться.
Все таки для шоссе не так важно контролируемо скользить, нагрузка на шину и момент более менее контролируемый, агрессивно оттормаживаться в поворотах, чтобы идеально пройти поворот и рано начать разгоняться сил не хватит. Ведь даже 1квт отдать очень тяжело. мне кажется, что и 600 ват могут ехать единицы, если речь идет о часе езды. Поэтому сцепные свойства шины не так важны, как аэродинамика и на подьемах в гору и ускорениях вес колеса.
Пароли вводить очень удобно. На мой взгляд самый удобный менеджер паролей.
Я имел в виду, что решение за куб, просто не имеет смысла, это просто замедленная версия решения с квадратом. Программист на с или Паскале скорее всего его бы даже не предложил, тк там нет функции sum
Если не использовать sum в цикле, а ручками считать сумму то как раз будет квадрат. Даже массив не нужен.
Перекачай только, она обновлялась каждый месяц
Я перешёл с canon d450 на sony a7cii. Разница больше 15 лет, дешёвый кроп против не самого дешёвого фф. На новом дорогущая оптика, но сказать что есть вов эффект на фото -- нет. Да неплохо. Да ИСО даже 6400 можно использовать, но при сьемке при хорошем свете разница небольшая. Вот по видео получше. Даже звук есть теперь.
А я так и не смог его запустить на андроид авто. И суппорт не помог.
Непонятно зачем людей злить. Ведь и так при продаже через Яндекс маркет есть нехилая наценка. Всегда пытаюсь посмотреть цену товара напрямую в магазине если что-то найду в Яндексе. И всегда напрямую купить дешевле и не на 20 рублей. Разница сильно больше.
Так в том то и дело, что похожие черты есть. В некоторых компаниях дикий набор. Многие компании пилят конкурирующий софт типа xdr. А емкость секурити, например, рынка в России не такая большая. Таким образом надуваются пузыри. Сейчас к счастью ковид закончился. Но похожего немало.
При этом в России, я думаю, этот же кризис будет чуть позже. Но с учетом того, что и емкость рынка меньше.
От этого страдают не только работники, но и работодатели, которые вынуждены откупаться 3-4 окладами, да и смотреть на то, чтобы найм был на задачу, а не про запас, как часто раньше было в топах западных фирм, что вело к миллионам долларов потерь.
Можно только пожелать российскоим работодателям тщательно рассчитывать свои потребности в людях.
А у обычного пользователя проблем и так минимум. И пользователю наплевать на тесты. Я пользуюсь года 4 наверное и проблем с мобильным приложением не было никогда.
Я бы поспорил с некоторыми решениями типа нового способа интеграции hacs это решение по ux явно сделано профессиональными програмистами.
Или например есть проблемы с ZigBee устройствами, которые частенько отваливаются. Но это проблема z2q , стиков и технологии вообще.
Есть недочёты при создании графиков, но при сравнении с другими они невероятно богаты и разнообразны
Мне также не нравится переход от редактирования сценариев и ui в yaml на визарды.
Но к мобильному приложению претензий нет.
Да хороший язык паскаль. Я не знаю развивался ли он все это время, но 30 лет назад он для задач обучения не уступал c++. Писать на нем достаточно просто. А Delphi был сильно быстрее c++ builder, например при компиляции.