O/ а есть ли вероятность, что числовое значение указателя на

динамический объект в куче окажется меньше, например 100?

Стандартом это не специфицируется. Так что в теории вероятность есть, и она ненулевая Зачем такое знание то?

Только теоретически, но фактически нереально

с чего бы

Ну на микроконтроллерах может каких разве что...

Имею в виду что практически не встречается

У меня объект либо хранит указатель, либо он nullptr но при этом ему нужно хранить небольшое число.

как и обычно главный вопрос зачем писать кривые вещи а потом бороться с ними)

Чего? Это как вообще? Если указатель равен nullptr, то как он может быть равен чему-то другому?

Что чего? Либо объект хранит указатель, либо число.

типичный случай необходимости UNION !

что-то вроде variant<int, T*>, видимо

variant, забудьте уже про юнион

Так а при чем тут указатель то? И при чем тут вероятность того, что он хранит малые численные значения? Есть вариант, да... Скорее всего это то, что нужно

Наверное хотел в указателе хранить число от 0 до 100 и сравнивать

Тоже ВАРИАНТ!

Если указатель меньше 100, то это не указатель

Ну по факту-то никто не мешает Хотя юнион/вариант будет более органичен для данного действа

Да с какой бы это стати? Указатель определяется типом Если тип - указатель, то это ни что иное, как указатель

а можно всю задачку с подробностями? В такой формулировке это немного неверно

Объект хранит либо указатель, либо число. Можно хранить и то и то, и если указатель nullptr, использовать это число. Можно сделать юнион, но где-то вам нужно будет хранить, какой тип у вас в юнионе сейчас, так что это не имеет смысла, кмк.

На x86-64 в указателе можно хранить и указатель, и небольшое число одновременно

он про другое

Есть

Почему же, я предлагаю ещё шире решение

Да и вообще как-то даже variant жирновато Просто две переменные в классе и ок. Указатель и число. Как-то без особой на то причины городить variant/union не имеет смысла. Да, неплохо подходит, но смысл?

я тоже предлагал, но зачем?

можно не использовать вариант, это лишний бул!

Как и встретить в Москве динозавра (особенно в современных ОС)

uint32_t так-то как минимум

если свой писать можно обойтись булем

что за экономия на спичках то

Это не значит, что нужно закладываться на поведение, что указатель имеет значение < 100

Как обойтись булем в variant?

у него 2 переменные

Можно. Жду пруфов

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

вариант ничего и не экономит

Пруфов чего, здравого смысла?)

Если речь про локальные переменные то про юнионы стоит забыть, если компилятор не говно

Пруфов использования нулевой странички в современных ОС

вариант фигово оптимизируется компилятором и он зачастую хуже самописного юниона

А что С++ только для современных ОС существует?

Нет, можно даже под dos написать программу

А для чего еще существует полноценный С++?

Вариант как Юнион должен лесом идти

Это не С++ будет

А что будет?

Так я не про юнион Просто в данном контексте не вижу глобального смысла использовать это: std::variant<int, T*> val; Вместо этого: int val_int; T* val_ptr; Ну уж очень сомневаюсь я, что в действительности это необходимо в задаче решаемой

Так если это локальные переменные то может быть и бред

C++ вообще не существует Потому что в рантаймах, компиляторах и ОС куча багов

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

да, смысл был в том, чтоб хранить информацию о типе в виде "а оно больше 100 ? указатель : число". Просто стало интересно, кажется я никогда не видел численно маленьких указателей.

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

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

По клешням

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

Иронично что вариант будет есть столько же памяти сколько и эти две переменные рядышком

вопрос удобства

Две переменные рядом Уютненько

По ногам...

"Тяжёлый - это надёжно. Если такой не выстрелит, то им всегда можно врезать по башке"