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

Why are pointers such a leading factor of confusion for many new, and even old, college level students in the C/C++ language?

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

Are there any tools or thought processes that helped you understand how pointers work at the variable, function, and beyond level?

Адреса ящики. Я помню, когда я учился программировать BASIC на микрокомпьютерах, были эти милые книжки с играми, и иногда приходилось указывать значения по определенным адресам. У них было изображение группы коробок, постепенно помеченных цифрами 0, 1, 2 ... и было объяснено, что только одна маленькая вещь (байт) могла поместиться в эти коробки, а их было много - некоторые компьютеры было аж 65535! Они были рядом друг с другом, и у всех был адрес.

What are some good practice things that can be done to bring somebody to the level of, "Ah-hah, I got it," without getting them bogged down in the overall concept? Basically, drill like scenarios.

Для дрели? Сделайте структуру:

struct {
char a;
char b;
char c;
char d;
} mystruct;
mystruct.a = 'r';
mystruct.b = 's';
mystruct.c = 't';
mystruct.d = 'u';

char* my_pointer;
my_pointer = &mystruct.b;
cout << 'Start: my_pointer = ' << *my_pointer << endl;
my_pointer++;
cout << 'After: my_pointer = ' << *my_pointer << endl;
my_pointer = &mystruct.a;
cout << 'Then: my_pointer = ' << *my_pointer << endl;
my_pointer = my_pointer + 3;
cout << 'End: my_pointer = ' << *my_pointer << endl;

Тот же пример, что и выше, за исключением C:

// Same example as above, except in C:
struct {
    char a;
    char b;
    char c;
    char d;
} mystruct;

mystruct.a = 'r';
mystruct.b = 's';
mystruct.c = 't';
mystruct.d = 'u';

char* my_pointer;
my_pointer = &mystruct.b;

printf("Start: my_pointer = %c\n", *my_pointer);
my_pointer++;
printf("After: my_pointer = %c\n", *my_pointer);
my_pointer = &mystruct.a;
printf("Then: my_pointer = %c\n", *my_pointer);
my_pointer = my_pointer + 3;
printf("End: my_pointer = %c\n", *my_pointer);

Выход:

Start: my_pointer = s
After: my_pointer = t
Then: my_pointer = r
End: my_pointer = u

Возможно, это объясняет некоторые основы на примере?

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

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

Я не понимаю, что сбивает с толку в указателях. Они указывают на место в памяти, то есть хранят адрес памяти. В C / C++ вы можете указать тип, на который указывает указатель. Например:

int* my_int_pointer;

Говорит, что my_int_pointer содержит адрес места, содержащего int.

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

Причина, по которой указатели, кажется, сбивают с толку многих людей, заключается в том, что они в основном не имеют или почти не имеют знаний в области компьютерной архитектуры. Поскольку многие, похоже, не имеют представления о том, как на самом деле реализованы компьютеры (машина), работа на C / C++ кажется чуждой.

Упражнение состоит в том, чтобы попросить их реализовать простую виртуальную машину на основе байт-кода (на любом языке, который они выберут, python отлично подходит для этого) с набором инструкций, ориентированным на операции с указателями (загрузка, сохранение, прямая / косвенная адресация). Затем попросите их написать простые программы для этого набора инструкций.

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

Я думаю, что основная причина, по которой у людей возникают проблемы с этим, заключается в том, что этому обычно не преподают интересно и увлекательно. Я бы хотел, чтобы лектор набрал 10 добровольцев из толпы и дал им линейку длиной 1 метр, заставил их встать в определенной конфигурации и использовать линейки, чтобы указывать друг на друга. Затем покажите арифметику указателя, перемещая людей (и куда они указывают свои линейки). Это был бы простой, но эффективный (и, прежде всего, запоминающийся) способ продемонстрировать концепции, не слишком увязнув в механике.

