АР
потому что для некоторых API реально лучше не придумаешь
struct S { .... };
void foo(S s);
foo({.a = 15, .x = 4, .b = "foo"});Size: a a a
2020 November 09
АК
хм. Просто раньше я думал что можно сделать что-то типа
так делай, просто порядок
a, x и b сохраняйАК
пропускать поля никто не запрещает
VO
я думал их задача собственно и была решить проблему "инициализировать надо в прямом порядке"
Чему я и удивляюсь. Ну и это несовместимость с обычным си
VO
это не проблема, а требование (следствие порядка вызова деструкторов), которое все вечно любили нарушать, инициализируя поля в конструкторе абы как (получая варнинги, в крайнем случае).
хоть с designated initializers не накосячили - сразу запретили
хоть с designated initializers не накосячили - сразу запретили
Причем тут деструкторы?
АК
Причем тут деструкторы?
отвечу вопросом на вопрос - почему инициализаторы полей в конструкторе класса всегда вызываются в порядке объявления полей в классе, а не в порядке, прописанном руками в инициализации?
АР
Чему я и удивляюсь. Ну и это несовместимость с обычным си
ну в си в принципе нет нетривиальных полей, поэтому там порядок примерно по барабану
VO
Что то я с утра вопроса не понял. У нас есть конструктор, в нем код. в этом коде поля и инициализируются
АР
кроме конечно явных спецэффектов
АР
типа {.x = i++, .y = i++}
VO
Ну и тут могли бы для тривиальных как минимум разрешить
ПК
Что то я с утра вопроса не понял. У нас есть конструктор, в нем код. в этом коде поля и инициализируются
Но поля в конструкторе инициализируются не в том порядке что ты написал, а а порядке объявления в классе
ПК
И при проёбе порядка ты не получаешь ошибку компиляции (баг стандарта, я считаю). Поэтому можно минусануть себе ногу легко. С designated тут понадежнее
ПК
Ну и тут могли бы для тривиальных как минимум разрешить
Лучше одно правило для всех, ато ещё разбираться каждый раз кто тут тривиальный
VO
Но поля в конструкторе инициализируются не в том порядке что ты написал, а а порядке объявления в классе
Про какой порядок речь? В каком случае?
VO
Ну офысетофф значит можно а тут нельзя?
АК
Про какой порядок речь? В каком случае?
struct A {
int x, y;
A() : y(1), x(y) {}
};EP
всем привет подскажите плз
class B : public class A{
void foo() override{
this->A::foo();
std::invoke(&A::foo, this);
}
};
std::invoke уходит в рекурсию, почему this->A::foo() отрабатывает норм?
class B : public class A{
void foo() override{
this->A::foo();
std::invoke(&A::foo, this);
}
};
std::invoke уходит в рекурсию, почему this->A::foo() отрабатывает норм?
VO
Ну тут не задумывался, не знал даже. Они решили это же на десигнатес натянуть?
АК
Evgen Pervenenko
всем привет подскажите плз
class B : public class A{
void foo() override{
this->A::foo();
std::invoke(&A::foo, this);
}
};
std::invoke уходит в рекурсию, почему this->A::foo() отрабатывает норм?
class B : public class A{
void foo() override{
this->A::foo();
std::invoke(&A::foo, this);
}
};
std::invoke уходит в рекурсию, почему this->A::foo() отрабатывает норм?
вызов по указателю на мембер-функцию получается виртуальным.
можно упростить до:
можно упростить до:
this->A::foo() - вызовется A::foo(this->*&A::foo)() - вызовется foo, как виртуальная