class A {
int m_a;
public:
constexpr A(int a) : m_a(a) {}
constexpr int a() const { return m_a; }
};
constexpr int fib(int v) { ... }
int main() {
A a1(1);
A a2(2);
int fib1 = fib(a1.a());
int fib2 = fib(a2.a());
}
И fib1, и fib2 инициализированы на стадии компиляции. У каждого класса свои данные, их не нужно помечать constexpr, чтобы провести инициализацию во время компиляции, и static тут вообще не причем.
Да, смысла от конструктора перемещения из константной ссылки нету. Я так и написал в статье. Оптимизировать что-либо такой конструктор не поможет. Чтобы получить ускорение, нужно избавиться от const. Суть статьи, как раз в том, чтобы предупредить хабрачитателей о таком неочевидном моменте.
Ваш пример неверен. Обратите внимание: у Саттера объекты возвращаются по значению. В этом случае можно поймать временный объект константной ссылкой, избежав лишнего копирования, и использовать его пока жива ссылка.
Ни в коем случае нельзя возвращать ссылки на локальные объекты из функций. Если Вы добавите немного вывода (output) в деструктор объекта и после получения объекта в функции main(), то убедитесь, что объект уничтожен до того, как Вы попытаетесь его использовать.
В документации Qt вы не найдёте описания функций работы с Canvas (что, в общем-то, логично), поэтому обратимся к сторонним источникам (первый результат гугла по запросу «canvas functions»).
Конечно. Спецификация OpenGL и GLSL — это как документация API, одна сухая теория. В книге содержатся более развернутое описание области, советы по практическому применению, примеры.
Все это, конечно, звучит очень круто, но мы можем видеть лишь «свет прошлого» только от сильных звезд, да все, что находилось на пути этого света. Люди не отражают столько света, чтобы увидеть что-то интересное. Да и много ли интересного Вы увидели бы глядя на головы людей?
При return value optimization в обоих случаях не будет вызвано конструкторов копирования вообще. Объекты сразу будут созданы на месте получения результата из функции.
Раз уж говорите, что важно понимать код, то нужно действительно понимать его:
Количество вызовов конструкторов копирования и деструкторов в обоих случаях одиннакого. В случае отсутствия return value optimization, временный объект, как и объект на стеке, будет создан, скопирован в другой временный объект (на время развертывания стека) и уничтожен.
Следующий код был скомпилирован на g++ 4.7.2 с опцией -fno-elide-constructors и в обоих случаях показал по 2 вызова конструктора копирования и деструктора (результат в конце): http://pastebin.com/VSgweiLM
P.S. хотя с эстетической точки зрения я тоже предпочитаю второй вариант
Хотя суть от этого не сильно меняется.
И
fib1
, иfib2
инициализированы на стадии компиляции. У каждого класса свои данные, их не нужно помечатьconstexpr
, чтобы провести инициализацию во время компиляции, иstatic
тут вообще не причем.const
пометить нельзя.this
, поэтому такие функции ведут себя так же, как и функции-нечлены.Ни в коем случае нельзя возвращать ссылки на локальные объекты из функций. Если Вы добавите немного вывода (output) в деструктор объекта и после получения объекта в функции main(), то убедитесь, что объект уничтожен до того, как Вы попытаетесь его использовать.
То, что Вы описали, — это контекст, он в документации есть: qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-context2d.html
P.S. Прошел по ссылке на статью википедии о Jedi Academy. Жанр: Шутер от первого/третьего и четвёртого лица слэшэр. Кто-нибудь знает, как это?
Интересно, будут ли теперь выходить новые издания The Orange Book?
Странно, что еще никто не привел цитату Билла Гейтса… Наверное всем лень.Ах нет же, мне просто было лень читать комментарии…
Количество вызовов конструкторов копирования и деструкторов в обоих случаях одиннакого. В случае отсутствия return value optimization, временный объект, как и объект на стеке, будет создан, скопирован в другой временный объект (на время развертывания стека) и уничтожен.
Следующий код был скомпилирован на g++ 4.7.2 с опцией -fno-elide-constructors и в обоих случаях показал по 2 вызова конструктора копирования и деструктора (результат в конце): http://pastebin.com/VSgweiLM
P.S. хотя с эстетической точки зрения я тоже предпочитаю второй вариант
При конфигурации, указав параметр -mp, можно ускорить время сборки, распараллелив ее на все ресурсы процессора.
Hint 2:
Так же полезно указывать -nomake tests -nomake examples, чтобы избежать излишней компиляции.