QA Fest — конференция №1 по тестированию и автоматизации. Финальная программа уже на сайте >>
×Закрыть

C++ дайджест #17: Embedded програмування на Raspberry Pi, Embedded Linux розробка

Привіт, мої любі сішники! Пропоную в цьому дайджесті розглянути embedded programming на Raspberry Pi та embedded Linux development. Почнімо? :)

Raspberry Pi

Raspberry Pi — одноплатний комп’ютер, на якому зазвичай встановлюють Linux (наприклад Raspbian) або Windows 10 IoT. Програмування на С++ зазвичай відбувається з використанням бібліотек WiringPi та pigpio. Для подальшого знайомства пропоную розглянути:

Linux Embedded

Для знайомства з embedded Linux development стануть у нагоді:

Modern C++

Your „top five” ISO C++ feature proposals

Use constexpr for faster, smaller, and safer code

Simplify Your Code With Rocket Science: C++20’s Spaceship Operator

Generic Interfaces with Generic Lambdas with C++ and SYCL

Kadane in next-gen C++

Maximum Drawdown in next-gen C++

Корисні посилання

The Power of Hidden Friends in C++

Developer Ecosystem in 2019 Infographic—Jet Brains

The Developer Ecosystem in 2019: Key Trends for C, C++, and a bit of Rust

VKHR — An AMD-Backed Open-Source Hair Renderer In Vulkan

New Vulkan Extensions in Driver 19.6.2

Little Trouble in Big Data — part1, part2

How fast is getline in C++

Інструменти

PVS-Studio in the Clouds — Running the Analysis on Travis CI

Clang/LLVM Support for MSBuild Projects

Intel’s ‘One API’ Project incorporates SYCL

Parsing JSON using SIMD instructions on the Apple A12 processor

Better Ways to Test with doctest — the Fastest C++ Unit Testing Framework

Оновлення

Цього місяця маємо такі оновлення:

Для новачків

What Books to Read to Get Better In C++

C++ Core Guidelines

Удивительные возможности современного C++, которые полезно знать каждому разработчику

Хвилиночка флуду

Способи відладки:

Книга C++ for Kids :D


← Попередній випуск: C++ дайджест #16
Наступний випуск: C++ дайджест #18

LinkedIn

53 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Странная подборка, особенно в разрезе «детям». У меня есть малинки 3 и 4. Последняя с 4 Гб оперативки. Там сразу инсталлирован scratch и python 2/3. Вот это нормальный старт для детей разных возрастов.

В чем конкретнее странность подборки?
Да, установлен scratch и python по умолчанию. Только дайжест жля тем кому интересен С++, раздел ембедед.

Книга «C++ for kids».
приведена в разделе «пофлудимо», как интересный факт. При чем она к малинке?

И как интересный факт, да scratch хороший старт для детей. Плюсы — ну не уверена.

Книжка — боянъ %)

Я три года назад постил: dou.ua/forums/topic/19432

Поделюсь заначкой годных презентаций по теме ембеда:
bootlin.com/docs

Спасибо! Побольше бы таких комментариев :)

Хорошая подборка си++ катится в хаос тартары ))

Вот скажем всё те же ж constexpr в варианте использования

Use constexpr for faster, smaller, and safer code

Костыль костыльности костыльной костыльности изначально причём костыльности вообще априори наверное надо ещё поискать современный компилятор который такое ещё делает но вот какие-то падаваны нашли костыль чем можно подпереть такой «код» каким чудом там вообще должен быть constexpr кроме чистой костыльности х.з.

Та же ж VC2017 на это выдаёт

: error C4703: potentially uninitialized local pointer variable ’h’ used

Это на уровне

Warning Level : Level3 (/W3)

— задаваемый проект по-умолчаю по мере создания нового проекта визардом проектов.

Даже более того есть статья на тему на минуточку 2012-го года:

[June 6, 2012] Warnings, /sdl, and improving uninitialized variable detection

а в инструкции с настройкам уровня Warning Level прямо прописано:

For a new project, it may be best to use /W4 in all compilations; this will ensure the fewest possible hard-to-find code defects.

