линух крут ? ну правда с 3.17 начиная ... на виндосе этот код запуска страниц 5-7 кода занимает

омг https://twitter.com/SylvainCorlay/status/1028939731860635649

линух крут ? ну правда с 3.17 начиная ... на виндосе этот код запуска страниц 5-7 кода занимает

Во время поисков способа сделать это я наткнулся на статью, где было описано как это сделать на виндузах, не больше 100-150 строк это заняло. Способ на виндузах мне больше нравится, ибо можно после выполнения загруженного кода можно с ним ещё что-нибудь сделать, например зашифровать обратно. В линуксах же реализация этого заняла бы как раз дохреналион строк, т.к системный вызов, который выполняет прогу из памяти, "затирает" текущий процесс, как, собственно, и другие вызовы выполнения программ, разве что кроме fork

Добрый вечер. Я часто пишу if (!v.empty()) v.pop_back(); и грущу потому что набрал много символов и не понимаю почему это не можно сократить. Обьясните, пожалуйста, почему более логично когда pop_back на пустом векторе бросает исключение, а не просто ничего не делает? Хотелось бы или чтобы он ничего не делал, или чтобы был метод std::vector::pop_back_or_none. Это у меня одного такие странные хотелки или кто-то еще так думает?

У джосатиса было объяснение по поводу лапидарности и unsafe-ности дизайна контейнеров STL. Если вкратце - была дилемма между безопссностью и производительностью. Выбрали втлрое, чтобы программист мог сам строить более безопасные абстракции с нужным уровнем оверхеда, а другие, у которых граничные случаи не встречаются, не платили за ненужные для них проверки

Здравствуйте, подскажите, есть ли в каких-нибудь библиотеках готовая реализация виртуальной памяти. Например, есть класс виртуальной памяти, которому я могу отдать сколь угодно много отдельный кусков памяти (указатель и размер), а этот класс бы реализовывал мне непрерывную память с доступом как к указателю, проще говоря, имел все те же операторы, что у обычного указателя.

std::allocator гуглите

Добрый вечер. есть функция, кторая возвращает unqiue_ptr. Eсть ли разница между return {} и return nullptr? https://godbolt.org/g/su1huC

https://godbolt.org/g/Zd4m23

Я вроде бы понял Дефолтная имплементация Dispose в исходниках : delete this; Так что, видимо, в этом методе нужно самовыпиливаться

https://t.me/xthon/809

https://godbolt.org/g/Zd4m23

https://godbolt.org/g/7i2QBU забавная оптимизация

У вас есть парсеры которые разбирают протоколы на линейной памяти, они проверены, написаны тесты, все по правила, представьте себе, что данные приходят кусками, и эти данные копировать в линейную память запрещено. Удобно было бы воспользоваться локальной виртуальной памятью для превращения их в линейную, и использовать уже написанные парсеры для линейной памяти. Надеюсь я объяснил. Конечно, можно переписать парсеры, и все сделать по другому. И я даже не спорю, что возможно будет работать быстрее.

Для решения такой проблемы существует паттерн проектирования Адаптер

У вас есть парсеры которые разбирают протоколы на линейной памяти, они проверены, написаны тесты, все по правила, представьте себе, что данные приходят кусками, и эти данные копировать в линейную память запрещено. Удобно было бы воспользоваться локальной виртуальной памятью для превращения их в линейную, и использовать уже написанные парсеры для линейной памяти. Надеюсь я объяснил. Конечно, можно переписать парсеры, и все сделать по другому. И я даже не спорю, что возможно будет работать быстрее.

Удобно было бы не завязываться на указатели

Вы сделали ошибку не применив вначале итераторы

линух крут ? ну правда с 3.17 начиная ... на виндосе этот код запуска страниц 5-7 кода занимает

Да не.. выделить исполняемую память, загадить ее кодом, вызвать

А можно замапать кусок памяти в память?

Через аналог mmap

Да не.. выделить исполняемую память, загадить ее кодом, вызвать

Ведь после вызова fexecev очищается память процесса, который ее засирает

ну если чистый код то да если это .exe/dll - то несколько страниц кода

Ведь после вызова fexecev очищается память процесса, который ее засирает

Да я про венду

понял

std::allocator гуглите

Я вот тоже решил, что ему нужен аллокатор, но, кажется, оказалось сложнее.

Я вот тоже решил, что ему нужен аллокатор, но, кажется, оказалось сложнее.

Тогда memory_resource

/cppref memory_resource

Search results for "memory_resource" 1. <memory_resource> 2. std::pmr::memory_resource 3. <experimental/memory_resource> 4. std::experimental::pmr::memory_resource

