лямбды там были сто лет как.

Барышня, вы так давно программируете на C++, что, видимо, забыли, как выглядели эти самый лямбды из Boost.Lambda. Так я вам напомню примером из официальной документации:

std::for_each(v.begin(), v.end(),
  ( 
    switch_statement(
      _1,
      case_statement<0>(std::cout << constant("zero")),
      case_statement<1>(std::cout << constant("one")),
      default_statement(cout << constant("other: ") << _1)
    ), 
    cout << constant("\n") 
  )
);

и никто не тащил их себе в проекты.

Из и не тащили как раз потому, что за пределами простейших выражений вида *_1 > *_2 это был страх и ужас. Какой-то сделанный на базе C++ новый подъязык.

В ряде проектов Boost был как раз под запретом для того, чтобы в кодовую базу не проникали вот такие навороты, которые сильно увеличивали время компиляции, усложняли отладку и приводили к частным internal compiler error.

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

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

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

кто умеет писать код, указателей на функции хватает выше крыши

А покажи-ка как ты обычно хранишь указатели на методы классов ?

Да.

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

Про С++ я вообще не хочу ни чего говорить. После того, как в стандарт впиндюрили (зачем-то) едва ли не половину, если не больше, буста...

Впрочем, это их проблемы. Хотят, так почему бы и нет.

С это временами странный язык, да.

При всей его «простоте» и «неразвитости синтаксиса» семантика там такая, что иной раз сидишь, втыкаешь в код и думаешь — а чё, пацаны, так можно было? =)))

Не без этого, да.

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

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

Ну хотя бы из 3-4 пунктов.

Или последует очередной публичный обсер персонажа, заявляющего о своем «отличном знании» C++?

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

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

да всё почти. из полезного разве что move semantics и variadic templates. но чтобы заметить прирост скорости от move - это надо ну оооочень специфическую задачу. и то там будет 0.01% в лучшем случае. стоит ли овчинка выделки? а вот для variadic templates не было аналогов. но, опять же, под них задач очень и очень мало.

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

да всё почти.

Все понятно. Ответ из категории «мне не нужно, значит никому не нужно».

Единственное, что можно цензурного ответить на ваши высказывания по поводу C++, так это: тетенька, хватит п*$деть.

Может у вас хотя бы получится сделать перечень того, что зря затащили в новые стандарты?

Ну хотя бы из 3-4 пунктов.

• std::*stream
• std::filesystem
• std::thread / future / promise
• std::locale / codecvt / collate

Хватит?

Я всё жду, когда они до сети дойдут. Но они, видимо, не - нутром чуют.

никакой магии, обычные функторы

Естественно. Только лямбды на порядок удобнее и позволяют не «мусорить» в коде различными классами функторов. Я уже не говорю про подход в Си, где заводят в функции void* параметр, куда передают руками контекст. Компилятору, кстати, проще оптимизации проводить на лямбдах, чем на классов функторов и уж тем более на указателях на функцию.

и главное, что лямбды там были сто лет как. и никто не тащил их себе в проекты

Не было лямбды, был костыль(хотя местами и красивый в реализации), который только грязь разводил в реальных проектах.

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

А если решаемы, но плохо?

Хватит?

Ну а что с этими библиотеками не так? Это же базовые вещи, вполне могут быть в стандартной библиотеке.

А до thread стандарт вообще не описывал модель памяти и поведение в среде с несколькими тредами.

Да, соглашусь на все 100%!

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

история дурости будет видна каждому.

О, да. И твой никнейм здесь, на ЛОРе, именно с дуростью и ассоциируется.

Ага... Ага...

Ну да, конечно...

Компилятору, кстати, проще оптимизации проводить

И именно потому, что компилятору проще, compile time соизмеримых по строкам кода проектов для С и С++ для последнего, как правило, больше.

Компилятору вообще насрать, если честно. Для него всё есть просто адреса и смещения. И не более. А уж указатели там или классы функторов, да до балды.

UPD. Как один аноним тут верно заметил, в конечном итоге всё сведётся к ассемблеру.

И именно потому, что компилятору проще, compile time соизмеримых по строкам кода проектов для С и С++ для последнего, как правило, больше

Да, это связано, хотя большая часть времени - это шаблоны. Но таки на Си компилятор не имеет возможности заниматься теми вещами, которые он проделывает для крестов.