А проблема именно в том что си++ на сегодня стал слишком велик и слишком хаотичен и чисто технически недоступен юным падаванам на сегодняшнем си++ вполне можно писать «в джава стиле» и в принципе это тоже будет как бы б си++ «faster, smaller, and safer code» (к) (тм) а можно писать вот такие костыльные костыли подпирающие вообще невнятно что но где-то как-то встречающиеся то ли на каком-то особом компиляторе то ли на каком-то из уровней настройки всё того же ж Warning Level то ли просто кто-то что-то не понял и не особо разбирался вообще...

... зато есть такой себе constexpr а круто! давайте подопрём его этим constexpr! и вообще давайте

constexpr everything!

ЗЫ: лично я например уже априори ставлю people warning на людей которые только употребляют слово clang просто потому что однозначно жди костылей а если на этом ещё и целый проект то костыли внутри вообще 146% как принцип. И это тоже одна из актуальнейших проблем современного си++.

ЗЫ: вот что самое удивительное вот зачем вообще писать такой когда когда писать на си++? И это тоже одна из актуальнейших проблем современного си++.

традиционно нихера непонятно, но... кто заставляет юных падаванов использовать ц++14/17 итд?
тут прикольнее ссылка есть. „ц++ для детей”. лезем в описание:
„Coding and web-design skills are becoming more and more important in our technological world. These concept books will familiarize young ones with the kind of shapes and colors that make up web-based programming language and give them the head start they need.”
„web-based programming language”, карл!

Да. Книга и идея — великолепны :D
( здесь должна уместна табличка «сарказм» )

1.Чем именно катится в тартары?
2. Писать новое можете и в джава стиле. Но давайте не забывать что львиная доля продуктов это легаси. И часто если такой код можно подпереть, то лучше таки подпереть.

И часто если такой код можно подпереть, то лучше таки подпереть.

что конкретно вы имеете в виду?

А проблема именно в том что си++ на сегодня стал слишком велик и слишком хаотичен и чисто технически недоступен юным падаванам

Когда именно стал Вы имеете ввиду? Если вы говорите о С++11/14 или 17 то я не могу согласиться с этим утверждением, потому что практически все новые фичи стандартов призваны улучшить читаемость, производительность удобство использования и.д. Те средства, без которых мы уже не представляем код в большинстве проектов: smart pointers, лямды, auto, template argument deduction, decltype, и т.д( можно бесконечно продолжать) есть результатом новых стандартов, над которыми трудилась уйма лучших умов.
Если вы же говорите о языке еще с 98го, тоже вынужена поставить под сомнение ваш комментарий: С++, как и С создавался больше как системный язык для взрослых дядь и теть. Если мы говорм о детишках- питон, бейсик, scratch, который есть в миллионах роботизировных игрушках(lego, cozmo и т.д) будут куда получше С++ для завлечение новых мозгов в мир программирования

И да, С++ это язык. Как его использовать решают люди. Если он превращается в хаос в конкретном проекте это вполне может быть проблемой проекта, а не языка.

Призваны-то они призваны, но вот часто делают всё с точностью до наоборот.

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

Ну и проблема в том, что много программистов хотят заюзать в задаче всё из С++. Причин море. От поучиться до шизы.

Все де больше считаю, что не новые фичи делают «все наоборот», а программисты, которые не совсем корректно их используют. Код сам себя пишет :)

Согласна, все должно быть к месту, но все же не могу согласиться, что язык

сейчас

сильно переусложнен :). Для начала освоения база осталась практически та же. А иногда и проще даже, по-моему(к примеру лябды легче в большинстве случаев обьяснять новичкам чем std::bind). С другой стороны многое из того, что в первозданной версии языка писалось десятком строк или обходилось хаками( простейший пример — псевдонимы вложенных шаблонов в шаблоны) сейчас можно написать одной строкой и без хаков.

которые не корректно

Корректно чаще всего, но там, где они просто не нужны.

База языка — это С, ну С с классами.
Но база это совсем не современный С++ со всеми его фичами и возможностями. Лично я забил уже на все эти новомодные фичи. Мне хватает С с классами выше крыши, иногда простенькие шаблоны и лямбды простенькие и простую часть STL. А новомодные фичи пусть Александреску изучает и юзает.

Использовать там где не нужно- тоже не корректно)

