Как ни странно, я хотел отправить вопрос, который был полной противоположностью этого. Большинство программистов, с которыми я работал, пошло с пользовательским подходом объектов/наборов данных. Это разбивает мое сердце, чтобы наблюдать, что кто-то с их определением таблицы SQL Server открывается на одном мониторе, медленно вводя класс обертки строки соответствия в Visual Studio в другом мониторе (вместе с частными собственностями и методами set методов get для каждого столбца). Это особенно болезненно, если они также подвержены составлению таблиц на 60 столбцов. Я знаю, что существуют системы ORM, которые могут создать эти классы автоволшебно, но я видел ручной подход, используемый намного более часто.
Технический выбор всегда включает компромиссы между за и против доступных параметров. Центральный набором данных подход имеет свои преимущества (подобное таблице базы данных представление в оперативной памяти фактических данных дб, классы, записанные людьми, которые знают то, что они делают, знакомый большому бассейну разработчиков и т.д.) также как и пользовательские объекты данных (проверка типа компиляции, пользователи не должны изучать SQL и т.д.). Если все остальные в Вашей компании идут путем DataSet, по крайней мере, технически возможно, что DataSets являются лучшим выбором для того, что они делают.
Обычно не имеет значения , какой шаблон вы пишете, важно то, что вы можете идентифицировать шаблон, чтобы определить, где возникают проблемы. Так уж получилось, что в ядре Linux они часто выбираются так, чтобы их можно было перехватить, если адреса разыменованы.
Взгляните на ядро Linux по адресу include / linux / dog.h . Этот файл содержит разные значения яда для многих различных подсистем ядра. Не существует одного подходящего значения яда.
Кроме того, вы можете проверить включаемые файлы для каждой архитектуры в дереве исходных кодов ядра Linux, чтобы получить информацию о том, что используется на конкретных архитектурах.
Я предполагаю, что вы уже отказались от NULL (т.е. 0 без преобразования типов). Это определенно самый безопасный вариант, поскольку теоретически действительный указатель может указывать на адрес памяти 0xDEADBEEF (или любой другой адрес памяти, отличный от NULL).
Согласно Википедии , BADC0FFEE0DDF00D используется в 64-битных системах IBM RS / 6000 для обозначения неинициализированных регистров ЦП. 1134080]
У меня нет для вас подходящего выбора, но вот список шестнадцатеричных слов , из которых вы можете составить свою фразу.
Я вижу несколько ответов, в которых утверждается, что NULL - хороший выбор, но я не согласен.
NULL часто используется как допустимое значение, возвращаемое функциями. Это указывает на возврат ошибки или неизвестное значение. Это другое значение, чем «неинициализированный указатель».
Использование отладчика в коде и обнаружение NULL оставило бы две возможности: указатель никогда не был инициализирован или не удалось выделить память.
Установка неинициализированного указателя на 0xDEADBEEF или его 64-битный эквивалент означает, что указатель NULL указывает на намеренное значение.
0x42
может работать как на 32-битной, так и на 64-битной версиях? (Он все равно должен вызвать сбой, поскольку он достаточно близок к NULL-указателю, и, учитывая, что он довольно велик, есть вероятность, что у вас не будет его при обычном разыменовании поля структуры с указателем структуры, равным NULL).
Это, конечно, зависит от ОС и среды. Я не думаю, что 0xDEADBEEF обязательно плохой указатель в произвольной 32-битной системе.
Реально любая современная ОС должна защищать доступ к первым нескольким страницам памяти процесса, поэтому NULL должно быть хорошим недопустимым значением указателя. Достаточно удобно, это уже предопределено для вас.
Большинство современных 64-битных систем позволяют использовать только младшие 248-252 бита адресного пространства; старшие биты адреса должны быть полностью нулевыми. Некоторые чипы (например, amd64) также позволяют использовать старший 248-252. Адреса вне этих диапазонов никогда не могут быть отображены в доступную память; аппаратное обеспечение просто не позволит этого сделать.
Поэтому я рекомендую использовать значение, близкое к 263, которое не приближается ни к одному из возможных пространств. Если первые четыре шестнадцатеричные цифры равны 7ff8, то значение будет NaN с плавающей точкой двойной точности, что очень удобно. Итак, предлагаемая мной симпатичная шестнадцатеричная фраза - 0x7FF8BADFBADFBADFBADF.
Кстати, не стоит использовать значение, близкое к 0, потому что в этом случае трудно отличить смещение разыменования NULL - например, обращение к члену структуры - от разыменования яда.