Конкретно в данном случае это особенность представления данных, если нам нужно вернуть ошибку, от этого никуда не деться. Да и в этом случае возможно будет RVO или что-то вроде этого, а если делать без Optional, то RVO будет точно.
В любом случае, заботиться о скорости работы именно на этом этапе разработки программы бесмыссленно. В том смысле, что лучше убирать «бутылочные горлышки» точечно, а не жертвуя выразительностью ради производительности
Да, но именно про это и была моя статья. Очень странное чувство, что хабр мне показывает какую-то другую статью, в отличие от остальных читателей :) Но видимо такая уж дурацкая у меня форма подачи, что не смог выделить ключевые моменты
Такое чувство, что мне не удалось донести своей статьей свои мысли. Потому что то, что пишите Вы, и другие комментаторы, почти все из этого я и пытался донести до читателя, за исключением некоторых пунктов.
Много чего может делать. В стандартную библиотеку даже специально добавили класс std::finally
Я собственно к тому именно и призываю, чтобы не писать в деструкторах код, который занимается чем-то помимо освобождения памяти, но не всегда это возможно
> то проект всё равно в срок никак сдать не получится
Не обязательно принимать все решения прямо в тот же спринт. Можно их чуть отложить на потом. Редко бывает что-то ну прям совсем срочное
> Да, техдолг и кривые решения удорожают разработку
А потом может возникнуть ситуация, что и в команду новые люди не идут, потому что легаси, и текущие спецы не могут устроиться на новую работу, потому что отстали от жизни
И вообще, в большинстве случаев работодатель нанимает новых людей по опыту. Но зачем, если в итоге этот опыт оказывается ненужен? А пилить код «от забора и до обеда» спокойно может и выпускник курсов
А у нас не в Москве, (с плотностью с точностью совпадающей с плотностью жителей в Праге вплоть до последней цифры) тоже наблюдается тенденция к высокооэтажной застройке
В любом случае, заботиться о скорости работы именно на этом этапе разработки программы бесмыссленно. В том смысле, что лучше убирать «бутылочные горлышки» точечно, а не жертвуя выразительностью ради производительности
Я собственно к тому именно и призываю, чтобы не писать в деструкторах код, который занимается чем-то помимо освобождения памяти, но не всегда это возможно
using Json = string
using Xml = string
это все один и тот же string
Можно, но зачастую слишком муторно пилить по контейнеру на каждый чих, чтобы воспользоваться ими всего в одном месте
По мне довольно плохое решение
А почему они зло?
Но результатом должна быть одна структура/класс. То есть мы должны получить из разных форматов одну структуру
По сути я это и предлагаю. Вместо конструкторов делать функции/статические методы
Не обязательно принимать все решения прямо в тот же спринт. Можно их чуть отложить на потом. Редко бывает что-то ну прям совсем срочное
> Да, техдолг и кривые решения удорожают разработку
А потом может возникнуть ситуация, что и в команду новые люди не идут, потому что легаси, и текущие спецы не могут устроиться на новую работу, потому что отстали от жизни
И вообще, в большинстве случаев работодатель нанимает новых людей по опыту. Но зачем, если в итоге этот опыт оказывается ненужен? А пилить код «от забора и до обеда» спокойно может и выпускник курсов
Ок, так понятнее