Противоречия тут нет. Указанные функции допустимо вызывать при условии, что все подлежащие изменению/копированию данные находятся в пределах одного и того же массива, т.е. что все вычисляемые в процессе работы функции значения указателей допустимо вычислять.
Практический пример — вызов функций WinAPI, доступных только в части версий Windows, на которых должна работать программа. Указатель на функцию получается вызовом GetProcAddress(), его нужно потом привести к типу «указатель на фнукцию с такими-то параметрами и таким-то возвращаемым значением».
В машиночитаемой зоне под фамилию, имя и отчество отведены разряды с шестого по сорок четвертый в верхней строке, в них может не поместиться целиком отчество, а в отдельных случаях — и целиком имя. Также в машиночитаемой зоне отсутствует полное наименование подразделения организации, выдавшей паспорт, — присутствует только числовой код подразделения.
Нет, именно в теле функции. С инициализаторами полей автоматика достаточно хорошо разбирается
Если члены класса — «обычные» указатели, а список инциализации инициализирует их, передавая результат new SomeType(), «автоматика» не поможет. Если, например, первые три инициализатора отработали успешно, а при работе четверого произошло исключение, отработают в обратном порядке деструкторы полностью сконструированных членов класса, которые для «простых» указателей тривиальные, и снова произойдет утечка привязанных к ним объектов.
Конструктор объекта выделил память одним new, вторым, третьим и на четвертом словил исключение. И что, не запустится деструктор и выделенная память утечет?
Если исключение покинуло конструктор, деструктор объекта вызван не будет. Если адреса созданных конструктором объектов хранятся в «обычных» указателях — членах класса, то «отработают» тривиальные деструкторы этих членов класса и действительно объекты, адреса которых хранились в этих членах класса, могут утечь. Чтобы этого избежать, нужно использовать «умные» указатели, деструкторы которых нетривиальные и позаботятся о привязанных к указателям объектах.
ничего не мешает присвоить полям-указателям NULL
Тогда они перестанут быть «вообще не инициализированными».
Деструктор выполняется при не полностью созданном объекте
В случае исключения деструкторы выполняются только для тех объектов (и подобъектов), которые были полностью сконструированы к моменту возникновения исключения.
часть вложенных объектов — вообще не инициализированы
В таком случае нельзя полагаться, что в них будут именно нулевые значения.
На Google Books есть электронный вариант с частичным предпросмотром, поиск по «this» позволяет найти пример кода с реализацией функции Link::insert() на 619-й странице, где выполняется сравнение this с nullptr.
Все сертификаты цепочки обычно выпущены одним и тем же центром — и корневой (он «самоподписанный»), и промежуточные (один или несколько), и сертификат сервиса. Сервис должен отдавать клиентам все сертификаты кроме корневого в этой цепочке.
Кто будет решать, что «здраво», а что — нет? Стандарт на то и стандарт, что является описанием «как правильно», все доводы, не подкрепленные требованиями стандарта, являются только мнениями, какими бы «здравыми» они ни были.
Код проверки, что сертификаты правильно разложены по хранилищам, вызывает X509Chain.Build(), затем проходит по коллекции X509Chain.ChainElements и проверяет, что каждый из сертификатов лежит в соответствующем хранилище (вызывает X509Store.Open(), затем проверяет, что сертификат присутствует в X509Store.Certificates, затем вызывает X509Store.Close()). Я не стал приводить этот код, чтобы не перегружать пост.
«Решение с установкой вручную» очень хорошо работает, нужно просто перечислить промежуточные сертификаты в определении сервиса.
Здесь взаимоисключающие параграфы — в первом сказано (со ссылкой на Стандарт), что доступ к переменным, объявленным с квалификатором volatile, нельзя оптимизировать, а во втором — что он все равно может быть оптимизирован. Причина — в неправильном понимании требований Стандарта. Если переменная сама объявлена с квалификатором volatile, то доступ к ней оптимизировать запрещено, но если сама переменная объявлена без квалификатора volatile и доступ осуществляется через «указатель на volatile», запрета на оптимизацию нет. Последнее утверждение часто вызывает споры (пример), но тем не менее подкрепить возражения требованиями Стандарта никому не удается, а чего нет в Стандарте — не требование, а только точка зрения.
Поэтому все реализации якобы гарантированной перезаписи памяти через «указатели на volatile» полагаются на поддержку компилятора — если разработчики компилятора готовы сделать немного больше, чем требует Стандарт, то фокус удастся. Главный плюс использования указателей на volatile — они легко опознаваемы как разработчиками, так и компилятором, хорошо передают намерение авторов кода, но тем не менее такое решение не является абсолютно переносимым.
Стандарт C++, тем не менее, позволяет проводить любые преобразования кода при условии, что сохраняется «наблюдаемое поведение» — последовательность чтений-записей в переменные, объявленные с квалификатором volatile, и вызовов функций ввода-вывода.
прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться
В наше время, я полагаю, многие сочтут странным, что при анализе была рассмотрена только вероятность такой ошибки, но не были учтены возможные последствия. Сколько понадобилось самых разных сбоев и аварий с тяжелыми последствиями, чтобы граничащий с безрассудством оптимизм поубавился…
Предлагаете явное приведение беззнакового типа к знаковому. При преобразовании беззнакового типа в знаковый, если исходное значение не может быть представлено в результирующем типе, результат преобразования зависит от реализации (implementation-defined). Вы уверены, что стоит полагаться на зависящее от реализации поведение в коде для обработки довольно редких ситуаций, предназначенном для неизвестного заранее множества платформ и компиляторов?
Хорошо, возьмем систему, где long восемь байт, а size_t четыре байта (например, при компиляции gcc под 32-разрядную систему). Размер файла, допустим, пять килобайт. Предлагаемая вами функция Fits() вернет "false", хотя число около пяти тысяч вполне помещается в четырехбайтный size_t.
Тогда они перестанут быть «вообще не инициализированными».
В таком случае нельзя полагаться, что в них будут именно нулевые значения.
«Решение с установкой вручную» очень хорошо работает, нужно просто перечислить промежуточные сертификаты в определении сервиса.
Поэтому все реализации якобы гарантированной перезаписи памяти через «указатели на volatile» полагаются на поддержку компилятора — если разработчики компилятора готовы сделать немного больше, чем требует Стандарт, то фокус удастся. Главный плюс использования указателей на volatile — они легко опознаваемы как разработчиками, так и компилятором, хорошо передают намерение авторов кода, но тем не менее такое решение не является абсолютно переносимым.