зачем std::advance, если итераторы заведомо random access?

зачем std::advance, если итераторы заведомо random access?

не все итераторы random access, а только которые реализуют концепт http://en.cppreference.com/w/cpp/concept/RandomAccessIterator

A RandomAccessIterator is a BidirectionalIterator that can be moved to point to any element in constant time. ключевой момент — in constant time

например, итератор в связном списке так не умеет

ясен пень, но речь-то шла о векторах/деках

а, сорян, вырвал из контекста)

гугл забанен роскомпозором: насколько медленны fstream в сравнении с FILE*? и существует ли какая-то популярная обёртка для FILE* для случаев когда нужно тесно сотрудничать с сишечкой, или традиция велит изобретать велосипеды и boost::shared_ptr<::FILE> f(open_or_die(filename, mode), std::ptr_fun(fclose))?

std::filesystem, boost::filesystem?

они про работу с путями и самой ФС, а не про чтение данных из конкретных файлов, не?

гугл забанен роскомпозором: насколько медленны fstream в сравнении с FILE*? и существует ли какая-то популярная обёртка для FILE* для случаев когда нужно тесно сотрудничать с сишечкой, или традиция велит изобретать велосипеды и boost::shared_ptr<::FILE> f(open_or_die(filename, mode), std::ptr_fun(fclose))?

тот самый ptr_fun, который в С++11 задепрекейтили и выпилили в С++17?

Да, и который еще жив в 0х

А почему задеприкейтили кстати, потому что лямбды?

говорят, можно в cref обернуть

Вместо fun_ptr?

гугл забанен роскомпозором: насколько медленны fstream в сравнении с FILE*? и существует ли какая-то популярная обёртка для FILE* для случаев когда нужно тесно сотрудничать с сишечкой, или традиция велит изобретать велосипеды и boost::shared_ptr<::FILE> f(open_or_die(filename, mode), std::ptr_fun(fclose))?

они быстрые https://stackoverflow.com/questions/31162367/significance-of-ios-basesync-with-stdiofalse-cin-tienull

вот ещё интересное чтиво http://codeforces.com/blog/entry/5217?locale=ru

особенно полезны вот эти две _putchar_nolock()/_getchar_nolock()

и как они связаны с fstream?

особенно полезны вот эти две _putchar_nolock()/_getchar_nolock()

остлоась только сд6елать их кроссплатформой

остлоась только сд6елать их кроссплатформой

http://acm.timus.ru/forum/thread.aspx?id=41492&upd=636589677435625658 там ещё добавить || defined(_MSC_VER) и будет работать под gcc/clang/MSVC

и MinGW

http://acm.timus.ru/forum/thread.aspx?id=41492&upd=636589677435625658 там ещё добавить || defined(_MSC_VER) и будет работать под gcc/clang/MSVC

ну пусть олимпиадкники на это дрочат, ок

ну пусть олимпиадкники на это дрочат, ок

мдя. такая ненависть

отчего же?

ни разу такого в проде не видел

отчего же?

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

когда вопросы начинаются про микрооптимизации, то конечно же и в проде подобное появляется

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

такой - нет =) конечно

такой - нет =) конечно

вот про то и речь ?

зачем std::advance, если итераторы заведомо random access?

Если честно, я просто привел std::advance как универсальный способ получения итератора. Да, для вектора/деки вычисление итератора делается за O(1) . В любом случае, какой способ хранения выбрать, решает автор вопроса, а варианты ему озвучены.

Как правильно делать? вот так: memcpy(reinterpret_cast<void *>(&region.address), reinterpret_cast<void *>(snapshot), sizeof(region.address)); или вот так: memcpy(&region.address, snapshot, sizeof(region.address)); Или вообще не так?

Как правильно делать? вот так: memcpy(reinterpret_cast<void *>(&region.address), reinterpret_cast<void *>(snapshot), sizeof(region.address)); или вот так: memcpy(&region.address, snapshot, sizeof(region.address)); Или вообще не так?

может начнем с контекста и задачи?

может начнем с контекста и задачи?

char *snapshot = mmap(...) struct {uintptr_t address; } region;

char *snapshot = mmap(...) struct {uintptr_t address; } region;

второй вариант. почему нет?

А разница вообще есть?

А разница вообще есть?

нет, только короче

второй вариант. почему нет?

плохой опыт был с этими void * в функциях

Там же каст к войду в мемкомпи будет

Или к uint8*

ERROR: S client not available

плохой опыт был с этими void * в функциях

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

А разница вообще есть?

Разница только в читаемости, и здесь второй вариант лучше

программирование -- это ремесло, которое всегда прокормит. но есть ощутимый потолок по доходу -- богатым не будешь.

программирование -- это ремесло, которое всегда прокормит. но есть ощутимый потолок по доходу -- богатым не будешь.

КАК СКАЗАЛ!

Ну может он не о выгоде в деньгах, что вы так сразу Личностный рост, довольство жизнью, все дела

для спокойной жизни самое оно. но если есть амбиции...

для спокойной жизни самое оно. но если есть амбиции...

То никто не мешает идти в тимлиды и выше по менеджменту когда будет хороший опыт

программирование -- это ремесло, которое всегда прокормит. но есть ощутимый потолок по доходу -- богатым не будешь.

Ощутимый потолок это 15 к на заводе с высшим образованием

но я отлично знаю Directx,C++/C/C#/Pythoon/PHP/Java script/

std::filesystem, boost::filesystem?

Упоминать это рядом со словами быстрей - это смешно, да.

но я отлично знаю Directx,C++/C/C#/Pythoon/PHP/Java script/

А чем Pythoon отличается от Python?

Да и какое отношение к чтению из файла имеют обе эти поделки?

неть отличий

Упоминать это рядом со словами быстрей - это смешно, да.

Пруфы?

Пруфы?

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

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

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

void StringToInt(string str) { return str.ToInt(); }

где ощибка