Компилятору вообще насрать, если честно. Для него всё есть просто адреса и смещения. И не более. А уж указатели там или классы функторов, да до балды.

Это для си так. И аналогичного кода в C++. Но не всегда так. Встраивание функций(а затем и локальные оптимизации) гораздо легче произвести при передаче через шаблоны, чем по указаталям.

Простейший пример:

void f1(void(*f)(void*))
{
    ...
}

template<typename F>
void f2(F f)
{
    ...
}

Где будет легче встроить f в тело функции, в f1 или в f2?

Как один аноним тут верно заметил, в конечном итоге всё сведётся к ассемблеру.

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

Компилятору вообще насрать, если честно. Для него всё есть просто адреса и смещения. И не более.

Так в том то и дело что более. Если не более, то куча оптимизаций не получилась бы.

UPD. Как один аноним тут верно заметил, в конечном итоге всё сведётся к ассемблеру.

Капитан очевидность. Но почти всегда важно что будет не только в конечном итоге, но и вначале и посредине.

std::*stream

Было еще до C++98.

std::filesystem

Почему?

std::thread / future / promise

Почему? Добавлю еще, что до C++11 в стандарте языка вообще не было поддержки многопоточности.

Ну и из того, что добавили в C++11 касательно многопоточности откровенно неудачное разве что std::async. К future претензия разве что в том, что там интерфейс бедный и примитивный.

std::locale / codecvt / collate

Это было в C++98.

Хватит?

Нет.

О, да. И твой никнейм здесь, на ЛОРе, именно с дуростью и ассоциируется.

Да хоть с чем, хоть с эталонным незнанием и идиотизмом. Главное, что ассоциируется. И вот даже такое анонимное чмо, как вы, видя кто и что написал, может сделать оценку сказанному.

Ну а что с этими библиотеками не так?

Кроме того, что половина из них сделана через жопу и API спроектирован только для хелловорлдов на первых занятиях по курсу «Освой C++ за 21 день»?

Как минимум вот это: https://xkcd.com/927/

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

При обоих вариантах стандарт лишь ухудшает картину.

Не нашёл на странице слово Rust, исправляю.

std::*stream

Было еще до C++98.

std::syncstream у тебя был до 98-ого года?

Добавлю еще, что до C++11 в стандарте языка вообще не было поддержки многопоточности.

А я добавлю, что до C++2x в стандарте вообще не было поддержки работы сетью, графическими данными, аудиопотоками, нейросетями, игровыми устройствами ввода, геопозиционированием, смарт-картами и сканерами отпечатка ануса.

Нет.

С тебя - хватит.

std::syncstream у тебя был до 98-ого года?

Не было. И что с ним не так?

А я добавлю, что до C++2x в стандарте вообще не было поддержки работы сетью,

И за это C++ до сих пор ругают.

и сканерами отпечатка ануса.
С тебя - хватит.

Эка вас бомбануло. Уж не вы ли из под анонимуса здесь писали?

Треды фундаментальны, хотя бы потому, что требуется их учёт в модели памяти и вычислений.

std::filesystem

И как работают с fs матёрые сишники?

Нате, чтоб мне не вставать с места — https://blog.noctua-software.com/c-lambda.html А чувак по ссылке почему-то может...

О, мои лямбды.

Сообщаю тебе новость - си это уже давно gnu c, ведь 99 и 11 стандарт - это просто стандартизация тех самых гнутых расширений. Поэтому со своим никакущем пониманием не лезь в эту тему.

не во всех версиях GCC

Кресты тоже не во всех версиях гцц поддерживаются - опять херня. К тому же, там дело не в поддерживается, а в совершенно ином.

но чтобы заметить прирост скорости от move

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

Поэтому со своим никакущем пониманием не лезь в эту тему.

Покажете пункты в 99-ом и 11-ом стандартах, которые лямбды в С описывают?

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

Да, это связано, хотя большая часть времени - это шаблоны. Но таки на Си компилятор не имеет возможности заниматься теми вещами, которые он проделывает для крестов.

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

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

Опять же, выкинь мусорную методичку.

void f1(void(*f)(void*))
{
    ...
}//стиль дерьма и не смог в язык.

void f1(void f(void *)) {
  ...
}//надо вот так