Как только вы дойдете до C и C++, некоторым людям станет труднее. Я не уверен, что это потому, что они, наконец, применяют теорию, которую они не понимают должным образом, или потому, что манипуляции с указателями по своей сути сложнее в этих языках. Я не могу вспомнить свой собственный переход так хорошо, но я знал указатели в Паскале, а затем перешел на C и полностью потерялся.

Пример учебника с хорошим набором диаграмм очень помогает в понимании указателей..

Джоэл Спольски делает несколько хороших замечаний по поводу понимания указателей в своей статье Guerrilla Руководство по собеседованию:

For some reason most people seem to be born without the part of the brain that understands pointers. This is an aptitude thing, not a skill thing – it requires a complex form of doubly-indirected thinking that some people just can't do.

На моем первом занятии по компьютерным наукам мы сделали следующее упражнение. Конечно, это был лекционный зал, в котором было около 200 студентов ...

Профессор пишет на доске: int john;.

Джон встает

Профессор пишет: int *sally = &john;.

Салли встает, показывает на Джона.

Профессор: int *bill = sally;

Билл встает, указывает на Джона

Профессор: int sam;

Сэм встает

Профессор: bill = &sam;

Билл теперь указывает на Сэма.

Думаю, вы поняли. Думаю, мы потратили на это около часа, пока не познакомились с основами присвоения указателей.

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

Я был связан с системами, в которых у нас были структуры, указывающие на другие структуры, указывающие на другие структуры. Некоторые из этих структур также содержат встроенные структуры (а не указатели на дополнительные структуры). Вот где указатели действительно сбивают с толку. Если у вас есть несколько уровней косвенного обращения, и вы начинаете с такого кода:

widget->wazzle.fizzle = fazzle.foozle->wazzle;

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

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

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

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

Я нашел "Учебник по указателям и массивам в C" Теда Дженсена отличным ресурсом для изучения указателей. Он разделен на 10 уроков, начиная с объяснения того, что такое указатели (и для чего они нужны), и заканчивая указателями на функции. http://web.archive.org/web/20181011221220/http://home.netcom.com:80/~tjensen/ptr/cpoint.htm

Двигаясь дальше, Beej's Guide to Network Programming учит API сокетов Unix, из которого вы можете начать делать действительно забавные вещи. http://beej.us/guide/bgnet/

Мне нравится аналогия с домашним адресом, но я всегда думал об адресе самого почтового ящика. Таким образом вы можете визуализировать концепцию разыменования указателя (открытие почтового ящика).

Например, следуя связному списку: 1) начните с вашей статьи с адреса 2) Перейдите по адресу, указанному на бумаге 3) Откройте почтовый ящик, чтобы найти новый лист бумаги со следующим адресом.

В линейно связанном списке в последнем почтовом ящике ничего нет (конец списка). В круговом связном списке последний почтовый ящик имеет адрес первого почтового ящика в нем.

Обратите внимание, что на шаге 3 происходит разыменование и когда вы ошибаетесь или ошибаетесь, если адрес недействителен. Предполагая, что вы можете подойти к почтовому ящику с недействительным адресом, представьте, что там есть черная дыра или что-то такое, что выворачивает мир наизнанку :)

Аналогия, которую я нашел полезной для объяснения указателей, - это гиперссылки. Большинство людей понимают, что ссылка на веб-странице «указывает» на другую страницу в Интернете, и если вы можете скопировать и вставить эту гиперссылку, они обе будут указывать на одну и ту же исходную веб-страницу. Если вы перейдете и отредактируете исходную страницу, а затем перейдите по любой из этих ссылок (указателей), вы получите новую обновленную страницу.

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

http://arjay.bc.ca/Modula-2/Text/Ch15/Ch15.8.html#15.8.5 говорит об этом немного более связно, чем я. :-)

Я думаю, что то, что делает указатели сложными для изучения, заключается в том, что до указателей вы будете довольны идеей, что «в этой ячейке памяти находится набор битов, представляющих int, double, символ, что угодно».