Огромная часть новых (ну не таких уже и новых :D, восьми летней давности) фич стандарта взята из буста — библиотеки, без которой редко какой большой проект обходится. И с бустом любой профессиональный сишник знаком с точно.

Чем больше проект тем лучше должна быть структура и безопаснее, части кода должны быть как можно более универсальными и т.д. и здесь как нельзя кстати себя хорошо проявляют «новомодные фичи».

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

Использовать или не использовать фичи — дело индивидуальное. По-моему мнению тому, кто не использует они не должны мешать. Кому необходимы — здорово, когда они есть.

библиотеки, без которой редко какой большой проект обходится

Хромиум с Блинком, например. 10 миллионов строк.

И с бустом любой профессиональный сишник знаком с точно.

Нет.

Чем больше проект тем лучше должна быть структура и безопаснее, части кода должны быть как можно более универсальными и т.д. и здесь как нельзя кстати себя хорошо проявляют «новомодные фичи».

С точностью до наоборот, большие проекты обычно старые, и в них нельзя пихать новые фичи, иначе развалится. И универсальный код медленнее специализированного. Всегда. STL как пример.

И потом на С пытаються дописывать костыли которые уже есть, проверены и оптимизированы в С++(К примеру эмуляция классов — любимый вопрос на собесседованиях)

На С++ с полиморфизмом удобно работать без динамической аллокации? А интерфейсные структуры в С это делают.

В С++ структуры и классы одно и тоже уже давно. Отличаются только дефолтным доступом к их членам. Но полиморфизм как бы подразумевает динамическую аллокацию, но ты ее можешь поменять, если нужно.

Но полиморфизм как бы подразумевает динамическую аллокацию, но ты ее можешь поменять, если нужно.

да щаз прямо всё так и есть ты деда не опохмелился ещё просто )) в си++ полиморфизм подразумевает работу с указателями и на этом собственно всё только отсюда и начинаются отсосы простите и проблемы когда берёшь массив из значений а полиморфизм там низзя! )) ах какой хароший езыг!

о! давайте пришеем ему ссылки! ))

ЗЫ: т.е. «нааллоцирую» себе объектов вообще тупо статически тупо в сегменте данных прямо в железной прошивке драйвера и дальше работай с ними полиморфически через единый интерфейс не хочу! в этом и фишка об которой я и говорю об которой вот даже ты попал «плюсы» на сегодня с одной стороны таки довольно простой именно что концептуально простой язык (никаких тебе чистых функций) но с другой стороны слишком объёмный и таки «хаотически сложный» настолько что простые падаваны в нём просто тонут и «пишут в джава стиле» а внутрях никак особо не разбираясь (ну и джависты ведь «рядовые» не разбираются в нутрях JVM) а только «имея некие представления» вроде магии )) вот как ты только что сейчас «подразумевает динамическую аллокацию».

ЗЫ: ктати вот за структуры и классы как ни странно годно сделано в том же ж сишарпе когда структуры это строго POD и трава не расти а хочешь класс «подразумеваюет динамическую аллокацию» делай класс и не выделывайся и это при том кстати что «плюсы» теперь таки разделяют «POD не POD» причём и класс и структуру тоже могут быть «POD не POD» включая полную иерархию has вот только развести их как-то уже не удосужились вот ведь в чём печаль и «плюсовый путь наши дни».

о ты ее можешь поменять, если нужно.
большие проекты обычно старые, и в них нельзя пихать новые фичи, иначе развалится.

тоже кстати крайне интересная особенности «такого хорошего нового с фичами языка» в котором interop на уровне языка предусмотрен только со «старыми» «сями» а вот за будущее как-то не подумали причём настолько что никаких намёков нет ни в ++11 ни в ++14 ни в ++17 ни даже в ++20 которого и самого толком пока нет.

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

auto generator = []{ int i = 0; yield i; };
for ( int i : 0..100 ) cout << generator() << endl;

или может так?

using Generator = []{ int i = 0; yield i; };
Generator generator1;
for ( int i : 0..100 ) cout << generator1() << endl;
Generator generator2;
for ( int i : 0..100 ) cout << generator2() << endl;

И где? ))

