#cpp #boost
Интересная библиотека. И ещё один из примеров использования CRTP(первым можно назвать std::enable_shared_from_this).
https://www.boost.org/doc/libs/1_67_0/libs/utility/operators.htm
Интересная библиотека. И ещё один из примеров использования CRTP(первым можно назвать std::enable_shared_from_this).
https://www.boost.org/doc/libs/1_67_0/libs/utility/operators.htm
this->notes.
#cpp #poll Предположим, имеем такой код: int x(1); new(&x) int(5); Вызывает ли этот код undefined behaviour? (можно пояснить свой ответ в комментариях 🙂 ) Ответ выложу завтра.
#cpp #stackoverflow
Ответ: нет.
Как и писали в комментариях, могут возникнуть вопросы при использовании объекта, переконструированного на стеке. Однако таких не будет.
Давайте рассмотрим случай not trivially destructible типа. При данном коде деструктор будет вызван лишь единожды, что может привести к утечкам памяти, если класс имеет своими полями некоторые указатели. Потому необходимо сделать явный вызов деструктора, после чего уже можно использовать placement new на это место.
Кто-то скажет, что использование объекта после вызова деструктора по стандарту является неопределённым поведением, но в данном случае мы используем не сам объект, а его storage.
Вот ссылка на вопрос с so, где сообщество поясняло мне за этот случай: https://stackoverflow.com/questions/69062579/is-using-placement-new-with-variable-on-the-stack-is-correct
Ответ: нет.
Как и писали в комментариях, могут возникнуть вопросы при использовании объекта, переконструированного на стеке. Однако таких не будет.
Давайте рассмотрим случай not trivially destructible типа. При данном коде деструктор будет вызван лишь единожды, что может привести к утечкам памяти, если класс имеет своими полями некоторые указатели. Потому необходимо сделать явный вызов деструктора, после чего уже можно использовать placement new на это место.
Кто-то скажет, что использование объекта после вызова деструктора по стандарту является неопределённым поведением, но в данном случае мы используем не сам объект, а его storage.
Вот ссылка на вопрос с so, где сообщество поясняло мне за этот случай: https://stackoverflow.com/questions/69062579/is-using-placement-new-with-variable-on-the-stack-is-correct
Stack Overflow
Is using placement new with variable on the stack is correct?
Let's take a look to this code:
A a(123);
new(&a) A(124);
Test says that in this case when program is shutting down destructor ~A() will called once. So if in A we has some pointers as fields we
A a(123);
new(&a) A(124);
Test says that in this case when program is shutting down destructor ~A() will called once. So if in A we has some pointers as fields we
#cpp #proposals
Интересные proposals за последнее время:
1. Stacktrace for exceptions: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2370r1.html
2. basic_string::resize_and_overwrite: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r9.html
3. Conversions from ranges to containers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1206r6.pdf
Интересные proposals за последнее время:
1. Stacktrace for exceptions: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2370r1.html
2. basic_string::resize_and_overwrite: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r9.html
3. Conversions from ranges to containers: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1206r6.pdf
Forwarded from Peltorator's Channel
Иногда так бывает, что асимптотика решения задачи зависит от количества делителей числа во входе. Когда я только начинал заниматься спортивным программированием, я несколько раз слышал такое утверждение: «количество делителей числа n — это примерно кубический корень из n». И с самого начала я относился к этому факту с подозрением: неужели у чисел может быть так много делителей?
На самом деле, это, конечно, не так, но оценка в кубический корень дает нужный порядок величин для грубых оценок на числах, с которыми мы имеем дело в реальной жизни (отличие не больше, чем в 4 раза при n ≤ 10^15, и не больше, чем в 10 раз при n ≤ 10^18). Давайте разберемся, сколько все таки на самом деле делителей у чисел, и как этим пользоваться, а также придумаем новую более точную оценку.
https://telegra.ph/Ocenka-na-kolichestvo-delitelej-chisla-09-10
На самом деле, это, конечно, не так, но оценка в кубический корень дает нужный порядок величин для грубых оценок на числах, с которыми мы имеем дело в реальной жизни (отличие не больше, чем в 4 раза при n ≤ 10^15, и не больше, чем в 10 раз при n ≤ 10^18). Давайте разберемся, сколько все таки на самом деле делителей у чисел, и как этим пользоваться, а также придумаем новую более точную оценку.
https://telegra.ph/Ocenka-na-kolichestvo-delitelej-chisla-09-10
Telegraph
Оценка на количество делителей числа
Предыстория и мотивация Иногда так бывает, что асимптотика решения задачи зависит от количества делителей числа во входе. Когда я только начинал заниматься спортивным программированием, я несколько раз слышал такое утверждение: "количество делителей числа…
#cpp #stackoverflow
https://stackoverflow.com/questions/9994421/preferred-standard-use-range-based-for-or-stdfor-each
https://stackoverflow.com/questions/9994421/preferred-standard-use-range-based-for-or-stdfor-each
Stack Overflow
Preferred standard use: range based for or std::for_each
In C++11, there are two loops over all elements (range based for and for_each). Is there any reason to prefer one over the other or are there situations where one is a better fit?
for (auto& e...
for (auto& e...
#common
Какая-то статистика от jetbrains.
https://www.jetbrains.com/ru-ru/lp/devecosystem-2021/cpp/#Which-C-standards-do-you-regularly-use
Какая-то статистика от jetbrains.
https://www.jetbrains.com/ru-ru/lp/devecosystem-2021/cpp/#Which-C-standards-do-you-regularly-use
JetBrains: Developer Tools for Professionals and Teams
Разработка на C++ — Инфографика «Экосистема разработки в 2021 году»
«Экосистема разработки в 2021 году» — это подробный отчет о том, что происходит в мире программирования: чем живут разработчики, какие языки, технологии и инструменты они используют.
#cpp
Множество различных(возможно в своём большинстве бесполезных) идиом C++.
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms
Множество различных(возможно в своём большинстве бесполезных) идиом C++.
https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms
#python #common
Метод, которым python решает проблемы с ромбовидным наследованием.
https://ru.wikipedia.org/wiki/C3-линеаризация
Метод, которым python решает проблемы с ромбовидным наследованием.
https://ru.wikipedia.org/wiki/C3-линеаризация
#cpp #proposals
Proposal for
Cool video about it: https://www.youtube.com/watch?v=PH4WBuE1BHI
Proposal for
std::expected: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0323r10.htmlCool video about it: https://www.youtube.com/watch?v=PH4WBuE1BHI
#cpp #proposals
Some new and interesting proposals:
1.
2.
3. Function to mark unreachable code: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r5.pdf
4. Fix the range‐based for loop: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r1.pdf
5. Change scope of lambda trailing-return-type: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2036r3.html
6. Remove unsafe conversions of unique_ptr<T>: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2413r0.html
7. A Unified Executors Proposal for C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r14.html
Some new and interesting proposals:
1.
auto(x): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0849r8.html2.
std::hive(std:colony): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0447r16.html3. Function to mark unreachable code: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r5.pdf
4. Fix the range‐based for loop: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2012r1.pdf
5. Change scope of lambda trailing-return-type: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2036r3.html
6. Remove unsafe conversions of unique_ptr<T>: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2413r0.html
7. A Unified Executors Proposal for C++: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0443r14.html