LINUX.ORG.RU

На YouTube выложены доклады с С++ конференции CoreHard Spring 2018

 , ,


5

4

Евгений Охотников. 25 лет истории C++, пролетевшей на моих глазах

Автор доклада познакомился с C++ в 1991-ом году, а с 1992-го года C++ является для докладчика основным языком разработки. Что происходило с языком за это время? Как и почему он стал популярным? Как начался застой в развитии C++? Как C++ потерял свою популярность? Есть ли место для C++ в современном мире? Попробуем поговорить об этом опираясь на 25-летний опыт программирования на C++.

Вадим Винник. Обработка коллекций: единая суть и множество проявлений

Обработка коллекций: единая суть и множество проявлений

Nicolai Josuttis. Beware of C++17

The devil is in the detail. This also applies to C++17. We get new cool features, but we also get new things to care for and remember. This talk discusses some of the cool features when they may lead to surprises.

Сергей Соложенцев. Фича-компонентный подход при разработке игр

Поговорим о том, как менялись подходы к работе с игровыми объектами в match 3 играх, и как мы пришли к текущему фича-компонентному подходу создания изменяемых игровых объектов. В чем его преимущества над остальными испробованными подходами для создания туториалов, многочисленных режимов, а также реюзинга кода.

Андрей Якимов. Перехват функций под Windows в приложениях с помощью

Я расскажу о перехватах функций в приложениях написанных на различных языках и технологиях. В докладе будут рассмотрены: базовые понятия, области применения, разновидности методов перехвата и их технические особенности, готовые библиотеки.

Андрей Карпушин. C++ для web с помощью Emscripten

В докладе я расскажу о своем практическом опыте компиляции и использовании C++ на веб страницах, о том что нужно сделать, чтобы портировать приложение на С++ под веб, об ограничениях с этим связанных, об интеграции С++ кода с JavaScript и другими элементами веб страницы.

Василий Немков. Ядро мультикриптовалютного кошелька Multy

3,5 блокчейна в 2 мегабайта: как, зачем и почему. Особенности разработки кросс-платформенных решений для блокчейна.

Александр Маркевич. From C++ to Objective-C

В этом докладе я хочу рассказать о том, что Obj-C/C++ — это расширение существующих C/C++. В данном докладе будут рассмотрены особенности языка, будет рассказано про управление памятью (retain/release vs. ARC vs. shared_ptr/unique_ptr), про Swift и почему он лучше или хуже Obj-C/C++.

Михаил Матросов. Многогранный С++ на практике

В С++ существует множество способов решения одной и той же задачи. Мы возьмём реальную задачу из моей практики и исследуем ряд инструментов С++ для её решения: контейнеры STL, boost.range, C++20 ranges, coroutines. Мы сравним решения с точки зрения их интерфейсов и производительности, а также увидим, как одно решение может быть легко получено из другого, если код правильно организован. В процессе мы посмотрим на возможности С++17: constexpr if, selection statements with initializer, std::not_fn, и т.д. Особое внимание будет уделено стандартным алгоритмам (моей любимой теме).

Павел Беликов. Как работает анализ Data Flow в статическом анализаторе кода

Анализ Data Flow (потоков данных) - технология анализа исходного кода программ, широко используемая в различных development tools: компиляторах, линтерах, IDE. Мы поговорим о нём на примере разработки статического анализатора. Рассмотрим классификацию и различные виды Data Flow анализа, смежные технологии, взаимодополняющие друг друга и проблемы, возникающие при его разработке, и сюрпризы, которые нам преподносит C++, когда мы пытаемся его проанализировать. В ходе доклада мы разберём несколько ошибок, найденных в реальных проектах с помощью этой технологии.

Александр Зайцев. Инструменты профайлинга С++ кода

Так бывает, что иногда ваше приложение начинает долго выполнять казалось бы обыденные задачи и потреблять большое количество оперативной памяти. А вы как разработчик и понятия не имеете, почему же так происходит (но вам интересно). В ходе доклада поговорим о средствах, которые могут нам понять причины странного поведения наших программ. Если не боитесь таких слов как Valgrind, gprof, gperftools и многих других - добро пожаловать!

Александр Чуприна. Настройка окружения для кросскомпиляции на основе docker'a

Как быстро и легко настраивать/обновлять окружения для кросскомпиляции проектов под различные платформы(на основе docker), как быстро переключаться между ними, как используя эти кирпичики организовать CI и тестирование(на основе GitLab и Docker).

Алексей Ткаченко. Кодогенерация C++ кроссплатформенно

