@DrewDDD

double*p показать, что операция p++ передвигает указатель по памяти на определенное кол-во байт впарво

0

@eva2326

Вы опять перепутали "указатель" и "адрес".
Понятие указателя четко определено: тип данных, который хранит адрес.

Непознаваемым может быть "адрес".
На самом деле он познаваемый, но только на уровне конкретной реализации с++.
То бишь, когда речь идет о конкретной реализации в конкретном компиляторе.

0

@Catstail

- так я
и имею дело с конкретным компилятором. А не со сферическим конем в вакууме. Возможно компиляторы с непознаваемым адресом и существуют, но мне что-то не попадались. А вам?

0

@eva2326

Попробуйте))
Добавлено через 3 минуты
Не правда.
Если бы вы подразумевали конкретный компилятор, то вы бы привели ссылку на спецификацию, или какой либо другой нормативный документ с описанием сабжа.

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

0

@Catstail

- "неправда" пишется слитно. Я посмотрел ваши посты. В них практически отсутствуют ссылки на спецификации... Так вы на чем программируете? На "банановом компиляторе"?

- это нетрудно. Но что это даст вам? Берем, в hex-вид и дальше дизассемблер. И что?

0

@DrOffset

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

Поэтому, я бы не спорил с тем, что на определенных платформах значение указателя - это некоторое число, но спорил бы с тем, что С++, как язык, это гарантирует. Исходя из стандарта С++ и вышеизложенных соображений.

1

@eva2326

Ваше исходное заявление:
Это - не правда, а ложь.

Ну так и где моё предсказание ????

У меня есть возражение !!!
Я вам последовательность предоставила, а предсказания так и не получила!

Вы меня обманули !!!!

0

@Catstail

DrOffset, Вы совершенно правы! Началу спора положил невинный вопрос ТС. А потом на меня набросились пуристы... Я давно понял, что мы с ними - на разных уровнях абстракции. Но когда мне говорят: "Вы неправы, т.к. путаете понятия", я, естественно, хочу разобраться. Если я ошибаюсь, чем мне грозит ошибка? К примеру, когда мне говорят не путай съедобные грибы и поганки, тут цена ошибки совершенно очевидна. Чем же я рискую, если буду считать, что указатель - это адрес, а адрес - это число? Да ничем! А если выяснится, что в каком-либо компьютере будущего адрес - это банан, то я не упаду в обморок и приму это к сведению. С наступающим Вас!

0

@Catstail

- просто отвлекался. Для процессора x86 ваша последовательность из 50 битов - бессмысленна. Ибо:

11010110011100011110000110101010001010000111011101 = D6 71 E1 AA 28 77 (два последних бита отброшены)

Берем онлайн дизассемблер и смотрим, что эта последовательность означает для x86 (на картинке). Первый байт не представляет нормальной команды. Дальше идет условный переход по адресу... Если же условие не соблюдено, то 8-битный аккумулятор сбрасывается по адресу es:[edi]. И еще два байта не представляют легальной команды x86 (распознаны как данные). Есть претензии?

Миниатюры

 

0

@eva2326

Чем рискуют люди, которые думают, что земля плоская?

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


Например:
Указатель-на-функцию-член принципиально отличается от указателя-на-данные.
Различия настолько принципиально принципиальны, что их в принципе не корректно сравнивать.

А размеры указателей-на-функции-члены могут варьировать в зависисмости от строения их классов.

Например:
Использовалось ли наследование? А если использовалось, то какое? Обычное? Множественное? Виртуальное?

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


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

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

Добавлено через 2 минуты
По-моему, это какая то бессмыслица.

0

@Catstail

- можно конкретный пример?

- я понял, что вы имеете в виду. Но тут мы меняемся ролями: "смещение от начала класса" звучит не очень хорошо.

- да вы приведите как выглядят эти "адреса с принципиально разным устройством"! Я понимаю, что вы имеете в виду. Но, вообще-то, речь шла про нативные типы (double, int). Их адрес - это просто число (номер байта начала в виртуальном адресном пространстве), нет? А указатели на сложные агрегаты данных - согласен, могут быть устроены сложнее (обычный адрес + флаги какие-нибудь) и что? Внутри адрес - это просто сигара просто число.


