Проверка на Null указателей

[Yegor]

Вот напишу я вам библиотеку, в которой одна из функций будет возвращать указатель (адрес) на буфер, и скажу, что в случае неудачи эта функция возвращает NULL (0). На этапе загрузки вы с этим ничего сделать не сможете. Вам придётся в своей программе проверять значение, возвращённое моей функцией, чтобы оно не оказалось равным нулю. Буквально IF ptr <> 0 THEN... Так?

В Жаве в аналогичной ситуации вы бы написали if (xyz != null) и никак иначе, потому что там модель ссылочная, адреса скрыты от программиста, ссылки в чистом виде не являются для программиста числами, и следовательно, сравнивать их с нулём нельзя — из-за чего и введена литера null (не является типом и не имеет своего типа; это своеобразный нолик для проверки и инициализации ссылок любого типа). UPD: спеки на Жаву в п. 4.1 говорят, что null таки имеет свой тип, но этот тип не имеет имени. In practice, the programmer can ignore the null type and just pretend that <code class="literal" style="color: rgb(0, 0, 0); font-size: 10.1999998092651px; font-style: italic; line-height: 16.7999992370605px;">null</code> is merely a special literal that can be of any reference type.

Но некоторые идут из страны весёлых языков Си/Си++. Особенно Си++. Ссылочная система там гарантирует, что объект будет валидным — null как в Жаве не требуется, и его нет. Но помимо неё есть ещё указательная система, и адреса под указателями имеют неявно числовой тип и могут быть какими угодно. До 2011 года полученные извне адреса сравнивали с нулём. Но для читаемости и чтобы не путать указатели с числами вместо нуля часто писали NULL (глобально определённая библиотечная константа, которая на самых первых этапах компиляции подменялась нулём). По той же причине люди пишут TRUE/FALSE вместо 0/1, как Валенок выше уже упомянул. А в 2011 стандартом на замену этому колхозу был введён литерал nullptr, который уже поддерживается на уровне компилятора как null в Жаве, но для указателей, а не для ссылок.

И вот SKV спрашивал, есть ли что-то вроде NULL/nullptr из мира Си++ (или ещё откуда). Ответ отрицательный: указатели придётся сравнивать с нулём или определить для себя константу с именем NULL.

[capzap]

Вот напишу я вам библиотеку, в которой одна из функций будет возвращать указатель (адрес) на буфер.

да не буду я пользоваться функцией, которая возвращает всё что угодно, скорее всего в таком случае перейду на яву, если это не решается в плк. И кста в ней , не обязательно буду возвращать null, лучше выбросить исключение. И еще если я объекту присвою null то он отправится в мусор и должен освободить ресурсы, в плк присвоив указателю ноль, он всёравно будет занимать двойное слово, а объект на который ссылался останется в памяти и надеюсь тоже сотрется со временем, а не останется занимать ресурсы

[Yegor]

Не всё что угодно, а нуль при неуспешном завершении. Это слишком распространённый приём, чтобы взять и махнуть на него рукой.

Существование и инициализированность указателя никак не влияют на время жизни объектов. Сборка мусора, когда она вообще есть, работает подсчётом ссылок. Указатели — не ссылки, а ссылки — не указатели.

[capzap]

я предпочитаю создать буфер, а в функцию передать указатель для его обработки

[Валенок]

Тогда код функции будет иметь проверку Вашего указателя на 0

[Спорягин Кирилл]

Вот для чего я собираюсь использовать проверку на null.

FUNCTION_BLOCK DispatcherModbus

VAR_INPUT
pModule : ARRAY[1..247] OF POINTER TO ModuleBase;
END_VAR

pModule - массив указателей на модули.
При первом вызове DispatcherModbus, я должен передать ссылки на все модули, которые у меня есть в системе.
Остальные остаются равными null. Затем в диспетчере я проверяю, есть ли модуль проверкой на null.

Так что проверка нужна.
Спасибо за совет использовать константу вместо 0, действительно, красивее.

[capzap]

Тогда код функции будет иметь проверку Вашего указателя на 0

я не отрицаю что проверки понадобятся, но могу использовать sizeof, а в функции через цикл прогнать, пускай даже нулевое количество циклов, только бы не по Вашему было
только всё равно не понимаю, как инициализированный буфер может не получить указатель, который Вы заставляете меня проверять, а уж инициализировать массив NULL значениями, эх, я так не умею

[Валенок]

только бы не по Вашему

как компромисс - можно так
if p < 1 then

а уж инициализировать массив NULL значениями, эх, я так не умею

а вот

FUNCTION_BLOCK DispatcherModbus

VAR_INPUT
pModule : ARRAY[1..247] OF POINTER TO ModuleBase;
END_VAR

[capzap]

а вот ...

у меня так рука не поднимется, я бы написал: pModule : ARRAY[1..247] OF DWORD := 0(247);
и то чтоб проверить
а на самом деле так проекты не пишутся, через бибку у меня вообще не встанет вопросов с адресацией, ООП в КДС2 не существует, поэтому ModuleBase это частный случай и универсальности от него ноль, полюбому писать реализацию каждый раз свою и под каждое устройство другого типа, про то чтобы держать в конфигураторе слейвы более 32 штук у меня сразу вопрос а тот ли контроллер выбрал человек

[Спорягин Кирилл]

у меня так рука не поднимется, я бы написал: pModule : ARRAY[1..247] OF DWORD := 0(247);
и то чтоб проверить
а на самом деле так проекты не пишутся, через бибку у меня вообще не встанет вопросов с адресацией, ООП в КДС2 не существует, поэтому ModuleBase это частный случай и универсальности от него ноль, полюбому писать реализацию каждый раз свою и под каждое устройство другого типа, про то чтобы держать в конфигураторе слейвы более 32 штук у меня сразу вопрос а тот ли контроллер выбрал человек

Если написать так: pModule : ARRAY[1..247] OF DWORD := 0(247);, то у Вас будет массив DWORD и как Вы будете обращаться к полям структуры ModuleBase не понятно. А я это делаю вот так:
if pModule[1]^.ReqForPooling then ....
Структура ModuleBase содержит поля, которые должны быть у любого модуля. Эти поля отвечают за организацию опроса. А вот остальная реализация модуля у каждого типа модулей, действительно, своя. Один обращается к регистрам хранения, другой к входным регистрам. Один читает 2 регистра, другой 8 и т.д. и т.п.
Одним словом ModuleBase - это базовый тип всех модулей. Конечно, организовать классическое ООП не получится, но писать в стиле приближенным к нему можно.