В докладе будет рассмотрена генерация кода при компиляции различных языковых конструкций, как простых, так и сложных, на различных платформах, как общераспространённых x86/x64, так и тех, которым уделяется меньше внимания: ARM, AVR. Также будут встречаться примеры для совсем экзотических процессоров вроде PowerPC и даже MicroBlaze. Основной упор будет делаться не на обработку данных, а именно на сопоставление различных конструкций кода с инструкциями целевых платформ.

Дискуссии:



Последнее исправление: tailgunner (всего исправлений: 1)

Ответ на: комментарий от slovazap

В начале ноября будет очередная C++ CoreHard. Заявитесь с докладом, поднимите уровень. Вы ведь сможете, правда же?

Заодно поведаете, почему Java и JavaScript-программистов в разы больше, чем C++ников, если у вас такое количество софтин в /usr/bin линкуется с libstdc++.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)
Ответ на: комментарий от eao197

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

p.s. спасибо за хороший ответ про мастерклассы

bonta ★★★★★
()
Ответ на: комментарий от bonta

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

Причем, насколько я помню, такое в C++17 поддерживается и в while, и в switch. Т.е. можно писать вот так:

#include <tuple>

enum class demo_t { first, second, third };

auto get_value() { return std::make_tuple(demo_t::second, 42); }

int main() {
	switch(auto [v, payload] = get_value(); v) {
		case demo_t::first: return 0;
		case demo_t::second: return 1 + payload;
		case demo_t::third: return 2 - payload;
	}
}

eao197 ★★★★★
()

Панельная дискуссия «C++ vs Rust»

«C++ vs Rust» == «C++ vs D»?
почему D не смог, а Rust сможет?

anonymous
()
Ответ на: комментарий от anonymous

В while нет init-statement.

Да, на счет while я ошибся. Мы пока еще даже на C++14 полностью не перешли.

eao197 ★★★★★
()
Ответ на: комментарий от Pacmu3ka

кто это сказал или это лично Ваше мнение?

bonta ★★★★★
()
Ответ на: комментарий от eao197

Заодно поведаете, почему Java и JavaScript-программистов в разы больше, чем C++ников, если у вас такое количество софтин в /usr/bin линкуется с libstdc++.

А зачем для этого целый доклад? Java и JavaScript с GC и без сырых указателей, C++ без GC и с сырыми указателями. Можно конечно раскрыть и дальше, рассказать о том, что наличие GC очень экономит время разработки, что сырые указатели это плохо потому что под вашу замечательную программу могут написать эксплоит и заставить выполнить произвольный код, если вы допустите ошибку, но на целый доклад тут вряд ли наберется.

SZT ★★★★★
()
Ответ на: комментарий от SZT

Если GC и указатели (или их отсутствие) - это всё что ты видишь в других ЯП, то ты не видишь ничего кроме C.

anonymous
()
Ответ на: комментарий от SZT

Мне кажется, вы сейчас пытаетесь побеседовать с какими-то вымышленными персонажами в своей голове.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Если GC и указатели (или их отсутствие) - это всё что ты видишь в других ЯП, то ты не видишь ничего кроме C.

Я не говорю о том, что я вижу или не вижу в других языках. Я говорю о причинах «почему Java и JavaScript-программистов в разы больше, чем C++ников». Отличия между C++ и Java, JavaScript конечно же не ограничиваются этим, но причина именно в этом.

SZT ★★★★★
()
Ответ на: комментарий от SZT

так себе причины, хотя кеп, очевидно из за спроса

anonymous
()
Ответ на: комментарий от SZT

В чем сложность указателей?

Например, я жавакодер, умею пользоваться ссылками. Пришел в C, а тут указатели - надо звездочку дописать, и иногда стрелку поставить вместо точки. Это и есть та сложность?

anonymous
()
Ответ на: комментарий от anonymous

В чем сложность указателей?

Указатель может выйти за границы и попортить память. Можно прочитать чужую память (как это было в Heartbleed). В какой-нибудь жаве тебе так сделать не даст сам язык.

SZT ★★★★★
()
Ответ на: комментарий от anonymous

В чем сложность указателей?

Вот тебе указатель object *p, а так же несколько вопросов.

  • Кто должен освободить память?
  • Можно ли передать данный указатель в др. поток?
  • Можно ли обращается к нему из нескольких потоков?

Ответы очевидны — документация и код который передаёт этот указатель в функцию. Если поведение объекта меняется, то весь процесс адаптации ручной без проверок компилятора.

