Читаю в Джоэла, в который раз натыкаюсь упоминания на сложность указателей, вплоть до того,
что он готов посвятить им отдельную часть мозга.
Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё.
Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то
проблемы, даже в школе.
Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику,
а теперь он на всех это проецирует?
Здравствуйте, dmz, Вы писали:
dmz>Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё. dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
Сложностей никаких, преимуществ тоже. Зато в дотнете можно забыть про них вообще.
Здравствуйте, dmz, Вы писали:
dmz>Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику, dmz>а теперь он на всех это проецирует?
Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
Здравствуйте, Oyster, Вы писали:
O>Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
O>Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
А что такое "адрес" она понимала? Если понимала что такое "адрес" и что такое "переменная", то до указателя
остался один небольшой шаг
O>>Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
dmz>А что такое "адрес" она понимала? Если понимала что такое "адрес" и что такое "переменная", то до указателя dmz>остался один небольшой шаг
Видишь ли, с указателями проблеп никаких. Есть проблемы с людьми которые их используют.
Вот прямо сейчас реанимируем проект который кто только не писал. Иногда указатели используются так, что хочется надругаться над автором всеми естественными и противоестественными способами. Наверное эти люди были очень сексуальны и это передается, таскать, виртуально ? Ничего другого предположить не могу, но указатели тут точно ни при чем
dmz>>Но в каком месте сложны указатели-то? СГ>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
А освновные положения ОТО могут быть сформулированы одним недлинным предложением?
Здравствуйте, dmz, Вы писали:
СГ>>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
dmz>А освновные положения ОТО могут быть сформулированы одним недлинным предложением?
Могут, но тогда количество этих предложений стремится к бесконечности.
Здравствуйте, dmz, Вы писали:
dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
Учить указатели по книжкам с легких примерчиков для детей (типа пробежаться по массиву, выделить фиксированную-загрузить-освободить) это одно... А вот когда тебя кинут на графику, системы сборщиков мусора и т.д. — получаешь совсем другой эффект, а именно шок от того что отладка почти всегда приводит к перезагрузке машины ... после этого "человеки" начинают "уважать" указатели.
Здравствуйте, dmz, Вы писали:
dmz>А что такое "адрес" она понимала? Если понимала что такое "адрес" и что такое "переменная", то до указателя dmz>остался один небольшой шаг
Вот как раз с адресом и были проблемы. Точнее, c тем, что переменная может хранить адрес, по которому будет найдена другая переменная, грубо говоря — отказывались мозги воспринимать идею ссылки. Правда, может, моего таланта репититора не хватило?
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, dmz, Вы писали:
СГ>>>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
dmz>>А освновные положения ОТО могут быть сформулированы одним недлинным предложением?
T>Могут, но тогда количество этих предложений стремится к бесконечности.
Один стремится к бесконечности? Где вы такую траву берёте?
Здравствуйте, Курилка, Вы писали:
dmz>>>А освновные положения ОТО могут быть сформулированы одним недлинным предложением?
T>>Могут, но тогда количество этих предложений стремится к бесконечности.
К>Один стремится к бесконечности? Где вы такую траву берёте?
Здравствуйте, dmz, Вы писали:
dmz>А освновные положения ОТО могут быть сформулированы одним недлинным предложением?
ОТО — это более-менее удачная попытка описать наше пространство-время (и, одновременно, физический принцип эквивалентности инерциальных систем отсчёта) с помощью Римановой геометрии. Стало быть, основное положение ОТО одним недлинным предложением можно выразить так: "Наше пространство-время — суть 4х-мерное Риманово многообразие."
Здравствуйте, Сергей Губанов, Вы писали:
СГ>ОТО — это более-менее удачная попытка описать наше пространство-время (и, одновременно, физический принцип эквивалентности инерциальных систем отсчёта) с помощью Римановой геометрии. Стало быть, основное положение ОТО одним недлинным предложением можно выразить так: "Наше пространство-время — суть 4х-мерное Риманово многообразие."
Объяснение этого даст цепочку предложений длинна которой стремится к бесконечности.
Здравствуйте, dmz, Вы писали:
dmz>Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику, dmz>а теперь он на всех это проецирует?
Я тоже иногда читая Дожоэля понимаю, что у него то ли в детстве, то ли сейчас были/есть какие-то проблемы.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Oyster, Вы писали:
O>Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
Это потому, что они от тебя совсем другого хотели.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Mamut, Вы писали:
M>Скажу крамолу Указатели непонятны, непонятны, непонятны, непонятны, непонятны, а потом — бац! — и все становится на свои места.
M>У некоторых, правда, не становится.
Вопрос в том, сколько это займет времени. Кроме того, не существует программиста, который решит любую проблему связанную с указателями за сколь угодно малое количество времени.
Указатели не составляют проблемы только при правильном использовании и идеальном дизайне. Кто может идеальный дизайн сделать — шаг вперед.
Кроме того, часть проблем никогда не решается — BSTR вам что нибудь говорит ?
Здравствуйте, Mamut, Вы писали:
M>Скажу крамолу Указатели непонятны, непонятны, непонятны, непонятны, непонятны, а потом — бац! — и все становится на свои места.
Это состояние называется в народе приход.
M>У некоторых, правда, не становится.
А это — импотенция.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dmz, Вы писали:
dmz>Читаю в Джоэла, в который раз натыкаюсь упоминания на сложность указателей, вплоть до того, dmz>что он готов посвятить им отдельную часть мозга.
dmz>Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё. dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
У меня были проблемы с указателями такого плана что я не мог понять зачем они нужны вообще
Oyster wrote:
> dmz>А что такое "адрес" она понимала? Если понимала что такое "адрес" и > что такое "переменная", то до указателя > dmz>остался один небольшой шаг > > Вот как раз с адресом и были проблемы. Точнее, c тем, что переменная > может хранить адрес, по которому будет найдена другая переменная, грубо > говоря — отказывались мозги воспринимать идею ссылки. Правда, может, > моего таланта репититора не хватило?
Понятие односвязного списка, по-моему, неплохо демонстрирует понятие указателя, а также
для чего его можно использовать.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Сергей Губанов, Вы писали:
СГ>ОТО — это более-менее удачная попытка описать наше пространство-время (и, одновременно, физический принцип эквивалентности инерциальных систем отсчёта) с помощью Римановой геометрии. Стало быть, основное положение ОТО одним недлинным предложением можно выразить так: "Наше пространство-время — суть 4х-мерное Риманово многообразие."
Ну вот, теперь все понятно!
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, kan_izh, Вы писали:
_>Понятие односвязного списка, по-моему, неплохо демонстрирует понятие указателя, а также _>для чего его можно использовать.
Объяснить порой тяжелее, чем понять Я и этот пример использовал...
Здравствуйте, dmz, Вы писали:
dmz>Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё. dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
Ну... когда я в первый раз в деятом классе посмотрел на С-код, который использовал указатели, он мне показался магическим Но после знакомства с ассемблером (Atary, Z80) все стало на свои места. Указатели требуют знания архитектуры, поэтому при обучении начинать надо оттуда. А списки, имхо, недостаточно для полного усвоения идеи В целом мне знакомы люди, у которых были проблемы с указателями.
M>Ну... когда я в первый раз в деятом классе посмотрел на С-код, который использовал указатели, он мне показался магическим Но после знакомства с ассемблером (Atary, Z80) все стало на свои места. Указатели требуют знания архитектуры, поэтому при обучении начинать надо оттуда. А списки, имхо, недостаточно для полного усвоения идеи В целом мне знакомы люди, у которых были проблемы с указателями.
А бывает вообще такое, что бы учили программировать без ознакомления с какой-нибудь (фон-неймановой) архитектурой?
Здравствуйте, dmz, Вы писали:
dmz>А бывает вообще такое, что бы учили программировать без ознакомления с какой-нибудь (фон-неймановой) архитектурой?
Бывает. Плюс в мое время много самоучек. Одного моего знакомого учили Basic так: это PRINT, это LET, это INPUT. а до остального сам догадаешься В любом случае этому уделяют внимания меньше чем нужно.
Здравствуйте, Сергей Губанов, Вы писали:
СГ> "Наше пространство-время — суть 4х-мерное Риманово многообразие."
Тогда, раз тебе все ясно, объясни исходя из этого определения, что вероятность прилепить свежую козявку к нижней поверхности стола не зависит от местоположения стола в комнате.
Я, например, смогу на пальцах с помощью указателей объяснить про ребалансировку дерева Хаффмана. А также почему третий байт в .tar.bz2-архиве равен первому символу имени архива, и почему вероятность появления последующего ненулевого бита равна нулю.
Здравствуйте, Mamut, Вы писали:
dmz>>Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику, dmz>>а теперь он на всех это проецирует?
M>Скажу крамолу Указатели непонятны, непонятны, непонятны, непонятны, непонятны, а потом — бац! — и все становится на свои места.
Почему крамолу? У меня точно так было. Правда "... непонятны, непонятны, ..." совпало с программирванием на Паскале, а "бац!" с началом программирования на Си. Вот что значит think different.
Здравствуйте, Mazay, Вы писали:
M>Почему крамолу? У меня точно так было. Правда "... непонятны, непонятны, ..." совпало с программирванием на Паскале, а "бац!" с началом программирования на Си. Вот что значит think different.
Это чистое совпадение
"For every complex problem, there is a solution that is simple, neat,
and wrong."
Здравствуйте, Mazay, Вы писали:
M>Почему крамолу? У меня точно так было. Правда "... непонятны, непонятны, ..." совпало с программирванием на Паскале, а "бац!" с началом программирования на Си. Вот что значит think different.
Согласен.
Возможность на Object Pascal-е (насчет Паскаля не могу сказать) написать:
var
p: PSomeStruct;
begin// и вот так:
p.SomeMember := 0;
// и вот так:
p^.SomeMember := 0;
// и это будет равнозначно :crash:
, никак не способствует нормальному пониманию указателей.
И если сюда еще приплюсовать функции с подобной сигнатурой:
procedure Finalize( var V [; Count: Integer] );
// илиprocedure New(var P: Pointer);
, которым непоняно что передавать: то ли адрес переменной, то ли саму переменную, и что вообще из всего этого получится.
Другими словами все это наверное можно назвать неочевидным level of indirection..
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, dmz, Вы писали:
dmz>Читаю в Джоэла, в который раз натыкаюсь упоминания на сложность указателей, вплоть до того, dmz>что он готов посвятить им отдельную часть мозга.
dmz>Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику, dmz>а теперь он на всех это проецирует?
Есть люди которым они поддаються, есть те, кто никак не может понять их концепцию. Тут или дано, или не дано.
Третьего не бывает.
_>Есть люди которым они поддаються, есть те, кто никак не может понять их концепцию. Тут или дано, или не дано. _>Третьего не бывает.
Ого — это теперь уже целая концепция? Может, даже парадигма?
_>А вы уверены что сами понимаете их в полной мере?
Здравствуйте, Сергей Губанов, Вы писали:
СГ>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
T>Это синтаксис. Фигня вобщем.
Какой нафиг синтаксис? Это определение и примеры использования. Понятие исчерпывающе определяется
в первых же преддложениях. И иллюстрируется на человекопонятном языке.
T>Почитай Джефа Эджера например. Такое могут осилить крайне малое количество программистов.
Читал, валяется где-то. Попытки Элджера сделать из си жабу мы рассматривать не будем — врядли
Спольски это имел ввиду.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, dmz, Вы писали:
T>>>Ахтунг ! Джоэл — женщина ! dmz>>То, что Джоэл — ахтунг, факт широко известный. Думаете, это как-то связано с указателями?
T>Ахтунг ! Джоэл — ахтунг !
А указатель — это фаллический символ! И если программист любит играться с указателями, то ...
Здравствуйте, dmz, Вы писали:
dmz>А бывает вообще такое, что бы учили программировать без ознакомления с какой-нибудь (фон-неймановой) архитектурой?
Конечно, митовский MIT 6.001 (который упоминает Джоэль) так и устроен . Это вводный обязательный курс CS.
Сначала аппликативное функциональное программирование. Ближе к середине семестра вводится понятие присваивания , и заодно обясняют, как из замыкания за пять минут сделать ООП с множественным наследованием и.т.д. Потом ленивые списки потоки многозадачность и.т.д. Потом на лиспе пишут интерпретатор лиспа. Учатся в 5 строчек менять динамический скопинг на лексический, трансформировать AST и.т.п. Потом на лиспе пишут интерпретатор ленивого функионального языка. Потом недетерминистического. Потом пролога. И только после этого проектируют регистровую машину и пишут для нее компилятор.
На самом деле, современный вариант курса, который занимает один семестр, заканчивается на ленивом интерпретаторе.
Поинт был: показать, что можно двигаться от лямбда-исчисления к фон-неймановской архитектуре, и так даже проще.
Здравствуйте, Владек, Вы писали:
T>>Ахтунг ! Джоэл — ахтунг !
В>А указатель — это фаллический символ! И если программист любит играться с указателями, то ...
Видишь ли, тут все сложно. С одной стороны когда играется слишком много (чистый c/с++ник) это одно. А совсем другое — когда совсем не играется — C#.
На счет видео не знаю, но ссылка на перевод уже точно неоднократно проскакивала. Сейчас начал заниматься по этому курсу, стараюсь читать оригинал, но все же иногда заглядываю в перевод.
Mystic,
> СГ> А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
> Бог с ней, ОТО... Вот квантовая механика...
Релятивистская
Posted via RSDN NNTP Server 2.0
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, _prometey2005, Вы писали:
_>Есть люди которым они поддаються, есть те, кто никак не может понять их концепцию. Тут или дано, или не дано. _>Третьего не бывает.
_>На западе этот факт давно известен.
_>А вы уверены что сами понимаете их в полной мере?
Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
Здравствуйте, _Obelisk_, Вы писали:
_O_>Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
А может переменная, хранящая адрес в памяти?
ЗЫ: Только не думайте, что я птыаюсь найти скрытый смысл .
It is always bad to give advices, but you will be never forgiven for a good one.
Oscar Wilde
Здравствуйте, _Obelisk_, Вы писали:
_O_>Думается мне, что проблемы с указателями возникают у тех, кто пытается найти в них скрытый смысл и какую-то глубину. Идея-то соврешенно простая: указатель — это просто адресс в пямяти.
Идея простая. Только использовать сложно. На самом деле указатели это не просто IPNode* pNode = NULL; Это ручное управление памнятью. И если с адресной арифметикой все в порядке у многих людей, то с ручным управлением памяти далеко не все в порядке.
Указатели надо
1. всегда инициализировать нулем
2. всегда ставить ассерт на !NULL при использование (как минимум)
3. всегда проверять что куда присваиваешь
4. всегда затирать нулем если объект разрушен
5. следить за
а. указателями на стек
б. хип
в. в секгмент данных
6. осторожно пользоваться адресной арифметикой
7. осторожно пользоваться приведением типа
Теперь про управление памятью
8. следить за тем
а. кто выделяет память
б. кто освобождает память
9. Проверять неявное выделение памяти
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Mystic,
>> СГ> А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
>> Бог с ней, ОТО... Вот квантовая механика...
ПК>Релятивистская
Здравствуйте, Mystic, Вы писали:
M>Здравствуйте, Сергей Губанов, Вы писали:
СГ>>А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
M>Бог с ней, ОТО... Вот квантовая механика...
Она еще проще формулируется :)
"Теория унитарных операторов в гильбертовом пространстве" :)
Фиг его знает, конечно, может так оно и правильней...
Но я отношусь к таким людям, которые весьма психуют, если из того, что им преподают хотя бы малая толика является "черным ящиком по определению". Т.е. ни в математике, ни в физике ни в химии в меня инфа совершенно не хотела лезть, если я абсолютно ясно не представлял себе, как именно что-ли происходит или откуда выводится.
Когда к нам в 9-м классе завезли "Корветы" и он высветил мне строку приглашения бэйсика, как сейчас помню — это заставило меня мучаться примерно неделю. Мучаться очень сильно вопросами: "КАК" и "ПОЧЕМУ"?
Я уже неплохо владел электроникой к тому времени, но мне трудно было представить себе размер микросхемы, которая выполняла бы бэйсик аппаратно (не микропрограммно, а именно аппаратно, так мне казалось по-началу). Потом я купил себе книжку по микропроцессорам (уже даже не помню какую), где так же дано было немного от дискретки и проектировании автоматов. Проглотил ее за 3 дня и... хлоп!!! Картинка ожила, все встало на свои места. От моего прежнего понимания транзисторов до только что понятых вентилей, тактов, состояний, микро- и макро- программного управления цифровым автоматами.
Если бы не эта книжка, я бы просто продолжал нервничать, видя "разумное" поведение бейсик-консоли и не понимая "КАК ЭТО?"
А от изучения Схемы и лямбд без понимания того, на чем это все зиждется лично мне мало было бы толку. Мне был бы банально не интересен предмет, который построен на непонятных мне принципах. Какой смысл строить интерпретатор Лиспа на Лиспе, если студент понятия не имеет о формальных грамматиках? А после того как поимеет, то тем более, строить интерпретатор с этого языка будет бессмысленно, ибо не добавит навыков/образования.
Здравствуйте, vdimas, Вы писали:
V>Когда к нам в 9-м классе завезли "Корветы" и он высветил мне строку приглашения бэйсика, как сейчас помню — это заставило меня мучаться примерно неделю. Мучаться очень сильно вопросами: "КАК" и "ПОЧЕМУ"?
... V>Если бы не эта книжка, я бы просто продолжал нервничать, видя "разумное" поведение бейсик-консоли и не понимая "КАК ЭТО?"
... V>А от изучения Схемы и лямбд без понимания того, на чем это все зиждется лично мне мало было бы толку.
Я не согласен абсолютно. Хорошо рассуждать, когда добрый американский дядя уже изобрел для тебя этот "Корвет". Схема зиждется на лямбда-исчислении. Лямбда-вычислитель никому не обязан быть реализован как компьютер. И к нашему счастью, Черча и Тьюринга не остановило то, что книгу про микропроцессоры взять было негде
Схему на 6.001 не изучают — ее используют после 10-минутной инструкции по применению.
V> Мне был бы банально не интересен предмет, который построен на непонятных мне принципах. Какой смысл строить интерпретатор Лиспа на Лиспе, если студент понятия не имеет о формальных грамматиках? А после того как поимеет, то тем более, строить интерпретатор с этого языка будет бессмысленно, ибо не добавит навыков/образования.
Интерпретаторы строят не на принципах формальных грамматик. Их строят на основе вычислительных моделей. Задумайтесь, чем отличается интерпретатор Scheme от интерпретатора Haskell. Грамматикой?
А вто что сами авторы пишут о "какой смысл" — Chapter 4. Metalinguistic Abstraction
Если кому интересно попробовать — помимо SICP, есть еще, по крайней мере, 4 университетских курса (широко применяемых за пределами породивших их университетов) на которых "пишут интерпретаторы":
Здравствуйте, _Obelisk_, Вы писали:
T>>Слишком много правил, не правда ли ?
_O_>Нет. Все правила неплохо запоминаются и следовать им можно на автомате.
Запоминаются. Можно следовать. Вот только поработоав три года на шарпе и вернувшись в плюсы я вижу, что надо учиться заново.
Здравствуйте, Tanker, Вы писали:
T>Указатели надо T>1. всегда инициализировать нулем
Хм... зачем? Указатели надо инициализировать перед использованием, как и все прочие переменные.
P := nil; // Следуем непогрешимому правилу #1 и получаем хинт.
P := AllocMem(16);
T>2. всегда ставить ассерт на !NULL при использование (как минимум)
В зависимости от контекста. Если мы получили адрес локальной переменной, функции/процедуры, то зачем тут Assert?
P := @I;
P^ := 4; // А тут, имхо, Assert лишь загромоздит кода, коинтольное изнасилование в голову выходит...
Во-вторых, отлов нулевых указателей почти везде работает на ура и не несет большой проблемы. То ли свалится Assert, то ли свалится использующий оператор --- не вижу разницы. Б\'ольшая проблема --- использование поврежденных указателей.
T>3. всегда проверять что куда присваиваешь
Целиком и полностью за, но настаиваю на том, что данный пункт справедлив не только в отношении указателей Если в переменную, которая хранит напряжение в вольтах мы поместим силу тока в амперах, то последствия могут быть не менее катастрофическими! Такая уж работа программиста, что надо проверять написанный тобою код. Всем надо пользоваться осторожно. Ошибка с указателями стоит слетом программы, а вот если забыть поставить условие WHERE ID = @ID в операторе DELETE... Если писать тяп-ляп, то тут уже все равно, указатели это, БД или что еще.
T>4. всегда затирать нулем если объект разрушен
Возможны различные схемы. В некоторых случаях это бессмысленно. А когда ты не уверен в том, что указателем никто больше не воспользется, то совет разумен.
procedure Test;
var P: Pointer;
begin
GetMem(P, 30);
try
finally
FreeMem(P);
P := nil; // Объект разрушен, следуем правилу #4end;
end;
T>5. следить за T> а. указателями на стек T> б. хип T> в. в секгмент данных
Тут я совсем не понял. Что значит --- за ними следить? Их надо различать в ряде случаев. Но если метод принимает указатель, то в большинстве случаев безразлично, на что он указывает.
T>6. осторожно пользоваться адресной арифметикой
Чем отличается от п. 3?
T>7. осторожно пользоваться приведением типа
Тавтология с п. 3.
T>Теперь про управление памятью T>8. следить за тем T> а. кто выделяет память T> б. кто освобождает память
Иногда это проблема. Иногда это тривиально. К тому же указатели это не обязательно динамическая память.
T>9. Проверять неявное выделение памяти
В смысле, проверять? Вот в .NET вся динамическая память выделяется неявно, как мне ее прикажете проверять???
T>Слишком много правил, не правда ли ?
Все с легкостью выводимо из понимания архитектуры. К тому же приведенные правила не имеют догматичный характер...
Здравствуйте, Mystic, Вы писали:
T>>Указатели надо T>>1. всегда инициализировать нулем M>Хм... зачем? Указатели надо инициализировать перед использованием, как и все прочие переменные.
M>
M> P := nil; // Следуем непогрешимому правилу #1 и получаем хинт.
M> P := AllocMem(16);
M>
Кто тебе сказал, что выделение памяти будет в том же методе ?
T>>2. всегда ставить ассерт на !NULL при использование (как минимум) M>В зависимости от контекста. Если мы получили адрес локальной переменной, функции/процедуры, то зачем тут Assert?
А ты только с локальными переменными работаешь ? Все методы без аргументов ?
M>
M> P := @I;
M> P^ := 4; // А тут, имхо, Assert лишь загромоздит кода, коинтольное изнасилование в голову выходит...
M>
Ассерт тормозит дебаг и несильно.
M>Во-вторых, отлов нулевых указателей почти везде работает на ура и не несет большой проблемы. То ли свалится Assert, то ли свалится использующий оператор --- не вижу разницы. Б\'ольшая проблема --- использование поврежденных указателей.
Читай выделенное. Для этого и надо выполнять п.1 — инициализировать нулем.
T>>3. всегда проверять что куда присваиваешь M>Целиком и полностью за, но настаиваю на том, что данный пункт справедлив не только в отношении указателей
С укузателями особый случай. Потому как указатель на экземпляр класса это фактически указатель на методы.
T>>4. всегда затирать нулем если объект разрушен M>Возможны различные схемы. В некоторых случаях это бессмысленно. А когда ты не уверен в том, что указателем никто больше не воспользется, то совет разумен.
Увереным вообще быть нельзя. Сейчас по проекту, который был заморожен два года назад, приходится много лишнего геморроя отлаживать потому как разрабы прежние считали что "В некоторых случаях это бессмысленно".
M>Тут я совсем не понял. Что значит --- за ними следить? Их надо различать в ряде случаев. Но если метод принимает указатель, то в большинстве случаев безразлично, на что он указывает.
Это я и имел в виду. Если метод модифицирует содержимое по указателю, надо различать, что передаешь в этот метод. Вот такие дела.
T>>6. осторожно пользоваться адресной арифметикой M>Чем отличается от п. 3?
Тем, что присваиваение в одном методе, а использование в другом.
T>>7. осторожно пользоваться приведением типа M>Тавтология с п. 3.
Про паскаль речи не идет. Почитай про множественное наследование.
T>>Теперь про управление памятью T>>8. следить за тем T>> а. кто выделяет память T>> б. кто освобождает память M>Иногда это проблема. Иногда это тривиально. К тому же указатели это не обязательно динамическая память.
Управление памятью означает чт именно динамическая память. Проблема как раз в том, что "Иногда это проблема. Иногда это тривиально."
T>>9. Проверять неявное выделение памяти M>В смысле, проверять? Вот в .NET вся динамическая память выделяется неявно, как мне ее прикажете проверять???
Мы вовсе не про дотнет. В c/с++ есть кучка мест, где память выделяется неявно. Макросы, функции глупые, структуры, конструкторы, операторы.
T>>Слишком много правил, не правда ли ? M>Все с легкостью выводимо из понимания архитектуры. К тому же приведенные правила не имеют догматичный характер...
Легко. К сожалению сишком мало программистов которые это все это соблюдают.
Здравствуйте, Tanker, Вы писали:
T>Здравствуйте, Mystic, Вы писали:
T>>>1. всегда инициализировать нулем M>>Хм... зачем? Указатели надо инициализировать перед использованием, как и все прочие переменные. T>Кто тебе сказал, что выделение памяти будет в том же методе ?
Минуточку, ты писал "указатели всегда надо инициализировать нулем". Я вполне допускаю существование случаев, когда указатели должны инициализироваться нулем.
T>>>2. всегда ставить ассерт на !NULL при использование (как минимум) M>>В зависимости от контекста. Если мы получили адрес локальной переменной, функции/процедуры, то зачем тут Assert? T>А ты только с локальными переменными работаешь ? Все методы без аргументов ? T>Ассерт тормозит дебаг и несильно.
Ну... насчет того, что тормозит отладка я не замечал. Во-вторых, ты писал "всегда". Я же не говорю, что такие Assert-ы надо исключить. Но в случае его отсутствия в Windows будет исключение, которое в большинстве случаев сгодится вмето Assert-а.
T>>>3. всегда проверять что куда присваиваешь M>>Целиком и полностью за, но настаиваю на том, что данный пункт справедлив не только в отношении указателей T>С укузателями особый случай. Потому как указатель на экземпляр класса это фактически указатель на методы.
А почему если указатели, то обязательно С++? Есть ассемблер и масса других языков. Кстати, стандарт С++ сообще подобными вещами не заморачивается, ты используешь особенности реализации. Может будем говорить о том, что надо не испольовать особенности реализации конкретного компилятора и бесбоязненно использовать указатели?
T>>>4. всегда затирать нулем если объект разрушен M>>Возможны различные схемы. В некоторых случаях это бессмысленно. А когда ты не уверен в том, что указателем никто больше не воспользется, то совет разумен. T>Увереным вообще быть нельзя. Сейчас по проекту, который был заморожен два года назад, приходится много лишнего геморроя отлаживать потому как разрабы прежние считали что "В некоторых случаях это бессмысленно".
Криво написать программу можно и без помощи указателей
T>>>7. осторожно пользоваться приведением типа M>>Тавтология с п. 3. T>Про паскаль речи не идет. Почитай про множественное наследование.
Мы про указатели или про C++?
T>>>9. Проверять неявное выделение памяти M>>В смысле, проверять? Вот в .NET вся динамическая память выделяется неявно, как мне ее прикажете проверять??? T>Мы вовсе не про дотнет. В c/с++ есть кучка мест, где память выделяется неявно. Макросы, функции глупые, структуры, конструкторы, операторы.
Мы про указатели или про C++?
Z>Интерпретаторы строят не на принципах формальных грамматик. Их строят на основе вычислительных моделей. Задумайтесь, чем отличается интерпретатор Scheme от интерпретатора Haskell. Грамматикой?
Да, этот вопрос потерял смысл без уточнения. В интерпретаторе 2 стадии — синтаксического разбора и собственно вычислений. Я имел ввиду первое, разумеется. Смысл второго действительно банален и может быть действительно кому-то интересен на начальном этапе.
А я вообще напирал на "механическую" сторону вопроса. Лично мне было бы неуютно и не интересно за компьютером, если бы я не понимал принципов его работы. А после того как начал понимать, можно уже и за Схему браться и за что угодно.
Здравствуйте, Mystic, Вы писали:
M>Минуточку, ты писал "указатели всегда надо инициализировать нулем". Я вполне допускаю существование случаев, когда указатели должны инициализироваться нулем.
Именно всегда. Т.к. ты не знаешь на момент разработки, что произойдет с кодом через некоторое время.
T>>>>2. всегда ставить ассерт на !NULL при использование (как минимум) M>>>В зависимости от контекста. Если мы получили адрес локальной переменной, функции/процедуры, то зачем тут Assert? T>>А ты только с локальными переменными работаешь ? Все методы без аргументов ? T>>Ассерт тормозит дебаг и несильно. M>Ну... насчет того, что тормозит отладка я не замечал. Во-вторых, ты писал "всегда". Я же не говорю, что такие Assert-ы надо исключить. Но в случае его отсутствия в Windows будет исключение, которое в большинстве случаев сгодится вмето Assert-а.
Исключение вылетит в самый неудобный момент, когда указатель ты передашь чурт-знает куда. Ассерт же указывает на ошибку сразу.
M>А почему если указатели, то обязательно С++? Есть ассемблер и масса других языков. Кстати, стандарт С++ сообще подобными вещами не заморачивается, ты используешь особенности реализации. Может будем говорить о том, что надо не испольовать особенности реализации конкретного компилятора и бесбоязненно использовать указатели?
Это не ко мне.
T>>Увереным вообще быть нельзя. Сейчас по проекту, который был заморожен два года назад, приходится много лишнего геморроя отлаживать потому как разрабы прежние считали что "В некоторых случаях это бессмысленно". M>Криво написать программу можно и без помощи указателей
Конечно. Но дело в том, что большинство багов на C/С++ — это именно указатели.
M>>>Тавтология с п. 3. T>>Про паскаль речи не идет. Почитай про множественное наследование. M>Мы про указатели или про C++?
Указатели "отдельно" не существуют. В с++ с ними свои проблемы. В паскале — свои. Я говорил только про С++. Не нравится — напиши как хорошо с указателями на паскале.
T>>Мы вовсе не про дотнет. В c/с++ есть кучка мест, где память выделяется неявно. Макросы, функции глупые, структуры, конструкторы, операторы. M>Мы про указатели или про C++?
Напишу еще разок — указатель без контекста это "сферический конь в вакууме".
В паскале свои проблемы — COM, WINAPI и тд.
Естественно, если ты пишешь программы не используя ни COM, ни WINAPI, то тебе и указатели не нужны. На нет и спроса нет.
P.S. Проблеммы c указателями встерчаются, как ни странно, именно там где эти самые указатели встречаются
Здравствуйте, Towiz, Вы писали:
O>>Ну как-то раз я пытался одной девушке объяснить, что такое указатели. Нет, даже двум! Оба раза провал
T>Нет, ну я одной девушке объяснил. Она даже поняла что такое связные списки. T>Потом мы поженились
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Mystic,
>> СГ> А я вот не понимаю в каком месте сложна Общая Теория Относительности, но встречал очень небольшое количество людей думающих также.
>> Бог с ней, ОТО... Вот квантовая механика...
ПК>Релятивистская
Товарищи, лучше проквантуйте ОТО. Вот тут мозги-то у вас и сплавятся.
Здравствуйте, vdimas, Вы писали:
V>В интерпретаторе 2 стадии — синтаксического разбора и собственно вычислений. Я имел ввиду первое, разумеется. Смысл второго действительно банален и может быть действительно кому-то интересен на начальном этапе.
Э... Я бы сказал, что смысл первого банален и может быть нтересен на начальном этапе.
Здравствуйте, Mystic, Вы писали:
M>Бывает. Плюс в мое время много самоучек. Одного моего знакомого учили Basic так: это PRINT, это LET, это INPUT. а до остального сам догадаешься В любом случае этому уделяют внимания меньше чем нужно.
Гм... А оказывается синтаксис я подзабыл уже...
[RSDN@Home][1.2.0][alpha][668]
[3лой человек вредит самому себе прежде, чем повредит другому. [Августин]]
dmz>Читаю в Джоэла, в который раз натыкаюсь упоминания на сложность указателей, вплоть до того, dmz>что он готов посвятить им отдельную часть мозга.
dmz>Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё. dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
А я вот встречаю людей, которые даже в Шарпе, где типа "не надо думать об указателях", пишут
потом не могут понять, почему у a1 изменилась улица.
Это чуть утрированный пример, но ситуация происходит именно такая. не понимают, почему ресурс которому дали Dispose() перестал быть доступен во всех объектах, которые на него ранее завели ссылки. Или почему в памяти все еще висит объект, который привязан через обработчик события.
Причем зачастую бывает что люди совсем неглупые.
Вот потому видимо, Джоел и выделяет это в отдельную область мозга. Что вроде бы ведь легко, а почему-то не у всех полчается...
Сложно ли иметь красивый почерк?
Сложно ли забросить мячик в корзинку с 3х метров?
Ну и самое главное — вот есть какие-то непонятные люди дальтоники. Типа не различают цвета. Ну не бред ли? Я вот понимаю математический анализ — это сложно — но отличить зеленый от голубого?? Какая проблема может быть? Даже в школе ни у кого нет проблем!
P.S.
Лично я помню, когда в школе изучал Паскаль, я просто не мог понять суть указателей. Все эти списки и прочая лабуда были мне белым шумом. Да, я мог сделать пример из учебника и посмотреть как он работает. Даже упражнения мог сделать, когда они были по полной аналогии. Но чуть в сторону — труба. А потом в какй-то момент наступило просто Просветление, иначе это не назвать. Я до сих пор помню этот момент — вся информация вдруг сложилась в стройную картину и я понял насколько это здорово и нужно! И уже не понимал, как же раньше это могло быть не понятно — ведь все так примитивно.. %)
Здравствуйте, Tanker, Вы писали:
T>Видишь ли, тут все сложно. С одной стороны когда играется слишком много (чистый c/с++ник) это одно. А совсем другое — когда совсем не играется — C#.
T>Я думаю играться надо в меру — С#/С++
Здравствуйте, dmz, Вы писали:
dmz>Читаю в Джоэла, в который раз натыкаюсь упоминания на сложность указателей, вплоть до того, dmz>что он готов посвятить им отдельную часть мозга.
dmz>Не, ну я понимаю — функциональное программирование наверное штука сложная — монады там, то-сё. dmz>Но в каком месте сложны указатели-то? А? Не помню что бы хоть кто-то испытывал с ними какие-то dmz>проблемы, даже в школе.
dmz>Может, у Джоэла были в детстве какие-то проблемы с указателями, которые травмировали нежную психику, dmz>а теперь он на всех это проецирует?
Суть указателей довольно проста, а вот использование может стать весьма утомительным.
Основным минусом использования указателей является их сильная зависимость от контекста.
Контекст пространства — указатель привязан к процессу,
использование указателя в другом процессе в общем случае небезопасно.
Контекст времени — в одном и том же процессе указатель валиден в течение некоторого интервала времени,
пока он указаывает на живой объект. Ни до, ни после, использование указателя небезопасно.
Указатель это один из видов ссылок (ссылки в обшем смысле) одних объектов на другие,
причем довольно опасный.
Плюсом указателей является их, видимо, самая высокая скорость разрешения в объект.
Так что указатель, с одной стороны — это просто адрес,
а с другой — это частный случай ссылок с определенными характеристиками,
которые нужно учитывать используя указатели.
m_n wrote: > Контекст пространства — указатель привязан к процессу, > использование указателя в другом процессе в общем случае небезопасно.
Кхм. Обращаться напрямую между процессами возможно вообще только в
особых случаях.
> Контекст времени — в одном и том же процессе указатель валиден в течение > некоторого интервала времени, > пока он указаывает на живой объект. Ни до, ни после, использование > указателя небезопасно.
Почему? Инициализируем указатель нулем при создании — и обращайся к нему
сколько хочешь, причем вполне безопасно.
> Указатель это один из видов ссылок (ссылки в обшем смысле) одних > объектов на другие, причем довольно опасный.
Отсюда подробнее.
Как для ссылок в общем случае определить адресную арифметику?
> Так что указатель, с одной стороны — это просто адрес, > а с другой — это частный случай ссылок с определенными характеристиками, > которые нужно учитывать используя указатели.
Скорее ссылки (в понимании CLR/JVM) — это частный случай указателей.
Здравствуйте, Cyberax, Вы писали:
C>m_n wrote: >> Контекст пространства — указатель привязан к процессу, >> использование указателя в другом процессе в общем случае небезопасно. C>Кхм. Обращаться напрямую между процессами возможно вообще только в C>особых случаях.
Использование указателя из другого процесса технически возможно,
так что нужно помнить чем грозит такое использование.
>> Контекст времени — в одном и том же процессе указатель валиден в течение >> некоторого интервала времени, >> пока он указаывает на живой объект. Ни до, ни после, использование >> указателя небезопасно. C>Почему? Инициализируем указатель нулем при создании — и обращайся к нему C> сколько хочешь, причем вполне безопасно.
Разумеется, Вы можете сделать использование указателей безопасным,
приложив дополнительные усилия, вот инициализация нулем — одно из них.
Проверка на нуль перед использованием или
отлов исключений при разыменовывании нулевых/невалидных указателей —
все это правила использования указателей.
Проблема в том, что правила использования указателей не следуют из их синтаксиса,
а держутся только на аккуратности/опыте разработчика.
А раз безопасность использования указателей контролируется человеком, а не компилятором,
значит использование указателей является небезопасным.
>> Указатель это один из видов ссылок (ссылки в обшем смысле) одних >> объектов на другие, причем довольно опасный. C>Отсюда подробнее.
Термин ссылка перегружен в этом абзаце, лучше вот так:
Указатель это один из видов реализации ассоциаций между объектами, причем довольно опасный.
Есть, по крайней мере, еще один вид реализации ассоциаций — это ассоциации по ключу.
Например, с объектом Заказ ассоциирован объект Клиент.
Как реализовать эту ассоциацию?
Можно через указатель на соответсвующий объект клиента.
А можно через ключ того же клиента.
Ключ более безопасный, но он более медленный при разрешении в объект.
У ключа отсутствует контекст пространства — ключ можно использовать в любом процессе.
Использование ключа частично следует из его синтаксиса —
ключ необходимо разрешать в объект перед использованием.
C>Как для ссылок в общем случае определить адресную арифметику?
>> Так что указатель, с одной стороны — это просто адрес, >> а с другой — это частный случай ссылок с определенными характеристиками, >> которые нужно учитывать используя указатели.
Все та же моя неточность:
Так что указатель, с одной стороны — это просто адрес,
а с другой — это вариант реализации ассоциаций с определенными характеристиками,
которые нужно учитывать используя указатели.
C>Скорее ссылки (в понимании CLR/JVM) — это частный случай указателей.
Согласен с Вами.
m_n wrote: > C>Кхм. Обращаться напрямую между процессами возможно вообще только в > C>особых случаях. > Использование указателя из другого процесса /технически возможно/, > так что нужно помнить чем грозит такое использование.
У твоего ассоциативного примера — тоже.
> C>Почему? Инициализируем указатель нулем при создании — и обращайся к нему > C> сколько хочешь, причем вполне безопасно. > Разумеется, Вы можете сделать использование указателей /безопасным/, > приложив дополнительные усилия, вот инициализация нулем — одно из них. > Проверка на нуль перед использованием или > отлов исключений при разыменовывании нулевых/невалидных указателей — > все это правила использования указателей.
А почему тогда в Java (языке со ссылками!) есть
NullPointerException?
> Указатель это один из видов реализации ассоциаций между объектами, > причем довольно опасный.
Уже лучше.
> Есть, по крайней мере, еще один вид реализации ассоциаций — это > ассоциации по ключу. > Например, с объектом Заказ ассоциирован объект Клиент. > Как реализовать эту ассоциацию? > Можно через указатель на соответсвующий объект клиента. > А можно через ключ того же клиента.
С теми же проблемами — а если по ключу будет лежать другой объект или
ничего не будет?
хотя, например, что такое функции/переменные/массивы одна из них схватила (дело было на Си).
"Всё что не убивает нас, делает нас сильнее..."
