Comments 16
> ThingWhatDoesCoolStuff
Поправьте what на that или which. Чтоб смысл был, а то спотыкаешься
Поправьте what на that или which. Чтоб смысл был, а то спотыкаешься
Есть очень универсальная мысль — так-то оно так, конечно, но случись что — вот тебе и пожалуйста.
Например, некоторый период я писал, в основном, на ActionScript, теперь пишу, в основном, на андроидной Java, ведь уже пора перейти на Kotlin — вот так из огня да в полымя, где от прошлого остается пепел.
ИМХО ваша статья применима к конкретному языку или отрасли. Мне как-то странно видеть, когда запрещено использование стандартных библиотек и вместо этого ничего не сделано. Если кто-то по каким-то соображениям запрещает библиотеку (например она не оптимизирована под конкретную архитектуру), то будь добр предоставь свою, предоставляющую те же методы с теми же свойствами. И тогда не должно быть проблем с зависимостями.
Как пример — всякие putchar, getchar и printf — под многие платформы имеют свои реализации, но библиотеки, что их используют, работают и компилируются с ними нормально.
Ну чего — вот есть Boost, отличный пример такой библиотеки. Да, без слез и пол литра в исходники не глянешь, но оно реально многими используется и экономит кучу времени на разработку.
Я недавно говорил нашему архитектору, что люблю копипастить (в тестах). Да, он хмуро посмотрел на меня, но понял, что я его подкалываю.
Смысл в данном применении для меня в том, что можно в трех разных местах попробовать разные реализации и выбрать ту которая работает лучше всего, а уже потом уже вынести в общий код. Это же принцип эволюции — мутация, комбинация. В результате получится реализация которая впитала лучшие качества своих предшественников.
В случае с изначальным выносом, нам придется три раза подряд чинить код пока мы не придем к оптимальной реализации. А последовательно — медленнее, чем параллельно.
Во как! Привел довод, называется. Аж сам удивился. И ведь не поспоришь… :)
Смысл в данном применении для меня в том, что можно в трех разных местах попробовать разные реализации и выбрать ту которая работает лучше всего, а уже потом уже вынести в общий код. Это же принцип эволюции — мутация, комбинация. В результате получится реализация которая впитала лучшие качества своих предшественников.
В случае с изначальным выносом, нам придется три раза подряд чинить код пока мы не придем к оптимальной реализации. А последовательно — медленнее, чем параллельно.
Во как! Привел довод, называется. Аж сам удивился. И ведь не поспоришь… :)
Но на практике возникает целая куча причин не использовать подобную чужую (пусть даже открытую) библиотеку. Во-первых, в такой библиотеке абсолютно точно не окажется какого-то необходимого вам функционала и её придётся дописывать. Во-вторых, огромной преградой окажутся зависимости данной библиотеки.
Самое главное, эта библиотека, если её до этого не использовали в тысячах проектов, стопудово будет глючить в неочевидных местах и её, если опен-сорс, придется дебажить и допиливать, а если не опен-сорс, то выпиливать из проекта и искать чем её заменить. А как изнутри выглядит, например, openssl, все помнят?
Поэтому, если можно обойтись без библиотеки, то лучше её не надо.
Задам, скорее всего, дилетантский вопрос, но всё же задам.
Чем так плоха эта идея?
Теоретически я мог бы просто сделать базовый класс «Container», определить в нём виртуальные методы, бла-бла-бла, боже я ненавижу себя уже просто за попытку подумать о таком ужасном варианте. Давайте просто забудем об этом навсегда.
Чем так плоха эта идея?
В общем — не так уж и плоха. Но автор писал об этом всём в контексте геймдева, где дорога каждая микросекунда, поскольку надо выдать много fps и в хорошем качестве. Интерфейс, базовый класс и реализация приведут к тому, что в объекте будет создана таблица виртуальных функций, а каждый вызов функции приведёт к поиску в этой таблице адреса, по которому её нужно вызывать. Это всё затраты времени. Копеечные в обычном приложении, но существенные в игре. Вариант с шаблонами позволяет этого избежать.
Вы уверены, что автор имел в виду именно эту причину? Если обратиться к таблице стоимости операций в тактах, то вызов виртуальной функции в С++ относится к одной из самых дешёвых и безобидных операций.
Даже по вашей таблице разница может достигать 4 раза. Это, мягко говоря, очень много.
На самом деле, виртуальные функции — это только половина беды. Основная проблема — код обрастает большим количеством крайне медленных dynamic_cast, мы теряет возможность грамотно оптимизировать код (потому что компилятор не знает, что нам прилетит в рантайме), в большинстве случаев теряем inline'овые функции (хотя final немного выправляет этот пункт) и т.д. и т.п.
На самом деле, виртуальные функции — это только половина беды. Основная проблема — код обрастает большим количеством крайне медленных dynamic_cast, мы теряет возможность грамотно оптимизировать код (потому что компилятор не знает, что нам прилетит в рантайме), в большинстве случаев теряем inline'овые функции (хотя final немного выправляет этот пункт) и т.д. и т.п.
Ответили выше. Поверим на слово, что в геймдеве действительно издержки на использование интерфейсов существенны.
Спасибо
Спасибо
Тут есть хороший ответ касательно использования stdlib в движке Unreal Engine
Спасибо. Почитаю. Но моя мысль была не о том, стоит ли использовать stdlib или не стоит.
Есть требование «не использовать» и в данном случае не важно, чем оно вызвано.
Я не понял, почему решение сделать интерфейс, позволяя пользователю самому указать какой список он будет использовать (хоть из stdlib, хоть какой самописный) плохое.
Но увидел ответ автора на вопрос выше: "В общем — не так уж и плоха. Но автор писал об этом всём в контексте геймдева, где дорога каждая микросекунда, поскольку надо выдать много fps и в хорошем качестве. Интерфейс, базовый класс и реализация приведут к тому, что в объекте будет создана таблица виртуальных функций, а каждый вызов функции приведёт к поиску в этой таблице адреса, по которому её нужно вызывать. Это всё затраты времени. Копеечные в обычном приложении, но существенные в игре."
Есть требование «не использовать» и в данном случае не важно, чем оно вызвано.
Я не понял, почему решение сделать интерфейс, позволяя пользователю самому указать какой список он будет использовать (хоть из stdlib, хоть какой самописный) плохое.
Но увидел ответ автора на вопрос выше: "В общем — не так уж и плоха. Но автор писал об этом всём в контексте геймдева, где дорога каждая микросекунда, поскольку надо выдать много fps и в хорошем качестве. Интерфейс, базовый класс и реализация приведут к тому, что в объекте будет создана таблица виртуальных функций, а каждый вызов функции приведёт к поиску в этой таблице адреса, по которому её нужно вызывать. Это всё затраты времени. Копеечные в обычном приложении, но существенные в игре."
Sign up to leave a comment.
Повторное использование кода — как это бывает на практике