Pull to refresh
-13
@1vanKread⁠-⁠only

User

Send message

Ну то что код становится проще для понимания и компактнее и так очевидно. И ничего особо продумывать не надо. Проперти это просто такой вид функции с другим синтаксисом

Т.е. предлагается не использовать типы с фиксированным размером вообще, ведь где-то в какой-то внешней библиотеке может ожидаться тип переменного размера?

Проперти - это просто такой вид функции (только без скобочек). Все остальное - Ваши выдумки

А еще хочется, чтоб их прорвало стандартизировать типы с фиксированным размером. Например int64_t зависит от компилятора:

  • GCC 32, Clang 32, VS 32, VS 64 - long long

  • GCC 64, Clang 64 - long

Следущий код успешно скомпилируют VS 32, VS 64 и GCC 32, но не скомпилирует GCC 64:

#include <cstdint>

struct S
{
    S(int i32) {}
    S(long long i64) {}
};

int main()
{
    int64_t x;
    S s(x);
}

GCC 64 просто не сможет выбрать, какой из двух конструкторов использовать.

Что нужно чтобы их прорвало добавить property в C++ ?

Вы удивитесь, но при создании любой библиотеки, 100% времени тратится на обустройство удобств дальнейшего программирования. Любая библиотека сама по себе даже не запускается

когда я вижу код вида a.b = c в С++ я по умолчанию считаю, что b это переменная,

В нормально используемом C++ в 99% времени у вас нет доступа к полям напрямую (это же не Си), а только через методы.

т.е. оверхед от обращения к ней минимален и я могу к ней обращаться таким образом сотни раз к примеру, а тут вдруг оказывается, что там каждый раз могут производится какие-то вычисления, которые могу быть отнюдь не быстрыми.

Если бы в С++ были проперти наряду с обычными функциями, то никто бы не запрещал для "тяжелых" функций не использовать проперти, а оставлять из функциями. Лучше, когда выбор есть, чем когда его вообще нет

По поводу физки. В игре оригинальная обработка столкновений или самостоятельно придуманная?

Более актуальная версия этой и других статей находится на ГитХабе: https://github.com/urho3d-learn/post-effects

Более актуальная версия этой и других статей находится на ГитХабе: github.com/urho3d-learn/materials

Более актуальная версия этой и других статей находится на ГитХабе: https://github.com/urho3d-learn/flappy-urho

Более актуальная версия этой и других статей находится на ГитХабе: https://github.com/urho3d-learn/editor

Более актуальная версия этой и других статей находится на ГитХабе: https://github.com/urho3d-learn/editor

Более актуальная версия статьи находится на ГитХабе: https://github.com/urho3d-learn/first-steps

А почему у мужика на последнем арте рука сквозь щит торчит? Мне кажется, щит иначе работает. Или это какой-то специальный щит, чтоб только руку оторовало, когда пушку зажигаешь?

А что за неустойка? Гос дума зарабатывала на видосиках в Ютубе?

Не до конца понимаю. Компилятор считает, что char* может перекрываться с чем угодно. Тогда зачем для задачи

Но что, если мы хотим реализовать каламбур массива unsigned char в серию unsigned int и затем выполнить операцию с каждым значением unsigned int? Мы можем использовать memcpy, чтобы превратить массив unsigned char во временный тип unsinged int.

использовать memcpy?

Цитата из https://github.com/alexanius/understanding_strict_aliasing/blob/master/understanding_strict_aliasing.markdown

Символьный тип. Типам char*, signed char*, или unsigned char* спецификация разрешает в особом порядке указывать на всё что угодно. Это значит, что они могут указывать на любую область памяти.

Т.е. компилятор должен предполагать, что unsigned char* и unsigned int* прекрываются и не оптимизировать там ничего

очень полезная и понятная статья, спасибо

Как связаны заголовок и содержимое статьи?

Information

Rating
Does not participate
Registered
Activity