Qualiant, Суммируйте интервал между кадрами, если сумма больше или равна заданному интервалу, то пересчитывайте логику. Если активных объектов будет очень много, то удобнее обновлять состояние отдельных объектов с большим временным интервалом. Напрмиер, траектория движения юнита будет обновляться раз в 5 секунд, но моменты выполения этого обновления для разных юнитов будут разными. Т.е. для каждого юнита будет считаться время с последнего обновления.
Видимо, я слишком буквально понял слово "таймер". Именно системный таймер, генерирующий события через заданные интервалы - не нужен. А переменная, в которой суммируется или всё время игры или какие интервалы - очень нужная и их может быть столько, сколько удобно для реализации игровой логики. Скорее всего, такой же таймер будет в каждом активном объекте и в статичных объектах, у которых есть анимация.
Про WinAPI плюсану. По нужде много лет пришлось программировать голый WinAPI и MFC. Теперь появилась возможность испоьзвоать что-то ещё и ОЧЕНЬ некомфотно переходить на QT. Иная идеология, всё по другому, всё непривычно. Лучше сразу изучать QT, чтобы не привыкать к плохому, а сразу учиться делать как белый человек.
*опускаться до WinAPI не стоит до тех пор, пока есть альтернативы
Евгений Шатунов, Нет. В стандарте указано А и Б. Если А и Б выполняется, то тривиальный. Если не выполняется, то не тривиальный. Оговорка в том, что выполнение А и Б не гарантирует, что тип тривиальный, хотя в приведённой ВАМИ ссылке указано, что у тривиального типа выполняется А и Б. Т.е. А и Б это необходимое, но не достаточное условие. Достаточность в стандарте не указана, потому что определяется логикой программы. Фактически, по стандарту, вообще не может существовать тривиального типа, содержащего указатель, потому что невозможно доказать его тривиальность, не имея всего кода приложения. Один и тот же класс может быть тривиальным и не тривиальным в зависимости от использующего класс кода.
Евгений Шатунов, Ещё раз повторю, чтобы вы точно поняли. Тривиальный конструктор копирования создаётся компилятором. Если вы сами его пишите, то это нетривиальный конструктор и объект перестаёт быть тривиальным. И ваш пример ассертит тогда.
Евгений Шатунов, Повторяю. А - содержит только тривиальные типы, Б - имеет тривиальный конструктор копирования. В вашем примере тривиальный конструктор копирования, поэтому А и Б выполняется. Напиши конструктор копирования и сработает ассерт.
Оговорка - не из стандарта. Сама оговорка: если объект не владеет адресуемым объектом, то он может быть тривиальным. т.е. допускает побайтовое копирование указателя без нарушения инварианта. Это настолько очевидные вещи, что я не понимаю, о чём мы говорим. Иначе класс прсто неправильно реализован. Правильную и неправильную реализацию формализовать нельзя (без явной аттрибуции), потмоу что и тот и тот код может быть верным в зависимости от "оговорок".
А и Б сложите вообще через & из той ссылки, которую вы дали. Сами пишите неправильныи пример, проверяющий не то, о чём мы говорим и используете это в качестве доказательной базы...
Вообще, я очень надеюсь, что в стандарте это помечено как UB.
Евгений Шатунов, По вашей ссылке написано, тип тривиальный, если А(скаляр) и Б(тривиальный коснтруктор копирования). Б не выполняется, значит - не тривиальный. Мне не с чем соглашаться.
В первом же сообщении я написал "и с кучей оговорок об использовании". Понимание происходящег и, что воообще там программируешь попадает под "оговорки".
Евгений Шатунов, Адресуемый указателем объект находится по указателю вне памяти "хозяина", а не по значению и имеет время жизни до удаления в деструкторе или до падения программы (если не реализован сборщик мусора). Всё, мне надоел этот офтоп. Если вам интересно, читайте стандарт. Мне не интересно пререкаться по всяким придиркам.
Евгений Шатунов, "и транслятор эту ошибку не обозначит. "
Именно поэтому я даже предположить не мог, что объект с указателем формально может считаться тривиальным. По вашей ссылке написано: "тривиальный конструктор копирования (и прочее тривиальное)", если конструктор не тривиальный, то весь объект более не тривиальный. Без привязки к указателям. Если объект владеет адресуемым объектом, то, в корректно реализованном объекте, будет нетривиальный конструктор копирования(присваивание) и деструктор. Исключением будет только "= delete" конструктор копирования и тривиальный деструктор с утечкой памяти. Так что я не понимаю, где вы видите формальное "разрешение" указателей в тривиальных объектах. Требование тривиального конструктора копирования делает объект с указателями (с владением) нетривиальным. По моему, это написано понятно и достаточно формализовано.
Евгений Шатунов, первая же строчка по вашей ссылке "T is TrivialType (that is, a scalar type, a trivially copyable class with a trivial default constructor". Если !"trivially copyable class", то это не TrivialType. Именно это я имел в виду под "по определению".
В любом случае, тривиальный или нет, но наличие указателя запрещает "сериализацию" бинарного дампа памяти всего объекта разом. Всё, я потерял интерес к этой теме.
Евгений Шатунов, Я не вижу противоречий. Если объект не владеет адресуемым объектом, то он может быть тривиальным, несмотря на наличие ссылки или указателя. Если он владеет объектом, то, по определению (из данной вами ссылки), не может быть тривиальным, потому что у него будет нетривиальный конструктор копирования и деструктор (не рассматриваем вариант с утечкой памяти).
Евгений Шатунов, Вы сами мне документ скинули про "тривиальные". Там английским по белому написано, что такое тривиальный тип. Сам по себе указатель - тривиальный тип, но класс, содержащий указатель (и владещющий адресуемым объектом) не является тривиальным типом.
Евгений Шатунов, тривиальные типы по определению не могут содержать ссылки или указатели. POD тоже. Нет конструктора копирования по умолчанию - не тривиальный. Пожалуй, только одно исключение могу придумать, если в POD структуре есть указатель, но объект им не владеет и не управляет временем жизни, тогда конструктор копирования по умолчанию можно использовать. Но я никогда не считал за POD объекты с указателями, поэтому даже как-то не подумал про это.
RADION NAZMIEV, Потому что тогда этот using переносится во все h/cpp файлы, куда был подключен этот хедер и куда были подключены хэдеры, вкулючающие этот хэдер и т.д. фактически, это равносильно отсутствию пространства имён.
using namespace можно спокойно использовать внутри функций (даже если они внутри хэдера) и внутри cpp файлов, но уже с опаской. Внутри хэдеров в 99,999% случаев using namespace испоьзовать нельзя.
Ярослав Иванов,
логовед - кто разбирается в логах
логовод - кто ведёт логи
логоводовед - кто разбирается в тех, кто ведёт логи
И не надо путать терминологию.
Видимо, я слишком буквально понял слово "таймер". Именно системный таймер, генерирующий события через заданные интервалы - не нужен. А переменная, в которой суммируется или всё время игры или какие интервалы - очень нужная и их может быть столько, сколько удобно для реализации игровой логики. Скорее всего, такой же таймер будет в каждом активном объекте и в статичных объектах, у которых есть анимация.