Где будет легче встроить f в тело функции, в f1 или в f2?

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

Я уже, вроде как, объяснял колхозникам, что никакого move нет.

Царь, это ты?

Кто тебе про лямбды говорил? Ты решил проигнорировать всё и вся и сыграть в идиота? Отвечай на мои тезисы, иди и показывай мне основания своим нелепым потугам про лямбды и про с тандарт.

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

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

posix

aliasing

базворд

А, извини. Думал, ты уже школу закончил.

Ну чего же ты так быстро обделался? Покукарекал бы ещё хоть что-то.

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

В этом коде на крестах ещё нет функции. Это шаблон функции. Компилятор с этим работает иначе, чем с простыми функциями.

Нету такого понятия как «легче»

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

Если ты сишник и для тебя move даёт какую-то скорость

Вот тут согласен. Сишникам move не нужен.

Вообщем, сообщаю новость - move - это копирование из си, либо дефолтное копирование из крестов, которое из си

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

В этом коде на крестах ещё нет функции. Это шаблон функции.

Ну дак и в чём проблема? Нету функции - нету твоего кукаретинга. Зачем начинал? Какое ещё встраивание функции, локальные оптимизации, если функции нету?

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

Компилятор с этим работает иначе, чем с простыми функциями.

Дак функции ещё нет, чего с нею работать.

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

Полная и нелепая херня.

С шаблонами этот контекст у компилятора шире.

Ещё более нелепая херня.

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

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

Я тебе даже больше скажу - твоя херня вообще не будет работать без сишной семантики. В этом все вы, вот ты пастишь код, но ты даже не понимаешь почему он работает. И твоя потуга описать f - тому подтверждение. У тебя в шаблоне написано тоже самое, работать оно не будет - будет работать лишь из-за сишной семантики передачи не-копируемых объектов.

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

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

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

Изначально в крестах копирование(и оно таким и является «по умолчанию») - есть сишное копирование, т.е. копирование.

Далее эту семантику переопределили и приколхозили раи, владение и всю фигню. Таким образом дефолтное копирование(именно объекта, а не накрученной поверх него семантики ресурсов) пропало.

И вот, собственно, move - это и есть «новое»/старое копирование. Именно поэтому любые копирование в си - мувы, т.к. никакая семантика сверху ненакручена и такого разделения вообще нет, но семантический эквивалент сишного копирование - крестовое перемещение.

Нету функции - нету твоего кукаретинга. Зачем начинал? Какое ещё встраивание функции, локальные оптимизации, если функции нету?

Во-первых, она есть в си. Во-вторых, она появится в C++, когда компилятор будет инстанцировать шаблон, в-третьих, в качестве параметра так же будет передан функтор(указатель на функцию, объект с operator() или лямбда).

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

Ты ошибаешься. Скажи, чтобы тебя убедило, что это так?

Так я про то же.

Только из этого следует, что для C++ move полезен.

Во-первых, она есть в си.

Во-первых тебе про си ничего не говорили.

Во-вторых, она появится в C++, когда компилятор будет инстанцировать шаблон

Во-вторых, трепло, ты определись в своих убогих потугах. Функция есть, либо её нет. Задача тебе задана - отвечай.

Ты ошибаешься. Скажи, чтобы тебя убедило, что это так?

Неужели какой-то балабол будет мне рассказывать об «ошибаешься»? Ты перепутал всё. Это не меня что-то убедило - это тебя что-то убедило, т.к. а) ты пользуешься нелепыми определениями вида «легче/сложнее» которых нет, да и к тому же не можешь объяснить своих потуг. А объяснять это должен ты, а не я.

Только из этого следует, что для C++ move полезен.

И? К чему ты это написал? Тебя кто-то рассказывал про С++ и про то, что move не полезен? Очевидно, что нет.

К тому же, move полезен не для С++, если под С++ мы понимаем именно язык - он полезен для абстракций поверх С++, хотя об этом ты сам выше говорил.

А объяснять это должен ты, а не я.

Да, просто чтобы зря время не тратить, хочется понять, что тебя в принципе убедит. Два исходника(на сях с указателем и крестах с шаблоном функции), которые с O2 будут иметь разную скорость выполнения (в пользу шаблонов функции)? Или ссылка на доку по компилятору? Или куски сырцов компилятора?

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

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