(no subject)

Интересно, есть ли какие-то вменяемые способы (и какие) писать "exception-safe" code в присутствии аппаратных исключений, т.е. вещей типа SEH исключений Windows или signals Unix-a?

По идее, как раз с использованием этого самого SEH написано ядро Windows, но я не так чтоб его много читал, да и по другим поводам.

Чисто теоретически, транзакционную семантику при наличии потенциального Access-Violation в любом месте кода (скажем, из-за ошибки Memory Manager или даже внешней деаллокации из паралельного треда), мне кажется, написать невозможно. Невозможно, поскольку написание exception-safe кода с транзакционной семантикой базируется на использовании некоторых операций, относительно которых заведомо известно, что они исключений не кидают (не генерируют). Такого рода гарантии возможны для прикладного С++ кода, кидающего "программные" исключения, но никак не для аппаратных исключений, которые могут случиться буквально где угодно.

Остается вопрос, какой же уровень safety и защиту от какого типа ошибок (если не от произвольного Access Violation) можно всё же обеспечить в подобном контексте, и что об этом думают или думали, в частности, разработчики Микрософта.

(no subject)

Внезапно осознал, что совсем практически себе не представлял, что оптимизатор может делать, а что не может, работая с константной ссылкой (равно как и с указателем на константу) в С++.

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

Вообще-то говоря, такие вещи надо бы знать идеально. Это даже не таинственного мультитредного С++ касается, который вот уже полтора десятка лет живёт без всякой стандартизации, а и вполне обычного стандартизированного однотредного С++, где мы можем из-под выше описываемого цикла вызывать заодно и какую-то внешнюю функцию без аргументов, меняющую значение переменной, на которую у нас есть константый указатель. Надо бы мне это знать. А вот нет. Как-то проскочил мимо, или же знал, но давно позабыл.

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

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

(no subject)

Recycling is the religion of XXI century.

If you do not recycle - you are against the God!