И, как я понял, к интерпретации битовой последовательности претензий нет?

Добавлено через 9 минут
Вообще объяснить - это сделать понятным. Что, в свою очередь, достигается разными приемами. Например, сведением новых понятий к уже известным. У вас же я замечаю противоположную тенденцию (была такая эпиграмма на одного поэта: "Поэт от слова внятного идет путем обратного. Чтоб из всего понятного все сделать непонятным" Почему-то вспомнилось )


- Те, кто не планирует поездок дальше, чем на 500 км - ничем. Потом будет иметь место нарастающая ошибка. Но вы не ответили на мой вопрос: чем рискую я в описанном выше случае? Вы бы, что называется, "положили меня на обе лопатки", если бы сказали примерно так: представление о том, что адрес - это просто число, не позволит вам отъехать дальше, чем на 100 км от дома решать вот такие задачи *** и вот такие ***, а также такие ***. И я бы согласился. Если бы вы заполнили поля, отмеченные звездочками.

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

0

@eva2326

Как вы это себе представляете?
Вам код написать, который проиллюстрирует, что такие указатели принципиально несовместимы?
Или вслух почитать стандарт с++?

Или достаточно будет отослать к быстрым делегатам?

Я не знаю, как ещё донести эту мысль: адрес не обязан быть просто числом, и может быть чем угодно.

double*p показать, что операция p++ передвигает указатель по памяти на определенное кол-во байт впарво

Я ни на кого не нападаю.
Можете думать, что земля круглая, или что адрес - это число, мне без разницы.

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

Вы ссылаетесь на ассемблер, на дебаггер, на циферки в черно-белой консольке.
Я ссылаюсь на правила языка.

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

Добавлено через 1 минуту
Не имеет значения.
В правилах нигде не сказанно, что там под капотом будет именно "смещение".
Там может быть всё, что угодно.

А вы по прежнему можете считать, что там будут "просто цифры", которые "просто по другому" интерпретируются компилятором.

0

IGPIGP

Catstail, приветствую)
Вам не переспорить. Это не имеет смысла, потому, что тут не прощают даже неверно поставленного ударения. По сути вы выбрали не тот тип который бы выбрал С++ "непурист". То есть, тот кто считатет что плохое состояние природы это непогода а не погода с плохим состоянием. Такой непурист выбрал бы size_t или unsigned int , что в общем-то по размеру соответствует вашему long (если иметь ввиду множество неотрицательных (не очень отрицательных ) значений. Вот тут
https://en.cppreference.com/w/cpp/types/size_t
То есть, вы почти правы. Но вот это почти вам вынесут вместе с мозгом. Советую остановиться.
Я помню наши с вами споры. Многое изменилось с тех пор)
С Новым Годом!

0

@DrOffset

0

@Catstail

IGPIGP, и Вас - с Новым годом! Необычайно приятен мне Ваш ответ! Да. Смиряюсь. Но не могу не вспомнить бессмертного А.П.Чехова. В "Скучной истории" (кажется) герой произносит фразу "Не представляю, как этот сухарь живет со своею женой". Можно перефразировать классика - не понимаю, как с такими представлениями о языке можно программировать с помощью конкретного компилятора.

- да, наконец дошло. Если говорить только о стандарте языка, то конечно. Но какое отношение это имеет к практическому программированию - непонятно. Осознание кривизны Земли для навигации - ключевой момент. А то, что адрес может быть чем угодно - что это мне даёт? Да ничего! В конкретных реализациях C/С++ адрес - это число. Даже если (как говорил бравый солдат Швейк), вы бы... Впрочем, стоп. Думаю, здесь уместно будет поставить точку в этой явно затянувшейся новогодней дискуссии! Если захотите еще обсудить что есть веревка - вервие простое глубокую философскую сущность понятий "адрес", "указатель", "переменная" и т.п. - к вашим услугам

1

IGPIGP