Когда вы впервые видите указатель, вы действительно не понимаете, что находится в этой ячейке памяти. "Что ты имеешь в виду, у него адрес?"

Я не согласен с утверждением, что «вы их либо получаете, либо нет».

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

Номер почтового ящика.

Это часть информации, которая позволяет вам получить доступ к чему-то еще.

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

Проблема с указателями не в концепции. Дело в исполнении и языке. Дополнительная путаница возникает, когда учителя полагают, что сложна КОНЦЕПЦИЯ указателей, а не жаргон или запутанный беспорядок, который C и C++ вносят в эту концепцию. Так много усилий затрачивается на объяснение концепции (как в принятом ответе на этот вопрос), и это в значительной степени просто напрасно тратится на кого-то вроде меня, потому что я уже все это понимаю. Это просто объясняет неправильную часть проблемы.

Чтобы дать вам представление о моем происхождении, я прекрасно понимаю указатели и могу грамотно использовать их на языке ассемблера. Потому что на языке ассемблера они не называются указателями. Они называются адресами. Когда дело доходит до программирования и использования указателей в C, я делаю много ошибок и очень запутываюсь. Я до сих пор не разобрался. Позвольте привести пример.

Когда api говорит:

int doIt(char *buffer )
//*buffer is a pointer to the buffer

чего он хочет?

он мог бы хотеть:

число, представляющее адрес буфера

(Для этого я скажу doIt(mybuffer) или doIt(*myBuffer)?)

число, представляющее адрес адреса в буфере

(это doIt(&mybuffer) или doIt(mybuffer) или doIt(*mybuffer)?)

число, представляющее адрес к адресу к адресу к буферу

(может быть, это doIt(&mybuffer). или это doIt(&&mybuffer)? или даже doIt(&&&mybuffer))

и так далее, и используемый язык не делает это таким ясным, потому что он включает слова «указатель» и «ссылка», которые для меня не имеют такого большого значения и ясности, как «x содержит адрес y» и « для этой функции требуется адрес y ". Ответ также зависит от того, что это за чертов "mybuffer" вначале и что doI собирается с ним делать. Язык не поддерживает уровни вложенности, встречающиеся на практике. Например, когда мне нужно передать «указатель» на функцию, которая создает новый буфер, и она изменяет указатель так, чтобы он указывал на новое местоположение буфера. Действительно ли ему нужен указатель или указатель на указатель, чтобы он знал, куда идти, чтобы изменить содержимое указателя. В большинстве случаев мне просто нужно угадать, что имеется в виду под «указателем», и в большинстве случаев я ошибаюсь, независимо от того, сколько опыта я имею в этом.

"Указатель" слишком перегружен. Указатель - это адрес значения? или это переменная, которая содержит адрес значения. Когда функции нужен указатель, нужен ли ей адрес, который хранится в переменной-указателе, или ей нужен адрес переменной-указателя? Я запутался.

Я думаю, это может быть проблема с синтаксисом. Синтаксис C / C++ для указателей кажется непоследовательным и более сложным, чем должен быть.

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

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

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

Многие бывшие разработчики C++ (которые никогда не понимали, что итераторы - это современные указатели до того, как сбросить код языка) переходят на C# и все еще считают, что у них есть достойные итераторы.

Хм, проблема в том, что все, что есть итераторы, совершенно не соответствуют тому, что платформы времени выполнения (Java / CLR) пытаются достичь: новое, простое использование, каждый - разработчик. Это может быть хорошо, но они сказали это однажды в пурпурной книге, и они сказали это даже до и перед C:

Косвенность.

Очень мощная концепция, но никогда не будет так, если вы будете делать это полностью. Итераторы полезны, поскольку они помогают с абстракцией алгоритмов, еще один пример. И время компиляции - это место для алгоритма, очень простого. Вы знаете код + данные или на другом языке C#:

