1) IN параметры в PL/SQL всегда pass by reference-to-const, то есть 100% точно
аналогичны C++ параметрам вида
,
и ни при каких обстоятельствах не могут быть иными, by design.
Ясность и железобетонность работы IN параметра не только автоматически освобождает мозг от вопроса правильности
использования модификатора const, но и, при понимании того, что это именно и только
, и никогда ничто иное, так же автоматически, дает все преимущества работы по ссылке.


2) В отличии от C++, на который вы ссылаетесь, в PL/SQL нет понятия "неинициализированная переменная",
это одна из причин, по которой в PL/SQL нет понятия "неопределённое поведение".

Все переменные всегда обязательно инициализируются значением,
и для unconstrained типов таким значением по умолчанию является Null (Null в PL/SQL это значение ),
а для ограниченных на Not Null типов вы обязаны указать начальное значение, согласующееся с прочими ограничениями типа.

3) Явно объявленное ограничение типа сорта Is Not Null всегда реализуется в виде атрибута типа значения, проверяемого в runtime,
оно принципиально не может быть проверено во время компиляции.
Исключением могли бы быть (может быть, и являются) Simple_* типы, т.к. на этапе компиляции проверка для них не требуется,
а фактически она всё равно возникает во время выполнения, как результат встроенного приведения типа фактического параметра к
типу формального, при их различии.
Именно и специально поэтому, если от кода требуется предельно и максимально достижимая производительность,
то и для входного параметра и внутри такого кода применяют не ограниченный на Not Null Тип.

4) Сравнивая PL/SQL с "другими языками", подразумевая это явно или нет, вы даете отсылки к таким "другим языкам",
которые являются языками программирования , но PL/SQL таковым не является .

В том смысле не является, в каком под "языками программирования" понимаются языки программирования общего назначения .
Таким языкам - языкам программирования общего назначения, запрещено нарушать закон исключения третьего.
И в этом существо дела.

PL/SQL проходит по другой категории - [i]процедурные расширения [/i] языка SQL.
Хотя он мог бы и языком программирования являться, но компания - владелец языка,
в стране своего существования, не рискует даже пытаться озвучивать такого сорта произношение,
дабы не возбуждать академически образованную общественность,
а все, что делала и делает в этом плане, делает так, чтобы и подозрений не могло возникать о возможности и допустимости
использования PL/SQL в отрыве от инфраструктуры Oracle Database.


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

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

здесь тоже, с оговоркой на то, что Simple_* типы самые быстрые by design.
И Not Null у них, похоже, чуть-чуть другой системы.

Впрочем, есть - в части значений OUT параметров вызываемой процедуры при возникновении в ней необработанной ошибки.
Однако это не подразумевает возможности неконтролируемого падения падения процесса,
обычно ассоциируемого с термином "неопределенное поведение" как неотъемлемая возможность такого поведения.

Вы бы сняли клоунский колпак.
Шутки у вас плоские, если всё ещё считать, что вы "продолжаете шутить".

что это, ты что - пьёшь по ночам?

Вы чё, белены объелись?
Расскажи, из какой ноздри таку бредятину доставать надо?

Правильно ли я понял, что вы утверждаете буквально следующее:
При объявлении в разделе деклараций процедуры/функции/анонимного блока
переменной типа, например, pls_integer, на стеке выделяется память не под значение для этой переменной,
а всегда и обязательно под адрес к выделяемому в куче значению?
И значение Null в Pl/SQL всегда опознается по нулевому значению этого адреса?

Я, правда, не знаю, как оно на самом деле, расскажите.
Я свою белену закатаю в трубочку, если вы как-то сможете обосновать своё суждение.

кстати, даже если на самом деле используется любая форма косвенности,
это означает лишь то, что что получение нуля в качестве адреса в параметре в PL/SQL невозможно в принципе.
Поэтому, и в таком случае тоже, аналогия с передачей nullptr в параметр в С++ - некорректна.

я уже не помню, где он их на самом деле различает.
Но право вдруг, когда-нибудь, начать повсеместно различать - точно за собой оставляет,
даже если не будет делать так никогда.

сорри, был глюк какойто, д.б. так:


Вы задали мне такой вопрос:
AmKad..попробуйте ответить на вопрос: какой способ передачи параметров в функцию в С/С++ (без учета наличия перегрузок) позволяет логически сделать параметр необязательным (непроинициализированным) и в вызываемой функции определить, был ли передан (проинициализирован) тот или иной параметр

Ответа на него я не знаю , в частности потому, что вообще отношения ни C, ни С++ не имею.
Технически, "в стиле C/C++", на уровне подсистемы передачи параметров, это можно было бы делать передачей как раз nullptr для пропущенного параметра, изолированного в промежуточную ссылочную переменную.
Однако Вы, задавая такой такой вопрос, вероятно не просто знаете на него правильный ответ,
но и понимаете, как он обосновывает утверждение о том, что nullptr "по смыслу наиболее близкое значение к ораколовому null".

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




В контексте данного конкретного топика это выглядит вообще как весёлая шутка:
Т.е., перевожу:
С++ развивается от C в направлении к Ada, в смысле непрерывного укрепления строгости системы типов,
а PL/SQL с рождения продрейфовал от Ada к "процедурным расширениям SQL", сразу и явно пожертвовав строгостью системы типов,
путём внедрения встроенного преобразования типов для значений.

Спасибо, посмеялся вместе с Вами.

AmKad,

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

Кстати, это правда мог бы быть простой вариант реализации за малую цену общей производительности.
Но даже, если это на самом деле так, и Вы абсолютно правы в своем "почти приравнивании" nullptr в C++ и Null в pl/sql,
а белены объелся именно я, это не отменяет того, что в логическом отношении PL/SQL-Null - это самостоятельное значение.

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

В этом смысле сравнение там, где вы именно именно в качестве передаваемого параметра nullptr используете как аналогию,
для меня остаётся как выглядящее неприемлемым.

если подразумевается, имеющими значение 0xFF, то в русском языке это называется - всегда инициализированы

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