ЗЫ: ну вот где те же ж мультимикросервисы на уровне языка где? )) ну хоть что-нибудь актуального наши дни!!! #плачит

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

надеюсь ты не об генераторе? ))

а почему это должно меня волновать? )) опять же «как мапить» видимо какой-то метод по-умолчаю с возможностью подстройки ну это чисто теоретически

... а как мапить виртаульные функции правильно? ))

... а как мапить виртаульные функции правильно? ))

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

эм... дык смотри та же ж история... пока «условные виртуальные функции» в рамках того же ж «условного контекста» они соотв. «относительно дешёвые» а когда они в другом контексте... )) то нас это снова не колышет просто потому что так и задумано как «так и задумано» уже сейчас когда мы просто вызываем современные «виртуальные функции» не сильно заботясь при этом об их реализации.

ЗЫ: а то даже и об том что они там вообще есть )) кстати интересный вопрос а есть ли вообще метод проверить что мы сейчас будем делать pure virtual call? и тоже смотри как интересно получается насколько язык «двойственный и лицемерный» ага ага )) с одной стороны чисто техническую на уровне концепции невозможность pure virtual call язык якобы гарантирует на уровне компиляции как невозможность инстанциировать pure virtual object но с другой стороны pure virtual call это вполне себе не undefined behavior (ок насколько я помню).

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

И где? ))

Давно есть. Чуть-чуть с другим синтаксисом, но суть не меняется.

    auto generator = [i = 0]() mutable { return i++; };
    for (int i = 0; i <= 100; ++i)
        cout << generator() << endl;

Конечно, если нужен тип Generator, то так красиво («using Generator = ...») уже не получится — нужно определять структуру/класс функтора Generator с явным полем i и перегруженным operator(). Древний, но в некоторых случаях по-прежнему актуальный подход.

А с этим синтаксисом «{ int i = 0; yield i; }» неочевидно, почему i должно каждый раз увеличиваться на единицу.

прикольно но незачот )) я yield i; (с ошибкой но то случайно) привёл в качестве «тупого примера yield но как-то рабочего» на его месте должен быть yield настоящий иначе конечно какой у генератора смысл?

	struct {
		int i = 0;
		int operator()() { return i++; }
	} generator2;
	for (int i : 0..100)
		sum += generator2();
Конечно, если нужен тип Generator, то так красиво («using Generator = ...») уже не получится

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

только это уже другой вопрос первый вопрос он всё равно не решает но в свою очередь это «ещё один вопрос почему в си++ всё так криво и ограничено?» ))

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

using Generator = decltype([]() mutable { return i++; });
но в свою очередь это «ещё один вопрос почему в си++ всё так криво и ограничено?» ))

Кривости особой не вижу. Разве что кроме необходимости писать слово mutable — но если разобраться, const по умолчанию у лямбд действительно имеет смысл (куда чаще нам нужен константный operator(), чем наоборот).

А вот насчёт ограниченности — да, есть такое. Пишите пропоузалы, кому не лень, чтобы это исправить. Уверен, комитет их с удовольствием рассмотрит.

кому не лень

мне лень )) у меня есть сишарп котлин свифт и эрланг и куча внутряшечки более низкого уровня

Это же ж при том при всём что «закат солнца вручную» (к) (тм) при некотором желании большого труда не составит ну ок если алгоритм позаковыристее то посложнее но принцип примерно принннём

	struct {
		int state = 0;
		int operator()() {
			switch (state) {
			case 0:
				++state;
				return 5;
			case 1:
				++state;
				return 10;
			case 2:
				++state;
				return 20;
			case 3:
				++state;
				return 40;
			case 4:
				++state;
				return 80;
			default:
				return 100;
			}
		}
	} generator3;
	for (int i : 0..100)
		sum += generator3();

это же ж как бы б же ж за то что вообще функторы и придуманы как «функция с состояниями» казалось бы б генераторы следующий шаг но нет ))

ЗЫ: ну да таки да но посмотрите на их производительность...

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

в смысле? это же ж крассический пример классического генератора:

int Generator() {
	yield 5;
	yield 10;
	yield 20;
	yield 40;
	yield 80;
	yield 100;
}

или зачем тебе вообще генераторы? ))