IEnumerable + LINQ + Massive Framework = штраф во время выполнения 300 МБ за отвратительное перетаскивание приложений через кучу экземпляров ссылочных типов ..

«Ле Пойнтер дешевый».

Причина, по которой это так сложно понять, заключается не в том, что это сложная концепция, а в том, что синтаксис непоследователен.

   int *mypointer;

Сначала вы узнали, что самая левая часть создания переменной определяет тип переменной. Объявление указателя работает иначе в C и C++. Вместо этого они говорят, что переменная указывает на тип слева. В этом случае: *mypointer указывает на int.

Я не полностью понимал указатели, пока не попытался использовать их в C# (с небезопасным), они работают точно так же, но с логичным и последовательным синтаксисом. Указатель - это сам тип. Здесь mypointer является указатель на int.

  int* mypointer;

Даже не заставляйте меня начинать с указателей функций ...

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

Путаница возникает из-за того, что несколько уровней абстракции смешиваются в концепции «указателя». Программистов не смущают обычные ссылки в Java / Python, но указатели отличаются тем, что раскрывают характеристики базовой архитектуры памяти.

Четкое разделение уровней абстракции - хороший принцип, а указатели этого не делают.

Причина, по которой мне поначалу было трудно понять указатели, заключалась в том, что многие объяснения содержат много чуши о передаче по ссылке. Все это только запутывает проблему. Когда вы используете параметр указателя, вы передаете Все еще по значению; но значение оказывается адресом, а не, скажем, int.

Кто-то уже связался с этим руководством, но я могу выделить момент, когда я начал понимать указатели:

Учебник по указателям и массивам в C: Глава 3 - Указатели и строки

int puts(const char *s);

For the moment, ignore the const. The parameter passed to puts() is a pointer, that is the value of a pointer (since all parameters in C are passed by value), and the value of a pointer is the address to which it points, or, simply, an address. Thus when we write puts(strA); as we have seen, we are passing the address of strA[0].

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

Даже если вы разработчик VB .NET или C# (как и я) и никогда не используете небезопасный код, все равно стоит понимать, как работают указатели, иначе вы не поймете, как работают ссылки на объекты. Тогда у вас будет распространенное, но ошибочное представление о том, что передача ссылки на объект методу копирует объект.

Я думаю, что основным препятствием для понимания указателей являются плохие учителя.

Почти всех учат лжи об указателях: что это не более чем адреса памяти или что они позволяют указывать на произвольные местоположения.

И конечно, что они трудные для понимания, опасные и полу-магические.

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

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