Введение ссылок и владения снимает вопрос по времени жизни объекта. Трейты Sync и Send снимает вопросы по многопоточности.

Вот элементарный пример на расте.

use std::rc::Rc;

struct Object {
    value: Rc<i32>,
}

fn main() {
    let value = Rc::new(12345);
    let obj = Object { value: value.clone() };
    std::thread::spawn(move || { // move говорит, что замыкание захватывает объекты (забирает их во владение)
        let _ = obj; // новый поток несёт ответственность за удаление объекта, но
        // error: `std::rc::Rc<i32>` cannot be sent between threads safely
    });
}

Компилятор не даст перенести Object в другой поток, т. к. value не потокобезопасен.

anonymous
()
Ответ на: комментарий от anonymous

зато во втором случае в первый аргумент тернарную операцию можно запихнуть (вдруг кому захочется)

grem ★★★★★
()
Ответ на: комментарий от SZT

Указатель может выйти за границы и попортить память.

Указатель не может никуда выйти, его может выпихнуть кривой код.

В какой-нибудь жаве тебе так сделать не даст сам язык.

За ваши деньги - любой каприз. Жаба на чем написана? Это же просто надстройка над С++, просто еще один уровень абстракции для кривожопых неумех, которые готовы пожертвовать производительностью в угоду написания кривого и условно безопасного кода.

anonymous
()
Ответ на: комментарий от grem

Ну это да. Поэтому обычно сохраняют значение в переменную до входа в if, а это засоряет скоуп, если после if'а она больше не нужна. А ведь это может быть и жирнющий объект и какой-нить контейнер... Ну и неймспейс не засоряется лишний раз.

anonymous
()
Ответ на: комментарий от slovazap

We are on the path to something that could destroy C++

Как C++ потерял свою популярность? Есть ли место для C++ в современном мире?

А мсье не пробовал посчитать сколько бинарников из /usr/bin (/usr/local/bin) у него линкуются с libstdc++ (libc++) чтобы о такой чуши даже не заикаться?

Бинарники в /usr/bin - это не современный мир. Это прошлое. Современный мир - это статистика stackoverflow, github, tiobe, ieee spectrum. Посмотри на общие тенденции C++ по этим рейтингам. Они плачевные.

Даже о великий Страуструп недвано прослезился:

We are on the path to something that could destroy C++

И, что самое забавное, по мнению автора язык должен быть ориентирован на рядовых разработчиков:

We need a reasonably coherent language that can be used by “ordinary programmers”

Это, конечно, очень хорошо коррелирует с текущим размером спецификации под 2 тыс. страниц.

Так что место в современном мире есть для C++, но это далеко не то место, которое С++ привык занимать.

anonymous
()
Ответ на: We are on the path to something that could destroy C++ от anonymous

собаки лают караван идет, все в С++ замечательно, все кто на нем пишут более 5 лет довольны, только ноют только те кто его не освоил

anonymous
()
Ответ на: комментарий от anonymous

Указатель не может никуда выйти, его может выпихнуть кривой код.

Ну да, конечно, а я то думал что если просто объявить где-то указатель и ничего не делать с ним, он куда-то выйдет...

Жаба на чем написана? Это же просто надстройка над С++

Отлично, пойду напишу компилятор сишки на брейнфаке и объявлю сишку надстройкой над брейнфаком. Кстати компилятор Javac написан как раз на Java, это HotSpot VM на плюсах. Но это ничего, можно на брейнфаке написать эмулятор x86 и скомпилировать сишку в x86 инструкции и запустить на брейнфаке, тогда уж точно прокатит. Заодно окажется что x86 это надстройка над брейнфаком.

просто еще один уровень абстракции для кривожопых неумех, которые готовы пожертвовать производительностью в угоду написания кривого и условно безопасного кода.

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

SZT ★★★★★
()
Ответ на: комментарий от SZT

это HotSpot VM на плюсах.

Э-э.. Тут такое дело. В новой Java JIT-компилятор тоже решили написать на Java. Не шмогли найти С++-программистов в Оракле для развития старого кода, который был на C++. Такие дела. Сам в шоке.

dave ★★★★★
()
Ответ на: комментарий от dave

в свинарнике не нашлось ни одной чистой хрюшки ? действительно странно

anonymous
()
Ответ на: комментарий от dave

Не шмогли найти С++-программистов в Оракле для развития старого кода, который был на C++.

Откуда дровишки, что мотивация была именно такой?

eao197 ★★★★★
()
Ответ на: комментарий от dave

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

anonymous
()
Ответ на: комментарий от anonymous