Понял. Ну, да, такого красивенького синтаксиса пока нет. Хотя в корутинах пытаются делать что-то подобное — думаю, с их появлением в языке и такие генераторы станут возможны как частный случай.

Пока что можно писать так:

	auto generator = [i = 0]() mutable
	{
		constexpr int values[] = { 5, 10, 20, 40, 80, 100 };
		int result = values[i];
		i = (i + 1) % std::size(values);
		return result;
	};

Ну или для любителей повыпен... ой, в смысле поэкономить строчки:

	auto generator = [i = 0]() mutable
	{
		constexpr int values[] = { 5, 10, 20, 40, 80, 100 };
		return values[std::exchange(i, (i + 1) % std::size(values))];
	};
Конечно, если нужен тип Generator, то так красиво («using Generator = ...») уже не получится

если зайти через зад то всё можно )) но через зад

	auto Generator = []() { return[i = 0]() mutable { return i++; }; };

	int sum = 0;
	auto generator1 = Generator();
	for (int i = 0; i <= 100; ++i)
		sum += generator1();
	auto generator2 = Generator();
	for (int i = 0; i <= 100; ++i)
		sum += generator2();

ЗЫ: ага т.е. можно ещё и так:

	const auto Generator = [i = 0]() mutable { return i++; };

	int sum = 0;
	auto generator1 = Generator;
	for (int i = 0; i <= 100; ++i)
		sum += generator1();
	auto generator2 = Generator;
	for (int i = 0; i <= 100; ++i)
		sum += generator2();

Здесь const auto Generator чтобы сам его нельзя было позвать #плачитЪ потому что логично и очевидно и сразу же ж и придумалось но всё ну супер через зад! ))

Сейчас через зад именно потому, что пока что не работает синтаксис
«using Generator = decltype([]()...)», который бы позволял определить тип, используя лямбды.
Ну и нет корутин.

Разумеется, другие варианты будут более костыльными, раз прямого решения в язык ещё не завезли.

Строчка «auto Generator = лямбда» создаст объект, а не просто определит тип. Дальше вызывать «Generator()» никто не запрещает, и такие вызовы будут менять оригинальный объект — а тебе нужна возможность создавать из него новые генераторы в их начальном состоянии. Так что не катит.

Второй вариант получше. Хоть и некрасиво, согласен.

Ещё как вариант, можно написать функцию, создающую генераторы, и юзать её:

inline auto MakeGenerator()
{
	return [i = 0]() mutable { return i++; };
}

void MyCode()
{
	int sum = 0;
	auto generator1 = MakeGenerator();
	for (int i = 0; i <= 100; ++i)
		sum += generator1();
	auto generator2 = MakeGenerator();
	for (int i = 0; i <= 100; ++i)
		sum += generator2();
}

Для любителей поэкономить строчки и/или запутать коллег можно так:

	auto MakeGenerator = []()
	{
		return [i = 0]() mutable { return i++; };
	};
	
	int sum = 0;
	auto generator1 = MakeGenerator();
	for (int i = 0; i <= 100; ++i)
		sum += generator1();
	auto generator2 = MakeGenerator();
	for (int i = 0; i <= 100; ++i)
		sum += generator2();

а Чукча не читатель однако ))

И потом на С пытаються дописывать костыли которые уже есть, проверены и оптимизированы в С++(К примеру эмуляция классов — любимый вопрос на собесседованиях)

Убивал бы за такое. Нужен ООП, юзайте С++ и не дурите мозги. Не нужен, юзайте С.

дык весь линукс же ж так написан да и винда впрочем фактически тоже см. Handle everywhere ))

И с бустом любой профессиональный сишник знаком с точно.

сколько точное число классов в последней версии boost и сколько точно было в предпоследней?

Чем больше проект тем лучше должна быть структура и безопаснее, части кода должны быть как можно более универсальными и т.д. и здесь как нельзя кстати себя хорошо проявляют «новомодные фичи».

вы путаете одно с другим но что конкретно вы имеете в виду?

вот например:

части кода должны быть как можно более универсальными

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

Использовать или не использовать фичи — дело индивидуальное.

ніт. именно про то и речь что как только «дело индивидуальное» так сразу хаос и бардак.

Кому необходимы — здорово, когда они есть.

