Стандарт C++17 официально сегодня

pragma once

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

некоторые плюшки обещают втянуть с С в С++, но возможно в 20 версии, покрайней мере обсуждения идут

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

move и forward, пожалуй, нужны. как и ссылочные типы (или как там оно по-русски называется). они дают некоторый прирост скорости при правильном использовании. но это надо понимать в тонкостях. мало кто понимает.

SFINAE нах не нужен. с ним точно проще не стало. люди стали меньше думать, но это не значит, что код будет работать :)

а плюсы становятся всё жирнее и тормознее.

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

а какие там плюшки? там единственная плюшка - это variable-length arrays и то это не то, что воображают макаки. так что особо втягивать нечего.

популярности не приобрели, особенно лямбды

Потмоу что бустовые лямбды выглядили как вырвиглазный пипец. И пользовать их - это писать write only код. Сейчас лямбды это красивый способ написать функтор прям на месте.

про скорость работы, конечно. время генерации вообще никого ни...(волнует).

от этого их нужность не повысилась.

ну, ещё фиксят баги предыдущих стандартов :)

вот это точно. лучше меньше, да лучше.

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

про скорость работы, конечно. время генерации вообще никого ни...(волнует).

Ну и как добавление filesystem должно повлиять на код, который до c++17 работал быстро?

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

Если ты совершенно не в теме - зачем высказывать свое некомпетентное мнение?

SFINAE нах не нужен

Приводить в пример boost, обмазанный SFINAE, и тут же говорить, что SFINAE не нужен...

Скорость работы стала медленнее? Можно пруфы, пожалуйста.

И да, скорость генерации тоже волнует людей

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

инициализация структур через имя

Я не в курсе, что там именно хотят стануть. restrict? Или какую-нибудь инициализацию через имя?

тем, что нубы начнут это использовать!

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

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

что такое «нужность» ? те кто пишет много кода в even driven для тех нужность повысилась

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

смарт-поинтеры и лямбды легко пишутся как библиотека.

Хех :-) Сейчас придут командные разработчики и скажут, что «велосипеды не нужны», что «в семантике велосипедов надо разбираться, а в стандартных велосипедах разбираться не надо, это ж стандарт!» :-)

лямбды. ибо нафиг не нужны

Ну, типа, краткая запись функторов :-) zen типа :-) Лол :-)

SFINAE нах не нужен. с ним точно проще не стало. люди стали меньше думать

Почему стали меньше думать? :-) Мозг сломался после цепепе на SFINAE и меташаблонного программироания? :-) Весьма может быть :-) Лол :-)

Поменял что-то в хедере, который инклудится в сто cpp

Язык должен быть простым для использования без ущерба его сфере применения

каким образом even(t) driven привязан к лямбдам? не вижу никакой связи. сигналы как были в онтопике, так никуда не делись. можно использовать разные шины. при чём тут лямбды и реализация?

Язык должен быть простым для использования без ущерба его сфере применения

Ты думаешь, это про цепепе? :-)

нет. язык должен быть универсальным и оптимизированным. для макак есть «простые» песочницы. пусть там резвятся.

Да, именно так.

Одно другому не должно мешать

на них вызов колбеков реализовывать проще, нах не нужные bind или объявления указателей на функции и потом их прибитие через имя класса::имя_метода, лямбда наше все!

а бустовская реализация filesystem ну оочень тормозная.

А что сравнимое, но не тормозное? Нативное API конкретной ОС?

а зачем ты часто что-то меняешь в хэдерах? да ещё и в системных? :)

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

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

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

Нативное API

«API» мужского рода :-)

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

только не говорите мне, что все прям фигачат кроссплатформу. я кроссплатформу в жизни видела от силы в 1% проектов в опенсорце. а в проприетарщине её ещё меньше.

Я не говорил про системные. Могу часто менять в хедерах темплейтный класс.

Представляешь себе - крестовики пилят кроссплатформу. Неожиданно, да? Сишникам сложно принять это

а зачем ты его включаешь везде? меняй так, чтобы не трогать основную часть проекта. divide et impera.

Представляешь себе - крестовики пилят кроссплатформу.

Хахаха :-) Да знаем, boost называется :-) И как, получилось сделать boost кроссплатформенным? :-) Лол :-)

Неожиданно, да? Сишникам сложно принять это

Зачем сишникам это принимать? :-)

Ну давай, начинай менять легаси.

А что, не получилось? Что тебя не устраивает? Есть проблемы, не спорю. Но их стараются фиксить.

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

И нахрена вся эта шустрость и заточенность под API конкретной ОС, если работа с ФС нужна только при старте и то только для того, чтобы найти несколько cfg-файлов?

Когда профайлер пальцем показывает на влияние filesystem::directory_iterator-а на производительность — это одно, тогда про тормознутость можно говорить. Только у многих ли это так?

а вот нафига тогда это в стандартной библиотеке? я именно про это и говорю: ненужное тащат в стандарт.

А я пишу либы на работе кроссплатформенные. И другие крестовики занимаются тем же.

А что нужное с твоей точки зрения?

Чтобы простые вещи делались просто.

Ну и у вас явно профдеформация и искаженное представление о кроссплатформе.

крестовики - это пауки такие.

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

Нет, у меня либы по работе с изображениями.

Тоже что-то не так?