Недавно на хабре была статья о разработке эмулятора солнечной системы в натуральных размерах и там пришлось очень много хитростей придумать чтобы решить проблему с недостаточной точностью флоатов. И автор в одном месте пишет что-то вроде " понятно зачем в движках есть возможность использовать даблы". Хотя ситуация конечно очень специфичная но тем не менее
На сколько я вник в устройство qt могу предположить что его надо не с gui фреймворками сравнивать а с игровыми движками - например бинарник "игры" на юнити будет весить пару метров даже если там одна картинка просто будет на весь экран. Потому что юнити поднимает тяжёлый бэкенд чтобы рисовать крутую графику не зависимо от того что по факту сделал юзер. С qt так же - чтобы нарисовать маленькую кнопочку он поднимет бэкенд рендеринга на вулкане, цикл приложения, систему сообщений и не бог весть что ещё что нужно для полноценного приложения и тянет множество зависимостей для своей работы и не важно что юзер только кнопочку нарисовал.
Ну, на qt всё это тоже есть и с очень удобными обертками и интегрировано в виджеты, даже бэкенды на свой вкус можно выбрать а не только вулкан, только это надо ещё придумать гуй который нельзя сделать тем что есть и нужно лезть на этот уровень
Ну так если вышка далеко то поговоришь пару минут и больше излучения не будет. А если вышка рядом то излучение будет всегда не важно говоришь сам или нет. Так как важна не только сила излучения но и его длительность то уже не так очевидно что лучше: пару минут с трубкой у уха или считай что всегда но источник излучения в 10 метрах(если говорить про крыши и жильцов верхних этажей).
То есть по вашему такие ограничения ради смеха появились? Рассуждать то можно сколько угодно и предполагать тоже. А мотивацию таких ограничений кто-то попытался найти и почитать?
Во во. Тут тот же вопрос возникает - почему так же не сделано. А если сковырнуть такого "лида" нельзя то надо работу другую искать а не ждать подобных ситуаций
Вы подсвечивали вышестоящему руководству что тимлид "плохой"? Почему вы продолжали столько времени работать под фактически руководством такого Лида а не ставили вопрос ребром? Вы рассчитывали что пронесёт или просто не думали о том что рано или поздно будет беда с таким лидом? Это как в истории про зло: зло расцветает если добро просто бездействует. Так и тут - вы ничего не делали просто ожидая что кто-то другой этого "лида" научит, уволит и тд? По моему мнению здесь вашей вины значительная часть так как ваше бездействие исходя из рассказанной вами истории не допускает рационального объяснения
"отпуск - это право работника" - при этом именно компанию накажут за то что сотрудник не о гулял подряд 2 недели в год. Так что право может и сотрудника но обязанность компании во многом
"У кого-то проблема со сторисами? Ну значит вы добавили себе в личные контакты людей, которые любят писать сторисы" - это не мы убогую фичу сделали, это вы неправильно ей пользуетесь/какие-то не такие.
Метод гет сет на чистые данные без предварительной обработки это нарушение инкапсуляции. В такой ситуации скорее всего дизайн класса сломан. На счёт инварианта очень легко вообразить что в процессе эволюции проекта нам потребуется менять поведение объекта например чтобы он перемещался только в определённой зоне или не мог уйти в минуса по положению. И тогда паблик свойство сделает очень больно тому кто будет это рефакторить под новые требования.
Всё что можно сказать исходя из факта наличия таких строк в плюсах - это что плюсы совместимы с С, и предлагает помимо этих строк свои строки. Почему совместимость с С занесена в минусы опять же непонятно
"Рассмотрим пример - dynamic_cast<> и RTTI (runtime type information). Это отключаемая фича в С++, но по-дефолту она включена и многими используется. Многими программистами С++ она воспринимается как бесплатная" - это какими многими? Джунами? Мб. Почему отсутствуе такого базового знания приписывается в минус языку решительно непонятно. На счёт отсутствия методов для работы со строками приводится в пример как раз то что есть split и starts_with. Это специально так? В целом много чего по делу. Но так же много такого как на примере выше.
Автор пишет про необходимость использовать мьютексов и атомиков в однопоточном коде. Это какая-то больная история. Причём, как подсказывает опыт, это никак не поможет если внезапно решим сделать код многопоточным, так как почти всегда потребует рефакторинга из-за более высокоуровневых требований которые идут в совокупности с внедрением многопоточности.
А можно возвращать std::optional в плюсах и тогда контракт явно обязывает проверять что внутри есть значение, другими словами будет сложно допустить ошибку. А указатели конечно такого контракта по умолчанию не содержат. И опшинал даст исключение если значение из него юзать когда он пустой.
Я как пользователь стаковерфлоу заинтересован чтобы они процветали а не загнулись от конкуренции с нейронками. Учитывая что те кто отвечают там занимаются альтруизмом фактически, я не вижу проблемы чтобы сервис получил возможность конкурировать с нейронками и дальше за счёт моих ответов, с которых я и так ничего не получаю.
Когда мак про 16 на м1 макс будет шуметь дам знать) у маков ноуты не взлетают как виндовые, так что на счёт потребительских минусов от вентилятора тут спорно.
Недавно на хабре была статья о разработке эмулятора солнечной системы в натуральных размерах и там пришлось очень много хитростей придумать чтобы решить проблему с недостаточной точностью флоатов. И автор в одном месте пишет что-то вроде " понятно зачем в движках есть возможность использовать даблы". Хотя ситуация конечно очень специфичная но тем не менее
На сколько я вник в устройство qt могу предположить что его надо не с gui фреймворками сравнивать а с игровыми движками - например бинарник "игры" на юнити будет весить пару метров даже если там одна картинка просто будет на весь экран. Потому что юнити поднимает тяжёлый бэкенд чтобы рисовать крутую графику не зависимо от того что по факту сделал юзер. С qt так же - чтобы нарисовать маленькую кнопочку он поднимет бэкенд рендеринга на вулкане, цикл приложения, систему сообщений и не бог весть что ещё что нужно для полноценного приложения и тянет множество зависимостей для своей работы и не важно что юзер только кнопочку нарисовал.
Не нужно qt покупать, есть lgpl с динамической линковкой в которой есть 99.9% того что может понадобиться
Ну, на qt всё это тоже есть и с очень удобными обертками и интегрировано в виджеты, даже бэкенды на свой вкус можно выбрать а не только вулкан, только это надо ещё придумать гуй который нельзя сделать тем что есть и нужно лезть на этот уровень
Ну так если вышка далеко то поговоришь пару минут и больше излучения не будет. А если вышка рядом то излучение будет всегда не важно говоришь сам или нет. Так как важна не только сила излучения но и его длительность то уже не так очевидно что лучше: пару минут с трубкой у уха или считай что всегда но источник излучения в 10 метрах(если говорить про крыши и жильцов верхних этажей).
То есть по вашему такие ограничения ради смеха появились? Рассуждать то можно сколько угодно и предполагать тоже. А мотивацию таких ограничений кто-то попытался найти и почитать?
Во во. Тут тот же вопрос возникает - почему так же не сделано. А если сковырнуть такого "лида" нельзя то надо работу другую искать а не ждать подобных ситуаций
Вы подсвечивали вышестоящему руководству что тимлид "плохой"? Почему вы продолжали столько времени работать под фактически руководством такого Лида а не ставили вопрос ребром? Вы рассчитывали что пронесёт или просто не думали о том что рано или поздно будет беда с таким лидом? Это как в истории про зло: зло расцветает если добро просто бездействует. Так и тут - вы ничего не делали просто ожидая что кто-то другой этого "лида" научит, уволит и тд? По моему мнению здесь вашей вины значительная часть так как ваше бездействие исходя из рассказанной вами истории не допускает рационального объяснения
"отпуск - это право работника" - при этом именно компанию накажут за то что сотрудник не о гулял подряд 2 недели в год. Так что право может и сотрудника но обязанность компании во многом
"У кого-то проблема со сторисами? Ну значит вы добавили себе в личные контакты людей, которые любят писать сторисы" - это не мы убогую фичу сделали, это вы неправильно ей пользуетесь/какие-то не такие.
Метод гет сет на чистые данные без предварительной обработки это нарушение инкапсуляции. В такой ситуации скорее всего дизайн класса сломан. На счёт инварианта очень легко вообразить что в процессе эволюции проекта нам потребуется менять поведение объекта например чтобы он перемещался только в определённой зоне или не мог уйти в минуса по положению. И тогда паблик свойство сделает очень больно тому кто будет это рефакторить под новые требования.
Всё что можно сказать исходя из факта наличия таких строк в плюсах - это что плюсы совместимы с С, и предлагает помимо этих строк свои строки. Почему совместимость с С занесена в минусы опять же непонятно
"Рассмотрим пример - dynamic_cast<> и RTTI (runtime type information). Это отключаемая фича в С++, но по-дефолту она включена и многими используется. Многими программистами С++ она воспринимается как бесплатная" - это какими многими? Джунами? Мб. Почему отсутствуе такого базового знания приписывается в минус языку решительно непонятно. На счёт отсутствия методов для работы со строками приводится в пример как раз то что есть split и starts_with. Это специально так? В целом много чего по делу. Но так же много такого как на примере выше.
Автор пишет про необходимость использовать мьютексов и атомиков в однопоточном коде. Это какая-то больная история. Причём, как подсказывает опыт, это никак не поможет если внезапно решим сделать код многопоточным, так как почти всегда потребует рефакторинга из-за более высокоуровневых требований которые идут в совокупности с внедрением многопоточности.
Через час этот прототип уже на свалке окажется и то что где-то там в будущем можно было прийти к конфликту с типами никто не узнает.
С std::optional можно не делать проверку и получать исключение если внутри ничего нет. Вроде это желаемое поведение?
А можно возвращать std::optional в плюсах и тогда контракт явно обязывает проверять что внутри есть значение, другими словами будет сложно допустить ошибку. А указатели конечно такого контракта по умолчанию не содержат. И опшинал даст исключение если значение из него юзать когда он пустой.
Я как пользователь стаковерфлоу заинтересован чтобы они процветали а не загнулись от конкуренции с нейронками. Учитывая что те кто отвечают там занимаются альтруизмом фактически, я не вижу проблемы чтобы сервис получил возможность конкурировать с нейронками и дальше за счёт моих ответов, с которых я и так ничего не получаю.
Обычному народу может и хорошо что не дают так просто пойти на непонятный сайт
Когда мак про 16 на м1 макс будет шуметь дам знать) у маков ноуты не взлетают как виндовые, так что на счёт потребительских минусов от вентилятора тут спорно.