Здравствуйте, sergey2b, Вы писали:
S>Подскажите пожалуйста есть ли варианты инициализировать переменную в конструкторе
S>class Viewer { S>public: S>Viewer(std::string suffix): S> kWindowName_(suffix.empty() ? kWindowName_ : kWindowName_ + " " + suffix){}; S>private: S> const std::string kWindowName_{"Video Viewer"}; S>};
S>данный код генерирует ошибку error G99FBF662: field 'kWindowName_' is uninitialized when used here
Здравствуйте, xma, Вы писали:
xma>это же константа, как ты её в теле конструктора изменишь — её либо сразу, либо в списке инициализации конструктора только можно задать
Здравствуйте, xma, Вы писали:
xma>Здравствуйте, T4r4sB, Вы писали:
TB>>добавил статик чтоб не хранить лишний элемент
xma>а точно ли так можно ? а то в старых стандартах C++ статические константные строки нельзя было инициализировать прямо в классе только за его пределами
Набирал в браузере, а так нельзя, да
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, sergey2b, Вы писали:
S>Подскажите пожалуйста есть ли варианты инициализировать переменную в конструкторе
Самый простой и чистый способ — это разнести труъ константу "дефолтное значение" и рантайм-константное поле.
И вынести код конструирования значения в функцию, для удобства.
class Viewer {
private:
static constexpr std::string_view kDefaultWindowName = "Video Viewer";
static std::string make_window_name(std::string_view suffix) {
std::string name{kDefaultWindowName};
if (!suffix.empty()) { name += " "; name += suffix; }
return name;
}
const std::string kWindowName = make_window_name(""); // для единообразия будем инициализировать поле так же, как в конструктореpublic:
V(std::string_view suffix) : kWindowName{make_window_name(suffix)} { ..... }
V() { ..... } // дефолтная инициализация поля - и какая-то копипаста тела конструктора с вариациями
V(SpecialTagAhaha) : V("special suffix ahaha") {} // ну или повторное использование самого универсального конструктора, который все поля руками настроил
};
Здравствуйте, sergey2b, Вы писали:
S>Подскажите пожалуйста есть ли варианты инициализировать переменную в конструкторе
S>class Viewer { S>public: S>Viewer(std::string suffix): S> kWindowName_(suffix.empty() ? kWindowName_ : kWindowName_ + " " + suffix){}; S>private: S> const std::string kWindowName_{"Video Viewer"}; S>};
S>данный код генерирует ошибку error G99FBF662: field 'kWindowName_' is uninitialized when used here
TB>>>добавил статик чтоб не хранить лишний элемент
xma>>а точно ли так можно ? а то в старых стандартах C++ статические константные строки нельзя было инициализировать прямо в классе только за его пределами
TB>Набирал в браузере, а так нельзя, да
Здравствуйте, B0FEE664, Вы писали:
BFE>Стоит отметить, что делать константы приватными смысла нет.
А это уж на усмотрение.
Такая константа вполне может быть деталью реализации, на которую не следует закладываться извне.
Вот захотим переименовать окошко, или захотим прикрутить туда l10n/i18n, и всё, константа не константа. У ней поменяется время жизни, например. И уже нельзя будет просто так взять и обращаться на стадии before-main.
Но с другой стороны, захотим прибить гвоздями, сэкономить на спичках, дать гарантии загрузки динамических библиотек, — и сделаем её настоящей статической константой, а то и вовсе констэкспром (как я, собственно, и сделал для примера).
Здравствуйте, xma, Вы писали:
xma>а точно ли так можно ? а то в старых стандартах C++ статические константные строки нельзя было инициализировать прямо в классе только за его пределами
Помимо этого в старых версиях стандарта порядок инициализации модулей был неопределен (поменялось что-нибудь с тех пор?), поэтому можно получить красоту, когда конструктор Viewer вызовется до того как kWindowName_Base будет инициализирован.
Здравствуйте, alsemm, Вы писали:
A>Помимо этого в старых версиях стандарта порядок инициализации модулей был неопределен (поменялось что-нибудь с тех пор?),
Всё так и осталось.
A>поэтому можно получить красоту, когда конструктор Viewer вызовется до того как kWindowName_Base будет инициализирован.
Да, но для этого зависимости между модулями нужно закрутить похитрее. Ну и чтобы налететь на эту проблему, у константы должно быть внутреннее связывание, всё-таки наверное. Что-то типа такого: http://rsdn.org/forum/cpp/3509539.1