что конкретно из этого:

smart pointers, лямды, auto, template argument deduction, decltype

было конкретно необходимо и почему конкретно?

А новомодные фичи пусть Александреску изучает и юзае

сын Александреску

что в первозданной версии языка писалось десятком строк или обходилось хаками( простейший пример — псевдонимы вложенных шаблонов в шаблоны)

проблема именно в том что вы так ничего и не поняли в чём именно проблема хотя упорно про это стремитесь писать и иметь мнение

а) «в первозданной версии си++» не было шаблонов
б) сами шаблоны как были так и остались «хаком отдельно от самого си++»

вот это и есть одна из ключевых проблем языка и да именно эту проблему и «призваны решать новые решения новых стандартов» но проблема в том что это не проблема «первозданной версии си++» это именно проблема уже «развития» каким путём оно пошло и к чему пришло.

проблема как раз в том что путь этот тупиковый именно с точки зрения языка си++ «в первозданной версии». Причём настолько что на его пути постоянно встречаются попытки таки с этого пути уйти вроде D Golang Rust C# и даже Java и проблема таки да как раз в том что как раз сам «си++ в первозданной версии» во всех этих «новых стандартах» практически не изменился (навскидку разве что «унифицированная форма инициализации» но и то скорее и таки «синтаксический сахар») а всё «развитие» идёт исключительно там где «шаблоны писались десятком строк и обходились хаками».

Даже лямбды и тот «синтаксический сахар» просто потому как это просто функторы в нулевом приближении вырождающиеся в «классические функции» и всё.

Как насчёт того чтобы наконец сделать простую и естественную передачу вызова метода объекта из любого одного контекста в любой другой? без «необходимых костылей» в виде всех этих async await promise future?

Может хотя бы включить генераторы напрямую на уровень языка? Опять же ж возвращаясь к предыдущему пункту при этом если бы б он работал то снова бы б никак не приходилось бы б заботиться об контекстах и переходах между ними.

Я не знаю вынести наконец тот самый «метапрограммирование» вообще в отдельный язык? Чем он по сути на сейчас и является?

К чему вообще весь этот «спор» «аргументированный» при этом

Код сам себя пишет :)
простую и естественную передачу вызова метода объекта из любого одного контекста в любой другой

 А потом удивляться, почему у падаванов все тормозит?
Кстати, вроде Obj-C сообщения в язык встроили (не копал детально). Это оно?

А потом удивляться, почему у падаванов все тормозит?

ты тоже путаешь инфраструктурные решения с местными ))

Кстати, вроде Obj-C сообщения в язык встроили (не копал детально). Это оно?

именно оно если уж на то пошло то objective-c решает конкцепцию ООП намного более ровно и правильно именно с точки зрения концепции

Но проблема даже не совсем в этом проблема в том что «плюсовая» реализация она тоже неплоха но проблема таки в том что дальше там пришлось «развивать язык» и натягивать сову на глобус в виде шаблонов которые с «первоначальными плюсами» стыкуются только по статической типизации ба! да ведь они до сих пор динамическую типизацию не умеют! ))

Никто же ж не говорит «си++ плохой» конкретно в чём проблема и что таки реально плохо что кто-то начинает говорить «ах смотрите какие хорошие новые фичи языка как удобно ими подпирать костыликами старый говнокод!» и что таких всё больше.

Вон уже оказывается буст был всегда и без буста плюсовик уже и не плюсовик вовсе стоп но ведь буст переехал в STL упс... ))

ты тоже путаешь инфраструктурные решения с местными ))

Ну че, а давайте ускорим работу, раскидав все объекты по потоку каждому. Сообщения между объектами в язык встроены. Правда, быстрее работать будет?))

раскидав все объекты по потоку каждому.

именно! в этом же ж цимес! структура «многопоточности» была актуальной где-то в 98-м когда многопоточность только появилась как устоявшаяся концепция но сегодня «плюсы» предлагают все эти promise future как... решение? многопоточности? 20 лет спустя? как круто!!! как актуально!!! ))

о можно я можно я! )) теперь исключение можно передать «бесшовно» между контекстами через promise future! как круто как круто! ну и что что в рамках одного процесса и одного языка и вообще вы все завидуете просто! ))