(Обратите внимание, прежде чем кто-либо станет педантичным по отношению ко мне, да, стандарт C++ действительно говорит, что указатели представлять адресов памяти. Но он не говорит, что «указатели - это адреса памяти, и ничего, кроме адресов памяти, и могут использоваться или рассматриваться как взаимозаменяемые с памятью. адресов ". Различие важно)

Каждый новичок в C / C++ сталкивается с одной и той же проблемой, и эта проблема возникает не потому, что «указатели трудно выучить», а «кто и как это объясняет». Некоторые учащиеся собирают это словесно, некоторые визуально, и лучший способ объяснить это - использовать пример "поезда" (подходит для вербального и визуального примера).

Где "паровоз" - это указатель, который не можешь содержит что-либо, а "вагон" - это то, что «локомотив» пытается тянуть (или указывать). После этого вы можете классифицировать сам «вагон», может ли он содержать животных, растения или людей (или их комбинацию).

Я подумал, что добавлю аналогию к этому списку, который я нашел очень полезным при объяснении указателей (в свое время) в качестве репетитора по информатике; сначала давайте:

Подготовить почву:

Рассмотрим стоянку на 3 места, эти места пронумерованы:

-------------------
|     |     |     |
|  1  |  2  |  3  |
|     |     |     |

В некотором смысле это похоже на ячейки памяти, они последовательные и смежные ... вроде как массив. Сейчас в них нет машин, так что это как пустой массив (parking_lot[3] = {0}).

Добавьте данные

Парковка никогда не остается пустой ... в противном случае это было бы бессмысленно, и никто не стал бы ее строить. Итак, предположим, что в течение дня на участке появляются 3 машины: синяя, красная и зеленая:

   1     2     3
-------------------
| o=o | o=o | o=o |
| |B| | |R| | |G| |
| o-o | o-o | o-o |

Все эти автомобили относятся к одному типу (машинам), поэтому можно думать об этом так: наши автомобили представляют собой своего рода данные (скажем, int), но имеют разные значения (blue, red, green; это может быть цвет enum).

Введите указатель

Теперь, если я отведу вас на эту стоянку и попрошу найти мне синюю машину, вы протянете один палец и укажете им на синюю машину в точке 1. Это все равно, что взять указатель и назначить его адресу памяти. (int *finger = parking_lot)

Ваш палец (указатель) не является ответом на мой вопрос. Глядя на в, ваш палец мне ничего не говорит, но если я посмотрю, где ваш палец - это указывает на (разыменование указателя), я могу найти машину (данные), которые я искал.

Переназначение указателя

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

Указатель физически не изменился, это все еще палец ваш, изменились только данные, которые он мне показывал. (адрес "парковочного места")

Двойные указатели (или указатель на указатель)

Это также работает с более чем одним указателем. Я могу спросить, где указатель, который указывает на красную машину, и вы можете другой рукой указать пальцем на первый палец. (это как int **finger_two = &finger)

Теперь, если я хочу знать, где находится синяя машина, я могу проследить направление первого пальца ко второму пальцу, к машине (данным).

Висячий указатель

Теперь предположим, что вы чувствуете себя очень похожим на статую, и вы хотите бесконечно держать руку, указывая на красную машину. Что, если эта красная машина уедет?

   1     2     3
-------------------
| o=o |     | o=o |
| |B| |     | |G| |
| o-o |     | o-o |

Ваш указатель все еще указывает на красный автомобиль был, но его уже нет. Допустим, туда подъезжает новая машина ... Оранжевая машина. Теперь, если я снова спрошу вас: «Где красная машина?», Вы все еще указываете туда, но теперь вы ошибаетесь. Это не красная машина, это оранжевая.

Указатель арифметики

Итак, вы все еще указываете на второе парковочное место (сейчас занято оранжевой машиной)

   1     2     3
-------------------
| o=o | o=o | o=o |
| |B| | |O| | |G| |
| o-o | o-o | o-o |

Что ж, у меня теперь новый вопрос ... Я хочу знать цвет машины на парковочном месте следующий. Вы видите, что указываете на точку 2, поэтому вы просто добавляете 1, и вы указываете на следующую точку. (finger+1), теперь, поскольку я хотел знать, какие данные были там, вы должны проверить это место (а не только палец), чтобы вы могли почитать указатель (*(finger+1)), чтобы увидеть, что там присутствует зеленый автомобиль (данные на это место)

В некоторых ответах выше утверждалось, что «указатели на самом деле не сложны», но не обращались напрямую там, где «указатели жесткие!» происходит от. Несколько лет назад я обучал первокурсников CS (всего один год, так как я явно отстой), и мне было ясно, что идея указателя не сложно. Что сложно понять зачем и когда вам нужен указатель.

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

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

Итак, я говорю: представьте, что ОЗУ - это массив (а у вас всего 10 байт ОЗУ):

unsigned char RAM[10] = { 10, 14, 4, 3, 2, 1, 20, 19, 50, 9 };

Тогда указатель на переменную на самом деле является просто индексом (первым байтом) этой переменной в ОЗУ.

Итак, если у вас есть указатель / индекс unsigned char index = 2, то значение, очевидно, является третьим элементом или числом 4. Указатель на указатель - это то место, где вы берете это число и используете его как сам индекс, например RAM[RAM[index]].

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