Сабж
Хочу изучить тему как хобби, чтобы мочь рисовать разное самостоятельно, без магии игрового движка.
Уровень нужен «для идиотов», для школьного уровня подготовки. Возможно, в учебниках для вузов такое есть? Тут кто-нибудь учится в вузе, или это уже не модно?
С меня как всегда ничего. Заранее спасибо)
На канале сообщества CoreHard появились видеозаписи докладов с прошедшей в начале ноября в Минске конференции C++ CoreHard Autumn 2018.
Важный дисклаймер. На конференции были проблемы с Интернетом и он-лайн трансляцией, поэтому в каких-то видеозаписях есть проблемы (например, выпадение отдельных кусочков).
Text Formatting For a Future Range-Based Standard Library - Arno Schödl
Concurrency and Parallelism in C++17 and C++20/23 - Rainer Grimm
Что должен знать каждый C++ программист или Как проводить собеседование - Игорь Садченко и Ко
Информационная безопасность и разработка ПО - Евгений Рыжков
Что не умеет оптимизировать компилятор - Александр Зайцев
Метаклассы: воплощаем мечты в реальность - Сергей Садовников
Asynchronous programming with ranges - Ivan Čukić
Обучаем на Python, применяем на C++ - Павел Филонов
Создание пакетов для открытых библиотек через conan.io - Константин Ивлев
Полезный constexpr - Антон Полухин
Кодогенерация C++ кроссплатформенно. Продолжение - Алексей Ткаченко
Обработка списков на C++ в функциональном стиле - Вадим Винник
Заглядываем под капот «Поясов по C++» - Илья Шишков
Ускорение сборки C++ проектов, способы и последствия - Александр Жоров
C++ CoreHard Autumn 2018. Знай свое «железо»: иерархия памяти - Александр Титов
Actors vs CSP vs Tasks vs ... - Евгений Охотников
Debug C++ Without Running - Anastasia Kazakova
Слайды докладов можно найти здесь
Допустим есть файл сохранённый в UTF8. Читать я его могу исключительно std::ifstream (без std::wifstream).
После прочтения файла, я хочу иметь возможность итерироваться по utf-8 символам, и даже сравнивать их
for (size_t i = 0; i < utf8String.size(); i++) {
if (utf8String[i] == 'ф') {
//...
}
}
Т.е. я хочу чтобы была возможность работать с каждым utf-8 символом, в независимости от того какой он длинны как с одним символом.
Что мне для этого нужно?
Я думал что wchar_t. Но есть такие два источника: 1. https://ru.wikipedia.org/wiki/Широкий_символ 2. https://stackoverflow.com/questions/17871880/should-i-use-wchar-t-when-using-...
Которые вроде как говорят что это не очень хорошо.
Еще я заметил (да на ++ уже пишу и не первый год), но заметил только сейчас, т.к.раньше просто не думал про это ибо не было нужно:
что std::wstring wstr = L"добро"; //да, система дебиан 8, x86-64, исходник сохранен в utf8.
в общем wstr==«добро» в оперативной памяти будет представлено не в utf-8 а в неведомой кодировке. Но по которой можно итерироваться и сравнивать.
Буква 'д' из этой строки будет иметь следующий байт-код 00110100 00000100 00000000 00000000 (wchar_t)
При этом если бы 'д' была в utf8 то она должна была бы иметь такие байты 11010000 10110100 {00000000 00000000} - в скобках хвост который как бы не имеет отношение к коду 'д', но заполняет тип wchar_t.
Вопросы: Можно ли как-то сделать так чтобы компилятор (g++) видя wchar_t c = L'д' или whchar_t c = 'д' - конструировал utf8 букву в wchar_t типе, а не в непонятной кодировке. И кстати в какой кодировке он её кодирует по умолчанию?
Есть ли какой-то способ прочитать преобразовать utf-8 строку, хранимую в std::string в std::wstring так чтобы после такого преобразования содержимое этой wstring можно было бы корректно вывести в std::wcout?
Я нашел такой способ Преобразование std::string в std::wstring
Но во первых он какой-то страншный и не очень понятный, какие-то шаблоны актуализируются...
А самое главное в моём debian8 и gcc4.3 нет такого хедера include <codecvt>
Поэтому у кого поновее пакетная база, и кому не лень, пожалуйста из ссылки выше запустите пример. Сделайте std::string str(«добро») и преобразуйте её в std::wstring Нужно чтобы после преобразования wstring строка корректно выводилась в std::wcout и можно было побуквенно (а не побайтово) итерироваться по ней, и посимвольно сравнивать.
В общем, т.к. у меня нет этого codecvt я сделал преобразование руками (да можно красивее, переносимее (учитывать порядок байт), при вызове из main не выходить за границы строки и т.д. и т.п. - не суть): https://pastebin.com/4E3nuNcM
и вот если приблизительно таким методом конструировать std::wstring которая содержит utf-8 можно будет итерироваться по ней (да, я знаю что utf8 может быть длиннее чем размер wchar_t, но у меня будет набор латиницы и кириллицы из utf8 документа), можно будет сравнивать с символами, но к сожалению не так wstr[0] = 'ы' а только с заранее созданными символами, подобным методом как строка создавалась. wstr[0] == wcharSymbol.
Это не удобно, а еще такая строка не может корректно выводится на std::wcout.
Т.е. заключительный вопрос - можно ли как-то пользуя нативный wchar_t работать посимвольно с utf-8 в c++ в линукс, имея полный ф-л такой как итерации, посимвольное сравнение, корректный вывод в std::wcout.
Если нельзя - есть ли возможно какие-то сторонние (причем легковесные библиотеки, код которых можно включить в проект, и собрать статически, и чтобы места не много тратили) которые предоставляют некий тип wideChar, полностью совместимый и с std::wcout и со всей stl(конейнерами, алгоритмами) и при этом желательно кросплатформенная?
Кстати в презренной винде на этом же наборе символов utf8 (латиница и кириллица) - всё очень хорошо (плохо там будет когда потребуется символ длиннее 2 байт) - т.к. там wchar_t это 2 байта, т.е. он как раз отлично соотвествует, и в wcout тоже выводится :)
Просьба не флудить а по конкретике писать :)
На YouTube стали доступны видео докладов обоих дней C++Russia 2018 (видео первого дня опубликовали в конце июня, на днях добавили еще и видео второго дня).
Вот список в хронологическом порядке публикации видео:
Jon Kalb, C++ Today: The Beast is Back
Алексей Салмин , Memory Management Tips & Tricks
Andrei Alexandrescu, Expect the expected
Евгений Лукьянец, Сборка в Docker с использованием Conan
Viktor Kirilov, Interactive C++ Compilation (REPL): The Lean Way
Mikhail Matrosov, Versatile C++ applied
Илья Шишков, Как научить языку C++: опыт создания курсов на Coursera
Дмитрий Соколов, Кодогенерация как рефлексия для бедных
Herb Sutter, New in C++20: The spaceship operator
Arno Schödl, From Iterators To Ranges
Александр Гранин, Функциональный подход к Software Transactional Memory
Денис Панин, Практическое метапрограммирование: пишем гетерогенную хэш-таблицу
Иван Пономарёв, Crash репорты Android NDK
Фёдор Короткий, Память – идеальная абстракция
Дмитрий Банщиков, Разделяемые библиотеки без внешних зависимостей
Borislav Stanimirov, DynaMix: A New Take on Polymorphism
Vadim Vinnik, Collection Processing. Single essence, multiple manifestations
Victor Ciura, Enough string_view to hang ourselves
Анастасия Казакова, Отладка кода на C++, без запуска и компиляции
Jonathan Boccara, 105 STL Algorithms in Less Than an Hour
Daveed Vandevoorde, Reflective Metaprogramming in C++
Павел Булатов, Переход на WebAssembly: стоит ли игра свеч?
Simon Brand, Modern C++ Parallelism from CPU to GPU
Евгений Зуев, Semantic API for C++ programms
Dietmar Kühl, Concept Based Testing
Дмитрий Кожевников, Подводные камни CMake и где они обитают
Rainer Grimm, Best Practices for Concurrency in Modern C++
Евгений Охотников, Акторы на C++: стоило ли оно того?
Алексей Малов, Опыт применения современного C++ в разработке desktop-приложений
Ivan Čukić, 2020: A void_t odyssey
Андрей Карпов, Эффективный C++ (Маерс тут ни при чём :)
Сергей Шамбир, Когда хорош процедурный C++
Иван Пузыревский, Асинхронность в программировании
Сергей Васильев, Статический анализ: ищем ошибки... и уязвимости?
Морально и физически разлагаюсь. Застрял на двух сериалах «Красный Карлик» и «Книжный магазин Блэка». Смотрю по пятому кругу, потому что всё остальное задрало. И вообще всё задрало. Подскажите подобного говнеца, про таких вот асоциальных типов.
Посоны, я вам покушать принес: ссылка
(создайте кто-нибудь тэг «ежедневное java безумие» или как-то так, ибо таких постов будет еще много? Благодаря Тэйлганнеру я еще нескоро смогу)
Короче, Java9 известна тем, что большинство ее фич похоронено внутри компилятора. Там происходят эпические рефакторинги, в рассылочках идут мощнейшие вбросы говна в вентилятор по поводу системы модулей. Но ничего из этого обычный разраб в норме не увидит.
Тут мы набросали несколько вещей, все же доступных для внешнего наблюдения:
- в интерфейсах теперь можно не просто делать методы, не только статические, но еще и приватные! Авторы воспросов для собеседования «чем абстрактный класс отличается от интерфейса»
бьются в истерике
- auto closable переменные в try-with-resources можно объявлять не только внутри try, а где угодно, если они effectively final
- List.of(1, 2, 3); реализация выбирается в зависимости от параметров
- IntStream.range(1, 10).dropWhile(x -> x < 5).forEach(System.out::println)
- Optional.empty().or(() -> Optional.of(«LOR уже не торт»))
- Optional.of(1).stream().map(x -> x * 3); такая мапа будет ленивой
- Optional.empty().ifPresentOrElse(x -> System.out.println(x), () -> System.out.println(«empty»));
- CompletableFuture.clone(); завершение клона не завершает родителя, завершения родителя завершает все слоны
- completableFuture.completeOnTimeout(«нифига, в жабе изобрели таймауты!», 1, TimeUnit.SECONDS)
- StackWalker может бегать по стектрейсам без создания Exception
- нижнее подчеркивание больше нельзя юзать как идентификатор
jshell> ProcessHandle current = ProcessHandle.current();
current ==> 6349
jshell> current.pid()
$33 ==> 6349
jshell> current.info().\TAB
arguments() command() commandLine() equals( getClass()
hashCode() notify() notifyAll() startInstant() toString()
totalCpuDuration() user() wait(
jshell> current.info().command()
$34 ==> Optional[/Library/Java/JavaVirtualMachines/jdk-9.jdk/Contents/Home/bin/java]
Как всегда, нужно/ненужно, будете ли вы лепить всё на интерфейсах, и так далее? =)
Перемещено leave из talks
Я не думаю, что кого-то можно впечатлить принципиальной возможностью запустить 10к потоков для обслуживания клиентов. Когда говорят про встанет раком, имеют в виду неоправданную потерю производительности.
Если ты готов померять реальный перформанс, пиши, я налабаю на еполле аналоги твоих тестовых серверов, чтобы не ты один тратил своё время. Меня например больше в всего в контексте этого спора интересует, как поведёт себя сервер с 10к потоков например на 4 ядрах против еполльного на одном таком же ядре, в вариантах без локов и с.
Результаты исследования можешь запостить на ЛОРе и восстановить честь среди пятизвездочных 😝
Начало дискуссии где-то рядом в удаленных по инициативе какого-то наркомана.
PS скорее всего я отвечу не раньше ночи или следующего утра.
Вышло второе издание книги о системе контроля управления версиями Git - «Pro Git». Переработан старый материал, исходный код книги переведен с разметки Markdown в AsciiDoc. Книга довольно сильно увеличилась в объеме, теперь ее PDF-версия содержит более 570 страниц.
Добавились новые главы, особое внимание уделено утилитам для работы с Git (GitLab, GitHub и пр.).
>>> Подробности
Alexander Stepanov Introduces Bjarne Stroustrup
о пользе битиков, адресов и прочих лейбницев.
ps. не новость ибо не в категорию.
Собственно, не знаю, было ли тут.
!Ъ - https://github.com/Swordifish90/cool-old-term
Ъ: Эмулятор терминала, с различными графическими эффектами старых, кинескопно-ламповых мониторов. Имеется огромное количество настроек, несколько стилизованных оригинальных шрифтов (отрисованы в векторе).
Используются технологии Qt5, QML. За основу взят Konsole, отрезанный от KDE.
Скриншоты:
Установка (требуется Qt >= 5.2; я собирал под Qt 5.3.1):
git clone https://github.com/Swordifish90/cool-old-term.git
cd cool-old-term
cd konsole-qml-plugin
qmake && make && make install
cd ..
./cool-old-termВыглядит суперски, но уж очень ресурсоёмкий; хотя интенсивность свистоперделок гибко настраивается.
Графические эффекты сделаны очень занимательно, не знал, что на Qt/QML можно сделать подобное.
Какие плагины вы используете, чтобы превратить vim в IDE для ________ (вписать язык)?
Интересует:
И общее для всех языков:
Ссылки:
Поглядел я тут на пацанов и увидел прогресс в их глазах. Поэтому я решил вести тут свой бложик, в котором я буду толкать матчасть, разбирать/разрушать всякие мифы и легенды, а так же их обсуждать с пацанами. Банить меня не надо - тут всё будет очень культурно.
Это будет формат для самых маленьких, где я буду показывать как что-то пилится по-пацаночке. Его задача - на примерах пересказать штеудмануал тем, кому лень его читать, но кто очень любит спорить про код, перфоманс и матчасть. Ну и просто интересные наблюдения.
Изначально я хотел написать про то: что такое бесплатные вычисления на примере is_range() + сумма елементов массива, но тут выявилась смешная особенность, поэтому пока без is_range().
Начнём с простого - сумма елементов(float) массива. Как написать её быстро? Обычный крестопоц сделает так:
auto summ = accumulate(begin(vec), end(vec), 0.)
Этот код выдаёт 5.6GB/s(мы всё бенчим в л1д 32килобайта массив). Казалось бы, если бы мы слушали всяких «гуру», которые нам говорят: accumulate() - оптимизирован, «ты что умнее создатели stl"а?», «конпелятор умнее тебе - сам всё делает оптимально», «руками что-то делать слишком сложно и не нужно» - то мы бы там и остались с этими 5.6ГБ, но мы пойдём дальше и поймём почему так, и является ли это тем, что намн ужно.
Но посмотрев на код - он не векторизован:
addq $4, %rdx
vcvtss2sd -4(%rdx), %xmm2, %xmm2
vaddsd %xmm2, %xmm1, %xmm1
Почему? Патамучто это основная флоатпроблема: Он не ассоциативен - флоат не имеет в себе точных представлений всех чисел входящих в диапазон его «представления» т.е. порядкопроблемы.
Поэтому конпелятор НЕ ВЕКТОРИЗУЕТ флоат по умолчанию, ну никак. Даже такую банальщину.
Для решения этих проблем - есть ключик -funsafe-math-optimizations, который входит в -ffast-math, который кладёт на точность при вычислениях. Добавив его мы получаем уже 44.9GB/s.
Но теперь мы получаем ещё одну проблему - надо думать: «как бэ сунуть эту ключик не повредив там, где этот ключик не нужен».
Поэтому ноцанам, которые хотят быстро и не хоятт рандомных жоп из-за тупости конпелятора - пишут всё руками. Допустим на той же сишке это пишется так:
double memadd_autovec(buf_t buf) { //5.609465GB/s, либо 44.969652GB/s с ffast-math
float * it = buf_begin(buf), * end = buf_end(buf), summ = 0.;
do {
summ += *it++;
} while(it != end);
return summ;
}
double hsumf(__v8sf v) {
return (v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7]);
}
double memadd_vec(buf_t buf) { //45.652002GB/s и класть на ffast-math
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ += *it++;
} while(it != end);
return hsumf(summ);
}
Т.е. разницы никакой нет, кроме нужной нам реализации горизантального сложение вектора. Когда я говорил пацану: «векторную сишку для написания быстрого кода юзать намного проще, чем плюсы» - поцан нипонимэ, да и любые пацаны скажут - ну дак с -ffast-math оба выдают по 45гигов - нахрен эта сишка нужна?
А вот зачем:
double memadd(buf_t buf) { //132.878440GB/s
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ += *it++;summ += *it++;summ += *it++;summ += *it++;
} while(it != end);
return hsumf(summ);
}
Это называется пацанский анролл копипастой, а вот заставить конпелятор нормально что-то разанролить очень сложно.
Если бы мы слушали всяких «гуру», которые нам вещают: «анрол говно и не нужен» - мы бы так и седели с 45-ю гигами, а так мы сидим с 132.878440GB/s. Т.е. анролл нам дал немного не мало ~300%.
Но основная мысль, которую толкают всякие «гуру» - это не надо следить за тактами/считать такты и прочее. Но мы о5 сделаем наоборот и посмотрим что будет.
Т.к. наш юзкейс упирается на 99% в throughput и дёргается одна инструкция, то нам достаточно просто считать теоретическую производительность для моего камня. 4.5(частота камня)*8(т.е. у нас камень с avx, то там вектор 32байта, либо 8флоатов.)*1(throughput нашей инструкции - в данном случае vpaddps из интел мануала). Т.е. 36гигафлопс, либо ~144гига. Т.е. мы сняли овер 90% теоретической производительности - остальные 10% у нас ушли в наши циклы, всякие горизонтальные суммы вектора и прочее, ну и конечно же чтение данных из кеша.
Но самое смешное - на моём хасвеле умножение имеет throughput 0.5 - т.е. на хасвеле умножение быстрее сложения. Это новая забористая трава у интела.
Казалось бы - какой жопой сложнее оказалось медленнее умножения - а вот так, на всяких штеудах производительность уже давно зависит не от каких-то технических возможностей, а от маркетинга и хотелок.
Поэтому очень смешно слушать, когда какие-то пацаны говорят: «float point имеет такую же производительность как и инты» - нет, оно имеет такоу же производительность лишь по причине того, что на штеуде инты тормазят так же, как и float.
И чтобы окончательно в этом убедится - мы взглянем на fma(вариации умножения со сложением/вычитанем), которые имеют throughput 0.5 - да, да - на хасвеле умножение+сложение в 2раза быстрее просто сложения. Это уже не просто трава - это что-то принципиально новое.
У целочисленного сложения же throughput 0.5 и казалось бы, если мы поменяем в нашей функции float на int - у нас будет сложение работать в 2раза быстрее, но это не так. Оно выдаёт те же 130гигов, а почему?
Вообще у камня есть такая фича, допустим у нас:
add $1, %reg0//вот тут инструкция add залочит регистр reg0
add $1, %reg0//а эта инструкция уйдёт в лок до особождения предыдущей инструкцией регистра reg0
Чтобы такой жопы небыло - есть специальная фича:
add $1, %reg0//lock reg0
add $1, %reg0//И тут вместо того, чтобы уйти в лок - камень вместо reg0 даёт инструкции любой свободный регистр.
Эта фича называется прееименование регистров, либо как-то так - мне лень гуглить.
Дак вот штука в том, что фича работает через жопу. Мне лень читать мануал и искать почему так, но штука в том, что она ограничивает throughput. На умножении и целочисленном сложении она огранивает throughput c 0.5 до 1.
И вот я решил заюзать сложении через fma:
__v8sf fmaadd(__v8sf a, __v8sf b) {
return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);// a + b * 1. == a + b.
}
double memadd_fma(buf_t buf) {
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
do {
summ = fmaadd(summ, *it++);
} while(it != end);
return hsumf(summ);
}
Но меня ждала жопа: 27.347290GB/s, причем не анролл и ничего не помогал. Я уж подумал, что мануал наврал, но позже до меня допёрло: у неё latency 5тактов и ((4.5×8)÷5)×4 ~= 29гигов - т.е. я получаю производительность с её latency, но какой жопой оно так?
Потом я вспомнил, что гцц гинерит анрольный код вида:
add $1, %reg0
add $1, %reg0
//а не
add $1, %reg0
add $1, %reg1
Т.е. на неё вообще не работает переименовывание регистров - и инструкции постоянно в локе. Я это проверил и оказался прав. Ну и я написал такой мемадд:
__v8sf fmaadd(__v8sf a, __v8sf b) {
return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);
}
inline void fma_10way_finality(__v8sf * cache, __v8sf * it, __v8sf * end) {
switch(end - it) {
case 8:
*(cache + 7) = fmaadd(*(cache + 7), *(it + 7));
*(cache + 6) = fmaadd(*(cache + 6), *(it + 6));
case 6:
*(cache + 5) = fmaadd(*(cache + 5), *(it + 5));
*(cache + 4) = fmaadd(*(cache + 4), *(it + 4));
case 4:
*(cache + 3) = fmaadd(*(cache + 3), *(it + 3));
*(cache + 2) = fmaadd(*(cache + 2), *(it + 2));
case 2:
*(cache + 1) = fmaadd(*(cache + 1), *(it + 1));
*(cache + 0) = fmaadd(*(cache + 0), *(it + 0));
case 0:
break;
default: error_at_line(-1, 0, __FILE__, __LINE__, "bad_aligned");
}
}
double memaddfma_10way(buf_t buf) {
__v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = (__v8sf){};
__v8sf * cache = (__v8sf[10]){{}};
uint64_t i = 0;
while((it += 10) <= end) {
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
*(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
i = 0;
}
fma_10way_finality(cache, (it - 10), end);
summ = (*(cache + 0) + *(cache + 1) + *(cache + 2) + *(cache + 3) +
*(cache + 4) + *(cache + 5) + *(cache + 6) + *(cache + 7) +
*(cache + 8) + *(cache + 9));
return hsumf(summ);
}
Пришлось хреначить финалити, ибо тут «анролл» на 10, а почему на 10 - для максимального throughput"а - надо, чтобы каждый каждый регистр юзался через 5тактов - т.е. 10регистров.
И вся эта порятнка нужна для борьбы с тупостью конпелятора.
Это уже: 214.167252GB/s(раельно там в районе 250 - просто мой бенч говно). 107 гигафлопс на ведро. Из теоретических 144, но тут уже влияние кеша. Причем 50+ из которых выкидываются и просто бесплатные.
Теперь вопрос к пацанам - что нам дадут эти гагфлопсы, когда у нас будет массив не 32килобайта, а 32мегабайта? Зачем нужно выживать максимум, когда скорость памяти отсилы 20-30гигабайт и нам хватит даже С++ кода с ffast-math?
Ну и призываются упомянутые мною пацаны: 
mv - этот тот експерт, что вещал про «руками переименовывать регистры не надо» и «анрол ваще ненужен», emulek вещал про ненужность счёта тактов, и не понимал что такое «беслпатно», AIv - не понимал в чем проблема плюсов, ck114 - так же не понимал в чем проблема плюсов.
Бенчи: https://gist.github.com/superhackkiller1997/606be26fa158ef75501d - вроде я там ничего не напутал.
P.S. - не выпиливайте пж, пусть пацаны «нужно» или «не нужно». Мне интеерсно. Ну и там рекомендации пацанов.
Добрый день. Умею говнокодить на C++, хочу развиваться и получать больше денег. Иду смотреть вакансии яндекса и вижу вопрос:
Какие из следующих стандартных контейнеров позволяют найти в них элемент (по его значению) за O(ln(n))?
std::vector
std::list
std::deque
std::set
std::multiset
std::hash_set
сортированный std::vector
сортированный std::list
сортированный std::deque
сортированный std::set
сортированный std::multiset
сортированный std::hash_set
Аргументируйте ответ, прокомментируйте правильность постановки вопроса
И понимаю, насколько я еще ничтожен. Что такое O(ln(n)) я еще понимаю, но какие алгоритмы используются в стандартной библиотеке - могу только догадываться. Хотя, возможно, вопрос на самом деле не сложный и я даже знаю как на него ответить, не углубляясь в детали реализации. Но всё равно хочется поднять свой уровень. В связи с этим посоветуйте литературу, чтобы углубить знания стандартной библиотеки C++ и вообще знания алгоритмов и с этими знаниями смочь устроиться в нормальное место.
Пожалуйста, не предлагайте перейти на другой язык, это слишком долго.
Ну и заодно пусть развернется дискуссия по поводу решения задач от яндекса:
Перемещено mono из talks
Некоторое время назад взялся за сабж. Я выбрал его именно потому, что слышал очень много отзывов о том, что это «только о программировании» и «ничего лишнего». Я несколько разочарован.
Первое, не самое важное, но тем не менее. Авторы взяли в качестве ЯП scheme, мотивируя это тем, что синтаксис очень прост для освоения новичком. Синтаксис то да, прост, но семантика не так уж и проста, и совершенно непонятно, почему было не взять любое другое подмножество лиспа, или даже бейсика, ведь для демонстрации принципов о которых там рассказывается вовсе не требуется сомнительное «волшебство» замыканий и продолжений. На одном синтаксисе далеко не уедешь, а семантику scheme (до глав о метаяз. абстракции) там не рассматривают вообще, и при этом заявляется, что низкий порог вхождения гарантирован. Это, мягко говоря, неправда.
Но самое главное — там слишком много воды. Для рассмотрения достаточно простых вещей, там берутся сложные, избыточные примеры. Например, главы о банковских счетах. Ведь основная мысль там — проблема разделения ресурса. Нахрена спрашивается было городить левые процедуры, вроде withdraw, get-money, put-money и проч. (названия там другие, но не суть), если для демонстрации идеи достаточно было change-balance и check-balance. Ведь основная проблема - в том чтобы посмотреть, а потом снять, чтобы другой объект не изменил в промежутке между двумя операциями. Вместо того, чтобы концентрироваться на основной вычислительной проблеме, на нас выливают тонны воды, в которой расмотреть основную мысль не очень то и просто.
Баланс только для примера. Вообще, вся книга написана тяжелым избыточным языком. Примеры нарочито переусложнены и перегружены ненужными (для прояснения текущей идеи) свистоперделками.
В связи с этим, хочу спросить, существует ли другая, возможно, более старая даже, книжка о программировании (и только о нем — не о типах, не об особенностях той или иной парадигмы и пр.), но только без демагогии?
UPD Забыл сказать, что я в корне не принимаю такие подходы, как «Структурное программирование», что-то в стиле «Something considered harmful» «не отстрели себе яйца», и языки заточенные под компиляцию. Поэтому подобные вещи не предлагать:)
Здравствуйте мои дорогие любители погромирования. Прочитал K&R «Язык программирования Си». Теперь нужна книга, которая расскажет как правильно писать код на С, общепринятые приёмы и стандартные алгоритмы решения типичных задач. Цель: пишу быдлокод для МК и хочу повысить свой скилл.
Перемещено mono из talks
Посоветуйте умных, правдоподобных мультфильмов в жанре киберпанк, что-нибудь близкое по духу к фильму "газонокосильщик".
Фильмы тоже можно, но, наверное, я их все пересмотрел.
Кстати, рекомендую посмотреть "газонокосильщик" режисёрскую версию, кто не смотрел, она на 37 минут длиннее и там правильная хронология сцен. А вторая часть - говно.
Автор C++, Страуструп сотоварищи, пишет в соавторстве статью о новой библиотеке для диспетчеризации по типам с помощью внешней интроспекции. Написано на шаблонах C++11 и оформлено в виде библиотеки. Называется Mach7. Выглядит в итоге как-то так:
int eval (const Expr& e)
{
Match(e)
Case(const Value& x) return x.value;
Case(const Plus& x) return eval (x. e1)+eval(x. e2);
Case(const Minus& x) return eval(x. e1)−eval(x. e2);
Case(const Times& x) return eval(x. e1)∗eval(x. e2);
Case(const Divide& x) return eval(x. e1)/eval(x. e2);
EndMatch
}
Теперь о том, что заинтересовало меня. В статье есть периодические отсылки к функциональному программированию.
Нет, не так. Давайте с начала. В объектно-ориентированном языке без прямой поддержки алгебраических типов данных, тип, представляющий дерево выражения какого-то языка, обычно будет написан как абстрактный класс, с производными классами, реализующими более конкретные варианты.
struct Expr { virtual int eval () = 0; };
struct Value : Expr { ⋯ int eval (); int value ; };
struct Plus : Expr { ⋯ Expr& e1; Expr& e2; };
Ну, то есть, хотим-то мы, наверное, как раз открытый подход, который подсмотрели из функционального программирования с его сопоставлением с образцом, но он слишком дорог с точки зрения CPU, если делать в лоб. Поэтому сделали Mach7, вот эту самую библиотеку на шаблонах, которая реализует открытый подход, но при этом не страдает по производительности, как если бы использовался тест на принадлежность к классу.
Насколько быстро теперь работает? Говорят, примерно как OCaml или Haskell: Библиотека реализована как стандартный C++11 код с шаблонным мета-программированием и несколькими макросами. Оно работает примерно также быстро, как эквиваленты на OCaml или Haskell, и даже иногда приближается по быстродействию или даже становится быстрее написанного руками C++ кода, который использует Visitor дизайн-паттерн.
Ну это хорошо, что так быстро, как OCaml или Haskell. Вопрос, зачем при таком раскладе использовать C++, замнём для ясности.
Но дальше вообще прелесть идёт: критика паттерна Visitor! Библиотека Mach7 и идеи в ней были мотивирована нашим неудовлетворительным опытом работы с различными C++-ными фронт-эндами и фреймворками для анализа программ. Проблема была не с самими фреймворками, но с фактом, что мы должны были использовать шаблон проектирования Visitor для того, чтобы смотреть, обходить и обогощать абстрактные синтаксические деревья целевых языков. Мы нашли Visitor-шаблоны неподходящими для прямого выражения логики приложения, удивительно сложными для обучения студентов, и часто более медленными, чем решения для обхода, написанные вручную. Вместо них, пользователи опирались на динамические приведения типов во многих местах, часто многоуровневые, таким образом предпочитая более короткий, более ясный, и более прямой код, нежели чем Visitor'ы. Соответствующий проигрыш в производительности был обычно незамечаем до более поздних стадий кодирования, когда уже было поздно что-то менять.
Ну можно поздравить C++, теперь можно на нём отдельные вещи писать почти так же коротко, ясно и почти так же быстро, как на OCaml.
Кроме функциональщины, в посте есть отсылка к лиспу, к Duff's device, и вообще, хорошая статья, надо студентам давать. C++ — это очень большой, огромный джип, и эта статья — неплохая иллюстрация.
А кто-нибудь здесь пишет на C или C++ в vim? Что у Вас интересного в конфигах? Не поделитесь своими .vimrc?
Посоветуйте что-нибудь по матанализу для людей со средним образованием, с нагрузкой по нарастающей. Чтобы с первых же страниц не пришлось лезть за пределы школьной программы.
В довесок также хотелось бы услышать названия стоящих трудов по, как бы это выразиться, философии науки и научному мышлению, что ли.
| следующие → |