Не нашел там конструктора копирования, там речь про operator=, разве нет?
Кстати проверил в Visual C++. Не дает создать конструктор копирования с аргументом по значению. Не знаю, заслуга ли это микрософта, или 11го стандарта, но претензия была напрасна. Про невиртуальный деструктор, тем не менее, «особенность» здравствует и поныне.
Выбешивают особенности виновника торжества (С++), такие как возможность написать конструктор копирования с передачей копии объекта, а не по ссылке, или базовый класс с невиртуальным деструктором,. Как мне кажется такие вещи не должны компилиться, а падать с ошибкой, ворнинга недостаточно. Но нет даже ворнинга. Это за пределами возможности выстрелить себе в ногу, это как документированная возможность вида «нажмешь эту кнопку — умрешь». Зачем кому либо вообще такая кнопка? Почему нельзя было сделать без нее?
«Я ничего не понял из того, что ты сказал, но ты заговорил, и достучался до моего сердца»(с) Джей и молчаливый Боб.
Трудно спорить с «сотрудником Интела», но я все таки считаю С++ надмножеством С, и «чистый С++» оксюмороном.
Нет, обратный порядок это один из лучших случаев, особенно при выборе пивота посередине. Такой массив будет отсортирован уже после первой итерации, дальше будут только сравнения без обменов.
Если пивот выбирается случайным образом, то вероятность худшего случая 1/(N!), если не напутал, причем от входного массива не зависит. Т.е. зависит конечно, учитывая то, что генераторы псевдослучайны. При этом, если выбирать пивот по принципу выборки трех элементов массива, и выбора среднего из них, то вероятность соотвественно еще ниже.
Почему-то глядя на эту тему, подумалось, что идет борьба разработчиков процессоров с программистами.
Мне вот просто интересно, если в процессоре изначально обойтись без этих оптимизаций с перестановками инструкций, то потом в программах можно будет обойтись без барьеров памяти, то есть мьютексы будут более просты и менее затратны.
Может это приведет к бОльшей производительности?
Я, когда лет 10 назад писал на дельфи, потом на С++ билдере, нелицензионно конечно же, откуда у студента такие деньги в те времена, тоже радовался, как у них все было хорошо в плане визуальной разработки. Несмотря на тормозной никудышный компилятор, у которого так и не появилось 64хбитной версии(или уже есть?), несмотря на баги с утечкой памяти в таких основополагающих классах, как AnsiString, все это было весьма привлекательно.
Года три назад решил для себя — изучаю C#, поставил студию, создал свое первое wpf приложение, и позабыл про Билдер насовсем. А теперь и обычный C++ ничего, и std::string вполне себе устраивает, И ВинФормс вполне хорош, уже не то, что разработка под mfc, которая и отпугнула в свое время. А уж компилируемый код настолько существенно быстрее работает, чем борландовский, сплошная радость. Да и вобщем то борландовский как мне показалось медленнее даже шарпового, несмотря на его не-нативность.
При сравнимых вещах обычно решает сила привычки, и даже если надо переходить, то или с тоской поглядываешь назад, или еще что, а тут как на новую ступень шагнул, и долго пинал себя пяткой, что не сделал этого раньше.
Временный пустой класс, пустой метод и вообще любые заглушки не вызывают вопросов. Вызывает вопрос, почему класс один? Требование заказчика иметь три разных, хлеб, пирожок и торт. Зачем заниматься самодеятельностью и объединять их в один, награждая перечисляемым типом? Заранее же неизвестно будет ли у них что то общее вообще, состояние или поведение. А кирпич при этом отдельно, хотя про него нам известно ровно столько же, сколько и про торт, который впоследствии может оказаться сленговым названием газобетона например, и его имеет смысл с кирпичем объединять, а не с хлебом.
Совершенствоваться в применении YAGNI еще есть куда, не правда ли, хех.
PS мне не нравится, на самом деле попытка подогнать исходные данные под ответ, то есть принцип YAGNI под заведомо неудачное решение Маркуса.
Пустой, или как его еще называют, маркерный интерфейс это вполне нормальное явление, даже в готовом продукте. А вот пустой класс заранее понятно, что он должен будет что-то из себя представлять.
И кстати совсем необязательно делать общехлебный интерфейс, ведь он же понадобится только при потреблении хлеба, а не при производстве, те есть может он нам и не будет нужен совсем. Чуть более простым кажется вариант, где у печей по методу на хлеб, пирожок и торт. Ну и на кирпичи понятное дело.
Но, даже заранее не зная что будет дальше, делать их все одним классом с перечисляемым полем… ну даже не знаю, у всех свой путь самурая, конечно же.
Ну вот, сразу появились «стратегии», базовые и наследуемые классы и пр. Я имел в виду то, что «хлеб» в исходной статье это переупрощение. Вряд ли кто-то пожелает, чтоб ему закодили сделать пустой класс, без состояния и поведения, в котором только тип BakeryProduct type. В реальном мире у него будут методы и события, в каждом торте и пирожке свое, и тут получится либо четырехкратный if-else, либо большой нечитаемый switch. Если его не делать изначально базовым с наследниками, то рано или поздно он придет к состоянию, когда все придется переписать с нуля, даже если требования заказчика не метания белки по лесу, а логичные и последовательные. Принцип YAGNI он, конечно же, более чем правилен, создание лишних сущностей и лишних связей между ними Борису явно не стоило даже пытаться делать. Но и Маркуса это никак не оправдывает, и то что, благодаря переупрощению, код получился без лапши еще не означает, что в реальном проекте ее не будет.
С одной стороны не надо пытаться предусмотреть какие то «изменяющиеся сущности», которых нет в требованиях, а с другой стороны не надо писать «универсальный код», когда эти сущности уже есть, лучше его разнести по классам, а не по if-else. Тут где-то и кроется та самая золотая середина, как мне кажется…
Как мне кажется, это переупрощение. Позволю себе сочинить список требований.
1) Игра походовая. Сетка гексагональная. Солдаты ходят, друг друга рубят, либо стреляют.
2) Герой должен иметь свои характеристики, которые добавляются к солдатам, плюс сам должен уметь периодически швырять какое то заклинание. Сила регулируется какой-то характеристикой героя, плюс само заклинание может быть одного из трех уровней.
3) Добавить магов, Маги должны швырять ту же магию, что и герой по типу, но рассчет силы от количества солдат. Отличие от стрелков — магия накладывает пост-эффекты, например горение постепенно сжигает здоровье, а оглушение не дает ходить какое то время и т.п.
4) Добавить препятствия и летающих солдат. Ну и сразу непролетаемые препятствия и телепортирующихся солдат.
5) Добавить солдатам активные расходуемые навыки, например лучник может один раз за игру огненную стрелу запустить. Также пост-эффекты.
6) Добавить персональные свойства, например тяжелобронированные солдаты получают меньше урона в ближнем бою, а «ловкие» периодически уворачиваются от урона, но не от магии.
На этот момент аццкая лапша имхо обеспечена, если изначально подходить к делу энумерацией. А фантазий у геймдизайнера еще немало.
А мне напоминает «лошади продают автомобили». 123 лошади в хундае это же настолько круче, чем 107 лошадей в фольксвагене. А то что они едут при этом одинаково — кого ж это волнует.
Вот так все и играют во все игры, особенно сетевые. Печально, с тоской в глазах. А ведь кроме того, что симулятор делает предпросчет, еще есть пинг, еще есть двойной или даже тройной видеобуфер, еще есть инпут лаг на телевизоре. Сколько факторов означающих, что ты уже мертв, но еще этого не знаешь, Бггг…
Вот только если игровыми объектами движет только физика, то из этого никакой игры в принципе никогда не выйдет. Ни печальной ни радостной. Казуальщина только, вроде злых птиц.
В полезности отвязки от переменного фреймрейта сомнений нет. Есть сомнения в полезности ручной интерполяции.
В отвязке без интерполяции смысла очень мало как раз, как написал автор, движение объектов будет сильно дискретным ака рывками.
Это прекрасно, что в движке SupremeCommander'а реализован continuous collision detection.
Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
А рэгдоллы и теннисные мячики могут в игровом мире и не участвовать. Физика для них может быть также развязана по частоте от игрового мира, как и графика.
Приведу в пример игру supreme commander. Там игровой мир обсчитывается всего 10 раз за секунду. Рассчитываются не только движения юнитов и боезарядов, а еще нахождение пути A* и какой-никакой AI для тысяч этих самых юнитов.
Никаких прохождений ракет сквозь самолеты не наблюдается. Тормознутости игрового мира нет и в помине. А вот если низкий фреймрейт, то видно сразу. Теорикрафтинг это хорошо, но если развязку игрового мира от фреймрейта придумали, то значит это кому то нужно.
В какой то из статей приводилась так же и возможность изменения скорости обсчета игрового мира, при которой FPS сопадает с отсчетами игрового мира, при этом следующий отсчет рассчитывается с учетом того, сколько времени занял предыдущий, ну или среднее время нескольки предыдущих.
В сетевой игре такое неприемлемо. FPS у людей может отличаться, проблемы в этом нет, а количество отсчетов игрового мира должно совпадать. В противном случае разная погрешность вычислений приведет к тому, что объекты сместятся настолько, что, например, один игрок в другого выстрелит и попадет, а у того на системе пуля пройдет мимо и он останется жив, то есть произойдет рассинхронизация. По этой же причине исключается возможность создания так называемых реплеев.
Эта же погрешность присутствует и на отрисовке, но на ней она не накапливается.
Это — единственный образец «более строгой типизации».
Отнюдь, int нельзя присвоить в short, например, возникает ошибка предлагающая принудительный каст. Хотя «расширение» происходит автоматически.
Но это еще ладно, а вот bool меня шокировал до глубины души.
Кстати проверил в Visual C++. Не дает создать конструктор копирования с аргументом по значению. Не знаю, заслуга ли это микрософта, или 11го стандарта, но претензия была напрасна. Про невиртуальный деструктор, тем не менее, «особенность» здравствует и поныне.
Трудно спорить с «сотрудником Интела», но я все таки считаю С++ надмножеством С, и «чистый С++» оксюмороном.
Если пивот выбирается случайным образом, то вероятность худшего случая 1/(N!), если не напутал, причем от входного массива не зависит. Т.е. зависит конечно, учитывая то, что генераторы псевдослучайны. При этом, если выбирать пивот по принципу выборки трех элементов массива, и выбора среднего из них, то вероятность соотвественно еще ниже.
Мне вот просто интересно, если в процессоре изначально обойтись без этих оптимизаций с перестановками инструкций, то потом в программах можно будет обойтись без барьеров памяти, то есть мьютексы будут более просты и менее затратны.
Может это приведет к бОльшей производительности?
Года три назад решил для себя — изучаю C#, поставил студию, создал свое первое wpf приложение, и позабыл про Билдер насовсем. А теперь и обычный C++ ничего, и std::string вполне себе устраивает, И ВинФормс вполне хорош, уже не то, что разработка под mfc, которая и отпугнула в свое время. А уж компилируемый код настолько существенно быстрее работает, чем борландовский, сплошная радость. Да и вобщем то борландовский как мне показалось медленнее даже шарпового, несмотря на его не-нативность.
При сравнимых вещах обычно решает сила привычки, и даже если надо переходить, то или с тоской поглядываешь назад, или еще что, а тут как на новую ступень шагнул, и долго пинал себя пяткой, что не сделал этого раньше.
Для меня Борланд/Эмбаркадеро умер три года назад.
Совершенствоваться в применении YAGNI еще есть куда, не правда ли, хех.
PS мне не нравится, на самом деле попытка подогнать исходные данные под ответ, то есть принцип YAGNI под заведомо неудачное решение Маркуса.
И кстати совсем необязательно делать общехлебный интерфейс, ведь он же понадобится только при потреблении хлеба, а не при производстве, те есть может он нам и не будет нужен совсем. Чуть более простым кажется вариант, где у печей по методу на хлеб, пирожок и торт. Ну и на кирпичи понятное дело.
Но, даже заранее не зная что будет дальше, делать их все одним классом с перечисляемым полем… ну даже не знаю, у всех свой путь самурая, конечно же.
С одной стороны не надо пытаться предусмотреть какие то «изменяющиеся сущности», которых нет в требованиях, а с другой стороны не надо писать «универсальный код», когда эти сущности уже есть, лучше его разнести по классам, а не по if-else. Тут где-то и кроется та самая золотая середина, как мне кажется…
1) Игра походовая. Сетка гексагональная. Солдаты ходят, друг друга рубят, либо стреляют.
2) Герой должен иметь свои характеристики, которые добавляются к солдатам, плюс сам должен уметь периодически швырять какое то заклинание. Сила регулируется какой-то характеристикой героя, плюс само заклинание может быть одного из трех уровней.
3) Добавить магов, Маги должны швырять ту же магию, что и герой по типу, но рассчет силы от количества солдат. Отличие от стрелков — магия накладывает пост-эффекты, например горение постепенно сжигает здоровье, а оглушение не дает ходить какое то время и т.п.
4) Добавить препятствия и летающих солдат. Ну и сразу непролетаемые препятствия и телепортирующихся солдат.
5) Добавить солдатам активные расходуемые навыки, например лучник может один раз за игру огненную стрелу запустить. Также пост-эффекты.
6) Добавить персональные свойства, например тяжелобронированные солдаты получают меньше урона в ближнем бою, а «ловкие» периодически уворачиваются от урона, но не от магии.
На этот момент аццкая лапша имхо обеспечена, если изначально подходить к делу энумерацией. А фантазий у геймдизайнера еще немало.
Вот только если игровыми объектами движет только физика, то из этого никакой игры в принципе никогда не выйдет. Ни печальной ни радостной. Казуальщина только, вроде злых птиц.
Для интерполяции не нужно детектирование коллизий. Интерполяция происходит между двумя просчитанными состояниями. Коллизии уже просчитаны. Экстраполяция отсутствует. Фиксед.
Никаких прохождений ракет сквозь самолеты не наблюдается. Тормознутости игрового мира нет и в помине. А вот если низкий фреймрейт, то видно сразу. Теорикрафтинг это хорошо, но если развязку игрового мира от фреймрейта придумали, то значит это кому то нужно.
В сетевой игре такое неприемлемо. FPS у людей может отличаться, проблемы в этом нет, а количество отсчетов игрового мира должно совпадать. В противном случае разная погрешность вычислений приведет к тому, что объекты сместятся настолько, что, например, один игрок в другого выстрелит и попадет, а у того на системе пуля пройдет мимо и он останется жив, то есть произойдет рассинхронизация. По этой же причине исключается возможность создания так называемых реплеев.
Эта же погрешность присутствует и на отрисовке, но на ней она не накапливается.
Перепутал с джавой, видимо.
Отнюдь, int нельзя присвоить в short, например, возникает ошибка предлагающая принудительный каст. Хотя «расширение» происходит автоматически.
Но это еще ладно, а вот bool меня шокировал до глубины души.