Откуда это «user don't care»?

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

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

Сильно сомневаюсь что потеря тактов на двух сравнениях заставить их трястись еще больше

блжад — в memmove как раз и добавляются эти 2 такта. Если всё правильно, то она работает ровно на одно сравнение дольше. Начиная с iPentium это ВООБЩЕ времени не занимает, т.к. инструкция сравнения работает ВМЕСТЕ с другой инструкцией. А инструкция перехода вперёд НЕ выполняется, т.к. предсказано, что его НЕ будет.

memmove начинает работать заметно медленно тогда, и только тогда, когда области неправильно перекрыты. Но в этом случае memcpy вообще правильно НЕ РАБОТАЕТ.

А так же есть UB

нет никакого UB. Попробуй молотком закрутить шуруп. Это UB?

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

обычное дело, к сожалению. Просто они где-то услышали, что memcpy «быстрая», или вообще не слышали про memmove.

memcpy не выдает аналога "-nan" - вместо этого она грозит пальчиком в документации, и предписывает творить UB в реализации.

дык в документации деление на ноль == UB. А по жизни получается число НЕЧИСЛО. С memcpy тоже получается НЕКОПИРОВАНИЕ, а какая-то хрень непонятная — размножение какой-то последовательности байтов по всей области.

UB не место в стандарте.

твои предложения стандартиризировать деление на ноль?

Не знаю, есть мнение что КЭП тут бессилен, если тебе это не очевидно. Компы - вообще то детерминированные творения.

кто тебе сказал такую глупость?

Пойми, «детерминированые» значит лишь то, что получается каждый раз одно и то же(и то, с допущением одной программы в одноядерном CPU, и без внешнего мира). Да, одна и та же хрень. Например при делении на ноль компьютер имеет полное право ОДИНАКОВО ЗАВИСАТЬ. Разве такое поведение не детерминировано? При этом другой, точно такой же компьютер может удалить все файлы. Это тоже детерминировано. Радует?

нет никакого UB. Попробуй молотком закрутить шуруп. Это UB?

Мастер кривых аналогий в действии. UB есть. Описано прямо в документации - The memory areas should not overlap.

дык в документации деление на ноль == UB.

Я не знаю как там у тебя лично, у меня деление на ноль генерить ошибку <DIVIDE>

твои предложения стандартиризировать деление на ноль?

Моё предложение состоит в том что было бы гараздо лучше если UB в поведении memcpy не было.

Например при делении на ноль компьютер имеет полное право ОДИНАКОВО ЗАВИСАТЬ.

А программист имеет полное право вызывать memcpy с пересекающимися регионами, ни сама memcpy ни стандарт никак не запрещают ему это делать, более того он может это делать не осознанно(изначально регионы не пересекались, а после n патчей от других разработчиков в 10% случаев стали пересекаться), и что ?

блжад — в memmove как раз и добавляются эти 2 такта. Если всё правильно, то она работает ровно на одно сравнение дольше.

И это стоит того что бы трястись над memcpy и кричать что её нельзя трогать ибо она жутко быстрая, не то что memmove ? Самому то не смешно

Ты к примеру уверен что сам код программы, что вызывает memcpy так же написан оптимально и не жрет лишние 10-20 тактов перед вызовом memcpy, сжирая таким образом всё эту мегаоптимизацию ?

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

Мастер кривых аналогий в действии. UB есть. Описано прямо в документации - The memory areas should not overlap.

в инструкции к печке тоже написано: «нельзя сушить кошек в микроволновке». Вычёркиваем?

Я не знаю как там у тебя лично, у меня деление на ноль генерить ошибку <DIVIDE>

потому-что ты в int'ах считал, а я в float'ах. Нельзя?

ну и потому, никто и не говорит о том, что UB определено, оно НЕ ОПРЕДЕЛЕНО. У тебя так, у меня — эдак, а у васи так ваще член отвалится.

Моё предложение состоит в том что было бы гараздо лучше если UB в поведении memcpy не было.

ищи другой глобус, в котором можно делить на ноль. В этом UB.

А программистговнокодер имеет полное право вызывать memcpy с пересекающимися регионами

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

Да, никто не запрещает. Твоя кошка.

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

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

Хороший стандарт не должен содержать UB, как минимум стремиться к этому /0

И это стоит того что бы трястись над memcpy и кричать что её нельзя трогать ибо она жутко быстрая, не то что memmove ? Самому то не смешно

дык я-то и не использую memcpy тогда, когда этого делать нельзя. У меня нет проблем.

Ты к примеру уверен что сам код программы, что вызывает memcpy так же написан оптимально и не жрет лишние 10-20 тактов перед вызовом memcpy, сжирая таким образом всё эту мегаоптимизацию ?

не уверен. Потому, если мне лень думать, я пишу memmove, УМВР, ЧЯДНТ?

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

а я считаю, что она уже написана, и имеется в glibc. А свою писать не нужно, ибо она будет работать ТОЛЬКО на моём локалхосте. А на остальных будет тупить. Потому я юзаю memmove, которая работает ВЕЗДЕ. Когда ребята в intel придумывают какой-то новый CPU, они делают новые memcpy/memmove, которые работают ещё быстрее. А как — я не знаю. И стандарт не знает. И даже сами ребята не знают, ибо ЕЩЁ НЕ ПРИДУМАЛИ.

А дебилы в адобе решили, что могут видеть будущее. Fail.

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

можно сделать микроволновку, которая будет анализировать внутреннее мяуканье. Её не сделали по двум причинам:

1. ты её не купишь, т.к. она будет стоить не 2000р, а 20 000р. А про кошку ты и без этого в курсе, надеюсь не дебил.

2. А если дебил, то ты засунешь попугайчика, который не мяукает.

Потому микроволновка «только грозит пальчиком из мана». Как и memcpy. Причины те же самые.