Чи потрібно молодим розумам засвоїти поняття вказівника?

Чому майстер С Денніс Річі ввів покажчики на С? І чому інші мови програмування, такі як VB.NET або Java або C #, усунули їх? У Google я знайшов деякі моменти, і я теж хочу слухати ваші коментарі. Чому вони усувають вказівні поняття в сучасних мовах?

Люди кажуть, що C - основна мова, а покажчики - це концепція, яка робить C потужним та видатним та змушує C все ще конкурувати з більш сучасними мовами. Тоді чому вони ліквідували вказівники більш сучасними мовами?

Ви вважаєте, що знання покажчиків все ще важливо для нових програмістів? У наші дні люди використовують VB.NET або Java, яка підтримує більш вдосконалені функції, ніж C (і не використовує жодних понять вказівників), і багато людей, як я бачу зараз (мої друзі), обирають ці мови, ігноруючи C, оскільки вони підтримують розширені функції. Я кажу їм, щоб почати з C. Вони кажуть, що марно вивчати поняття покажчиків, коли ви робите вдосконалені речі в VB.NET або Java, які неможливо в C.

Що ти думаєш?

Оновлено :

Я читаю в Google коментарі:

1. Раніші комп'ютери були надто повільними і не оптимізовані.

2. Використання покажчиків дозволяє отримати прямий доступ до адреси, а це економить час, а не копіювати її у викликах функцій.

3. Безпека значно гірша за допомогою покажчиків, і тому Java та C # не включали їх.

Ці та ще деякі, що я знайшов. Мені ще потрібні цінні відповіді. Це було б дуже вдячно.

Ще в ті часи розробники працювали набагато ближче до металу. По суті, C був заміною більш високого рівня для складання, яка майже наближається до апаратних засобів, наскільки ви можете отримати, тож було природно, що вам потрібні вказівники для ефективного вирішення проблем кодування. Однак покажчики - це гострі інструменти, які при необережному використанні можуть завдати великої шкоди. Крім того, пряме використання покажчиків відкриває можливість для багатьох проблем із безпекою, які тоді не були проблемою (в 1970 році Інтернет складався з декількох десятків машин у декількох університетах, і його навіть не називали подібним ...), але з цього часу набуває все більшого значення. Тож нині мови вищого рівня свідомо розроблені, щоб уникнути необмежених покажчиків пам'яті.

Якщо говорити про те, що "вдосконалені речі, зроблені в VB.Net або Java, неможливо в C", показує дуже обмежену точку зору, якщо не менше :-)

Перш за все, всі ці мови (навіть складання) є Тюрінгом завершеними, тому теоретично все, що можливо на одній мові, можливо в усіх. Подумайте лише про те, що трапиться, коли фрагмент коду VB.Net або Java буде зібраний і виконаний: зрештою, він переводиться на (або відображається в) машинний код, тому що це єдине, що розуміє машина. У компільованих мовах, таких як C і C ++, ви можете фактично отримати повний корпус машинного коду, еквівалентний вихідному вихідному коду вищого рівня, як один або кілька виконуваних файлів / бібліотек. У мовах, що базуються на VM, складніше (а може і не можливо) отримати ціле еквівалентне представлення машинного коду вашої програми, але все-таки це десь там, в глибоких поглибленнях системи виконання та JIT.

Тепер, звичайно, зовсім інше питання, чи можливе якесь рішення певною мовою. Жоден розумний розробник не почне писати веб-додаток на зборах :-) Але корисно мати на увазі, що більшість або всі ці мови вищого рівня побудовані на основі величезної кількості бібліотечного коду виконання та класу, великий шматок яка реалізована мовою нижчого рівня, як правило, на С.

Отже, щоб перейти до питання,

Як ви вважаєте, важливі знання про вказівки для молоді [...]?

Поняття за вказівниками - непряме . Це дуже важлива концепція, і IMHO кожен хороший програміст повинен зрозуміти її на певному рівні. Навіть якщо хтось працює виключно з мовами вищого рівня, непрямість та посилання все ще важливі. Нерозуміння цього означає неможливість використовувати цілий клас дуже потужних інструментів, серйозно обмежуючи здатність вирішувати проблеми в довгостроковій перспективі.

