Минусы: больший объём памяти, необходимый для выполнения.
А теперь я предлагаю вам подтвердить своё утверждение результатами тестов, где ваш сравниваемый код на javascript требует для выполнения меньше памяти.
Оператор простого присвоения нельзя определить вне класса. Впрочем для остальных операторов правило не меняется, при объявлении вне класса стоит возвращать референс на первый аргумент, а не значение.
Реализуя Linux версию, мы сразу решили, что обязательно надо поддержать отслеживание запусков компилятора. Это поможет программистам быстрее и проще знакомиться с анализатором PVS-Studio. Дело в том, что, используя эту утилиту, проект сможет проверить любой член команды, не отвлекая людей, занимающихся поддержкой makefile-ов и вообще системы сборки. В больших проектах далеко не каждый знает, как собственно собирается их приложение. Тем более, не каждый найдет время и желание разбираться, как и куда прописать вызов PVS-Studio. Всё это ещё может быть усложнено наличием автогенерируемого makefile. Понятно, что во всём можно разобраться, но это является существенным барьером на пути первой проверки проекта и удовлетворения исследовательского любопытства.
Сомнительная функция, допустим у меня в makefile что-то такое:
Тем более, что сборка часто запускается в много потоков, отжирая все 100% ресурсов машины. В таких условиях сложно синхронизировать параллельную работу компилятора и анализатора. А исходники к тому же могут быть как временными файлами, так и просто потоками.
Самым универсальным способом для любой системы сборки была бы замена компилятора, например:
CXX="pvs g++" make
При этом собственно сначала отрабатывает анализатор, который получает на вход всю нужную команду компилятора, а затем передает эстафету компилятору.
Впрочем standalone версия, без запуска компиляции, тоже была бы полезна. Я бы, например, использовал анализатор как дополнительный шаг сборки в пререквизитах для компиляции.
Ну и совсем шикарно если бы вы учли возможность кросс-компиляции. У существующих анализаторов с этим как-то не очень.
Если дело пойдет, буду агитировать за внедрение вашего продукта у нас. Удачи!
Извините, но компилятор всё делает правильно, это вы где-то запутались.
Что мы тут видим? А видим мы боль. Компилятор проигнорировал тот факт, что конструкторы и деструкторы M имеют глобальные побочные эффекты. Умный компилятор выбросил из нашей логической цепочки:
— создание копии m1 для передачи копии локального объекта как результата работы функции;
— вызов деструктора локального объекта m1 (что логично после выполнения первого пункта).
Деструктор локального объекта был вызван только после вызова конструктора копирования m2/m3.
В итоге — I изменилась не на 10, а на 6.
Ничего компилятор не проигнорировал. В этом случае вообще нет copy elision. Создал временный объект, скопировал его, вызвал деструктор. И так два раза. Итого 6. Деструкторы объектов m2 и m3 вызываются уже при выходе из main(). А вот что действительно вызывает вопрос: почему в вашем выводе не присутствует вывода из этих деструкторов. Корректный результат, который получаю я, должен выглядеть так:
M(100)
M(const M &obj)
~M()
M(-100)
M(const M &obj)
~M()
6
~M()
~M()
В следующем примере у вас вообще undefined behavior, так как вы возвращаете ссылку на временный объект. Обратный порядок вызова копирующего конструктора и деструктора обусловлен тем, что вы не продлеваете время жизни временных объектов, возвращая иx по значению. Они удаляются до выхода из функции.
Copy elision это очень полезная оптимизация, и в 99.999% случаев она обладает не только желаемым, но и вполне очевидным для программиста поведением, а вы её выставляете как какое-то зло и источник проблем.
P.S. Здесь вы забыли вернуть значение:
M &operator=(const M &obj)
{
/* Копирующий оператор присваивания */
i = obj.i;
cout << "M &operator=(const M &obj)" << endl;
}
У степени двойки установлен всего один бит, у n-1 этот бит будет сброшен и их конъюнкция гарантированно даст 0. Условие выполняется только для степени двойки, т.к. при наличии более одного установленного бита будет сброшен только младший.
Ни разу не видел более плохого решения, вы хотите получить целое число, но при этом используете логарифмы и экспоненты для такой тривиальной задачи. К тому же у вас по условию только целочисленная арифметика.
public class Solution {
public static int recursion(int n, int i) {
return (n==0) ? i : recursion( n/10, i*10 + n%10 );
}
public static void main(String[] args) {
System.out.println(recursion(158, 0));
}
}
Всё, что «отсутствует» в C++ элементарно может быть реализовано:
#include <boost/variant.hpp>
#include <iostream>
#include <utility>
template <class T, class E>
class Result {
public:
template <class U>
Result( U&& obj )
: value( std::forward<U>( obj ) )
{
}
T unwrap() &&
{
assert( value.which() == 0 );
return std::move( boost::get<T>( value ) );
}
template <class F>
Result or_else( F f ) &&
{
if ( value.which() == 0 ) {
return std::move( boost::get<T>( value ) );
}
else {
return f();
}
}
private:
boost::variant<T, E> value;
};
class File {
public:
static Result<File, bool> open( const std::string& s )
{
if ( s == "exist" ) {
return File{};
}
else {
return false;
}
};
};
int main()
{
auto file = File::open( "unexist" ).or_else( [] { return File::open( "exist" ); } ).unwrap();
}
Третее – не уверен, что в С++ получится c такой же легкостью передавать в комбинаторы замыкания, которые в результате будут заинлайнены и не будут создавать каких-либо накладных расходов
А теперь я предлагаю вам подтвердить своё утверждение результатами тестов, где ваш сравниваемый код на javascript требует для выполнения меньше памяти.
Сомнительная функция, допустим у меня в makefile что-то такое:
Тем более, что сборка часто запускается в много потоков, отжирая все 100% ресурсов машины. В таких условиях сложно синхронизировать параллельную работу компилятора и анализатора. А исходники к тому же могут быть как временными файлами, так и просто потоками.
Самым универсальным способом для любой системы сборки была бы замена компилятора, например:
При этом собственно сначала отрабатывает анализатор, который получает на вход всю нужную команду компилятора, а затем передает эстафету компилятору.
Впрочем standalone версия, без запуска компиляции, тоже была бы полезна. Я бы, например, использовал анализатор как дополнительный шаг сборки в пререквизитах для компиляции.
Ну и совсем шикарно если бы вы учли возможность кросс-компиляции. У существующих анализаторов с этим как-то не очень.
Если дело пойдет, буду агитировать за внедрение вашего продукта у нас. Удачи!
И резуьтат работы программы будет несколько отличным от приведенного в статье:
Вывод который сделал автор о работе программы не имеет отношения к copy elision. И на его компиляторе оптимизации не происходило.
Ничего компилятор не проигнорировал. В этом случае вообще нет copy elision. Создал временный объект, скопировал его, вызвал деструктор. И так два раза. Итого 6. Деструкторы объектов m2 и m3 вызываются уже при выходе из main(). А вот что действительно вызывает вопрос: почему в вашем выводе не присутствует вывода из этих деструкторов. Корректный результат, который получаю я, должен выглядеть так:
В следующем примере у вас вообще undefined behavior, так как вы возвращаете ссылку на временный объект. Обратный порядок вызова копирующего конструктора и деструктора обусловлен тем, что вы не продлеваете время жизни временных объектов, возвращая иx по значению. Они удаляются до выхода из функции.
Copy elision это очень полезная оптимизация, и в 99.999% случаев она обладает не только желаемым, но и вполне очевидным для программиста поведением, а вы её выставляете как какое-то зло и источник проблем.
P.S. Здесь вы забыли вернуть значение:
Сделаем вот такие хелперы:
Тогда программа будет выглядеть вот так:
Ни разу не видел более плохого решения, вы хотите получить целое число, но при этом используете логарифмы и экспоненты для такой тривиальной задачи. К тому же у вас по условию только целочисленная арифметика.
Всё будет заинлейнено.
Но что мешает использовать тот же подход в C++/Java?