Сильно зависит от опыта разработчика, уровня проработанности предметной области, наличия готовых инструментов, степени зрелости самого процесса разработки, сроков.
В принципе, как и скорость написания каллиграфиграфических символов))
Я не пытаюсь сказать, что C++ идеальный язык, но и делать из него вселенское зло, как здесь пытаются, не нужно
С++ не вселенское зло. Китайский язык тоже не вселенское зло. Это не отменяет того факта, что С++ - сложный, и боюсь самый сложный промышленный язык, из известных мне на сегодняшний день. Сложность написания программ на нём возникает зачастую не из-за сложности решаемых проблем, а из-за количества нюансов самого языка, которые нужно учитывать, чтобы ничего не разломать в процессе.
Ну ничего, завезут скоро std::start_lifetime_as и заживём!
P.S.
В нормальных языках спорят о каких-то реальных проблемах, какие-то там подходы к решению тех или иных задач, но самые жаркие споры в С++ комьюнити до сих пор о самом С++. Гспди, на что я трачу жизнь...
Так стоп. После того, как я скастил 0x3 к указателю, с точки зрения синтаксиса программы последующее разыменование - это обращение к объекту.
У компилятора нет никакой возможности доказать, что там этого объекта нет. Этот объект может жить в другом TU. Следовательно компилятор ничего не остаётся, кроме как поверить мне на слово.
Я не согласен. Конечно синтаксически С++ достаточно прост (хотя и Haskell не сказал бы я, что сложен). Основная убер фича С++ - это UB. Писать код без него - подобно искусству каллиграфии. Haskell может быть сложен с той точки зрения, что требует некоторого математического бекграунда для понимания. Но с точки зрения способов выстрелить в себе в ногу С++ впереди всей планеты.
Что значит речь не о том? Я компилятору вполне внятно сказал "по этому адресу лежит объект с типом volatile int, я хочу в него записать значение, и меня вообще не волнует, что ты об этом думаешь". И компилятор обязан сгенерировать код. Без вариантов. Компилятор компилирует один TU, и может тупо не видеть этот int. Но будет он там или нет - дело даже не компилятора. Компилятор не располагает объекты в бинаре. Линковщик это делает.
В данном случае компилятор может вообще выкинуть этот код, если он докажет, что там лежит не инт.
Мне лень ходить в стандарт, поэтому я схожу на cppreference.
volatile object - an object whose type is volatile-qualified... volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access
А я утверждаю, что UB - это прежде всего behaviour. Компилятор всегда на строчку `*((volatile int*)0x3) = 1` сгенерирует один и тот же код. Он не может не сгенерировать код записи в память, когда его об этом явно просят. С точки зрения компилятора поведение очень defined.
А вот во время исполнения мы можем получить как defined, так и undefined поведение. Если мы создали все условия, чтобы по адресу 0x3 всё было валидно, значит поведение всегда будет well-defined. В ином случае - да UB.
При таком взгляде на проблему, линкер скрипты вполне себе обеспечивают гарантированно определённое поведение.
Не какой-то, а конкретный код генерируется. UB происходит не на стадии компиляции, а на стадии исполнения программы. Если по адресу записываемому адресу на момент исполнения программы всегда живёт объект нужного типа, абсолютно валидно туда что-то писать. До момента старта программы UB нет.
- Я протестировал 14 миллионнов метавселенных
- И в скольки из них люди сочли это полезным?
В принципе, как и скорость написания каллиграфиграфических символов))
С++ не вселенское зло. Китайский язык тоже не вселенское зло. Это не отменяет того факта, что С++ - сложный, и боюсь самый сложный промышленный язык, из известных мне на сегодняшний день. Сложность написания программ на нём возникает зачастую не из-за сложности решаемых проблем, а из-за количества нюансов самого языка, которые нужно учитывать, чтобы ничего не разломать в процессе.
Да, но никто ж не пишет каллиграфически в обычной жизни? Все просто калякают буквы как попало и вроде ок, письменность работает :)
На С++ приходится выводить текст программы медленно и вдумчиво, нигде не ошибаясь, иначе UB)
Занятно, что крах AMD преподносится как трагедия, но неудачи Intel сейчас сопровождаются ехидными шуточками)
Битый пиксель и черная дыра самые завораживающие конечно
Я предлагаю не иметь на кухне телевизор) Решает проблему на 100%)
На фоне трат на одну широко нашумевшую войну, траты на Уебб, равно как и нытье правительств об отсутствии денег, звучат оч смешно.
Но ведь можно полировать параллельно?)
Ещё раз - дайте мне кусок стандартам, который подтверждает, что писать в случайную память - это UB
И тем не менее он генерируется. Чудеса, не иначе
Ну ничего, завезут скоро std::start_lifetime_as и заживём!
P.S.
В нормальных языках спорят о каких-то реальных проблемах, какие-то там подходы к решению тех или иных задач, но самые жаркие споры в С++ комьюнити до сих пор о самом С++. Гспди, на что я трачу жизнь...
Прошу прощения, но я спать. Я уже час как хочу лечь, но этот бессмысленный спор меня затянул :)
Так стоп. После того, как я скастил
0x3к указателю, с точки зрения синтаксиса программы последующее разыменование - это обращение к объекту.У компилятора нет никакой возможности доказать, что там этого объекта нет. Этот объект может жить в другом TU. Следовательно компилятор ничего не остаётся, кроме как поверить мне на слово.
Я не согласен. Конечно синтаксически С++ достаточно прост (хотя и Haskell не сказал бы я, что сложен). Основная убер фича С++ - это UB. Писать код без него - подобно искусству каллиграфии. Haskell может быть сложен с той точки зрения, что требует некоторого математического бекграунда для понимания. Но с точки зрения способов выстрелить в себе в ногу С++ впереди всей планеты.
Что значит речь не о том? Я компилятору вполне внятно сказал "по этому адресу лежит объект с типом volatile int, я хочу в него записать значение, и меня вообще не волнует, что ты об этом думаешь". И компилятор обязан сгенерировать код. Без вариантов. Компилятор компилирует один TU, и может тупо не видеть этот int. Но будет он там или нет - дело даже не компилятора. Компилятор не располагает объекты в бинаре. Линковщик это делает.
Мне лень ходить в стандарт, поэтому я схожу на cppreference.
Да. Но это ведь не означает, что внутри UB нет валидной программы на С++ :)
А я утверждаю, что UB - это прежде всего behaviour. Компилятор всегда на строчку `*((volatile int*)0x3) = 1` сгенерирует один и тот же код. Он не может не сгенерировать код записи в память, когда его об этом явно просят. С точки зрения компилятора поведение очень defined.
А вот во время исполнения мы можем получить как defined, так и undefined поведение. Если мы создали все условия, чтобы по адресу 0x3 всё было валидно, значит поведение всегда будет well-defined. В ином случае - да UB.
При таком взгляде на проблему, линкер скрипты вполне себе обеспечивают гарантированно определённое поведение.
Не какой-то, а конкретный код генерируется. UB происходит не на стадии компиляции, а на стадии исполнения программы. Если по адресу записываемому адресу на момент исполнения программы всегда живёт объект нужного типа, абсолютно валидно туда что-то писать. До момента старта программы UB нет.