Тож моя відповідь - так, якщо ви хочете стати по-справжньому хорошим програмістом, ви також повинні розуміти покажчики (як і рекурсія - це інший типовий камінь спотикання для розробників-початківців). Можливо, вам не потрібно буде починати це - я не думаю, що C є оптимальним як перша мова в наш час. Але в якийсь момент слід ознайомитися з непрямістю. Без цього ми ніколи не можемо зрозуміти, як насправді працюють інструменти, бібліотеки та рамки, які ми використовуємо. А майстриня, який не розуміє, як працюють його інструменти, дуже обмежений. Досить справедливо, ви можете зрозуміти це і в мовах програмування вищого рівня. Один хороший тест на лакмус - це правильно реалізувати подвійний список - якщо ви можете це зробити улюбленою мовою, ви можете стверджувати, що ви досить добре розумієте непрямість.

Але якщо ні для чого іншого, ми повинні зробити це, щоб навчитися поваги до старих програмістів, яким вдалося побудувати неймовірні речі, використовуючи смішно прості інструменти, які вони мали (порівняно з тим, що ми маємо зараз). Всі ми стоїмо на плечах гігантів, і нам добре визнати це, а не робити вигляд, що ми самі гіганти.

Я думаю, вам потрібно відрізнятись.

Java та інші мови вищого рівня не вдалили покажчики. Що вони зробили, це зняти просту арифметику вказівника.

Насправді, Java все ще дозволяє захищену та обмежену арифметику вказівника: доступ до масиву. У звичайному старому C доступ до масиву - це не що інше, як перенаправлення. Це різні позначення, синтаксичний цукор, якщо ви хочете, щоб чітко повідомляти, що ви робите.
Все-таки array[index]рівнозначно *(array+index). Через це це також рівнозначно, index[array]хоча я думаю, що деякі компілятори C можуть попередити вас, якщо ви це зробите.
Як наслідок, pointer[0]рівнозначно *pointer. Це просто тому, що "вказівник на масив" - це адреса першого запису масиву, а адреси наступних елементів обчислюються додаванням індексу.

У Java звичайна арифметика вказівника (посилання та перенаправлення) більше не існує. Однак покажчики існують. Вони називають їх посиланнями, але це не змінює те, що воно є. А доступ до масиву все одно - це саме те саме: Подивіться на адресу, додайте індекс і використовуйте це місце в пам'яті. Однак у Java він перевірить, чи знаходиться цей індекс у межах масиву, який ви спочатку виділили. Якщо ні, то це викине виняток.

Тепер перевага Java-підходу полягає в тому, що у вас немає коду, який просто сліпо записує довільні байти в довільні місця пам'яті. Це підвищує безпеку, а також безпеку, тому що якщо ви не зможете перевірити переповнення буфера тощо, час виконання виконує це за вас.

Недоліком цього є те, що він просто менш потужний. Програмування безпечної пам'яті можна робити на C. Неможливо скористатися швидкістю та можливостями небезпечного програмування на Java.

