There are no overload for pointers to non-static member, pointers to volatile, or function pointers (other than the ones with signatures accepted by the (10-12) overloads). Attempting to output such objects invokes implicit conversion to bool, and, for any non-null pointer value, the value 1 is printed (unless boolalpha was set).

Загадка: что выведет данный код? https://pastebin.com/ckQ2PA2j

Если бы я получил такую задачу на собеседовании, ушел бы.

Если бы я получил такую задачу на собеседовании, ушел бы.

Стандартная тема же, вроде (хотя я только недавно столкнулся, но вот и в чате сразу увидел). Типа virtual default argument, pure virtual method body и пр. Есть гораздо более глубокие и непонятные вещи. На http://cppquiz.org можно позалипать.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html

чо, вас опять implicit conversions покусали?

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r0.html

Он упустил самый важный момент в бумаге: как это влияет на производительность? До этого компиляторы могли полагаться на то, что знаковое переполнение - это UB и генерировали код который рассчитывал на то, что переполнение не случится. С этой бумагой всё меняется...

Он упустил самый важный момент в бумаге: как это влияет на производительность? До этого компиляторы могли полагаться на то, что знаковое переполнение - это UB и генерировали код который рассчитывал на то, что переполнение не случится. С этой бумагой всё меняется...

Ну так ведь ничего не меняется же. На UB всё равно нельзя было рассчитывать.

Не совсем. Если машину с ones' complement сейчас встретить нереально, то c saturation arithmetic вполне себе. То есть не удовлетворять никаким требованиям и городить UB дешевле, чем гарантировать 2000000000 + 2000000000 = -294967296.

Ну так ведь ничего не меняется же. На UB всё равно нельзя было рассчитывать.

Я понимаю, но это значит, что в коде кто-то потенциально полагается на UB,так?

Более того, в WG21 недавно ходила дурная идея сделать так, чтобы size() возвращал int. В этом случае можно получить небольшой выигрыш в производительности как раз за счёт того, что стандарт гарантирует UB в случае signed переполнения

Да наоборот, такую дурь не пропускают, всё хорошо :) давайте лучше яву похороним! Благо и замена есть

Более того, в WG21 недавно ходила дурная идея сделать так, чтобы size() возвращал int. В этом случае можно получить небольшой выигрыш в производительности как раз за счёт того, что стандарт гарантирует UB в случае signed переполнения

Мне вчера человек на собеседовании заявил, что ненавидит UB в плюсах, и считает, что надо поправить все места в спеке, где есть UB. В общем, в моей компании он работать не будет :)

а у вас в компании любят UB?

а у вас в компании любят UB?

Код работает в 1000 раз быстрее... правда такую хуйню делает

UB - это главная сила плюсов. Всё остальные плюшки разве что приятны. А UB - это СИЛИЩА.

Код работает в 1000 раз быстрее... правда такую хуйню делает

сила для любителей прострелить себе ногу)

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

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

Он упустил самый важный момент в бумаге: как это влияет на производительность? До этого компиляторы могли полагаться на то, что знаковое переполнение - это UB и генерировали код который рассчитывал на то, что переполнение не случится. С этой бумагой всё меняется...

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

правильно готовить UB... хм, звучит как-то херово

правильно проектировать имелось в виду*

лучше не стало :)

UB - это главная сила плюсов. Всё остальные плюшки разве что приятны. А UB - это СИЛИЩА.

Я бы тебя на работу не взял

А я бы и тебя не взял, ты весь код удаляешь! 😭

Я бы тебя на работу не взял

На самом деле, ты его поинт понял неправильно.

https://ideone.com/t6ZRHw В Джаве мы бы заплатили во всех четвырёх функциях. C++ позволяет заплатить только в одной.

https://ideone.com/t6ZRHw В Джаве мы бы заплатили во всех четвырёх функциях. C++ позволяет заплатить только в одной.

так никто и не понял, что хотел сказать чувак

К чести сказать, в HotSpot это бы всё так же прекрасно заинлайнилось компилятором, как и в C++.

чатик, здесь кто-то отрицает полезность отсутствия проверки на границы массива во время обращения к элементам массива?

эмм.... а что hotspot выдал при обращении к массиву за его пределы?

чатик, здесь кто-то отрицает полезность отсутствия проверки на границы массива во время обращения к элементам массива?

К данному коду это имеет какое-то отношение? Тут-то нету обращения за пределы.

и что ты хотел этим сказать?

ну если вызвать getThird, то чистой воды UB

ну если вызвать getThird, то чистой воды UB

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

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