упорно про это стремитесь писать и иметь мнение

 — что это за хамство??? Мне кажется, Вы чуток перепутали интернет ресурс, нет?

К чему вообще весь этот «спор» «аргументированный» при этом

какой спор? Был комментарий «катится в тартары» к моей статье — уточнила делали.
и да, написала свое мние( которое, исходя из Вашего комментария иметь не должна) в комментарии под СВОЕЙ статьей, потому что для этого и они как бы и нужны.

Приходите в соседнюю тему dou.ua/...​ums/topic/27840/#comments
Там веселее

Мне кажется, Вы чуток перепутали интернет ресурс, нет?

эм... это же ж ДОУ? ))

и да, написала свое мние

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

но если что это даже придумал не я ))

youtu.be/VK-b1CtIATw?t=23

какой спор? Был комментарий «катится в тартары» к моей статье — уточнила делали.
и да, написала свое мние( которое, исходя из Вашего комментария иметь не должна) в комментарии под СВОЕЙ статьей, потому что для этого и они как бы и нужны.

кстати да кроме своего мнения к.м.к. имеет смысл... ну не знаю даже надо подумать как «не хамски выразить» )) но «коментарий катится в тартарары» был конкретно к этому

Use constexpr for faster, smaller, and safer code

насколько я понимаю это не «СВОЕЙ статьей» которая в свою очередь не «статьёй» но просто дайджест. т.е. насколько я понимаю там внутри по содержанию даже «своего мнения» нет я правильно понимаю? соотв. в свою очередь и «коментариев к нему» чисто технически быть не может разве нет?

Если вы говорите о С++11/14 или 17 то я не могу согласиться с этим утверждением, потому что практически все новые фичи стандартов призваны улучшить читаемость, производительность удобство использования и.д.

ок в конкретном прецеденте constexpr призван решить проблему вовзрата значения неинициализированной переменной которая в свою очередь возникает из-за проблемы неполного покрытия допустимых значений аргумента switch имеете ли вы в виде что «новая фича constexpr» и была призвана улучшить именно это либо «и это в т.ч.»?

decltype, и т.д( можно бесконечно продолжать)

хороший пример decltype не спорю позволяет писать код «в несколько новом стиле» и как до этого обходились страшно подумать! структуировали программный код? да ладно! или в каком именно стиле позволяет писать код новая фича decltype ?

Ещё раз обратите внимание и auto и decltype призваны решить проблему которая прямо проблема _кода_ прямо _си++_ когда сам код самого си++ становится настолько сложным что это уже проблема его писать.

Как результат «результатом новых стандартов» есть решение не новых проблем программирования вообще как такового более современного но затыкание пальцами дыр старинных «стандартов и концепций» благодаря которым писать новый код уже совершенно невозможно как минимум с человеческой точки зрения и «на выручку приходит» компилятор с его auto и

template argument deduction

просто потому что уже нереально писать в простейшем примере

std::tuple<int, long, double> t(4, 3, 2.5);

вместо того чтобы написать

std::tuple t(4, 3, 2.5);

Именно про это я и говорю что язык с одной стороны упёрся в свою собственную сложность и да дарованные этим относительные возможности но с другой стороны полностью упёрся в невозможность применения всех этих возможностей и самого языка в целом толпами неокрепших падаванов за плечами и в умами которых исключительно

Если мы говорм о детишках- питон, бейсик, scratch, который есть в миллионах роботизировных игрушках(lego, cozmo и т.д) будут куда получше С++ для завлечение новых мозгов в мир программирования

И вот получается что в _реальности_ им как раз плевать что именно там выведет template argument deduction и вообще вот это всё работает ну и ладно!

И да, С++ это язык. Как его использовать решают люди. Если он превращается в хаос в конкретном проекте это вполне может быть проблемой проекта, а не языка.

ок вы так ничего и не поняли дальнейший «типа дискуссию» имею смысл прекратить благо опыт в таких «типа дискуссий» уже немалый )) причём этот опыт как раз прямо про это «а давайте везде писать constexpr!» (к) (тм)

ЗЫ: но ок вот смотрите в сишарп неинициализированная переменная просто ошибка компиляции всё.

Подписаться на комментарии