Вы только не обижайтесь, но Вы демонстрируете весьма негибкий подход к набору специалистов. Скажите честно, сколько по-настоящему крутых спецов ваша компания наняла за последние пару лет. В соотношении с тем количеством спецов, что от вас ушли.
Была такая компания, и не одна, которая растила узконаправленных спецов со студенческой скамьи, которые писали соответствующий код. В результате сформировалась весьма специфическая атмосфера, идеи и код по эволюционному развитию аналогичный Австралии по отношению к остальному миру. И разумеется до пуфиков они доросли только тогда, когда позвали хороших спецов со стороны,
Ну не сказал бы я, что он прям уж работает. Претензий к нему стабильно больше, чем к GCC и MSVC, пока он на уровне «так себе поделка». Данный пример, с вашим комментарием
Вопрос в другом: а хочу ли я, чтобы он так делал? И в моём случае ответ однозначен: да, разумеется.
однозначно определяет дальнейшее развитие продукта в сторону наиболее косячную с итераионным развитием в сторону «ну да, неочевидно, странно, но зато оптимизировано в другом месте». Подход весьма скоро приведёт Вас к взрослению, когда пезанская башня начнёт очень сильно наклоняться.
Для сравнения подходов, крайне рекомендую покодить полгодика-годик на том же Python 3.x, весьма освежает подход к очевидному и понятному и заставляет по-другому взглянуть на свой код на C++.
Также было бы полезно попрактиковаться в Boost.Python, там всё сделано для удобства пользователя, каким бы программистом он ни был. Сравните подход, его аккуратность и очевидность происходящего в процессе написания кода.
Да нет, уважаемый коллега, я весьма неплохо орудую C++, крайне неплохо, рискую показаться грубым, но я бы поумерил ваш пыл в мою сторону, однако, как и любой пользователь, я люблю такого же уважительного отношения ко мне как к пользователю, какое проявляю сам к пользователям моих систем. Если пользователю моего продукта что-то неочевидно, виноват я, так и тут, очевидно, что шланг ведёт себя крайне неестественно и оптимизацией подменяет наиболее очевидное поведение. Можно сколько угодно прикрываться стандартом, тут это шлангу никак не помогает.
Ещё раз повторяю, любое неочевидное поведение продукта, который вводит пользователя продукта в глубокий ступор — бесспорное багло. В данном случае очевидное донельзя. Отрицая это, Вы ставите себя в весьма глупое положение.
Ну-ну, незачем быть настолько агрессивным, отстаивая правильность поведения при «неопределённом поведении». Фактически компилятор ведёт себя максимально неочевидным способом. В точности нуль разработчиков ожидает то, чего они получат и никого это не устроит. Детали реализации пользователей компилятора не волнуют, как и ваши проблемы с некими программистами, выросшими на Java, храни их боже.
О! Тензор на Хабре! Наконец-то!
Вам, ребята, можно долго и интересно рассказывать о своём технологическом стеке, о гибкости перехода от одной технологии к другой и разноуровневой разработке.
Вы однозначно лучшие из всех, с кем я когда-либо работал! Так держать!
Сам там когда-то руководил отделом Ядра Платформы, а до этого оптимизировал систему распределения памяти при вычитывании результатов SQL-запросов и внедрял связку C++/Python, результатом чего в том числе стал цикл статей на Хабре и в журнале «Хакер» про Boost.Python.
Уровень культуры разработки у вас выше чем у 90% столичных контор. Да и ребята на порядок сильнее.
Есть такой же typedef для std::string. Мы с Вами оба видим замечательные стеки с кучей ненужной информации во время ошибок компиляции, линковки или логирования через typeid: std::basic_string<… std::allocator <… > > и т.д. Особенно если мы специализируем шаблон от std::string, там вообще песня получается. Если перегрузка от std::string, или конструкции, содержащей подобный typedef, тоже получаем километровую неинформативную простыню. Вам это точно надо? Вы хотите множить подобный подход? Одно дело через using отсекать лишние упоминания namespace'ов — пространства имён как раз благо, а совсем другое — создавать видимость, что всё хорошо, когда всё крайне запущено, запутано и переусложнено.
API обязан быть простым, понятным и в нём не должно быть ничего лишнего. Sine qua non.
Разработчик, использующий Ваш API не должен через раз делать dynamic_cast, static_cast или, не дай бог, const_cast, только потому, что разработчик API не предусмотрел очевидные use cases. Всё должно быть логично и максимально минималистично в использовании.
В object::data конечно же нужен виртуальный деструктор. Вечером всё поправлю. Извините за неточность. Вообще shared_ptr тоже не вариант, больше подойдет комбинация подходов из первых двух статей: by-value или copy-on-write — оптимально и без дополнительных затрат.
Объект на куче прекрасно оптимизируется, во-первых by-value из материала второй статьи через placement new для небольших объектов, во-вторых через copy-on-write для больших объектов. Двойная логика работы с классами в больших проектах всё равно пишется, если используется Pimpl, здесь подход позволяет осмыслить классы данных, спрятанные в реализации, через аналогичное дерево иерархии. Зачем: мы пишем код без указателей и ссылок, работая именно с экземплярами классов, а не с какими-то малопонятными ссылками на то, что создала фабрика и выдала нам в виде неудобной синтаксической конструкции в лучшем случае или в виде raw указателя в худшем.
Если вы инкапсулируете привычные интерфейсы типа ISomething* в удобные классы работы с этими интерфейсами Something, то это хорошо. Если вам платят за то, что вы просто пишете код, который хоть как-то работает, не расширяем и трудно читаем — это тоже неплохо (но не для новичка разбирающего ваш код, конечно же).
Чтобы было ближе к Qt имеет смысл сделать copy-on-write для данных. То есть заменить на небольшую обвязку наз std::shared_ptr с перегрузкой operator -> с const. Вообще действительно похоже.
То, что это единственная причина, по которой здесь нужен виртуальный деструктор, в такой модели в наследниках нет никаких данных, да и сами деструкторы в них не подразумеваются.
Скорость разработки с использованием таких классов прямо пропорциональна скорости разработки приложения. Скорость разработки интерфейсных классов при этом не отличается от разработки из с применением паттерна Pimpl.
В некоторых случаях у нас нет выбора и часть функционала надо писать на C++, при этом предоставляя удобный интерфейс для работы другим разработчикам.
Pimpl'ы повзоляют легко менять реализацию. В приведённом коде так же легко можно менять поля и реализацию классов object::data с наследниками. Здесь преимуществ не меньше, а больше. Этот подход гибче и дополнительные классы более обоснованы.
Связка с другими языками это хорошо, но данный подход будет отлично работать и сам по себе в C++ для C++, предоставляя удобный способ работы с иерархией классов.
Всё на самом деле гораздо интереснее. Сейчас C++ очень часто встраивается в высокоуровневые библиотеки бизнес-логики и писать биндинги под такие обобщённые объекты на порядок проще. Соответственно преобразования в те же Python и C# получаются крайне простыми и код будет почти одинаковым, что важно. Это верно и в обратную сторону, в игровой индустрии например C++ состовляет основу движка и поверх идёт скриптовая обвязка, оптимизировать данный подход несложно, а разработчики будут легко работать как внутри движка, так и в расширениях. Сейчас скорость разработки на вес золота.
Кроме всего прочего очень часто библиотеки общего пользования очень часто изобилуют Pimpl'ами. Данный подход позволяет оптимизировать расходы на разработку «классов реализации» выстроив иерархию классов данных, что опять же положительно скажется на скорости разработки.
Не стоит также забывать на скорость вхождения в работу новых людей. Код получается простым и понятным, в нём проще разобраться, новички быстро втягиваются и пишут полноценный код. Опять же увеличивая скорость разработки.
Вы правы, всё что нужно — это добавить конструктор перемещения object(object&&) и оператор перемещения operator = (object&&). В целом можно вообще разделить объекты по ссылке и по значению как из второй статьи цикла Академии с оптимизацией placement new для небольших классов и скаляров. Также можно внутри класса в принципе запретить null-значения, то есть ругаться на object без данных и на dynamic_cast, который вернул null. В целом идею можно развивать до полноценной библиотеки или встраивать в существующую, профит весьма привлекателен.
Была такая компания, и не одна, которая растила узконаправленных спецов со студенческой скамьи, которые писали соответствующий код. В результате сформировалась весьма специфическая атмосфера, идеи и код по эволюционному развитию аналогичный Австралии по отношению к остальному миру. И разумеется до пуфиков они доросли только тогда, когда позвали хороших спецов со стороны,
однозначно определяет дальнейшее развитие продукта в сторону наиболее косячную с итераионным развитием в сторону «ну да, неочевидно, странно, но зато оптимизировано в другом месте». Подход весьма скоро приведёт Вас к взрослению, когда пезанская башня начнёт очень сильно наклоняться.
Для сравнения подходов, крайне рекомендую покодить полгодика-годик на том же Python 3.x, весьма освежает подход к очевидному и понятному и заставляет по-другому взглянуть на свой код на C++.
Также было бы полезно попрактиковаться в Boost.Python, там всё сделано для удобства пользователя, каким бы программистом он ни был. Сравните подход, его аккуратность и очевидность происходящего в процессе написания кода.
Вам, ребята, можно долго и интересно рассказывать о своём технологическом стеке, о гибкости перехода от одной технологии к другой и разноуровневой разработке.
Вы однозначно лучшие из всех, с кем я когда-либо работал! Так держать!
Сам там когда-то руководил отделом Ядра Платформы, а до этого оптимизировал систему распределения памяти при вычитывании результатов SQL-запросов и внедрял связку C++/Python, результатом чего в том числе стал цикл статей на Хабре и в журнале «Хакер» про Boost.Python.
Уровень культуры разработки у вас выше чем у 90% столичных контор. Да и ребята на порядок сильнее.
API обязан быть простым, понятным и в нём не должно быть ничего лишнего. Sine qua non.
Разработчик, использующий Ваш API не должен через раз делать dynamic_cast, static_cast или, не дай бог, const_cast, только потому, что разработчик API не предусмотрел очевидные use cases. Всё должно быть логично и максимально минималистично в использовании.
Если вы инкапсулируете привычные интерфейсы типа ISomething* в удобные классы работы с этими интерфейсами Something, то это хорошо. Если вам платят за то, что вы просто пишете код, который хоть как-то работает, не расширяем и трудно читаем — это тоже неплохо (но не для новичка разбирающего ваш код, конечно же).
В некоторых случаях у нас нет выбора и часть функционала надо писать на C++, при этом предоставляя удобный интерфейс для работы другим разработчикам.
Pimpl'ы повзоляют легко менять реализацию. В приведённом коде так же легко можно менять поля и реализацию классов object::data с наследниками. Здесь преимуществ не меньше, а больше. Этот подход гибче и дополнительные классы более обоснованы.
Связка с другими языками это хорошо, но данный подход будет отлично работать и сам по себе в C++ для C++, предоставляя удобный способ работы с иерархией классов.
Кроме всего прочего очень часто библиотеки общего пользования очень часто изобилуют Pimpl'ами. Данный подход позволяет оптимизировать расходы на разработку «классов реализации» выстроив иерархию классов данных, что опять же положительно скажется на скорости разработки.
Не стоит также забывать на скорость вхождения в работу новых людей. Код получается простым и понятным, в нём проще разобраться, новички быстро втягиваются и пишут полноценный код. Опять же увеличивая скорость разработки.