Catstail, мы живём в дискретном мире, где всё что не возьми - целое число. Да. Это набор нулей и единиц. Но язык С++ постоянно удаляется от предметной области - физической модели вычислительной системы в сторону построения некой абстрактной машины. То есть, понятие типа объекта размягчилось и сменилось понятием выражения. Понятие ссылки (способа доступа, в частности) сдаёт позицию понятию значения. В человеческой логике, значение - контекстно зависимый информационный набор связанный с физическим объектом. То есть, это способ интерпретации некоторой сущности существующей объективно (независимо от нашего сознания). В стандарте С++ значения это категории существующие независимо от чего бы то ни было, связанного с физикой системы.
Я надеюсь, что не подниму слишком большого шума, - на мелкий стараюсь не реагировать.
Однако, всё сказанное к тому, что недалеко то время, когда компилятор не даст вам ни какой гарантии о том, что значение указателя не связанного с каким либо объектом, сохраняется как некоторое значение. Это трудно представить, но задекларировать в стандарте - раз плюнуть.
Что касается контекста и значения в контексте, то в С есть указатель на char. Этот тип имеет целый набор значений с которыми он может быть связан.
1. Указатель - целое число для хранения представления адреса символа;
2. Указатель по п.1. для доступа к строке символов (реализуется на уровне библиотек, но это не важно, поскольку набор операций предоставляемый библиотеками типа string.h де-факто, стандартное свойство языка С).
3. Указатель для доступа к массиву char без терминатора (массиву, который запросто может содержать терминаторы внутри и не содержать оный в конце).
Последнее, это значение разделяемое системой и программистом. Ибо кроме программиста, размера ни кто не знает. То есть, значение высокого уровня может быть субъективно(!).
***
А внутренне, - в части представления, такой указатель содержит (всегда и независимо от инициализации или оптимизации кода, где целевого объекта фактически нет) целое число, которое язык позволяет использовать для доступа к объекту типа char (символу на данной системе), вне зависимости от контекстно зависимых значений более высокого уровня.
Хух... О чём тут спорить? - Oбовсём (слитно т.к. раздел форума как контекст присутствует). И это отличная причина, не делать этого. Даже самая сложная предметная логика, может быть описана простыми принципами. Но может быть и иначе и тогда только талмуд спасает праведную душу.


Добавлено через 1 час 4 минуты
Вот простая неточность, которая может вызвать возражение. Форма может быть любой, что прискорбно.
Да. Существует значение представимое целочисленным литералом 0. Оно не должно проецироваться ни в какой адрес. Это исключение и я не упомянул о нём. И такой момент может поломать любую тему, уведя её в сторону.
Но само по себе, - наличие высокоуровневой абстракции "nullptr" как раз хороший пример, который показывает неизбежность присутствия таких вещей. Есть системы, где нулевой адрес существует физически и защитить этот ноль призван nullptr. Это тот случай, когда указатель не есть адрес, а есть отсутствие адреса. Спор о том, считать ноль адресом или нет, неразумен. Но факт есть факт - указатели это уникальный тип, имеющий в наборе значение которое интерпретируется как отсутствие значения. Представьте как славно было бы, если бы у всех целых типов было уникальное значение вроде "nothing". И именно указатели позволяют осуществить полноту такой логики. Но их заменили ссылками почти повсеместно и говорить о том, что это сделано из злонамеренных побуждений - риск прослыть конспирологом. Впрочем, в нормальных языках ссылки существуют как неконстантные объекты и их также можно занулять как и указатели. Я верю, что наступит день, когда С++ станет в ряд с такими языками. Подобное расширение для ссылок расширяет функциональность не влияя на совместимость с ранее написанным кодом. Борцы за безопасность могут придти в ярость, но им это просто необходимо (гормонально). Бог с ними)
И ещё по одной (фигурально, конечно)

2

@Catstail

- почему же трудно представить? Можно представить. Но зачем его менять? Разве что из-за сборки мусора... Но я с этим смирюсь. (Кстати, при этом адрес останется числом! )