Насправді вказівники чи арифметичні вказівники нічого важкого. Вони просто пояснюються звивистими способами, тоді як увесь вказівник - це покажчик одного гігантського масиву (ваш простір пам’яті), все, що посилається на значення, дає вам індекс, де його знайти, все, що робить перенаправлення - це шукати. значення при заданому індексі. (Це трохи спрощено, тому що воно не враховує, що значення мають різний розмір у пам'яті, залежно від їх типу. Але це детальна обставина, а не частина фактичної концепції)

ІМХО, кожен, хто займається нашою роботою, повинен мати можливість зрозуміти це, або вони просто в неправильному полі.

Поняття покажчиків є важливим у загальному корпусі знань комп'ютерного програмування. Розуміння цієї концепції добре для програмістів або програмістів будь-якої мови, навіть якщо мова не підтримує її безпосередньо.

Покажчики використовують їх у структурах даних (пов'язані списки) та дизайні бази даних (зовнішній ключ).

Такі мови, як VB та C #, можуть передавати дані шляхом "посилання" на методи, які можна розглядати як тип вказівника.

Розуміння того, де дані розподіляються в пам'яті (стек проти купи), все ще важливо для ефективності алгоритмів.

Навчання правильним основам, на мою думку, важливо.

Так, так, так, так і так !!!

Якщо ви не знаєте основ, ви НІКОЛИ не зможете вирішити справді важкі, дивні, складні та складні проблеми, які з’являються на вашому шляху.

І якщо ви дійсно добре розумієте основи, ви набагато продаваніші на ринку праці.

Я працював одного разу з хлопцем, який програмував 10 років, і поняття не мав, як працюють покажчики. Я (набагато молодший) проводив години на дошці, навчаючи його. Це відкрило мені очі. Він не мав НЕ ІДЕЯ щодо стільки основних речей.

Знайте стільки, скільки можливо.

Так, розуміння важливе.

Кілька місяців тому я програмував на C #, і хотів зробити копію списку. Звичайно, що я зробив, NewList = OldList;а потім почав змінювати NewList. Коли я намагався роздрукувати обидва списки, вони були обидва однакові, оскільки це NewListбув лише вказівник на OldListкопію, а не її копія, тому я фактично змінювався OldListвесь час. Не знадобилося мені занадто багато часу, щоб зрозуміти це, але деякі мої однокласники не були такими швидкими, і мені довелося пояснити, чому це відбувається.

Приклад:

List<int> a = new List<int>();
a.Add(2);
a.Add(9);
a.Add(8);
a.Add(1);
List<int> b = new List<int>();
b = a; //Does not make a copy, b is just a synonym!
b.Sort();
for (int i = 0; i < a.Count; i++)
{
    Console.WriteLine("a: " + a[i] + " b: " + b[i]);
}

І звичайно, результат такий:

a: 1 b: 1
a: 2 b: 2
a: 8 b: 8
a: 9 b: 9

Знання, як їх використовувати, не так важливо, але розуміння їх є вирішальним!

Покажчик концепції! = Вказівник на арифметику! = Вказівник на синтаксис

Перше важливо завжди, якщо вам потрібно (і ви робите) розуміння глибокої / неглибокої копії, передайте посилання / передайте значення і т.д.

Чому майстер С Денніс Річі ввів покажчики на С?

Тому що покажчики - це дуже потужний механізм, який можна використовувати багатьма способами.

І чому інші мови програмування, такі як VB.NET або Java або C #, усунули їх?

Тому що покажчики - це дуже небезпечний механізм, який можна зловживати багатьма способами.

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

Ось неповний список, для яких покажчиків використовуються:

• динамічний розподіл ( new T)
• рекурсивні структури даних ( struct T { T* next; /* ... */ };)
• ітератори над масивами ( for (T* p = &a[0]; p != &a[0] + n; ++p) { ... })
• спільний доступ до об'єктів ( T* new_pointer = existing_pointer;)
• підтип поліморфізму ( T* pointer_to_base = pointer_to_derived;)
• старий виклик за посиланням ( mutate(&object);)
• необов'язкові типи ( if (p) { /* ... */ })

Зауважте, що використання єдиного механізму для всіх цих концепцій демонструє як силу та елегантність досвідченого програміста, так і великий потенціал плутанини для когось нового в програмуванні.

Чому? Ви можете написати величезну систему з конструктором форм і генератором коду. Хіба це недостатньо? (іронія)

І зараз серйозно, покажчики не є важливою частиною програмування у багатьох областях, але вони дозволяють людям зрозуміти, як працює внутрішня система. І якщо у нас не буде нікого, хто розуміє, як працює внутрішня система, виникне ситуація, коли SQL2020, Windows 15 та Linux 20.04 будуть записуватися у зібраний сміттям віртуальну машину, що працює над 30 шарами абстракції, з кодом, згенерованим через IDE, у JavaScript .

Це, безумовно, не те, що я хочу бачити.

Так що так, вони обов'язково повинні!

Ні Java, ні C # не усунули покажчики, вони мають посилання, які майже однакові. Те, що було усунуто, - це вказівна арифметика, яку можна опустити у вступному курсі.
Жодне нетривіальне додаток не обійтися без концепції покажчиків чи посилань, тому варто навчатись (без них не можна обійтися динамічним розподілом пам'яті).

Розглянемо наступне в C ++ та Java, і я думаю, що це не дуже відрізняється в C #:
aClass *x = new aClass();
aClass x = new aClass();
Немає великої різниці між вказівниками та посиланнями, правда?
Потрібно уникати арифметики вказівника, якщо це не потрібно і при програмуванні на моделях високого рівня, тому проблем там не так багато.

Професійний програміст повинен оволодіти покажчиками.

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

Люди, які хочуть вирішити особисті проблеми за допомогою програмування (як я, який використовує багато сценаріїв Python), цілком можуть їх ігнорувати взагалі.

Ну, це моя думка ...; о)

Змінні покажчики адреси є конкретним випадком більш узагальненої концепції непрямості. Індирекція використовується в більшості (всіх?) Сучасних мов у багатьох конструкціях, таких як делегати та зворотні виклики. Розуміння поняття непрямості дозволяє вам знати, коли і як найкраще використовувати ці інструменти.

Абсолютно ДА ! Кожен, хто програмує, повинен розуміти вказівки та непрямість.

Покажчики - це те, як великий обсяг доступу до даних здійснюється всіма мовами. Покажчики є апаратною характеристикою всіх мікропроцесорів. Мови високого рівня, такі як Java, VB і C #, по суті, відключають прямий доступ до покажчиків від користувачів мови з посиланнями. Посилання посилаються на об’єкти за допомогою схеми управління пам'яттю мови (наприклад, це може бути вказівник з метаданими або просто число для таблиці пам'яті).

Розуміння того, як працюють покажчики, є основним для розуміння того, як насправді працюють комп'ютери. Покажчики також більш гнучкі та потужні, ніж посилання.

Наприклад, причина, чому масиви починаються з нуля індексу, полягає в тому, що масиви насправді є скороченою для арифметики вказівника. Не дізнавшись про те, як працюють покажчики, багато початківців програмістів не дуже отримують масиви.

int a, foo[10];
foo[2] = a;

Рядок 2 в арифметиці вказівника буде таким:

*(foo + sizeof(int) * 2) = a;

Не розуміючи покажчиків, не можна зрозуміти управління пам'яттю, стеком, купою чи навіть масивами! Крім того, потрібно зрозуміти покажчики та перенаправлення, щоб зрозуміти, як передаються функції та об'єкти.

TL: DR : Розуміння покажчиків є основоположним для розуміння того, як комп'ютери насправді працюють .

Я думаю, що це зводиться до того, що потреба впоратися з покажчиками відпала, оскільки програмісти менше мали справу з прямим обладнанням, на якому вони працювали. Наприклад, розподілити структуру даних пов'язаного списку таким чином, щоб ідеально вписуватися в послідовність 640 байтових модулів пам'яті, якими володіло спеціалізоване обладнання.

Робота з покажчиками вручну може спричинити помилки (що призводить до витоку пам’яті та експлуатаційного коду) і забирає багато часу, щоб виправитись. Тож Java та C # тощо тепер керують вашою пам’яттю та вашими вказівниками за допомогою своїх віртуальних машин (віртуальних машин). Це, мабуть, менш ефективно, ніж використання сировинних C / C ++, хоча ВМ постійно вдосконалюються.

C (і C ++) як і раніше широко використовуються мови, особливо у високопродуктивних обчислювальних машинах, іграх та вбудованих апаратних просторах. Я особисто вдячний, що дізнався про покажчики, оскільки перехід до посилань на Java (подібна концепція до покажчиків) був дуже легким, і я не розгубився, побачивши свою першу NullPointerException (яку насправді слід назвати NullReferenceException, але я відступив) .

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

Це об'єктивна правда:

Деякі мови підтримують прямий доступ до пам'яті (покажчики), а деякі - ні. Для кожного випадку є вагомі причини.

1. Як сказав хтось тут, ще за часів С, автоматичне управління пам’яттю було не таким досконалим, як сьогодні. І люди, як би там не було, звикли. Тоді хороші програмісти мали набагато глибше розуміння комп'ютерних програм, ніж наше покоління (мені 21 рік). Вони використовували перфокарти та дні очікування протягом деякого часу компіляції на мейнфреймі. Вони, напевно, знали, чому кожен шматочок у їхньому коді існує.

2. Очевидною перевагою мов, таких як C, є те, що вони дозволяють точніше контролювати свою програму. Коли вам це справді потрібно в ці дні? Тільки коли ви створюєте інфраструктурні додатки, такі як програми, пов’язані з ОС та середовищами виконання. Якщо ви хочете просто розробити гарне, швидке, надійне та надійне програмне забезпечення, то автоматичне управління пам’яттю найчастіше - ваш кращий вибір.

3. Справа в тому, що прямий доступ до пам'яті в основному зловживався протягом історії розробки програмного забезпечення. Люди створювали програми, які просочували пам’ять, і насправді були повільнішими через надлишкове розподілення пам'яті (в С просто і звичайно розширювати віртуальний простір пам’яті для кожного окремого розподілу).

4. В наші дні віртуальні машини / час виконання виконують набагато кращу роботу, ніж 99% програмістів при розподілі та звільненні пам'яті. Крім того, вони дозволяють отримати додаткову гнучкість у потоці, який ви хочете мати у вашій програмі, оскільки ви (в основному) не зайняті звільненням виділеної пам’яті в потрібний час та місце.

5. Щодо знань. Я думаю, що приємно, що програмісти знають, як реалізуються середовища, в яких вони запрограмовані. Не обов’язково до найдрібніших деталей, але велика картина.

Я думаю, що цікаво знати, як працюють покажчики (принаймні). Те саме, що знати, як реалізується поліморфізм. Звідки ваш процес отримує свою пам'ять і як. Це речі, які мене завжди цікавили особисто. Я можу чесно сказати, що вони зробили мене кращим програмістом, але я не можу сказати, що вони є освітнім необхідністю для кожного, хто хоче стати хорошим програмістом. В будь-якому випадку, знаючи більше, це часто покращить вашу роботу.

1. Як я бачу, якщо все, що вас просять, це створити додаток на Java або C # або щось подібне, то вам потрібно зосередитись на правильних техніках проектування та реалізації. Тестовий код, чистий код, гнучкий код. У тому порядку.

Тому що навіть якщо ви не знаєте всіх дрібних деталей, хтось, хто зможе, зможе змінити те, що ви створили, на щось, що просто краще. І це часто не є складною роботою, коли у вас є належний, чистий і перевірений дизайн (і це, як правило, більша частина роботи).

Якби я був інтерв'юером, який прагнув найняти когось для мовної програми на високому рівні, це були б речі, які мене найбільше цікавлять.

Знання низького рівня - це бонус. Це добре для налагодження та час від часу створюючи трохи кращі рішення. Це робить вас цікавою людиною, професійно. Це дарує вам певну повагу на робочому місці.

Але в сучасному світі це не священна вимога.

Для більшості практичних цілей для мов OO високого рівня достатньо розуміння посилань, вам не потрібно розуміти, як ці мови реалізують посилання з точки зору покажчиків.

Є набагато більш функціональні та сучасні підходи до багатопарадигми, які я б оцінив набагато вище, ніж міг би робити фантазійну арифметику вказівника, щоб сказати, написати 1000-ту оптимізовану функцію копіювання рядків, ймовірно, що вона працює гірше, ніж String.copy вашого std lib будь-яким способом.

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

Я часто бачу абсолютно невдалі спроби мікрооптимізувати веб-сервлет або аналогічний код для 5% -го виграшу, коли кешування (запам'ятовування), оптимізація SQL або просто налаштування веб-сервера можуть отримати невеликі зусилля 100% або більше. Погортання покажчиків - це передчасна оптимізація в більшості випадків.

Безумовно, нам потрібно мати ґрунтовну концепцію вказівника, якщо ви дійсно хочете бути хорошим програмістом. Причиною для концепції Pointer став прямий доступ до вашої вартості, яка стає більш ефективною та ефективною із обмеженнями часу ...

Крім того, зараз кілька днів, враховуючи мобільні додатки, які мають дуже обмежену пам’ять, нам потрібно дуже обережно використовувати його, щоб його робота була дуже швидкою з відповіддю користувача ... Тому для цього нам потрібне пряме посилання на значення ...

Розглянемо пристрої Apple або мову Objective C, яка повністю працює лише з концепцією вказівника. Усі змінні, оголошені в Цілі C, мають покажчик. Вам потрібно пройти вікі Objective C