Тогда memory_resource

Там даже есть именно непрерывный пул

а почему boost::optional::is_initialized() deprecated но только в документации но не в заголовке?

Надр патч закинуть

блин, серьёзно? стандартный модуль cmake определяет дирку для конфигов как /usr/etc/<PROGNAME>???

Есть ли в стандартнвх библиотеках функция для разделения строки по разделителю?

strtok)

а вообще - проще сделать find_if кмк

Есть ли в стандартнвх библиотеках функция для разделения строки по разделителю?

boost::split

Есть ли в стандартнвх библиотеках функция для разделения строки по разделителю?

template <typename InIt, typename OutIt, typename T, typename F> InIt split(InIt it, InIt end_it, OutIt out_it, T split_val, F bin_func) { while (it != end_it) { auto slice_end (find(it, end_it, split_val)); *out_it++ = bin_func(it, slice_end); if (slice_end == end_it) { return end_it; } it = next(slice_end); } return it; }

https://github.com/PacktPublishing/Cpp17-STL-Cookbook/blob/ce2b8ae0aa4b1c36902ec9c838fa1e152699b590/Chapter06/split.cpp

Бустовый сплит позволяет делать вектор string_ref а не заниматься тупым копированием строк

Вопросы уровня новичка - @supapro.

Бустовый сплит позволяет делать вектор string_ref а не заниматься тупым копированием строк

ктож мешает переписать под string_view ?

Интересно, а почему unified call syntax или extension functions не приняли в стандарт? Вижу много пропозалов на эту тему, но в драфте C++20 ничего на эту тему нет

Интересно, а почему unified call syntax или extension functions не приняли в стандарт? Вижу много пропозалов на эту тему, но в драфте C++20 ничего на эту тему нет

Да, полезно было бы очень...

в моей команде поэтому все срут сотни public методов вместо того чтобы free functions писать.

Интересно, а почему unified call syntax или extension functions не приняли в стандарт? Вижу много пропозалов на эту тему, но в драфте C++20 ничего на эту тему нет

Конечно, лажовая немного тема для языка программирования, на уровне соглашений, но выход будет на мультиметоды и более лучшее FP

в моей команде поэтому все срут сотни public методов вместо того чтобы free functions писать.

Может ты не привык в OOP?

Ну видимо у меня недостаток джавового бекграунда

Ну и опять же Мейерс аргументирует против паблик методов. Идеальный код - минимальный паблик интерфейс у класса, остальное всё extension методами, которых в c++ нет

Хотя вроде как в Resharper проблему частично решили https://www.reddit.com/r/cpp/comments/6ik3p4/now_that_modern_ides_support_dotcomplete_to_free/ , жаль его нет под linux

'''tvaneerd C++ Committee, Lockfree, Postmodern 3 points · 1 year ago This is awesome. We could continue down this road by never updating C++ and instead just have our IDEs enable us to type in whatever syntax we want, and autoconvert to C++. We could each have our own favourite syntax! '''

Там ещё прикольный пример для UFC c chaining приводят

collection.filter(..).sort().map(..)..

Ну видимо у меня недостаток джавового бекграунда

Это только плюс

Интересно, а почему unified call syntax или extension functions не приняли в стандарт? Вижу много пропозалов на эту тему, но в драфте C++20 ничего на эту тему нет

вроде бы активно эту фичу продвигает буквально пара человек, и на последних заседаниях их не было

collection.filter(..).sort().map(..)..

да, это будет практически как Linq-To-Object из шарпа

и как трейтсы в расте, и как exension functions в котлене

думаю просто ещё не достаточно раскрученная фича

когда модули завезут?

вроде бы активно эту фичу продвигает буквально пара человек, и на последних заседаниях их не было

ЗАТО Один из них -- Сам Страуструп!

в последнем посте саттер написал что будут на следующем митинге модули отдельно обсуждать

вроде как пропосалы на модули от ms и google слили в один

хотя я не понимаю зачем модули нужны большинству людей

Как минимум это должно ускорить сборку проектов, которые на них будут написаны.

Да банально удобство.

@antoshkka кажется говорил что модулям будет посвящено отдельное промежуточное заседание где-то в сентябре, хотя возможно я путаю с какой-то другой фичей вроде концептов

Ну и отсутствие сайд-эффектов инклудов - тоже норм тема

ну я вот сейчас работаю с клангом, вроде как проект большой, а собирается достаточно быстро

Можно будет адекватнй развить инфраструктуру как в других языках а ля Rust/Haskell, да даже JS

Плюс разграничение уровней доступа на уровне модуля. Типа public члены модуля, private