Сообщение Re[3]: Приведение базового класса в конструкторе потомка от 03.09.2019 5:17
Изменено 03.09.2019 8:04 rg45
ЕМ>Чтобы оптимизатор делал передачу структур до 64 разрядов через регистры. Впрочем, для не-POD этого, похоже, не добиться — он всегда генерит временную переменную, даже если по факту никаких вызовов конструкторов/деструкторов там нет (все вычисляется во время компиляции).
R>>почему конструктор не explicit
ЕМ>Именно, чтобы можно было преобразовывать неявно.
Я думаю, тебе полезно будет освежить в памяти рекомендации из этой чудесной книженции:
C++ Coding Standards. 101 Rules, Guidelines, and Best Practices.
(Цитаты взяты из русского перевода книги).
Правило №8. Не оптимизируйте преждевременно
Передача параметров по ссылке (рекомендация 25), использование префиксной формы операторов ++ и -- (рекомендация 28) или подобных идиом, которые при работе должны естественным образом "стекать с кончиков ваших пальцев", преждевременной оптимизацией не являются. Это всего лишь устранение преждевременной пессимизации (рекомендация 9).
Правило №9. Не пессимизируйте преждевременно
Избежание преждевременной оптимизации не влечет за собой снижения эффективности. Под преждевременной пессимизацией мы подразумеваем написание таких неоправданных потенциально неэффективных вещей, как перечисленные ниже.
- Передача параметров по значению там, где применима передача параметров по ссылке (рекомендация 25).
Правило №15. Активно используйте const
Пример. Избегайте const в объявлениях функций, принимающих параметры по значению. Два следующих объявления абсолютно эквивалентны:
void Fun( int x ); void Fun( const int x ); // Объявление той же самой функции: // const здесь игнорируется
Во втором объявлении модификатор const избыточен. Мы рекомендуем объявлять функции без таких высокоуровневых модификаторов const, чтобы тот, кто читает ваши заголовочные файлы, не был дезориентирован...
Правило №40. Избегайте возможностей неявного преобразования типов
Не все изменения прогрессивны: неявные преобразования зачастую приносят больше вреда, чем пользы. Дважды подумайте перед тем, как предоставить возможность неявного преобразования к типу и из типа, который вы определяете, и предпочитайте полагаться на явные преобразования (используйте конструкторы, объявленные как explicit, и именованные функции преобразования типов).
ЕМ>Чтобы оптимизатор делал передачу структур до 64 разрядов через регистры. Впрочем, для не-POD этого, похоже, не добиться — он всегда генерит временную переменную, даже если по факту никаких вызовов конструкторов/деструкторов там нет (все вычисляется во время компиляции).
R>>почему конструктор не explicit
ЕМ>Именно, чтобы можно было преобразовывать неявно.
Я думаю, тебе полезно будет освежить в памяти рекомендации из этой чудесной книженции:
C++ Coding Standards. 101 Rules, Guidelines, and Best Practices.
(Цитаты взяты из русского перевода книги).
Правило №8. Не оптимизируйте преждевременно
Передача параметров по ссылке (рекомендация 25), использование префиксной формы операторов ++ и -- (рекомендация 28) или подобных идиом, которые при работе должны естественным образом "стекать с кончиков ваших пальцев", преждевременной оптимизацией не являются. Это всего лишь устранение преждевременной пессимизации (рекомендация 9).
Правило №9. Не пессимизируйте преждевременно
Избежание преждевременной оптимизации не влечет за собой снижения эффективности. Под преждевременной пессимизацией мы подразумеваем написание таких неоправданных потенциально неэффективных вещей, как перечисленные ниже.
- Передача параметров по значению там, где применима передача параметров по ссылке (рекомендация 25).
Правило №15. Активно используйте const
Пример. Избегайте const в объявлениях функций, принимающих параметры по значению. Два следующих объявления абсолютно эквивалентны:
void Fun( int x ); void Fun( const int x ); // Объявление той же самой функции: // const здесь игнорируется
Во втором объявлении модификатор const избыточен. Мы рекомендуем объявлять функции без таких высокоуровневых модификаторов const, чтобы тот, кто читает ваши заголовочные файлы, не был дезориентирован...
Правило №40. Избегайте возможностей неявного преобразования типов
Не все изменения прогрессивны: неявные преобразования зачастую приносят больше вреда, чем пользы. Дважды подумайте перед тем, как предоставить возможность неявного преобразования к типу и из типа, который вы определяете, и предпочитайте полагаться на явные преобразования (используйте конструкторы, объявленные как explicit, и именованные функции преобразования типов).