и как это работает? виртуальная машина в виртуальной машине?

ХЗ как оно работает, но ничто не мешает интерпретатору байткода генерировать машкод.

tailgunner ★★★★★
()
Ответ на: комментарий от SZT

Зачем тогда плюсы? Пиши сразу на ассемблере, плюсы это просто надстройка над ассемблером

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

Там же в плюсах какие-то смартпоинтеры с проверкой границ придумали для криворуких неумех

смартпоинтеры это простейшая фигня, которую любой ньюфаг реализовывал самостоятельно, если оно ему было надо. а то что оно попало в stl - вообще пофиг, и без stl нормально ими пользовались

anonymous
()
Ответ на: комментарий от dave

А ссылку можно? Поскольку в англоязычных источниках (например) речь идет о том, что C++ная версия компилятора и HotSpot-а стала большой и сложной, поэтому ее трудно развивать и проще переписать заново. А, поскольку Java перестала тормозить, то и переписали на Java.

Это несколько отличается от «не смогли найти».

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну, сам же написал, что «трудно развивать». Я немного утрировал, но не сильно на мой взгляд. Ссылку у СтиваДжобса проси.

dave ★★★★★
()
Ответ на: комментарий от eao197

ущипните меня, когда это java перестала тормозить ? да там за один только GC нужно закопать ее заживо

anonymous
()
Ответ на: комментарий от eao197

Кстати, в том интервью было немного и про то, что сложно сейчас найти специалистов по Си++. Но, конечно, формулировки там не такие резкие, какие мы можем позволить себе на ЛОРе :)

dave ★★★★★
()
Ответ на: комментарий от dave

Ну, сам же написал, что «трудно развивать». Я немного утрировал, но не сильно на мой взгляд.

Любой старый код трудно развивать. Это принципиально отличается от ситуации, когда не найти человека.

что сложно сейчас найти специалистов по Си++

Как-то вообще не видно, чтобы всерьез искали. По крайней мере в наших палестинах.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

ну дык времена то какие? У меня ноут 8 ядер и 64 гига памяти и SSD на 500 гигов. И это не топовый нихера. И да. Ява не тормозит тут. Железо таки догнало. Ява просто язык будущего всегда был и вот оно наступило.

anonymous
()
Ответ на: комментарий от dave

Просто вспоминается история с переписыванием Yahoo! Store с Lisp-а на C++ и Perl. Там как раз одна из причин, ЕМНИП, была в том, что у Yahoo были проблемы с наймом толковых Lisp-еров после ухода Грэхема и Ко.

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

и это все нужно только для того что бы ява работала ? да пофиг топовое или нет, у меня своих идей дохрена чем эти ресурсы занять полезным чем отдавать все только что бы ява хоть как то запустилась и работала
о том какой там сказочный GC который за открытие файла в 80 мег, съедает полтора гига памяти, и загрузка проца этим процессом под 50%, притом же прога которая писана на Qt и открывает 150 мб файл, съедает всего 300 мег, и так во всем софте, куда не ткнешь, везде яве всего мало, и цпу и памяти и диска, да в пень колоду ее, пусть глупые гномики ее используют, которые еще верят в сказки что она что то делает быстрее чем нейтивный код скомпиленный из С или С++

anonymous
()
Ответ на: комментарий от anonymous

Да не будут их переписывать. С++ тихонька помрет скоро, только в легаси кишках останется, а раст будет развиваться, потому что в кои то веке современный язык без пиздецов появился. Ди, кстати тоже развивается. Конфы проводятся, язык улучшается, комьюнити есть, хоть и не такое громкое, как у раста (потому что просто работают). Ну а один проект, который «ниосилили», так не показатель нифига.

anonymous
()
Ответ на: комментарий от anonymous

бла бла бла я эти опусы последние лет 10+ слышу, последнего убийцу С++ уже закопали, а С++ опять в дамках, но дети после школы бегут и рассказывают об очередном убийце, я так понимаю вы никогда не закончитесь :))

anonymous
()
Ответ на: комментарий от anonymous

а я года 3 назад слышал, что раст через 2 забросят совсем. Однако язык развивается, проекты пишутся, а самое главное, в него идут те, кто помоложе и поумнее (ну порог то выше). Есть конечно те, кто из-за узости ума, не может в борровчекер, ну так динозавры тоже вымерли.

Так что С++ скоро (дадим старичку лет 10-12) будет примерно на уровне COBOL. Вроде и круто и дорого, но нужно чтоб совсем махровое легаси поддерживать.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.