Вот еще пример в тему: чему равно значение переменной цикла сразу после завершения цикла? Пурист скажет: "надо читать стандарт!". А я скажу: не обязательно. Просто присваивайте переменной цикла нужное значение, а что там после цикла осталось - неважно! И не пользуйтесь тем, что там лежит, сразу после завершения цикла. Я при этом ничего не потеряю. А пурист пусть вычисляет, сколько ангелов разместится на кончике иглы, чему будет равно значение переменной х после выполнения следующего кода:

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

Под занавес - две цитаты из классиков, которые мне близки: "Плюньте на совершенство, иначе вы не сдвинетесь с места и никогда не доберетесь до сути вещей" (Ж-П Сартр); "Не верь ничему, но сомневайся только в том, в чем стоит сомневаться" (Д.Пойа).

1

IGPIGP

У нас оно недоступно ибо вышло из области. Если выше цикла объявить указатель и внутри цикла его установить, то по выходе из области попытка разыменования приведёт к неопределённому результату.
Выполнение кода с операциями модифицирующими lvalue но не разделёнными точками следования неопределено и... Я не против пуризма. Программист это в определённом смысле (контексте) пурист. Я против пуризма, уводящего тему в сторону. Я против пуризма для самоутверждения. Я против пуризма вне разумного контекста, иными словами.
Я люблю военное:
Ни слова правды, но суть - как слеза.
Это совершенство в сути своей. Ведь что бы понять что такое
нужно строго и без сомнения определить что к чему. И сомневаться только в том, что ты правильно определил в чем стоит сомневаться а в чём - категорически не стоит.
Это как ни разу не подумать о белой обезьяне. Контекст - бог истины. Белый Гендальф, с белой обезьяной на белом плече. Что принесёт нам белый бык? Сказку про белого бычка? Посмотрим.

1

@DrOffset

В общем смысле это дает возможность писать переносимые программы.

Есть реализации, где адрес - это пара чисел. Или, где адрес - это число, но в регистр для данных его загрузить нельзя, не поместится. Максимальная разрядность целого числа на такой платформе меньше, чем разрядность указателя.

Но тут даже не в этом дело. Выше вы упомянули long, и к этому тоже были вопросы.
Очень много "боли" было от кода "непуристов", которые в течении десятка лет писали код для 32-битных платформ в святой уверенности, что long всегда будет помещать в себя значение указателя. Несколько лет назад мы как раз переводили огромный проект для с 32 бит на 64. И я бы предпочел, чтобы его писали пуристы, пусть даже с некоторыми перегибами в формализме.
По теме: https://www.viva64.com/ru/a/0004/

На всякий случай, для корректного преобразования указателя в число в C++ существует специальный целый тип uintptr_t. Этот тип специально сделан опциональным как раз для тех случаев, когда на платформе нет возможности осуществить такое преобразование. Если в вашей реализации такой тип присутствует, значит преобразовывать в целое можно, но использовать надо именно этот тип, чтобы потом, когда ваш код, например, будут портировать на большую разрядность, не было проблем.

"пурист" скажет, что в этом выражении UB, и рассматривать его с точки зрения вычислимости не имеет смысла.

2

IGPIGP

Пуриcт попытается щёлкнуть по носу говорящего (непуристически) про:
и свести тему с рельс на десятки страниц. Я прекрасно понимаю желание Catstail, защищаться. Вот почему я стал рядом. Про size_t и uintptr_t в этой теме было вот тут:
double*p показать, что операция p++ передвигает указатель по памяти на определенное кол-во байт впарво
7 постов вверх)
Catstail, раз уж я опять выполз - хочу про нулябельность, контекст и ненулябельный тип сказать ещё.У типа size_t такое значение присутствует именно в контексте применения в качестве индекса. Причина именно в том, что индексация начинается с 0 и максимальное значение для типа size_t в типичной реализации (четыре фантомаса) не может быть индексом ни какого элемента, поскольку количество элементов не может быть больше максимумв для size_t. То есть заклинание:
работает) У класса std::string значение npos так и реализовано (обычно).
Если посчитать всё противопуристские заклинания оговорки типа иногда, обычно и пр., становится смешно. Вот так смеясь я пишу.

0

@DrOffset

0