Оптимизация сравнения this с нулевым указателем в gcc 6.1

такие проверки были нормальным защитным программированием

А в те времена стандарт это не считал UB?

Оптимизация сравнения this с нулевым указателем в gcc 6.1

а что мешало проверить указатель перед его разыменовыванием, а не после?
т.е.

MyType* p = new MyType;
if(p == 0)
  onMemoryLack();
else
  p->someMethod();

Оптимизация сравнения this с нулевым указателем в gcc 6.1

if (this == 0)

В нормальном коде никогда этого не встретить
Надо вообще компилятору выдавать ошибку «пересмотрите свой код немедленно» при обнаружении такого

Я хочу знать, какой код работает в моём теле

С чего вы взяли, что программисты, занимающиеся железом, сначала метили в софтверные компании?

Прощай, объектно-ориентированное программирование

На мой взгляд, эта проблема, также, как и многие другие, указанные в посте, вытекает из-за непродуманного проектирования, а не из ООП

Например, на С++:
Ничего не мешает передавать в А константную ссылку на В, если нужны 100% гарантии*, что данные в В не изменятся. В данном случае, если конструктор А требует неконстантную ссылку, то проект не скомпиляется — будет возможность продумать дальнейшие шаги по устранению до запуска программы
Если объект А все-таки принимает неконстаную ссылку, значит он меняет что-то в В, значит создание А должно сопровождаться ожиданием, что в В что-то может измениться
Объект А для своих внутренних нужд может изменять только свои приватные данные, а не внешние, т.е. В в данном случае
То есть, при самом обычном (даже не самом хорошем) проектировании указанной проблемы с ссылкой не должно возникнуть, в принципе

*100% гарантии все равно не будет, т.к. существует const_cast, но это крайний случай, который опять-таки вытекает из проектирования. Константные ссылки, константные методы и т.д. придумали не просто так

Прощай, объектно-ориентированное программирование

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

Может кто-нибудь объяснить мне подробнее «Проблему ссылки (The Reference Problem)», а то автор статьи как-то не очень понятно ее расписал? а в поисковиках что-то нашел, но не то

Прощай, объектно-ориентированное программирование

Это не фото 19 века, а картина Arch of Constantine (Rome), нарисованная Бернардо Беллотто в 18 веке

Немного размышлений и советов по оптимизации кода на С++

… поправка… т.к. '*s' в данном случае равно 's[0]'

Немного размышлений и советов по оптимизации кода на С++

Вы добавили '*s', а надо просто 's', т.к. s в данном случае равно s[0]

Немного размышлений и советов по оптимизации кода на С++

Если s — это пустая строка (""), то s[0] = 0 — тут проблем нет

А вот если s это nullptr, то s[0] приведет к неверному чтению из памяти, поэтому надо проверять в самом начале, что s не 0 (NULL, nullptr)

Вторая загадка Марса

Все больше и больше находят признаки, показывающие, что Марс — не пустая планета. Уверен, что будут происходить новые и новые сенсационные открытия с этой планеты
Кстати, не окажется ли так, что когда найдут жизнь на Марсе, то выяснится, что она была завезена случайно земными станциями-марсоходами?

Социальная сеть вселенной Звёздных войн

joke: Интересно, а хватит ли мощностей всех компьютеров в мире, чтобы также проанализировать Санта-Барбару?

Американский генетик обещает решить проблему старения через пять лет

Так и вижу описание этого товара в AliExpress через пять лет:
Набор, оживись сам, не старик, не умер, плазма, бесплатная доставка

Как я много раз не бросил разработку своей второй игры

Я считаю, что это бесценный опыт. Тут главное — продолжать разрабатывать и воплощать новые идеи. Далеко не все выстреливает, но чтобы дойти до того, чтобы выстрелило — надо набираться практического опыта. Так что полностью поддерживаю Вас

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

Чтобы парсер понял, что структура закончилась и считана полностью.

Иначе следующее поле будет считаться частью этой структуры. Это будет путаница и для парсера, и для человека.

Любое многстрочное поле (которым является структура в данном синтаксисе) начинается с имени, а заканчивается завершающей строкой.

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

Это чтобы часть пробелов не учитывать, а часть учитывать? В каком сценарии такое может быть нужно?

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

Например:

level1+
  level2+
    level3+
      level4+
        text%
          >  Это красная строка.
          >А это обычная строка.
          >  Это еще одна красная строка.
          >     Это цитата, которая имеет свое количество отступов.
          >     И эти отступы легче посчитать от первого символа, чем от левого края.
        ^
      ^
    ^
  ^
^

«часть пробелов не учитывать, а часть учитывать» — это вытекающий эффект из вышесказанного функционала.

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

Если надо в одном поле сохранить завершающий перевод строки, а в другом нет, какая у них должна быть разметка?

Вставка пустых строк в конце текста реализована (признаюсь, что в виде побочного эффекта) только при использовании служебного символа "%", т.е. при таком форматировании, при котором первый символ не учитывается, но является точкой отсчета отступов.

Например:

text%
  .string 1
  .string 2
  .
^

В следующей версии обязательно рассмотрю возможность более удобно это реализовать. Кончено же, с обратной совместимостью.

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

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

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

Из внешних инструментов может подойти любой внешний генератор уникальных последовательностей, например UUID или vaomark.com

Да, способ в этом плане для большого и разнообразного текста не дает 100% гарантии, что без использования методов поиска и/или генерации можно будет подобрать подходящую завершающую строку. Согласен, что это усложняет задачу.

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

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

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

Да.
Я этому ньюансу уделил мало внимания в статье. После Вашего комментария добавил упоминание об этом в статью.

Формат хранения данных HV как попытка решения проблемы наглядного хранения текстовых полей

Для этого нужно решить задачу подбора символа, не встречающегося в исходном тексте. Как именно вы планируете это делать?

Не символа, а целой строки (не подстроки!), которая не встречается в исходном тексте. То есть простые вхождения завершающих строк в качестве подстрок в более длинные строки не считаются концом текста.

1) В тексте несложно найти строки, которые целиком равны завершающей.

2) Можно переопределять завершающие строки. В особо сложных случаях можно ввести случайный набор символов.