Как вы относитесь к паскалю? , (есть гипотеза)

Голосование только для тех, кто знает какой-нибудь диалект паскаля и писал на нем что-нибудь сложнее helloworld.

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

Моим первым ЯП был бейсик. Никто не заставлял меня учить его насильно - все сам. Я признаю, что современный бейсик, в общем-то, нормальный язык. Но вот писать на нем категорически не хочется даже в теории - лучше уж на фортране-66, чес-слово. И я, конечно же, не одинок - наверное, все слышали, что "курица - не птица, бейсик - не язык" и что "студенты, начинавшие с бейсика, безнадежно испорчены".

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

Вот я и подумал: может быть, паскаль ненавидят те, у кого он был первым, "учебным" высокоуровневым языком?

Цитата

Начинал(а) с другого языка, паскаль - хороший язык

Python - хороший язык для обучения в школах. Pascal - был им 20 лет назад, сейчас на дворе 14-й, если верить календарю

Цитата AVA12 @ 01.01.14, 16:44

Причина в том, что новичок слишком часто сталкивается с проблемами, и зачастую совершенно непонятно, в чем же именно проблема и что от него хочет этот бежевый ящик, и негативные эмоции переносятся на "тупой" язык программирования.

Это верно в отношении C/C++, как первого языка.

Цитата AVA12 @ 01.01.14, 16:44

Если судить беспристрастно, то паскаль (особенно современные диалекты) - отличный язык.

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

Цитата Мяут-Настоящий @ 01.01.14, 16:58

Для каких задач он отличный?

Skype? Работает же, на Delphi написан.

Цитата

для обучения - из-за бедности парадигм и концепций

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

Остальное - офтопик.

Где вариант - пофиг? Чем больше паскалят - тем лучше джавистам

Цитата AVA12 @ 01.01.14, 17:16

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

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

Цитата Pacific @ 01.01.14, 17:13

Skype? Работает же, на Delphi написан.

По поводу Delphi (это кстати отдельный язык) - в холиварах куча тем, милости прошу. Правда у Skype на нем написана только морда виндового клиента.

Цитата AVA12 @ 01.01.14, 17:16

Структурное программирование, ООП, модули, обработка ошибок, нормальные строки "из коробки", быстрый компилятор

Все это уже есть в Python. А еще есть встроенные списки, множества и словари, foreach-цикл (причем только он). Синтаксис у Python выразительнее, и к тому же обязывает расставлять отступы.
А еще есть интерактивный интерпретатор, который позволит вообще не думать о том, что это такое на первом занятии.
Ну и как я заметил - зачем забивать голову языком, который потом применяться человеком врядли будет.

Как пример кода на Python. Задание - считать с клавиатуры 2 числа и вывести в шестнадцатиричной системе счисления их сумму.

a = int(raw_input('Enter a: '))
b = int(raw_input('Enter b: '))
 
print hex(a + b)

Цитата

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

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

Цитата

и к тому же обязывает расставлять отступы

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

Цитата

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

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

Цитата

print hex(a + b)

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

У меня на 5.5-м, 6-м и 7-м Паскалях множество интересного написано, включая системное. Но ничего промышленного, это да.

Сообщение отредактировано: Qraizer - 01.01.14, 19:08

Начинал с бесика второй язык был паскаль.
Третий ассемблер, затем си, php, sql, c#, си++.
Ненавижу то, что паскаль был второй. Не навижу потому что знаю лучше чем си++. Но язык хороший и лучше чем си/си++, но нехватает популярности у паскаля - нет массы кода которая очень нужна.

С одной стороны языки учил сам. Хотя это не совсем правда.

AVA12, почему или "ненавижу" или "хороший"? Между ними такая гамма вариантов...
Вот конкретно сейчас я никак к паскалю не отношусь. У меня просто нет повода как-либо к нему относиться

Добавлено 01.01.14, 20:23
ИМХО, единственный приличный наследник Паскаля - Ада.

Сообщение отредактировано: D_KEY - 01.01.14, 20:23

D_KEY, можно ведь и воздержаться от голосования.

Цитата AVA12 @ 01.01.14, 18:11

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

Ну вот я и не призываю разбираться с обобщенным программированием и MPL в C++. И даже об итераторах и генераторах ни слова

Цитата AVA12 @ 01.01.14, 18:11

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

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

Цитата AVA12 @ 01.01.14, 18:11

Может, чтобы научиться учиться?

Ну если есть возможность научить сразу хорошему языку, почему избегать ее?

Цитата AVA12 @ 01.01.14, 18:13

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

Может быть. Но не на первом занятии, когда еще ни слова о циклах не сказано.

Добавлено 01.01.14, 21:23

Цитата D_KEY @ 01.01.14, 20:15

У меня просто нет повода как-либо к нему относиться

Ну вот голосилку создали - повод появился

Цитата Мяут-Настоящий @ 01.01.14, 18:04

Как пример кода на Python. Задание - считать с клавиатуры 2 числа и вывести в шестнадцатиричной системе счисления их сумму.

Новичек ничего не поймет в этом коде. Если начинать изучать с питона или .net или java, то не будешь понимать как это работает изнутри, соответственно человек дальше своего носа не увидит проблему.

Сообщение отредактировано: Wound - 01.01.14, 21:51

Цитата Мяут-Настоящий @ 01.01.14, 21:22

Цитата D_KEY @ 01.01.14, 20:15

У меня просто нет повода как-либо к нему относиться

Ну вот голосилку создали - повод появился

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

Добавлено 01.01.14, 22:37
Из его наследия полезными нельзя назвать ни виртовские модулы2 с оберонами и компонентными паскалями, ни делфи. По крайней мере на данный момент. Косвенный наследник - Ада - получился годным языком(хотя синтаксис не в моем вкусе). Еще более дальний родственник(если вообще можно его таковым считать) - Eiffel - хоть и является одним из возможных эталонов ОО-языка, но распространения не получил. Как я понял, виртовские концепции p-кода и пр. внесли больший вклад в развития отрасли(в данном случае, виртуальные машины), чем непосредственно разработанные им языки...

Цитата AVA12 @ 01.01.14, 16:44

Начинал(а) с паскаля, сам(а) - ненавижу!

Язык хороший, чтобы не говорили другие, но ненавижу я его - он мне всю жизнь испортил. Не потому что он был первым, и сним связаны негативные воспоминания первых неудач.
Формально первым ЯВУ был QBasic, но как понял в чем прикол транслаторов и компиляторов, стал искать для себя второе. Учился сам, никаких знакомых программистов не было у меня. Да ваще в то время среди друзей только у одного был комп. В тырконете наткнулся на Паскаль (Турбо который и под ДОС). Название было наслуху, поэтому был уверен что не прогадаю с его выбором. Изучил его вдоль и поперек. Причем чем дольше изучал тем глубже уходил в аппаратную часть.
Когда понял в чем прикол ДОС-программ и Виндовс-прог, был (мягко сказать) немного растроен, и стал искать для себя второе. Ну естесственно выбор пал на Делфи. И стех пор вот почти уже 10 лет я программирую на Делфи.
Уже не помню как произошло осознание в чем прикол Делфи-программистов и (например) СИ-программистов в контексте рынка труда, но это было очень глубоким разочарованием.
Вобщем высокооплачиваем программистом (как я задумывал) я не стал.

Паскаль как язык для обучения неплохой вариант. Но лучше либо Си (без плюсов), либо питон. Имхо, разумеется

Добавлено 02.01.14, 04:38

Цитата Суровый @ 02.01.14, 04:31

И стех пор вот почти уже 10 лет я программирую на Делфи.

Переучиться пробовал? С дельфи на шарп легко пересесть, например.

Цитата OpenGL @ 02.01.14, 04:36

Переучиться пробовал? С дельфи на шарп легко пересесть, например.

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

Добавлено 02.01.14, 05:11
Короче не учите Паскаль, Делфи, а то на заводе будуте работать!

Цитата Wound @ 01.01.14, 21:50

Новичек ничего не поймет в этом коде. Если начинать изучать с питона или .net или java, то не будешь понимать как это работает изнутри

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

Цитата OpenGL @ 02.01.14, 04:36

без плюсов

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

Добавлено 02.01.14, 06:56
В плане обучения в С++ не хватает только нормальных модулей(но их нет и в си).

Фу! Паскалюга! Фу-фу-фу!

Добавлено 02.01.14, 07:49
Я отношусь к нему так: да, есть что похуже... но не много

Цитата D_KEY @ 02.01.14, 06:54

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

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

Добавлено 02.01.14, 09:29

Цитата D_KEY @ 02.01.14, 06:54

иначе есть риск получить синдром утечка и зациклиться на голом си.

Имхо, маловероятно Такое с более приятными языками типа шарпа может произойти наверное.

Автор темы поискал предложения по работе, паскаля там не нашел и решил рассказать, как это неправильно?
"Современные диалекты Паскаля", который Delphi, уже видимо окончательно сдал свою нишу Це-шарпу и живет только из ностальгии некоторых программописателей.

P.S. Паскаль у меня был третьим, между Васиком и C, быстро прошел мимо. Кроме костылей ничем не приметился. Потом в фоновом режиме был Delphi - ибо VCL, опять кроме костылей и несуразностей ничем не примечателен.

Добавлено 02.01.14, 09:33
Да, по самому опросу. "Начинал с другого языка, паскаль не хороший язык, я его не ненавижу, могу потроллить паскалелюбов"

Цитата trainer @ 02.01.14, 09:30

Delphi - ибо VCL, опять кроме костылей и несуразностей ничем не примечателен.

Шо не получилось VCL-драйвер написать для Виндовс?

Цитата trainer @ 02.01.14, 09:30

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

А Васик стало быть замечательный язык, потому что самый первый?

Цитата AVA12 @ 01.01.14, 16:44

Начинал(а) с другого языка, паскаль - хороший язык.

ЗЫ: начинал с С++. Жалею, что не с ассемблера (а ведь предлагали).

Добавлено 02.01.14, 12:13

Цитата Мяут-Настоящий @ 01.01.14, 21:22

Ну если есть возможность научить сразу хорошему языку, почему избегать ее?

Вероятно, поэтому.

Сообщение отредактировано: shm - 02.01.14, 12:13

После перехода на Java - паскаль кажется ужасным. Эти отдельные объявления interface/implementation, каша из переменных, которые декларируются в одном месте, вложенные функции, к которым нереально написать автотесты... Хотя для обучения можно использовать - там особой разницы нету.

Цитата [S]mike @ 02.01.14, 12:20

вложенные функции, к которым нереально написать автотесты...

А к static, надо понимать, легче? Или к приватным методам класса?

Цитата AVA12 @ 01.01.14, 16:44

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

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

Цитата Qraizer @ 02.01.14, 13:38

А к static, надо понимать, легче? Или к приватным методам класса?

В Java для этого есть package visibility.

Цитата [S]mike @ 02.01.14, 12:20

Эти отдельные объявления interface/implementation

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

Добавлено 03.01.14, 07:54

Цитата [S]mike @ 02.01.14, 12:20

которые декларируются в одном месте

Ну а с этим пожалуй согласен, для локальных переменных такое повышенное внимание, как отдельная секция - и вправду не нужно

Цитата --Ins-- @ 03.01.14, 07:53

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

В идее есть команда навроде "свернуть/развернуть реализации методов". По идее то, что нужно.

Цитата OpenGL @ 03.01.14, 08:50

В идее есть команда навроде "свернуть/развернуть реализации методов". По идее то, что нужно.

И привязываешься к IDE, пересядешь за другую где этого не будет и будешь страдать.

Цитата Wound @ 03.01.14, 08:54

И привязываешься к IDE, пересядешь за другую где этого не будет и будешь страдать.

Во-первых, в сообщении, на которое я отвечал, про IDE и говорилось. Во-вторых, я почти уверен, что в остальных более-менее популярных java ide эта функция имеется - главное поискать получше.

Цитата OpenGL @ 03.01.14, 09:11

Во-вторых, я почти уверен, что в остальных более-менее популярных java ide эта функция имеется - главное поискать получше.

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

Цитата OpenGL @ 03.01.14, 08:50

В идее есть команда навроде "свернуть/развернуть реализации методов". По идее то, что нужно.

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

Сообщение отредактировано: --Ins-- - 03.01.14, 10:45

Цитата OpenGL @ 03.01.14, 08:50

В идее есть команда навроде "свернуть/развернуть реализации методов". По идее то, что нужно.

Да фигня это всё. Лично меня в плюсах разделение объявления и определения очень радуют.
А в этих джавошарповских портянках фиг разберёшься.

Цитата --Ins-- @ 03.01.14, 10:42

И уж тем более - это не недостаток, как пытается выдать Смайк.

Ну это-то само собой Слишком уж субъективная штука. Лично мне по-барабану. Впрочем, на явашарпах я только мелочь всякую писал, так что не знаю, как оно в реальном проекте.

Цитата OpenGL @ 02.01.14, 09:28

Для обучения навыку выражать свою мысль в виде кода хватит и Си.

Может быть, но не всегда. Пространства имен, строки, динамические массивы, классы и даже шаблоны в том или ином виде(уж лучше макросов-то). В новом стандарте - enum-классы, array, строгая инициализация, циклы по коллекциям, да auto тот же... Все это может пригодиться при обучении. Зачем искусственно ограничивать?

Цитата

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

Так же, как и тонкости Си Не о тонкостях же речь. С++ проще в использовании, при использовании его гораздо легче отгородиться от тонкостей, чем при использовании Си.

Цитата

Цитата D_KEY @ 02.01.14, 06:54

иначе есть риск получить синдром утечка и зациклиться на голом си.

Имхо, маловероятно Такое с более приятными языками типа шарпа может произойти наверное.

Но я много раз видел, как люди после си отказываются даже С++ использовать, не говоря уже о шарпах-явах.

Добавлено 03.01.14, 11:49

Цитата --Ins-- @ 03.01.14, 10:42

И уж тем более - это не недостаток, как пытается выдать Смайк.

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

Цитата MyNameIsIgor @ 03.01.14, 10:50

Да фигня это всё. Лично меня в плюсах разделение объявления и определения очень радуют.
А в этих джавошарповских портянках фиг разберёшься.

Как будто в джавашарпах кто-то мешает писать интерфейс отдельно. Или в плюсах — в одном месте.

Цитата D_KEY @ 03.01.14, 11:46

Но тут проблема в том, что в новых языках так не делают...

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

Цитата korvin @ 03.01.14, 12:03

Как будто в джавашарпах кто-то мешает писать интерфейс отдельно.

Это как? Или ты имеешь в виду заводить в Java под каждый класс дублирующий его интерфейсный тип? Во-первых, это маразм, во-вторых - это не будет то же самое, т.к. методы интерфейсного типа должны быть публичными и instance, а как насчет приват, протектед и статик?

Сообщение отредактировано: --Ins-- - 03.01.14, 12:45

Цитата D_KEY @ 03.01.14, 11:46

Так же, как и тонкости Си

Думаю, что при обучении плюсам обучаемый будет фактически учиться языку "С с классами", что, разумеется, сложнее, чем просто Си.

Цитата D_KEY @ 03.01.14, 11:46

Но я много раз видел, как люди после си отказываются даже С++ использовать, не говоря уже о шарпах-явах.

Например, Торвальдс? Вот честно - не знаю ни одного весомого аргумента в пользу Си перед плюсами, кроме "С++ отсутствует на целевой платформе" и "быстродействия плюсов не хватает".

Цитата D_KEY @ 03.01.14, 11:46

Может быть, но не всегда. Пространства имен, строки, динамические массивы, классы и даже шаблоны в том или ином виде(уж лучше макросов-то). В новом стандарте - enum-классы, array, строгая инициализация, циклы по коллекциям, да auto тот же... Все это может пригодиться при обучении. Зачем искусственно ограничивать?

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

Цитата OpenGL @ 03.01.14, 13:20

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

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

Сообщение отредактировано: --Ins-- - 03.01.14, 13:28

Цитата --Ins-- @ 03.01.14, 12:43

Во-первых, это маразм

Почему? Это то же самое, только гибче, т.к. модули в этих ваших паскалях не «first-class citizens».

Цитата --Ins-- @ 03.01.14, 12:43

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

И? Как будто процедуры интерфейсной части модуля могут быть какими-то другими.

Цитата --Ins-- @ 03.01.14, 12:43

и instance

И что?

Цитата --Ins-- @ 03.01.14, 12:43

а как насчет приват

Это часть реализации модуля/объекта, в чем проблема?

Цитата --Ins-- @ 03.01.14, 12:43

протектед и статик?

А что с ними?

Цитата OpenGL @ 03.01.14, 13:20

Цитата D_KEY @ 03.01.14, 11:46

Так же, как и тонкости Си

Думаю, что при обучении плюсам обучаемый будет фактически учиться языку "С с классами", что, разумеется, сложнее, чем просто Си.

Да почему сложнее-то, когда классы с методами гораздо проще воспринимать и создавать, чем структуры + отдельные функции?

Цитата

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

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

Добавлено 03.01.14, 14:35

Цитата korvin @ 03.01.14, 12:03

Как будто в джавашарпах кто-то мешает писать интерфейс отдельно.

Без создания лишних сущностей(интерфейсов) в явашарпах это сделать нельзя. Ты не путай две разные сущности с разделением объявления и определения одной и той же сущности. У Бертрана Мейера это называется краткой и полной формой класса, если правильно помню. Но он предлагает, чтобы среда разработки могла легко предоставить краткую форму. Я нахожу, что это менее удобно, чем явное разделение.

Цитата --Ins-- @ 03.01.14, 07:53

адекватной замены для этого IDE не предлагает

Eclipse Ouline?

Ну или javadoc на худой конец

Цитата --Ins-- @ 03.01.14, 13:27

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

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

Цитата D_KEY @ 03.01.14, 14:29

Да почему сложнее-то, когда классы с методами гораздо проще воспринимать и создавать, чем структуры + отдельные функции?

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

Цитата D_KEY @ 03.01.14, 14:29

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

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

Цитата D_KEY @ 03.01.14, 14:29

Я не предлагаю пуститься во все тяжкие и изучать С++ во всей его полноте.

Тогда зачем чуть выше про тонкости Си спрашиваешь?

Цитата korvin @ 03.01.14, 12:03

Как будто в джавашарпах кто-то мешает писать интерфейс отдельно. Или в плюсах — в одном месте.

Нет, в плюсах ничто не мешает всё слепить.
Но интерфейсы - это не то:
1) Они ничего не говорят о приватных методах и полях, статических методах и полях. Т.е. в плюсах я просто открываю и вижу что у класса есть, это помогает читать реализацию.
2) Они не призваны служить объявления и определения, они для полиморфизма. Из этого следует некислый такой WTF-эффект читающего, если я интерфейсы для каждого класса напишу.

Цитата OpenGL @ 03.01.14, 15:09

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

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

Цитата D_KEY @ 03.01.14, 15:37

Как только речь именно о структурах данных и операций над ними, классы и методы прямо ложатся на то, о чем идет речь.

Так это инкапсуляция только.

Цитата OpenGL @ 03.01.14, 15:09

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

Будет достаточно - ничего не имею против. Я против того, чтобы изначально ставить ненужные рамки. Используем С++ и все. А уж что конкретно мы будем использовать - будет зависеть от программы курса, а не языка

Цитата D_KEY @ 03.01.14, 14:29

Без создания лишних сущностей(интерфейсов) в явашарпах это сделать нельзя. Ты не путай две разные сущности с разделением объявления и определения одной и той же сущности.

Интерфейс есть всегда, хоть ты его явно прописываешь, хоть неявно в public-секции класса. Никакой путаницы.

Цитата OpenGL @ 03.01.14, 15:09

для обучения писанию алгоритмов вполне достаточно простого Си.

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

Цитата OpenGL @ 03.01.14, 13:20

и "быстродействия плюсов не хватает".

И ты им веришь?

Цитата MyNameIsIgor @ 03.01.14, 15:32

1) Они ничего не говорят о приватных методах и полях, статических методах и полях.

У тебя много сложных приватных методов и полей в классах? Может стоит подумать о рефакторинге? =)
А при каждом изменении приватных методов и полей (читай реализации) придется перекомпилировать все унаследованые классы? Какая-то хреновая модульность получается.

Цитата MyNameIsIgor @ 03.01.14, 15:32

2) Они не призваны служить объявления и определения, они для полиморфизма.

Отчего же? Интерфейс — это определение типа объекта.

Цитата korvin @ 03.01.14, 15:56

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

Ты про блок-схемы? У языка, на котором учишься, должен же быть хоть какой-то интерпретатор-компилятор.

Цитата Qraizer @ 03.01.14, 15:57

И ты им веришь?

Нет. Но вполне допускаю, что они могут быть правы

Цитата OpenGL @ 03.01.14, 16:11

Но вполне допускаю, что они могут быть правы

Только в одном случае: кастомная реализация на каждый случай. При этом никто не мешает так же поступать в Плюсах, коли припечёт.

Цитата korvin @ 03.01.14, 15:56

Цитата D_KEY @ 03.01.14, 14:29

Без создания лишних сущностей(интерфейсов) в явашарпах это сделать нельзя. Ты не путай две разные сущности с разделением объявления и определения одной и той же сущности.

Интерфейс есть всегда, хоть ты его явно прописываешь, хоть неявно в public-секции класса. Никакой путаницы.

Ты путаешь отдельную сущность с объявлением сущности, а после этого говоришь о том, что нет путаницы? Хм...

Добавлено 03.01.14, 16:43
В новой яве, например, вроде в интерфейсах можно указывать реализацию методов по умолчанию. Это выглядит достаточно нелепо на фоне твоих заявлений

Цитата OpenGL @ 03.01.14, 16:11

Ты про блок-схемы?

Нет.

Цитата OpenGL @ 03.01.14, 16:11

У языка, на котором учишься, должен же быть хоть какой-то интерпретатор-компилятор.

Да — мозг.

Цитата D_KEY @ 03.01.14, 16:40

Ты путаешь отдельную сущность с объявлением сущности, а после этого говоришь о том, что нет путаницы? Хм...

Что?

Цитата D_KEY @ 03.01.14, 16:40

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

Ява выглядит нелепо на фоне почти чего угодно.

Вроде в США Яву в школах преподают. Это в России учителя только Паскаль знают.

P.S.
За невозможность создавать нормальный ГУЙ в 2002г. на ТР 7 я своего учителя на Паскале вспоминаю... не добрым словом... год жизни в пустую...

Цитата korvin @ 03.01.14, 17:47

Цитата D_KEY @ 03.01.14, 16:40

Ты путаешь отдельную сущность с объявлением сущности, а после этого говоришь о том, что нет путаницы? Хм...

Что?

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

Цитата

Ява выглядит нелепо на фоне почти чего угодно.

Ну возьми trait'ы в scala. Там можно задавать реализацию. Или еще более отдаленный пример - тайпклассы в Haskell. Кстати, их ты тоже предлагаешь их использовать в данном контексте? Я бы рассматривал выделение объявлений как расширенный вариант списка экспорта модуля или что-то в таком духе.

Добавлено 03.01.14, 20:18

Цитата Keepun @ 03.01.14, 19:27

За невозможность создавать нормальный ГУЙ в 2002г. на ТР 7 я своего учителя на Паскале вспоминаю... не добрым словом... год жизни в пустую...

GUI как раз неважен, ИМХО. И к программированию прямого отношения не имеет.

Начинал... ну, наверное, это программирование в машинных кодах на Электронике Д3-28. Причём сразу в боевом режиме - обработка статистики производства за несколько лет и прогнозирование на будущее. И ведь заработало, практически сразу...

Паскаль - только что посчитал - был шестым. Хороший? нет. Сказать, что ненавижу - тоже нет. Такой средненький на то время язычок, главным образом от того, как там сделана работа со строками. Это уже много позже к нему начали прикручивать турбо-вижн и остальные прилады.

Дисциплинирует? из шести начальных моих языков только в одном можно (можно!) было не сильно париться за переменные и протчая - GW-Basic. Остальные пять - Паскаль, фортран, и три ипостаси ассемблера (машинные коды ведь тоже он), попробуй там не озаботься.

---

Нет в нём ничего такого уникально-образовательного. Мне вообще кажется, что его как образовательный просто кто-то красиво спозиционировал (или как сейчас говорят - пропиарил). Тогда ведь всё начиналось с абсолютного нуля, с чистого листа, аналогии с программированием на БЭСМах если и просматривались, то весьма слабенькие... вот кто-то и подсуетился. А все повелись. ИМХО.

Akina
Всё правильно. Дейкстра создавал паскаль как работу над ошибками это был его 3 язык. Основная концепция паскаля была то что он был одно проходным. А потому простым откуда видиммо и родилось, то что ему надо учить. А если учесть что он занимался им в вузе, то понятно что ему как-то надо было оправдать его создание.
Кстати паскаль не сильно отличается от Си. Разве что в Си были другие концепции положены. Всё есть функция. И работа с указателями.

Правда практика критерий истины. И реалии таковы что реализации играли существенную роль. Откуда в Borland Pascal паскаль появились указатели. Да и работа со строками. Собственно и в Фортране ввод вывод не был стандартизирован. А сейчас там и ООП есть.
И боже упаси читать стандарта SQL.

Макросы в ассемблере появились тоже для создания описания функций и локальных переменных. Приближая ассемблер к высокоурожайным языкам.
А так как Си создавался как копия ассемблера, то первоначальное описание функции было другим. А потом только стандартизировалось в то, что имеем.

Цитата korvin @ 03.01.14, 16:03

У тебя много сложных приватных методов и полей в классах? Может стоит подумать о рефакторинге? =)

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

Цитата korvin @ 03.01.14, 16:03

А при каждом изменении приватных методов и полей (читай реализации) придется перекомпилировать все унаследованые классы?

Придётся или нет совсем не зависит от чисто синтаксического разделения объявления и реализации сущности.

Цитата korvin @ 03.01.14, 16:03

Отчего же? Интерфейс — это определение типа объекта.

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

Добавлено 03.01.14, 22:05

Цитата Pavia @ 03.01.14, 21:27

Дейкстра создавал паскаль

Вирт же.

Цитата Pavia @ 03.01.14, 21:27

Разве что в Си были другие концепции положены. Всё есть функция.

Нет там ничего подобного. Всё функция - это функциональщина. А сишечка - обычный процедурный язык.

Цитата Pavia @ 03.01.14, 21:27

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

Паскаль создавал Вирт, который после Паскаля не прекратил свою "работу над ошибками", в результате чего появились Модула, Модула-2, Оберон и Оберон-2(от которых пошли компонентный паскаль и др. языки, но это уже другая история).

Добавлено 04.01.14, 02:26

Цитата --Ins-- @ 03.01.14, 12:43

Цитата D_KEY @ 03.01.14, 11:46

Но тут проблема в том, что в новых языках так не делают...

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

Кстати, Вирт и сам убрал это разделение при переходе с Модула-2 на Оберон.
В статье где он поясняет, почему он убрал/добавил то или иное средство, он ничего по этому вопросу не прояснил...

Цитата

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

Сообщение отредактировано: D_KEY - 04.01.14, 02:26

Цитата korvin @ 03.01.14, 17:47

Да — мозг.

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

Добавлено 04.01.14, 04:05

Цитата Qraizer @ 03.01.14, 16:12

Только в одном случае: кастомная реализация на каждый случай. При этом никто не мешает так же поступать в Плюсах, коли припечёт.

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

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

Цитата MyNameIsIgor @ 03.01.14, 10:50

Да фигня это всё. Лично меня в плюсах разделение объявления и определения очень радуют.
А в этих джавошарповских портянках фиг разберёшься.

Это самое, а есть ли в шарпе кодеэксплорер как в дельфях? Типа чтоб сам сбоку выписал что там в классе есть.
А то сидишь в кокретном методе и вынужден сбоку держать дубль окна со сверутыми объявлениями(((

Цитата Keepun @ 03.01.14, 19:27

За невозможность создавать нормальный ГУЙ в 2002г.

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

Сообщение отредактировано: --Ins-- - 04.01.14, 06:56

Цитата --Ins-- @ 04.01.14, 06:53

Считаю, что это внесло огромный вклад в обучение программированию

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

Добавлено 04.01.14, 08:30
Вообще, я убежден, что наибольший вклад в обучение программированию вносит чтение кода, а не его написание.

Цитата D_KEY @ 03.01.14, 20:16

Разговор зашел о разделении объявлений и определений. В качестве аналога ты предлагаешь заводить еще одну сущность - интерфейс

Не надо заводить, она и так есть.

Цитата D_KEY @ 03.01.14, 20:16

Или еще более отдаленный пример - тайпклассы в Haskell. Кстати, их ты тоже предлагаешь их использовать в данном контексте?

Крайне неудачный пример, в Хаскелле нет классов.

Цитата MyNameIsIgor @ 03.01.14, 21:57

Просто увидеть, сжато и коротко.

Там выше скриншот был.

Цитата OpenGL @ 04.01.14, 04:02

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

Какой программы? Ты же про алгоритмы говорил.

Цитата --Ins-- @ 04.01.14, 06:38

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

Да ну? Может ты расскажешь?

Цитата Мяут-Настоящий @ 04.01.14, 08:26

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

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

Цитата korvin @ 04.01.14, 08:53

Да ну? Может ты расскажешь?

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

Сообщение отредактировано: --Ins-- - 04.01.14, 09:30

Цитата

Цитата

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

Какой программы? Ты же про алгоритмы говорил.

алгоритмы - алгоритмами, но начинающему очень полезно наглядно видеть то, что он делает. Мало кому приносит удовольствие решать академическую задачу с вводом двух чисел в консоли и последующим выводом туда же.
Лично у меня был дельфи (5й) в институте (первым, был и асм, но позже), и по началу меня бесило что я не мог сразу разобраться со св-вами (да, нам на первых парах рассказывали про VCL) и понять как сделать процедуру. А когда разобрался - дальше я уже развивался сам, это был лишь толчок к самообучению, и к концу курса я уже сам все изучал в практическом программировании, институт лишь подкидывать задачи по алгоритмам. И насколько я знаю из моей группы больше никто не пошел дальше (по крайней мере в проф.деятельность). Небыло бы удобного гуя - и меня бы это не заинтересовало, торговал бы сейчас китайским товаром или стоял в цехе за станком. А главное в институте - не научить алгоритмам, а научить учиться дальше, подтолкнуть и вызвать резонанс, дальше учащийся уже сам попрет. Программированием можно заниматься "для себя" когда задача интересная или ее делать интересно. Кому интересны академические задачи? 99% нужны чтобы сделать, сдать лабу и забыть.
Банальные алгоритмы заполнения матриц и операций над ними гораздо привлекательней выглядят в GUI, а не в архаичной консоли и выводом в тестовый файл

Цитата korvin @ 04.01.14, 08:53

Какой программы? Ты же про алгоритмы говорил.

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

Цитата antonn @ 04.01.14, 09:37

Программированием можно заниматься "для себя" когда задача интересная или ее делать интересно. Кому интересны академические задачи? 99% нужны чтобы сделать, сдать лабу и забыть.
Банальные алгоритмы заполнения матриц и операций над ними гораздо привлекательней выглядят в GUI, а не в архаичной консоли и выводом в тестовый файл

Согласен, но гуй тут не обязателен, мне в свое время было интересно рисовать всякие картинки или графики функций еще на БК-0010 в бейсике. Вполне себе без гуя. Матрицы с выводом в консоль конечно скучные, но не из-за того что нет гуя, а просто потому что это скучно. Так что вопрос просто стоит в том, чтобы было интересно, а не чтобы был гуй. Ну и чтобы была обратная связь какая-то, так что мозг как замена машине, которая выполняет твои команды - не пойдет.

Сообщение отредактировано: --Ins-- - 04.01.14, 10:04

Цитата

Согласен, но гуй тут не обязателен, мне в свое время было интересно рисовать всякие картинки или графики функций еще на БК-0010 в бейсике. Вполне себе без гуя. Матрицы с выводом в консоль конечно скучные, но не из-за того что нет гуя, а просто потому что это скучно. Так что вопрос просто стоит в том, чтобы было интересно, а не чтобы был гуй

наверное потому что ничего особо круче у тебя не было в то время?
а я в школе на бейсике рисовал кораблики выводя картинки через битовые маски (не помню точно как, но в тетрадке рисовали по клеточкам картинки и деля на блоки 8*8 пикселей вычисляли байты, которыми картинка задавалась). И мне это было очень интересно, просто потому что у меня дома даже телика не было и ничего круче утюга и МК-54 (для которого небыло инструкций и игры из МК на нем не все можно было забить). Очень вряд ли что сейчас у меня будет желание этим заняться
а интерес напрямую зависит от наглядности и удобства (ну и получения результата, конечно). Гуем проще и наглядно показать, и удобств добавить (особенно в дельфи с визуальным редактором - накидал компонент, настроил, скомпилил - окно сразу работает, остается лишь заняться логикой).
Тем более, что 13 лет назад стояли CRT, которые еще более менее держали развертку в винде (ну 98-я была), а в "досе" - глаза вылезают уже через 15 минут...

Цитата antonn @ 04.01.14, 10:12

наверное потому что ничего особо круче у тебя не было в то время?

Ну допустим, но вот еще пример: ты же дельфист, Юрия Зотова должен знать. Слышал его историю как он в кружке программистов в школе обучал 10-тилеток программировать игры для калькуляторов? Это уже было во времена распространения PC, тем не менее детям было интересно. Представь себе мальчика, у которого еле макушка над партой торчит, который рассказывает как он взял данные из такого-то регистра, перенес их в такой, затем выполнил эту команду, причем рассказывает явно понимая что говорит, т.к. он в самом деле это сам сделал

Сообщение отредактировано: --Ins-- - 04.01.14, 10:50

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

Прям в тему обучения и паскаля
http://govnokod.ru/14314

Сейчас интереснее хвастаться перед одноклассниками калькулятором под Android, а не под консоль.

Цитата Мяут-Настоящий @ 04.01.14, 13:44

Прям в тему обучения и паскаля

Цитата

C++ (1340)
Pascal (359)

И не говори

--Ins--, ну плюсы значительно чаще юзаются, так что это нормально

Цитата --Ins-- @ 04.01.14, 10:03

мне в свое время было интересно рисовать всякие картинки или графики функций еще на БК-0010 в бейсике.

Кому поржать? Думал запостить пару ностальгических скриншотов результатов своих подобных Турбо-Бэйсиковых поделий. Пишет, мол, overflow. Давай разбираться, включил трассировку... выбил виндовый видео-драйвер. Без малого дело резетом не кончилось, кое-как ребутнулся с принудительным логоффом троих пользователей из-под fast user switch.
Не буду скрины выкладывать, ну их.

Цитата --Ins-- @ 03.01.14, 10:42

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

Ага, очень "удобно", чтобы задекларировать какое-то приватное поле - лезть в интерфейс, потом возвращаться назад. Это так дико распыляет внимание, что я несказанно доволен, что больше не должен от этого страдать. А современная ИДЕ вполне может справиться с отображением интерфейса класса/модуля. Окно Outline очень удобно в Эклипсе. В Дельфях тоже есть что-то подобное, но оно недоразвитое какое-то, пользоваться нереально.

Цитата [S]mike @ 04.01.14, 18:26

Ага, очень "удобно", чтобы задекларировать какое-то приватное поле - лезть в интерфейс, потом возвращаться назад. Это так дико распыляет внимание, что я несказанно доволен, что больше не должен от этого страдать.

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

Цитата Мяут-Настоящий @ 04.01.14, 08:26

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

Как правило решение задач самостоятельно ознакамливает с многими новыми вещами и с алголритмами в том числе.

Цитата Мяут-Настоящий @ 04.01.14, 08:26

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

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

Цитата D_KEY @ 04.01.14, 19:26

Скорее всего, код чаще читаю, чем пишу.

О чем тогда спорим?

Цитата [S]mike @ 04.01.14, 18:26

Цитата --Ins-- @ 03.01.14, 10:42

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

Ага, очень "удобно", чтобы задекларировать какое-то приватное поле - лезть в интерфейс, потом возвращаться назад. Это так дико распыляет внимание, что я несказанно доволен, что больше не должен от этого страдать. А современная ИДЕ вполне может справиться с отображением интерфейса класса/модуля. Окно Outline очень удобно в Эклипсе. В Дельфях тоже есть что-то подобное, но оно недоразвитое какое-то, пользоваться нереально.

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

Цитата Wound @ 04.01.14, 23:18

Как правило решение задач самостоятельно ознакамливает с многими новыми вещами и с алголритмами в том числе.

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

Цитата Wound @ 04.01.14, 23:18

Обычно чужой код унылый, в большинстве своем.

Ну так я и не призывал читать плохой код.

Цитата [S]mike @ 04.01.14, 23:28

Цитата D_KEY @ 04.01.14, 19:26

Скорее всего, код чаще читаю, чем пишу.

О чем тогда спорим?

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

Добавлено 05.01.14, 10:38
Надо бы это как-то замерить...

Цитата --Ins-- @ 04.01.14, 09:09

Цель - чисто визуальное отделение объявлений и заголовков от реализации для лучшей читаемости кода.

Т.е. то, что в части реализации могут быть объявлены приватные переменные, типы, процедуры и т.д. тебя не смущает?

Добавлено 05.01.14, 11:28

Цитата OpenGL @ 04.01.14, 09:53

обучаясь реализовывать алгоритмы.

При изучении алгоритмов, не учат их реализовывать.

Цитата korvin @ 05.01.14, 11:28

Цитата OpenGL @ 04.01.14, 09:53

обучаясь реализовывать алгоритмы.

При изучении алгоритмов, не учат их реализовывать.

Что? Не обращают внимание на детали, да. Но простая реализация на практических занятиях обычно требуется.

Цитата korvin @ 05.01.14, 11:28

При изучении алгоритмов, не учат их реализовывать.

Тогда толку от такого обучения будет немного.

Цитата --Ins-- @ 05.01.14, 06:41

А, ну это ты просто иде пользоваться не умеешь, иначе бы знал, что это можно делать не подымаясь наверх

Это ты про Introduce Field в рефакторинге? Смешно. В диалоге даже нету возможности указать тип переменной, что он там "угадает" - никому непонятно. В Эклипсе для всех джава рефакторингов есть превью, кстати.

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

Цитата D_KEY @ 05.01.14, 10:37

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

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

А как в новом или развивающемся проекте без написания нового кода?

Цитата [S]mike @ 05.01.14, 12:53

Цитата D_KEY @ 05.01.14, 10:37

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

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

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

Добавлено 05.01.14, 18:16

Цитата

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

Оно может и удобно при написании кода, но вот при чтении... Не знаю. В общем, в возможности отделения объявлений от определений я вижу только достоинства, а вот недостатки(дублирование, например) вполне компенсируют средства IDE. Я кстати, так и не понял твой пример... По мне так проще переключиться на объявление класса(без реализации), добавить поле и вернуться к тому же месту реализации, где ты остановился, чем искать в единой портянке место для поля...

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

Цитата D_KEY @ 05.01.14, 18:08

Так даже этот новый код ты читать будешь больше, чем писать, нет?

Дык, ты же просматриваешь новые строчки и соседние, а не весь код.
Мне нравится вывод diff на втором мониторе...

Цитата D_KEY @ 05.01.14, 18:08

А еще я уверен, что если бы в Яве так можно было делать, то люди бы так и делали

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

Цитата [S]mike @ 05.01.14, 23:21

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

Не для линковки, а для компилятора, ибо язык требует объявления всех используемых сущностей.

Цитата [S]mike @ 05.01.14, 23:21

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

Эта фича ортогональна разделению объявления и реализации.

Читал статью, в которой сам Вирт позиционировал паскаль как язык для демонстрации современных (на момент его создания) методов программирования.

Это:

• описанные Дейкстрой принципы структурного программирования;
• описанные им же методы доказательства правильности программ (инварианты и т.п.);
• структуры данных (включая работу с динамической памятью);
• демонстрация работы достаточно сложных алгоритмов манипулирования данными;

При этом к языку предъявлялись

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

Существующие языки этим требованиям не удовлетворяли, поэтому Вирт и взялся за разработку нового языка и компилятора для него.
В принципе этим требования лучше отвечал бы какой-нибудь интерпретируемый язык, но тут Вирт похоже дал слабину, надеясь, что паскаль может пригодиться и в промышленном программировании (например для написания простых программ). Или может быть у него было какое-то предубеждение против интерпретаторов - может он думал, что работа с интерпретатором как-то расслабит студентов (вроде именно это было главным фактором).
Так и родился язык, почти не допускающий эффективной компиляции, имеющий слабенькую библиотеку, который тем не менее благодаря простоте и возможности создания исполняемых файлов занял довольно большую долю в разработке ПО.
Для промышленного программирования Вирт позднее разработал семейство похожих на паскаль (видимо в расчёте, что студенты пересядут на них с учебного паскаля) "модул". Позднее он перешёл к ним и в учебном процессе.
Однако модулы, хоть и были заметно развитее Паскаля, тоже оказались в каком-то смысле ущербными (в частности, их невозможно оказалось совмещать с другими языками, с тем же фортраном, на котором к тому времени было написано множество библиотек).

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Цитата amk @ 07.01.14, 20:29

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Только Вирт не имел никакого отношения к turbo pascal, к моменту появления которого(первой версии) у него уже была Модула-2.

amk

Цитата amk @ 07.01.14, 20:29

Кстати, Turbo-Pascal 5.5 уже был ОО языком, хотя, похоже, почти никто его ОО-возможностями не пользовался.

Borland удачно продавал Visio библиотеку.

Цитата Pavia @ 08.01.14, 16:06

Borland удачно продавал Visio библиотеку.

TurboVision. Visio - это совсем другое и от Microsoft.

Сообщение отредактировано: trainer - 09.01.14, 08:29

Наверное, имелся в виду Turbo Vision

Все-таки, мне кажется, что не Visio, а Turbo Vision...

Вот заладили, ес-но Турбо Визион.

Цитата Суровый @ 10.01.14, 09:33

Вот заладили, ес-но Турбо Визион.

правда что-ли?

вот и я говорю, Turbo Vision

В колледже был турбопаскаль 7.1 кажется. Ненавижу это время! Можно сказать, велосипеды мастерили кувалдами.

Цитата AVA12 @ 01.01.14, 16:44

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

Ну значит смело можно начинать с С++... потому что сейчас куда ни плюнь - везде java/php/C# В особо тяжелых случаях - 1С. А С++ хорошо раскрывает парадигму ООП, и при этом куда больше оторван от реалий, чем Паскаль - что для обучения полезно.

Хотя согласен с Мяутом - питон был бы ещё лучше, но мне пока никак не удаётся его протащить в РПД.

Цитата Dark_Sup @ 10.01.14, 10:17

и при этом куда больше оторван от реалий, чем Паскаль

Хорошая шутка

В детстве мне притащили 80386-ой канпик с ms-dos и turbo pascal 6.0. На нем и начал писать программки. Никакого неприятного осадка насчет паскаля не осталось, зла на него не держу. Про C и C++ узнал потом, далеко не сразу. Как и все, думал, что это один язык:)

Сообщение отредактировано: reinterpret_alexey - 27.01.14, 09:51

Цитата Keepun @ 03.01.14, 19:27

За невозможность создавать нормальный ГУЙ в 2002г. на ТР 7 я своего учителя на Паскале вспоминаю... не добрым словом... год жизни в пустую...

Turbo Vision - псевдографический GUI
Super Vision - настоящая графика, VESA-режимы были

Цитата AVA12 @ 01.01.14, 18:11

Цитата

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

Все не так однозначно,

зачем складывать п раз? Достаточно один раз к логарифму м прибавить логарифм п

"Пап, а как пишется цифра восемь? - Так же, как бесконечность, только повернутая на пи пополам"

Цитата Dark_Sup @ 10.01.14, 10:17

Хотя согласен с Мяутом - питон был бы ещё лучше, но мне пока никак не удаётся его протащить в РПД.

он не type safety, для начинающих это не гуд,

Цитата sergioK @ 29.01.14, 16:14

Цитата Dark_Sup @ 10.01.14, 10:17

Хотя согласен с Мяутом - питон был бы ещё лучше, но мне пока никак не удаётся его протащить в РПД.

он не type safety, для начинающих это не гуд,

Вы перепутали. Питон является dynamic typed language, но с type safity у него не так все плохо.

Цитата D_KEY @ 29.01.14, 19:40

Цитата sergioK @ 29.01.14, 16:14

Цитата Dark_Sup @ 10.01.14, 10:17

Хотя согласен с Мяутом - питон был бы ещё лучше, но мне пока никак не удаётся его протащить в РПД.

он не type safety, для начинающих это не гуд,

Вы перепутали. Питон является dynamic typed language, но с type safity у него не так все плохо.

В нем не надо прописывать тип переменной , не так важно как это называеться ,
или уже не так ?

Почему не начинать учить с Си Я не очень понимаю ,

Сообщение отредактировано: sergioK - 29.01.14, 21:06

Цитата sergioK @ 29.01.14, 20:40

В нем не надо прописывать тип переменной , не так важно как это называеться ,
или уже не так ?

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

Цитата sergioK @ 29.01.14, 20:40

В нем не надо прописывать тип переменной , не так важно как это называеться ,
или уже не так ?

Почему не начинать учить с Си Я не очень понимаю ,

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

Цитата Мяут-Настоящий @ 30.01.14, 07:20

Цитата sergioK @ 29.01.14, 20:40

В нем не надо прописывать тип переменной , не так важно как это называеться ,
или уже не так ?

Почему не начинать учить с Си Я не очень понимаю ,

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

Меня учили писать грамотный код
А что как называеться я могу и не помнить,
си дает понимание того что под капотом.

Цитата sergioK @ 30.01.14, 17:55

Меня учили писать грамотный код

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

Цитата sergioK @ 30.01.14, 17:55

си дает понимание того что под капотом.

Могут ли курсы автомехаников научить физике?

Цитата Мяут-Настоящий @ 30.01.14, 19:16

Цитата sergioK @ 30.01.14, 17:55

си дает понимание того что под капотом.

Могут ли курсы автомехаников научить физике?

научить нет времени мало, дать понятие можно, если студент увидит в дебаге как выглядит память,
и сам напишет/прочувствует что такое *(a+i) или swap(&a,&b) ничего плохого будет,

Цитата sergioK @ 31.01.14, 15:19

научить нет времени мало

Цитата sergioK @ 31.01.14, 15:19

ничего плохого будет

=))) Думаю, sergioK пора сменить учебник по C/++ на учебник по русскому языку. =)

UncleBob, это видимо он написал песню "денег мало длинный шмель."

Добавлено 07.02.14, 07:23

Цитата korvin @ 31.01.14, 20:17

=))) Думаю, sergioK пора сменить учебник по C/++ на учебник по русскому языку. =)

Или не ему, а создателям гугл-переводчика. Впрочем, они его кажется и так штудируют днём и ночью, просто офигевают от его неформализуемой красоты.

Имел дело с бейсиком(Q-, Sinclair-, Visual-), паскалем (Turbo-, Delphi, немного Free-), 1С, С, С++, php и рядом командных, редких и узкоспециализированных. Ни за что не скажу, что паскаль - плох. Ни в абсолюте, не относительно.

Самый ад - это бейсик, в любой его интерпретации. Не, на нём можно что-то делать, но от его идеологий порой мозг скрипит. 1С - по сути, наследник бейсика: что-то почищено, но многое - оставили. Паскаль и пых - норм языки если ты не пытаешься пилить на них что-то, для чего они не предназначены. Учиться на паскале можно - там не нужно сразу нырять с головой в работу с памятью как в С и он не заставляет извращаться как, порой, VB. PHP - мог-бы, но его надо чистить от бредятины, доставшейся в наследство от старых версий. Си - если начинать с него, то ты либо станешь его адептом до конца жизни, либо просто возненавидишь программирование. С плюсами наверное тоже самое, хоть и не так категорично.

По сабжу у меня сложилось мнение, что паскаль/делфи ненавидят в основном сишники (в т.ч. и бывшие) и делают они это чаще всего потому что это делают другие сишники, при этом сами, порой, с сабжем никогда и не сталкивались. Особенно хорошо это было заметно при популяризации С# когда переметнувшиеся на него плюсовики вдруг стали хвалить всё, что раньше ругали (и продолжают ругать) в Делфи.

Сообщение отредактировано: Dark Side - 13.02.14, 03:11

А можно пример того, что хвалят в шарпе и ругают в делфи?

Отсутствие множественного наследования реализаций

Не помню уже толком, что-то на тему кнопкокидательства_на_форму.

Добавлено 13.02.14, 16:28
Ещё помню претензии к паскалю, что там объявлять переменные можно только в начале, а в С - где угодно. Каково-же было моё удивление, когда вдруг в одном опенсорсном проекте gcc (хоть и определённым образом настроенный через makefile) вдруг послал меня с этим "где угодно" далеко и надолго.

Сообщение отредактировано: Dark Side - 13.02.14, 16:28

Цитата Dark Side @ 13.02.14, 16:22

Каково-же было моё удивление, когда вдруг в одном опенсорсном проекте gcc (хоть и определённым образом настроенный через makefile) вдруг послал меня с этим "где угодно" далеко и надолго.

Старые версии Си требовали объявлений в начала блока, т.е. разница с паскалем все-равно была.

Воплей во время холиваров всегда было больше чем разницы. Хотя это нормально.

Цитата D_KEY @ 13.02.14, 07:46

А можно пример того, что хвалят в шарпе и ругают в делфи?

В том что это Борланд , который продавать не умеет

Цитата Qraizer @ 13.02.14, 13:02

Отсутствие множественного наследования реализаций

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

Цитата Mr.Delphist @ 14.02.14, 09:02

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

Ну примеси и подобные вещи: http://en.wikipedia.org/wiki/Mixin - довольно удобны.

А после этого они тоже говорят, мол, множественное наследование не нужно?

Цитата Qraizer @ 14.02.14, 14:02

А после этого они тоже говорят, мол, множественное наследование не нужно?

Множественное наследование - не нужно.

Добавлено 14.02.14, 17:46
На самом деле, примеси - это не попытка обойти запрет на множественное наследование. Это лучше, чем множественное наследование. И отсутствие примесей в C++ - существенный недостаток.

Сообщение отредактировано: applegame - 14.02.14, 17:46

Цитата applegame @ 14.02.14, 17:39

примеси - это не попытка обойти запрет на множественное наследование
...
отсутствие примесей в C++ - существенный недостаток.

Потрясающая логика В C++ не стали запрещать множественное наследование, потому миксины, как отдельная конструкция, там не нужны. То же касается и интерфейсов.

Добавлено 14.02.14, 18:27

Цитата applegame @ 14.02.14, 17:39

лучше, чем множественное наследование

Чем?

Сообщение отредактировано: D_KEY - 14.02.14, 18:52

Цитата applegame @ 14.02.14, 17:39

На самом деле, примеси - это не попытка обойти запрет на множественное наследование.

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

applegame, простое - тоже.

Цитата D_KEY @ 14.02.14, 18:26

Чем?

Цитата korvin @ 14.02.14, 20:28

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

Миксины не встраиваются в иерархию классов. Никаких вам неопределенных ромбиков и лишних сущностей.
Например, посмотрим на бустовские интрузивные контейнеры. Чтобы класс мог быть элементом интрузивного контейнера его приходится наследовать от специальных классов, нужных только чтобы добавить несколько членов. Можно конечно и руками вписать нужные элементы, но это как-то совсем уже крайний случай. А если один класс должен быть в нескольких контейнерах? Да еще могут быть применены различные стратегии. В итоге иерархия засирается кучей коротких веток, которым там делать явно нечего. Миксины идеально подходят для этой задачи. Разница, скорее эстетическая, чем практическая, тем не менее.

Цитата applegame @ 15.02.14, 06:28

Никаких вам неопределенных ромбиков и лишних сущностей.

И что будет, если включить в класс два миксина с одинаковыми методами?

Цитата korvin @ 15.02.14, 06:47

И что будет, если включить в класс два миксина с одинаковыми методами?

Зависит от языка. В D это решается указанием идентификатора при подмешивании. После чего можно уточнить вызываемый метод применяя соответствующий идентификатор.

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

Цитата applegame @ 15.02.14, 06:28

Никаких вам неопределенных ромбиков и лишних сущностей.

Неопределённых ромбиков и лишних сущностей не существует. Вам наврали.

Цитата D_KEY @ 15.02.14, 09:20

applegame, если у нас есть механизм наследования, который способен решить все эти задачи, то зачем нам вводить лишние сущности в виде отдельного механизма интерфейсов и отдельного механизма миксинов, да еще и наследование при этом оставлять, только функциональность обрезать?

Универсальное зачастую хуже специализированного. Особенно когда самая главная функциональность практически не востребована.

Цитата D_KEY @ 15.02.14, 09:20

И ты еще что-то заявляешь о лишних сущностях?

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

Цитата Qraizer @ 15.02.14, 11:39

Неопределённых ромбиков и лишних сущностей не существует. Вам наврали.

Существует еще как. Правда C++ решил их своим излюбленным методом - костылями.

Сообщение отредактировано: applegame - 15.02.14, 11:42

Цитата applegame @ 15.02.14, 11:40

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

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

Добавлено 15.02.14, 13:14

Цитата applegame @ 15.02.14, 11:40

Правда C++ решил их своим излюбленным методом - костылями.

Аргументировано.

Цитата D_KEY @ 13.02.14, 16:34

Старые версии Си требовали объявлений в начала блока, т.е. разница с паскалем все-равно была.

Также старые версии требовали локальные объявления с инициализацией размещать после объявлений.
Так правильно:

int a;
int b = 0;

А так - ошибка:

int a = 0;
int b;

Добавлено 15.02.14, 14:48

Цитата applegame @ 15.02.14, 11:40

Лишние сущности - это гусеницы на самолете.

Сообщение отредактировано: trainer - 15.02.14, 14:49

trainer, на самом деле и так и так правильно, и все соответствующие стандарту (описанию) языка компиляторы оба примера компилировали без проблем. Другое дело, что некоторые из них накладывали разные ограничения, например, при использовании goto или switch не в любом блоке можно было разместить объявление.

Цитата applegame @ 15.02.14, 11:40

Существует еще как. Правда C++ решил их своим излюбленным методом - костылями.

Ты повёлся на маркетинговый мусор под ковром. Приведи пример существующей проблемы, я докажу, что тебе наврали.

Добавлено 15.02.14, 18:51
P.S. Заявить о вредности множественного наследования реализаций и объяснить его отсутствие в своём языке заботой о нас-таких-блин-бедных - это излюбленный троллинг горемык от маркетинга. Если нам не надо, мы просто не будем пользовать. А вот если надо, а его нет, тогда на помощь приходят костыли типа примесей, агрегатов с делегатами и прочими кротовыми норами, заполненными вакуумом с отрицательной плотностью энергии, лишь бы мы-такие-блин-бедные смогли-таки решить нашу задачу без мата в адрес маркетологов, и не дай бог эта задача не оказалась последней, решаемой нами-такими-блин-бедными на чудо-языке-всём-из-себя-удобном. И мало у кого мозги к этому времени не оказываются промытыми до такой степени, чтобы сообразить, что обычно задача диктует архитектуру, которую уже программист должен имеющимися средствами реализовать, а не наоборот - подгонять архитектуру под имеющиеся средства, лишь бы решить задачу.

Цитата Qraizer @ 15.02.14, 18:41

Добавлено 15.02.14, 18:51
P.S. Заявить о вредности множественного наследования реализаций и объяснить его отсутствие в своём языке заботой о нас-таких-блин-бедных - это излюбленный троллинг горемык от маркетинга. Если нам не надо, мы просто не будем пользовать.

+10000,
Эти самые маркетологи говорят множественное наследование плохо - потому что есть проблема
в том что один и тот же метод ,но с разной сигнатурой может оказаться в разных классах,
и код не скомпилируеться,
Да она есть, но в интерфейсах проблема точно такая же ,

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

Цитата sergioK @ 15.02.14, 21:11

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

Нет, они, в основном, говорят, что множественное наследование плохо из-за проблемы ромба. А ее в интерфейсах нет.

Да ладно вам, узбагойдесь. Тема о паскакале

И часто разработчикам приходится сталкиваться с этим ромбом? Лично мне ни разу не захотелось так наследование организовать.

В любом случае, Qraizer прав. Это не проблема и не недостаток. Просто нужно принять то или иное решение. Возможно, что, например, в Eiffel(где ромб можно разруливать не только по классам, но и по полям, а так же решение принимается итоговым классом, а не промежуточными) это сделано лучше, чем в C++, не знаю, не использовал Eiffel на практике. Некоторые языки с множественным наследованием, такие как Питон и Scala(для trait'ов) просто линеаризуют иерархию. Возможно, это так же является более простым решением и лучшим компромиссом, чем у C++. Но вот именно для C++ подход с делением на обычное и виртуальное наследованием является самым органичным, поскольку соответствует принципу нулевой стоимости, не приводит к преждевременной пессимизации и позволяет управлять ситуацией как вздумается... Отказ же от множественного наследования привел бы к появлению интерфейсов и отдельного механизма миксинов/делегатов, что я плохо себе представляю в контексте остальных возможностей языка. Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Цитата D_KEY @ 16.02.14, 13:30

Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Что значит отказались ?
Что и кто мешает его применять, там где считаешь нужным разумееться ?

Цитата sergioK @ 16.02.14, 17:38

Цитата D_KEY @ 16.02.14, 13:30

Делегирование, кстати, в С++ рассматривали, но отказались в пользу множественного наследования...

Что значит отказались ?
Что и кто мешает его применять, там где считаешь нужным разумееться ?

Я имею в виду специальный языковой механизм делегирования, который когда-то предлагался:

class B {
    int b;
    void f();
};
 
class C : *p {
    B *p;
    int c;
};

void f(C *q)
{
    q->f(); // означает q->p->f()
}

Угу.

Цитата

...
Концепция выглядела многообещающей для представления структур, требующих большей гибкости, чем может дать обычное наследование. В частности, присваивание делегирующему указателю могло бы использоваться для изменения конфигурации объекта во время выполнения. Реализация была тривиальной, затраты - минимальными. Поэтому данную идею испытали несколько пользователей.
Много времени и сил здесь положил Билл Хопкинс (Bill Hopkins). К сожалению, все пользователи, применившие механизм делегирования, пострадали от серьезных ошибок и путаницы. Из-за этого возможность была исключена как из проекта, так и из Cfront версии 2.0.
Причины ошибок:

• функции в делегирующем классе не замещают функции в классе, которому операция делегируется;
• функция, которой передается управление, не может воспользоваться функциями из делегирующего класса или каким-то иным способом «вернуться» в делегирующий объект.

Ясно, что две эти проблемы взаимосвязаны. Разумеется, пользователи были предупреждены. Предостережения не помогли. Более того, я сам забыл собственные правила и попался в ловушку. Таким образом, проблему нельзя было назвать мелким огрехом, который исправляется с помощью обучения и предупреждений компилятора. В то время она казалась непреодолимой.
Сегодня мне кажется, что указанные проблемы имеют фундаментальный характер. Для решения первой потребовалось бы изменять таблицу виртуальных функций объекта, которому делегируется управление, если он связан с делегирующим объектом. Это плохо согласуется с языком в целом и с большим трудом поддается разумному определению. Кроме того, обнаружились примеры, когда мы хотели, чтобы два разных объекта делегировали управление одному и тому же «разделяемому» объекту. Нашлись и такие задачи, в которых нужно было делегировать управление через В* объекту производного класса D.
...

Сообщение отредактировано: Qraizer - 16.02.14, 18:43

Цитата Qraizer @ 16.02.14, 18:41

Цитата

Причины ошибок:

• функции в делегирующем классе не замещают функции в классе, которому операция делегируется;
• функция, которой передается управление, не может воспользоваться функциями из делегирующего класса или каким-то иным способом «вернуться» в делегирующий объект.

Ясно, что две эти проблемы взаимосвязаны. Разумеется, пользователи были предупреждены. Предостережения не помогли. Более того, я сам забыл собственные правила и попался в ловушку. Таким образом, проблему нельзя было назвать мелким огрехом, который исправляется с помощью обучения и предупреждений компилятора. В то время она казалась непреодолимой.
Сегодня мне кажется, что указанные проблемы имеют фундаментальный характер.

Это такие же «проблемы», как и проблема множественного наследования.

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

Добавлено 17.02.14, 12:29
P.S. Покажите на Дельфях код, который влёгкую меняет делегируемый объект в рантайм или разделяет его с кучей себе подобных.

Добавлено 17.02.14, 12:33
P.P.S. Ах да, ещё было бы интересно как Дельфи справится вот с этой задачей, на которую я уже ссылался в соседней теме. Напомню суть, чтоб много не читать. Там есть интерфейс, есть его готовая реализация, и есть расширение интерфейса. Хочется увидеть класс, реализующий новую версию интерфейса, но при этом пользующийся уже готовой реализацией его старой версии. Доп.условие: ни старый интерфейс, ни его реализация не курсе о новой версии вообще никак.

Добавлено 17.02.14, 12:37
P.P.P.S. Два доп.условия: наш класс при этом "является" реализацией старой версии интерфейса.

Сообщение отредактировано: Qraizer - 17.02.14, 12:37

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

Что, наследование - это плохо, да?

Цитата D_KEY @ 17.02.14, 15:57

Что, наследование - это плохо, да?

Местами да, плохо.

type
  IA = interface
    procedure A;
  end;
 
type
  TA = class(TInterfacedObject,IA)
    procedure A;
  end;
 
type
  IB = interface(IA)
    procedure B;
  end;
 
type
  TB = class(TA,IB)
    procedure B;
  end;

в чём подвох?

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

Цитата applegame @ 17.02.14, 16:03

Цитата D_KEY @ 17.02.14, 15:57

Что, наследование - это плохо, да?

Местами да, плохо.

Местами плохо все

Цитата D_KEY @ 17.02.14, 15:57

Что, наследование - это плохо, да?

Я этого не говорил.

Shaggy, и никаких warnings?

Цитата korvin @ 17.02.14, 18:28

Цитата D_KEY @ 17.02.14, 15:57

Что, наследование - это плохо, да?

Я этого не говорил.

Тогда я не понял, что ты имел в виду.

Добавлено 17.02.14, 18:36

Цитата amk @ 17.02.14, 16:58

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

В питоне происходит линеаризация иерархии, если что.

Цитата D_KEY @ 17.02.14, 18:33

Тогда я не понял, что ты имел в виду.

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

Так вот кто придумал дюбель-гвозди с резьбой!

Цитата Qraizer @ 17.02.14, 18:29

Shaggy, и никаких warnings?

нет, с чего бы?

Ну как же, ведь TB реализует IB не полностью. В Плюсах аналогичная картина, и не все компилеры при этом варнингуют.

Цитата Qraizer @ 18.02.14, 12:03

Ну как же, ведь TB реализует IB не полностью

Реализует то он как раз полностью. В плюсах это было бы реализацией коцепта - концепт IB тип TB реализует.
В шарпе тоже в таком случае всё отлично.

Цитата Qraizer @ 18.02.14, 12:03

В Плюсах аналогичная картина, и не все компилеры при этом варнингуют

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

Цитата Qraizer @ 18.02.14, 12:03

Ну как же, ведь TB реализует IB не полностью

интерфейс требует наличия в классе двух методов
класс их предоставляет
сигнатуры совпадают
больше ничего не требуется

Цитата MyNameIsIgor @ 18.02.14, 12:16

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

Вот это кстати да. В Дельфях это, пожалуй, не нужно. Интерфейс суть однозначно интерфейс.
Shaggy, то же и в Плюсах, сходи по ссылке. Однако в отличие от, не всё так однозначно. По ссылке автор напутал с виртуальным и невиртуальным наследованием, просто сделав по шаблону из литератур, авторов которых за неполноту раскрытия темы следовало бы линейкой по рукам. Результатом сего компилятор смутился и, несмотря на корректный достигнутый результат, заявил о своём смущении.

Добавлено 18.02.14, 12:58
Ну ладно, а если мы возьмём две реализации двух интерфейсов? Нужно будет агрегировать или сводить к единому предку?

Цитата Qraizer @ 18.02.14, 12:57

Ну ладно, а если мы возьмём две реализации двух интерфейсов? Нужно будет агрегировать или сводить к единому предку?

например так:

type
 IA = interface
   procedure A;
 end;
 
type
 TA = class(TInterfacedObject,IA)
   procedure A;
 end;
 
type
 IB = interface
   procedure B;
 end;
 
type
 TB = class(TInterfacedObject,IB)
   procedure B;
 end;
 
 
 type
   TC = class(TInterfacedObject,IA,IB)
     private
       FA:IA;
       FB:IB;
 
       property A:IA read FA implements IA;
       property B:IB read FB implements IB;
   end;

но объединить интерфейсы нельзя
конструкция

type
  IC = interface(IA,IB)
  ...
  end;

недопустима

Цитата Shaggy @ 18.02.14, 14:18

но объединить интерфейсы нельзя

Что ж так? Во всех остальных языках с интерфейсами — можно.

Цитата D_KEY @ 17.02.14, 18:33

В питоне происходит линеаризация иерархии, если что.

Линеаризация линеаризацией, но как бы ты выкарабкивался, если бы память объекта базового класса была частью памяти унаследованного? В результате с линеаризацией или без у тебя всё равно оставалась бы проблема двух экземпляров класса в вершине ромба. В C++ она худо-бедно решается виртуальным наследованием, в питоне всё наследование получается виртуальным, поэтому нет хотя бы этой части проблемы. Плюс днамическая утиная типизация, благодаря чему нет необходимости преобразовывать ссылки к ссылкам на базовый тип.

Зачем вообще привлекать терминологию c++? В Питоне нет обычного и виртуального наследования, как это понимается в c++. Проблема ромба просто устраняется за счёт линеаризации.

Цитата korvin @ 18.02.14, 14:36

Что ж так?

а зачем?

Цитата Shaggy @ 18.02.14, 14:18

например так:

Т.е. всё-таки агрегировать... досадно.

Цитата Shaggy @ 18.02.14, 18:08

а зачем?

А как ты в типе параметра метода указываешь, что он должен удовлетворять нескольким интерфейсам? Т.е. например

interface ReadWriter extends Reader, Writer {}
 
...
public void someMethod(ReadWriter x) { ... }

Цитата D_KEY @ 16.02.14, 13:30

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

Я-таки нашёл свой эксперимент.

Внимание! предупреждаю:

struct NullType {};
 
template <typename L, bool V, typename R>                       struct TList;
template <typename T, bool V1, typename L, typename R, bool V2> struct TList<T, V1, TList<L, V2, R> >
{
  typedef T               Head;
  typedef TList<L, V2, R> Tail;
};
template <typename T, bool V>                                   struct TList<T, V, NullType>
{
  typedef T        Head;
  typedef NullType Tail;
};
template <typename T, bool V1, typename L, typename R, bool V2> struct TList<TList<L, V2, R>, V1, T>;
template <typename T, bool V>                                   struct TList<NullType, V, T>;
 
template <typename T, size_t N>                     struct GetType;
template <typename L, bool V, typename R, size_t N> struct GetType<TList<L, V, R>, N>
{
  typedef typename GetType<R, N-1>::result result;
};
template <typename L, bool V, typename R>           struct GetType<TList<L, V, R>, 0>
{
  typedef L result;
};
 
template <typename T, size_t I> struct Item { T node; Item(): node(T()) {} };
 
template <typename T, size_t N, typename Z>             struct GenHierarchy;
template <typename L, typename R, size_t N, typename Z> struct GenHierarchy<TList<L, false, R>, N, Z> :
                                                             Item<L, N>, GenHierarchy<R, N+1, Z>
{
};
template <typename L, typename R, size_t N, typename Z> struct GenHierarchy<TList<L, true,  R>, N, Z> :
                                                     virtual Item<L, N>, GenHierarchy<R, N+1, Z>
{
};
template <typename L, size_t N, typename Z>             struct GenHierarchy<TList<L, false, NullType>, N, Z> :
                                                     Item<L, N>, virtual GenHierarchy<NullType, N+1, Z>
{
  typedef Z result;
};
template <typename L, size_t N, typename Z>             struct GenHierarchy<TList<L, true,  NullType>, N, Z> :
                                             virtual Item<L, N>, virtual GenHierarchy<NullType, N+1, Z>
{
  typedef Z result;
};
template <size_t N, typename Z>                         struct GenHierarchy<NullType, N, Z> {};
 
template <typename T> struct GenerateTree: GenHierarchy<T, 0, T>
{
  template <size_t I>
  typename GetType<T, I>::result& field()
  {
    return static_cast<Item<typename GetType<T, I>::result, I>&>(*this).node;
  }
};
 
template <size_t I, typename Gen>
typename GetType<typename Gen::result, I>::result& field(Gen& gen)
{
  return static_cast<Item<typename GetType<typename Gen::result, I>::result, I>&>(gen).node;
}

Список типов создаётся так: тип поля (получает номер 0), признак разделения (true/false), следующий элемент списка (поле получит номер на 1 больше) ... или NullType (конец списка). Пример:

typedef TList<int,     false,                                // struct { separated int     0;
        TList<int,     true,                                 //          shared    int     1;
        TList<float,   false,                                //          separated float   2;
        TList<wchar_t, false,                                //          separated wchar_t 3;
        TList<int,     false,                                //          separated int     4;
        TList<float,   true, NullType> > > > > > TypeList;   //          shared    float   5; };

На его основе создаётся тип объекта(ов), который просто используется в качестве базы, когда и где надо. Пример:

struct Right: GenerateTree<TypeList> {};
struct Left : GenerateTree<TypeList> {};
 
struct Tuple: Right, Left {};

Тут в виду прямых множественных предков базы определены разными, но совпадающими типами Right и Left, ибо одинаковые непосредственные базы в Плюсах запрещены. Но хотя бы один будет опосредованным, они могут быть одинаковыми.
Для доступа к совмещаемым полям можно использовать последнюю функцию field<N>(), указав номер поля в N и экземпляр структуры в параметре. Для совмещаемых этого достаточно, однако для отделённых следует заботиться о разрешении неоднозначности и использовать метод GenerateTree<>::field<N>() нашего экземпляра. Пример:

template <typename Dst, typename Src>
Dst& select(Src& src)
{
  return static_cast<Dst&>(src);
}
 
int main()
{
  Tuple tuple;
 
  select<Right>(tuple).field<0>() = 123;
  select<Right>(tuple).field<1>() = 456;
  select<Right>(tuple).field<2>() = 789.147f;
  select<Right>(tuple).field<3>() = L'q';
  select<Right>(tuple).field<4>() = 258;
  select<Right>(tuple).field<5>() = 147.789f;
  select<Left >(tuple).field<0>() = 321;
  select<Left >(tuple).field<1>() = 654;
  select<Left >(tuple).field<2>() = 987.369f;
  select<Left >(tuple).field<3>() = L'Q';
  select<Left >(tuple).field<4>() = 852;
  select<Left >(tuple).field<5>() = 963.987f;
 
  std::wcout<< select<Right>(tuple).field<0>() << '\t'
            << select<Right>(tuple).field<1>() << '\t'
            << select<Right>(tuple).field<2>() << '\t'
            << select<Right>(tuple).field<3>() << '\t'
            << select<Right>(tuple).field<4>() << '\t'
            << select<Right>(tuple).field<5>() << '\n'
            << select<Left >(tuple).field<0>() << '\t'
            << select<Left >(tuple).field<1>() << '\t'
            << select<Left >(tuple).field<2>() << '\t'
            << select<Left >(tuple).field<3>() << '\t'
            << select<Left >(tuple).field<4>() << '\t'
            << select<Left >(tuple).field<5>() << std::endl;
 
  field<1>(tuple) = 456;
  field<5>(tuple) = 147.789f;
 
  std::wcout<< field<1>(tuple) << '\t'
            << field<5>(tuple) << '\n'
            << sizeof tuple    << std::endl;
}

Жёстко, но работает. Но ни разу не понадобилось, нето так долго б не искал.

Цитата korvin @ 19.02.14, 03:51

А как ты в типе параметра метода указываешь, что он должен удовлетворять нескольким интерфейсам?

никак, нет необходимости
все нужные интерфейсы запрашиваются явно

D_KEY, ты же сам решил питон с C++ сравнить. Без деталей реализации сравнение бессмысленно, я и написал, что реализация наследования в питоне слишком отличается от таковой в C++. И попытка реализации в C++ чего-то подобного питоновскому обойдётся слишком дорого.

Сравнение без деталей реализации не бессмысленно, оно показывает разницу подходов и принципов, лежащих в основе языков.

Цитата Shaggy @ 19.02.14, 16:30

все нужные интерфейсы запрашиваются явно

В смысле так:

procedure DoSomething (x: InterfacedObject);
var
  r: Reader;
  w: Writer;
begin
  if not (x is Reader) then Exit;
  if not (x is Writer) then Exit;
  r := x as Reader;
  w := x as Writer;
  ...

что ли?

r:=x as Reader;
 
// или
 
if Supports(x,Reader,r)
then

Ну я так и написал. А если интерфейсов будет больше? Как-то это криво и неудобно.

Цитата korvin @ 20.02.14, 10:33

Ну я так и написал

нет
1. is с интерфейсами не работает
2. даже если бы работала, зачем делать две проверки вместо одной?

Цитата korvin @ 20.02.14, 10:33

А если интерфейсов будет больше? Как-то это криво и неудобно

это такая агитация за "god/magic method"?

Цитата Shaggy @ 20.02.14, 10:58

нет
1. is с интерфейсами не работает

Да не суть важно.

Цитата Shaggy @ 20.02.14, 10:58

2. даже если бы работала, зачем делать две проверки вместо одной?

Т.е. при присваивании

r := x as Reader;

происходит проверка? А если x не реализует Reader, что произойдет? Выброс исключения?

Цитата Shaggy @ 20.02.14, 10:58

это такая агитация за "god/magic method"?

Нет, при чем тут это?

Где тут god'овость?

interface Reader {
    Read(...)
}
 
interface Writer {
    Write(...)
}
 
interface Opener {
    Open() : Error
}
 
interface Closer {
    Close()
}
 
interface OpenReadWriteCloser { Open, Reader, Writer, Closer }
 
procedure DoSomething(x : OpenReadWriteCloser) Error {
    var request, response : Data
    if err := x.Open(); err != nil {
        return err
    }
    delay x.Close()
    x.Read(&request)
    ...
    x.Write(response)
}

Цитата korvin @ 20.02.14, 11:39

происходит проверка? А если x не реализует Reader, что произойдет? Выброс исключения

да
supports возвращает false
а с помощью queryinterface можно и причину узнать
используй что тебе удобнее, но не всё же сразу

Цитата korvin @ 20.02.14, 11:39

Где тут god'овость?

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

korvin, короче, этот is как dynamic_cast<>, только хуже на порядок.

Цитата Shaggy @ 20.02.14, 12:08

используй что тебе удобнее, но не всё же сразу

Спасибо, предпочитаю делать это с помощью системы типов, а не вот такие извращения.

Цитата Shaggy @ 20.02.14, 12:08

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

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

Цитата Qraizer @ 20.02.14, 12:40

короче, этот is как dynamic_cast<>, только хуже на порядок.

s/is/as/ =)

Цитата korvin @ 20.02.14, 13:28

Спасибо, предпочитаю делать это с помощью системы типов, а не вот такие извращения.

пожалуйста
ты привёл громоздкую и не работающую конструкцию. я тебя поправил
зачем так нервничать?

Цитата korvin @ 20.02.14, 13:28

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

эту конструкцию не понял

Цитата Qraizer @ 20.02.14, 12:40

короче, этот is как dynamic_cast<>, только хуже на порядок.

Цитата Shaggy @ 20.02.14, 14:23

ты привёл громоздкую и не работающую конструкцию. я тебя поправил
зачем так нервничать?

Я не про твои поправления, а про систему типов Делфи.

Цитата Shaggy @ 20.02.14, 14:23

эту конструкцию не понял

Ну я-то сейчас на Go в основном пишу, а там интерфейсы — это просто группа методов и наличие реализации интерфейса не задается явно (а ля «class Foo implements Bar» в Джаве), а по наличию реализаций соответствующих методов. Как следствие — интерфейсы можно объявлять постфактум по месту необходимости.

Например: многие библиотечные типы (не интерфейсы) имеют метод «String() : string» и мы хотим написать функцию Print(...), которая бы печатала любое значение, имеющее этот метод (String) с его (метода String) помощью. Для этого мы просто описываем интерфейс «Stringer { String() : string }» и далее функцию «Print(x : Stringer)» и вуаля, всё работает как надо.

Но это частность, суть в возможностях объекта. Это как с режимом доступа к файлу: ro, wo, rw — третий является комбинацией первых двух, только статично. Например:

interface Input {
    Byte   GetByte();
    String GetLine(String delim);
    ...
}
 
interface Output {
    void PutByte(Byte b);
    void PutLine(String s);
    ...
}
 
interface InputOutput extends Input, Output;

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

Сообщение отредактировано: korvin - 20.02.14, 15:11

Цитата korvin @ 20.02.14, 15:10

Ну я-то сейчас на Go в основном пишу, а там интерфейсы — это просто группа методов и наличие реализации интерфейса не задается явно (а ля «class Foo implements Bar» в Джаве), а по наличию реализаций соответствующих методов.

Т.е. duck typing? А если метода не хватает, будет ошибка в рантайме или сразу?

Цитата Mr.Delphist @ 21.02.14, 16:07

А если метода не хватает, будет ошибка в рантайме или сразу?

Сразу конечно.

Цитата Mr.Delphist @ 21.02.14, 16:07

Т.е. duck typing?

Только для интерфейсов.

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

Цитата HardRock @ 07.03.14, 11:51

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

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

Хороший мужик был.

Цитата AZote @ 17.03.14, 09:35

Хороший мужик был.

Только болезный очень... Насколько помню, старина Блез помер в возрасте 39 лет. Впрочем, Франция - это видать место такое суровое.... даже из тех кто был с ним лично знаком - никто не выжил.
То ли дело Бьорн Страуструп или Гвидо ван Россум - живут и радуются.

Посмотрим как они будут жить лет через триста. =)

template <lang T> C<T>++ будет жить и здравствовать.

Лет через триста программисты не будут нужны, ибо роботы с их задачами будут справляться лучше

Цитата Qraizer @ 18.03.14, 12:22

template <lang T> C<T>++ будет жить и здравствовать.

Ну только язык будет называться не C, а какой-нибудь Y или Z... или вообще "Я", буквы-то кончатся.

Цитата Dark_Sup @ 18.03.14, 12:55

Ну только язык будет называться не C, а какой-нибудь Y или Z... или вообще "Я", буквы-то кончатся.

По-моему, уже почти все буквы заняты. Так что будет называться как-нибудь С++3x0

Не, будет C**. =)

Цитата korvin @ 18.03.14, 15:37

Не, будет C**. =)

C Boobs?

С++ сперва предполагалось назвать C+.
Но потом кто-то заметил, что в C это будет синтаксической ошибкой.

Так что языка C** скорее всего не будет.

Если С - какой-то класс, то С** - указатель на указатель на С

Цитата OpenGL @ 19.03.14, 04:09

Если С - какой-то класс

Почему именно класс?

Ну пусть будет тип

Цитата OpenGL @ 19.03.14, 04:09

Если С - какой-то класс, то С** - указатель на указатель на С

Да, но указатель должен как-то называться, поэтому надо писать C**myC

Проще надо быть: **C

Цитата Dark_Sup @ 19.03.14, 09:41

Да, но указатель должен как-то называться, поэтому надо писать C**myC

Если это описание типа аргумента функции, то не обязательно.

Мда... шутка про объединение всех языков в единый мегаязык не прокатила.

Скрытый текст

program Hello;

{$APPTYPE CONSOLE}

uses
SysUtils;
type t = class
s: array of t;
end;
var t1: t;
i,j,k: integer;
begin
{ TODO -oUser -cConsole Main : Insert code here }
t1.Create;
end.

Delphi 7. Компилится

Цитата Добрый кот @ 20.03.14, 13:35

Delphi 7. Компилится

а не должно? где лопата?

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

Цитата Qraizer @ 20.03.14, 14:07

В СиПлюсах ничего необычного, для Дельфей - экстравагантно, но допустимо.

А что экстравагантного? Классы же в дельфях - указатели. Тот же TComponent, если отбросить лишнее, вышеописанным t и будет.

Экстравагантно выглядит. Ссылочная семантика - она такая, да. Для сравнения: в Плюсах нет указателей на ссылки и как следствие массивов ссылок, т.к. семантически это неоднозначная конструкция.

Цитата Qraizer @ 20.03.14, 14:59

Экстравагантно выглядит.

Ничего экстравагантного. И это не массив ссылок, а массив указателей.

Цитата korvin @ 20.03.14, 15:03

И это не массив ссылок, а массив указателей.

А мне вот тоже кажется, что к ссылкам ближе. Указатели - полноценный самостоятельный тип, со своими значениями и операциями.

Цитата Добрый кот @ 20.03.14, 13:35

program Hello;

{$APPTYPE CONSOLE}

uses
SysUtils;
type t = class
s: array of t;
end;
var t1: t;
i,j,k: integer;
begin
{ TODO -oUser -cConsole Main : Insert code here }
t1.Create;
end.

Delphi 7. Компилится

В целом согласен с Вами...

Но всё же, академической строгости ради, должен заметить, что
в тексте этой маленькой программы при компиляции - целых три предупреждения:
о том, что i,j,k - лишние, а также - одна принципиальная ошибка:

t1.Create

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

На самом деле должно было быть:

t1 := t.Create

Ну и в конце, опять же для академической строгости, следовало бы добавить t1.Free

program Hello; {$APPTYPE CONSOLE}
type
  t = class
    s : array of t;
  end;
var
  t1 : t;
begin
  t1 := t.Create;
  t1.Free;
end.

Или, если не использовать t1 вообще, то можно было бы отказаться в данном случае и от var-секции:
То есть использовать анонимный объект!

program Hello; {$APPTYPE CONSOLE}
 
type
  t = class
    s : array of t;
  end;
 
begin
  with t.Create do try
    //...
  finally
    Free
  end
end.

Но в целом, повторю, с учетом исправления приведенных неточностей и ошибок - идеологически правильный пример!

Более того, добавлю от себя, что все объявления передаваемых переменных ссылочных типов в заголовке функции/процедуры, через VAR/CONST/OUT-параметры,
таких, например, как PChar, PInteger и т.д. (или таких, как объекты, которые по факту - также указатели), есть по определению ссылки-на-сылку, например:

procedure TForm1.Button3Click(Sender: TObject);
  procedure Foo(var v : PChar);
  begin // здесь V передается как ссылка на ссылку, к которой прибавляется 3 - великолепный пример адресной арифметики в Паскале!
    if (v+3)^ <> 'D'       // - если 4-ая буква в слове (третья начиная с нуля, на которую указывает p^) не равна 'D'  
      then Caption := v    // - вывести всё слово
      else Caption := v+3  // - вывести остаток строки, начиная с этой буквы
  end;
var
  p : PChar;
begin
  p := 'ABCDEF';
  Foo(p)
end;

Я уж не говорю про классические Паскалевские цепочки неопределённой длины (указатель-на-указатель-...-на указатель):

type
  PMy = ^TMy;
  TMy = record
          Num : integer;
          Next : PMy
        end;
var
  p : PMy;
...

И далее, после соответствующих инициализаций допустимо:

P^.Next^
P^.Next^.Next^
P^.Next^.Next^.Next^ и т.д.

или, опуская символ (^):

P.Next.Next.Next

что допускается современным синтаксисом при соблюдения условия однозначности трактования ситуации компилятором.
И введено это правило для классов (вместо объектов), но распространяется на прочие указатели.

Кстати, именно поэтому в примере выше - там где речь идет о (v+3)/(v+3)^ - опускать этот символ (^) нельзя!

Потому что:

(v+3)^ - это сам 4-ый символ
(v+3)  - это остаток строки, начиная с этого 4-го символа

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

Сообщение отредактировано: Barklay - 22.03.14, 14:13

Ну и так, вдогонку, хохмы ради (Холивар у нас, в конце концов, или где!):

procedure TForm1.Button1Click(Sender: TObject);
var
  a : PChar;
  b : PPChar; // - стандартный, между прочим, тип, определенный в модуле System
  c :^PPChar;
begin
  a := 'ABCDEF';
  b := @a;
  c := @b;
 
  Caption := b^;
  Caption := b^+2;
  Caption := b^^;
 
  Caption := c^^;
  Caption := c^^+2;
  Caption := c^^^;
end;

Особенно доставляет вот эта строчка:
Caption := c^^^
- Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи!

Цитата D_KEY @ 20.03.14, 15:11

А мне вот тоже кажется, что к ссылкам ближе.

Креститься надо, когда кажется. =)

data Ptr a = Ptr a | Nil
data Ref a = Ref a

var x : TObject;
x := nil;

Ок?

Добавлено 24.03.14, 03:18

Цитата Barklay @ 22.03.14, 00:57

Я уж не говорю про классические Паскалевские цепочки неопределённой длины (указатель-на-указатель-...-на указатель):

Они не паскалевские. Это стандартная реализация односвязного списка.

Цитата korvin @ 24.03.14, 03:15

Цитата D_KEY @ 20.03.14, 15:11

А мне вот тоже кажется, что к ссылкам ближе.

Креститься надо, когда кажется. =)

data Ptr a = Ptr a | Nil
data Ref a = Ref a

var x : TObject;
x := nil;

Ок?

Нет, не ок. nil/null не основное отличие ссылок от указателей(хотя в C++ оно существенно). В той же scala, например, null просто является экземпляром bottom-типа ссылочных типов - Null Основная разница между ссылками и указателями заключается в том, что указатели представляют собой самостоятельный полиморфный тип, со своими значениями(адреса) и операциями(адресная арифметика, разыменование).

Цитата Barklay @ 24.03.14, 01:05

- Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи!

А вот не надо путать ссылки и указатели. Компетентные Си-шники в курсе разницы. В отличие от компетентных в Паскале/Дельфи, как они это уже много раз демонстрировали.

Цитата D_KEY @ 24.03.14, 04:35

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

Это языко-специфичное отличие. В "типобезопасных" языках никакой адресной арифметики нет и быть не может, а разыменовывание выполняется автоматически (что может привести к NullPointerException например). Так что, имхо, если имеет смысл различать эти понятия, то только с позиции типизации. Как, например, в C++ и Kotlin.

Цитата korvin @ 24.03.14, 05:41

В "типобезопасных" языках никакой адресной арифметики нет и быть не может, а разыменовывание выполняется автоматически

Поэтому там ссылки, а указателей нет.

Добавлено 24.03.14, 05:56

Цитата korvin @ 24.03.14, 05:41

В "типобезопасных" языках никакой адресной арифметики нет и быть не может

Чем принципиально адресная арифметика отличается от индексации? Если нужно проверять валидность индекса, то можно проверять и выход указателя за диапазон выделенного под массив блока.

Добавлено 24.03.14, 06:06

Цитата korvin @ 24.03.14, 05:41

Так что, имхо, если имеет смысл различать эти понятия, то только с позиции типизации.

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

Цитата D_KEY @ 24.03.14, 05:51

Поэтому там ссылки, а указателей нет.

Если бы они были non-nullable, были бы ссылками и никаких NullPointerException не возникало бы в принципе.

Цитата D_KEY @ 24.03.14, 05:51

Чем принципиально адресная арифметика отличается от индексации?

Тем что в ряде языков адресами управляет GC, да и без него обращение к произвольнольному адресу что по-твоему должно означать?

Цитата D_KEY @ 24.03.14, 05:51

Чем принципиально адресная арифметика отличается от индексации? Если нужно проверять валидность индекса, то можно проверять и выход указателя за диапазон выделенного под массив блока.

Ну и зачем тогда эта самая адресная арифметика, если уже есть индексация?

Цитата D_KEY @ 24.03.14, 05:51

Ну вот что, например, означает ссылка на ссылку

Она означает ссылку. Как сумма нулей, как произведение единиц.

Цитата D_KEY @ 24.03.14, 05:51

и имеет ли она смысл?

Практический — нет. И в приведенном делфийском коде нет ссылок.

Сообщение отредактировано: korvin - 24.03.14, 14:42

Цитата korvin @ 24.03.14, 14:41

Цитата D_KEY @ 24.03.14, 05:51

Поэтому там ссылки, а указателей нет.

Если бы они были non-nullable, были бы ссылками

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

И ты так и не ответил на аргументы мои относительно null. С чего ты взял, что ссылка не может быть null'ом?

Добавлено 24.03.14, 15:25

Цитата korvin @ 24.03.14, 14:41

Ну и зачем тогда эта самая адресная арифметика, если уже есть индексация?

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

Сообщение отредактировано: D_KEY - 24.03.14, 15:27

Цитата D_KEY @ 24.03.14, 15:21

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

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

Цитата D_KEY @ 24.03.14, 15:21

И ты так и не ответил на аргументы мои относительно null. С чего ты взял, что ссылка не может быть null'ом?

Ты не задавал этого вопроса. Потому что тогда: 1) она не будет отличаться от указателя, 2) ее придется правильно разыменовывать (ну или точнее проверять адрес), и 3) никакой неоднозначности:

Цитата Qraizer @ 20.03.14, 14:59

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

не будет.

Но я помню, что Qraizer как раз вроде показывал пример, как можно получить NULL-ссылку в плюсах. Или память меня подводит. И какой должен быть логический смысл у NULL-ссылки?

Цитата D_KEY @ 24.03.14, 15:21

Потому, что она является более общей концепцией

Вот те раз. А то, что оператор [] можно перегрузить и таким образом получить обощенный способ доступа по индексу к любому типу коллекций, в т.ч. и связным спискам, которые вообще как попало размещаются в памяти, не считается? Или они взаимозаменяемы? Смогу я по связному списку пройтись с помощью адресной арифметики?

Добавлено 24.03.14, 15:46

Цитата D_KEY @ 24.03.14, 15:21

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

Итераторы-то каким образом обобщают указатели?

Добавлено 24.03.14, 15:53

Цитата korvin @ 24.03.14, 15:44

Цитата D_KEY @ 24.03.14, 15:21

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

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

Единственное, на что я могу согласиться (в качестве компромиса =)), так это, что 1) указатели в C, 2) ссылки в C++ и Паскале (которые var, const) и 3) объекты в Java, Delphi, etc — это три разных механизма. 3–й занимает промежуточное место между 1–м и 2–м.

Добавлено 24.03.14, 15:54
http://programmers.stackexchange.com/quest...rom-a-c-pointer

Сообщение отредактировано: korvin - 24.03.14, 15:54

Цитата korvin @ 24.03.14, 15:44

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

Цитата Qraizer @ 20.03.14, 14:59

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

не будет.

Я говорил о семантической неоднозначности. Вот есть у меня

int  x;
 
int& y1 = x;
int&&y2 = y1; // предположим; на самом деле такого синтаксиса в языке нет.

На что ссылается y2? На y1 или x? Если первое, то y2, являясь псевдонимом y1, даёт доступ к значению y1, что противоречит основополагающему свойству ссылок. Если второе, то зачем сия конструкция, если она полностью аналогична обычной ссылке?

Цитата korvin @ 24.03.14, 15:44

Но я помню, что Qraizer как раз вроде показывал пример, как можно получить NULL-ссылку в плюсах. Или память меня подводит. И какой должен быть логический смысл у NULL-ссылки?

Приводил. Но как пример дерьмостайла.

Цитата Qraizer @ 24.03.14, 16:27

На что ссылается y2? На y1 или x? Если первое, то y2, являясь псевдонимом y1, даёт доступ к значению y1, что противоречит основополагающему свойству ссылок. Если второе, то зачем сия конструкция, если она полностью аналогична обычной ссылке?

Второе, я ж написал.

Цитата Qraizer @ 24.03.14, 16:27

Но как пример дерьмостайла.

Это да, просто вдруг D_KEY будет настаивать именно на технической, принципиальной возможности. =)

korvin, ты не прав Указатели отличаются от ссылок не null'ом(ещё раз прошу обратить внимание на scala, где null формально объектом является), а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

Добавлено 24.03.14, 17:21
И не надо ориентироваться на специфику C++.

Цитата D_KEY @ 24.03.14, 17:20

а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

Да какой полиморфный тип? Простое uint число. =)

Цитата D_KEY @ 24.03.14, 17:20

И не надо ориентироваться на специфику C++.

Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null. Просто сущности три, а слова всего два.

Цитата D_KEY @ 24.03.14, 17:20

ещё раз прошу обратить внимание на scala, где null формально объектом является

И что? Что вообще это значит «формально является объектом»?

Добавлено 24.03.14, 17:35
Важно то, что объектные типы как и указатели являются типом-суммой с точки зрения типизации. В отличие от «чистых ссылок».

Добавлено 24.03.14, 17:45
Одно из исключений, которое я знаю — Ocaml, там нет null-«объекта». Однако и сделать такой «фокус»:

var x : T;
 
procedure Proc (var x : T);
begin
  x = T.Create('bar');
end;
 
begin
  x = T.Create('foo');
  Proc(x);
  Println(x); // => bar
end.

не получится.

Сообщение отредактировано: korvin - 24.03.14, 17:45

Цитата Qraizer @ 24.03.14, 16:27

Приводил. Но как пример дерьмостайла.

А можно взглянуть на него?

Цитата D_KEY @ 24.03.14, 17:20

И не надо ориентироваться на специфику C++.

Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =)

Сообщение отредактировано: korvin - 24.03.14, 17:50

Цитата korvin @ 24.03.14, 15:44

Цитата D_KEY @ 24.03.14, 15:21

Ты сейчас говоришь, что в той же Java есть указатели? Правильно я тебя понял?

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

Нет, неправильно. В Java нет указаталей. В Java есть ссылки. А название исключения говорит о непоследовательности разработчиков.

Цитата

1) она не будет отличаться от указателя

Будет. Она не будет самостоятельным типом и не будет уметь адресную арифметику.

Цитата

И какой должен быть логический смысл у NULL-ссылки?

В плюсах? Никакого. "Вообще" - вполне может быть. "Пустой объект" или что-то в таком духе. С отдельным типом(bottom-тип для ссылочных типов).

Цитата

А то, что оператор [] можно перегрузить и таким образом получить обощенный способ доступа по индексу к любому типу коллекций, в т.ч. и связным спискам, которые вообще как попало размещаются в памяти, не считается? Или они взаимозаменяемы? Смогу я по связному списку пройтись с помощью адресной арифметики?

Так итераторы же.

Цитата

Цитата D_KEY @ 24.03.14, 15:21

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

Итераторы-то каким образом обобщают указатели?

Потому что они и есть обобщенные указатели. У них есть операции для перемещения и операция разыменования. Указатель - частный случай итератора.

Добавлено 24.03.14, 19:06

Цитата korvin @ 24.03.14, 17:30

Цитата D_KEY @ 24.03.14, 17:20

а тем, что представляет собой самостоятельный полиморфный тип с определённым набором значений и определённым набором операций.

Да какой полиморфный тип? Простое uint число. =)

Не обязательно ptr<T>

Цитата

Окей, а как насчет var-параметров в Паскале? Или ref-параметров в C#? out-параметров в других языках? Вот это всё ссылки и они не могут быть null.

Это передача по ссылке. Один из способов передачи. Тип самостоятельный они не образуют, объекты имеют исходный тип.

Цитата

Что вообще это значит «формально является объектом»?

То, что null - это объект класса Null. Обычный объект, а не какое-то специальное значение для обозначения отсутствия объекта.
И когда ты пишешь

var x : SomeType = null;

Ты просто ссылаешься на объект null и все. А работает это дело потому, что Null - bottom-тип всех ссылочных типов.

Цитата

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

Совсем не обязательно. null может быть экземпляром bottom-типа.

Добавлено 24.03.14, 19:07

Цитата korvin @ 24.03.14, 17:50

Цитата D_KEY @ 24.03.14, 17:20

И не надо ориентироваться на специфику C++.

Как будто арифметика указателей — меньшая специфика С/С++/Паскаля. =)

Переходим на итераторы и все ок. Хотя категории итераторов фактически прижились только в C++ и D(там правда range'ы), что на мой взгляд странно.

Сообщение отредактировано: D_KEY - 24.03.14, 19:08

Цитата OpenGL @ 24.03.14, 17:50

А можно взглянуть на него?

Тю, та вот:

int *null = 0;
int &ref = *null;

По Стандарту разыменование NULL-поинтера допустимо, но недопустимо использование результата сего действа, ибо попадает под неопределённое поведение. Тут результат как таковой не используется, т.к. в точке определения ссылки и естественно её инициализации подссыльный объект не требуется. Но он безусловно будет нужен при любом (в отличие от указателя) использовании ссылки, и нет простых способов проверить валидность ссылки, кроме банального и уродливого подобия if (!&ref).
Так что ссылки на NULL - это безусловно стиль, которого следует избегать всеми силами. Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно.

Цитата Qraizer @ 24.03.14, 19:44

Ссылки в целом как раз вводились для того, чтобы избавиться от указателей и связанных с ними неудобствах там, где только это возможно.

Для перегрузки операторов они вводились же вроде.

Цитата D_KEY @ 24.03.14, 20:09

Для перегрузки операторов они вводились же вроде.

А как связана перегрузка операторов и ссылки?

Цитата OpenGL @ 25.03.14, 04:33

Цитата D_KEY @ 24.03.14, 20:09

Для перегрузки операторов они вводились же вроде.

А как связана перегрузка операторов и ссылки?

Без ссылок нельзя было нормально ввести перегрузку операторов. Указатели не подходят поскольку являются отдельным типом со своими операциями, а писать *a + *b вместо нормального a + b как-то странно.
Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем.

Цитата

Кстати, жаль, что this ввели раньше ссылок, а то и он был бы ссылкой, а не указателем.

Хорошая мысль. Интересно, а чтобы ещё изменилось в С++, если бы его начали писать сейчас с нуля ( без совместимости с С )?

Сложно сказать. Возможно, что-то вроде D

Цитата D_KEY @ 24.03.14, 20:09

Для перегрузки операторов они вводились же вроде.

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

Цитата korvin @ 24.03.14, 03:15

Они не паскалевские. Это стандартная реализация односвязного списка.

Я говорил о классических Паскалевских цепчках, имея в виду выражения:

P^.Next^.Next^.Next^

а вовсе не структуры данных, на примере которых их работа демонстрировались!
Классические, потому что современных компиляторах они превращаются в:

P.Next.Next.Next

И даже объяснил, почему теперь можно опустить знак (^), а также пояснил когда этого делать нельзя.

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

А то, что я с их помощью иллюстрировал, судя по Вашей реплике, прошло мимо Вас...

На этом примере я показал, что в Паскале многоранговая ссылочность вовсе не экзотика,
как утверждал некоторый ваш коллега (подозреваю - Си-шник), и поэтому его "весьма компетентное"
мнение о экстравагантности ссылкок-на-ссылки для Паскалей выглядит просто нелепо!

Тем более, что постом ранее я поддержал другого нашего коллегу, лишь поправив некоторые досадные
неточности в приведенном им примере, а также показал целых три разных класса ситуаций, в которых
ссылка на ссылку в Паскале - просто штатная ситуация: это и VAR'ы, и System-ный тип PPChar, свободно
наращиваемый по прихоти пользователя, это, наконец, все стандартные Form1.Memo1.Lines..., которыми
испещрен простейший текст на Дельфи, (поскольку все объекты есть по сути ссылки) - многоранговые,
цепочечные ссылки.

Воистину, когда мудрец показывает на звезды, глупец смотрит на палец! (с)

И вот в такой ситуации находится эксперт, который положив ногу-на-ногу может сказать

...Ну-уу, для Паскаля это экзотика, а вот в Плюсах...

А потом с неподражаемой непосредственностью, хвастается, что вот де, он то знает различие между ссылками и указателями...
Не понимая, что необходимости такого знания в их "кривых" языках нужно стыдиться, как рваных носков знаменитого финансиста,
ибо в нормальных языках такой необходимости нет! Паскали - они великолепны, не так ли!

Как ответил Лапласс Наполеону:
— Вы написали такую огромную книгу о системе мира и ни разу не упомянули о его Творце!
— Сир, я не нуждался в этой гипотезе.

Цитата Qraizer @ 25.03.14, 12:58

Цитата D_KEY @ 24.03.14, 20:09

Для перегрузки операторов они вводились же вроде.

Это можно было бы обойти и проще. При этом и ссылки не нужны были бы в таком виде.

Ну можно было не делать отдельный тип, если ты об этом, а ограничится способом передачи параметров и возврата значения. Ты об этом?

Добавлено 25.03.14, 15:30

Цитата Barklay @ 25.03.14, 15:13

Цитата korvin @ 24.03.14, 03:15

Они не паскалевские. Это стандартная реализация односвязного списка.

Я говорил о классических Паскалевских цепчках, имея в виду выражения:

P^.Next^.Next^.Next^

Но в этом выражении нет указателя на указатель на указатель.
Указатель на указатель на указатель это:

type PPPMyType = ^^^TMyType

Не помню, допускается ли такая запись в Pascal'ях.
В Си было бы MyType ***.

Цитата D_KEY @ 25.03.14, 15:20

Но в этом выражении нет указателя на указатель на указатель.
Указатель на указатель на указатель это:

type PPPMyType = ^^^TMyType

Не помню, допускается ли такая запись в Pascal'ях.
В Си было бы MyType ***.

Ну во-первых, это: P^.Next^.Next^.Next^, или это: P.Next.Next.Next

это именно ссылка-на-ссылку-... Посмотри в дебагере ASM-код

А то - "Но в этом выражении нет указателя на указатель на указатель" - Это может быть в Си - нет, а в Паскале - есть! Самые настоящие!
Вот они, ещё раз - "весьма компетентные" суждения сишников о Паскалях!

А во-вторых вы "хочете" каких то особых песен, так их уже было для вас у меня, всего пару постов назад:

Цитата Barklay @ 24.03.14, 01:05

Особенно доставляет вот эта строчка:
Caption := c^^^
- Это я про "экстравагантность ссылок-на-ссылки" и прочие "весьма компетентные" суждения Си-шников о Паскале/Дельфи!

А заглянуть внутрь, в текст программы из этого поста недосуг было? По верхам читаем только?!

Там ведь полный текст программы - но он чуть длинней обреза окна.
Зато эти примеры полностью рабочие и потому легко проверяемы.
В отличие от теоретических си-шных умствований - как там "В Си было бы бла-бла-бла..."

Сообщение отредактировано: Barklay - 25.03.14, 17:04

Barklay, мало того, что ты вообще не осилил исходного поста, так ухватившись за знакомый термин "ссылка", пытаешься "их коллегу в данный момент Сишника", в бытности заядлого Паскалянта, убедить, что он нихрена не понимает в предмете твоего вброса. Наивно, уважаемый.

Цитата Qraizer @ 25.03.14, 17:43

Barklay, мало того, что ты вообще не осилил исходного поста,

Поясни, о каком посте идет речь, что ты имеешь в виду?

Вот этот. В нём написано лишь то, что в Дельфях так писать не принято. Экстравагантность заключается в неявности того, что массив хранит не элементы классов, а ссылки на них. Ну просто потому, что классы в Дельфях всегда ссылочный тип. Дальнейшее сравнение с Плюсами понятно тем, кто присутствовал тут в священных войнах на тему "смешанная семантика типов - это зло или нормально?".

Цитата Barklay @ 25.03.14, 15:46

Ну во-первых, это: P^.Next^.Next^.Next^, или это: P.Next.Next.Next

И то, и другое.

Цитата

это именно ссылка-на-ссылку-... Посмотри в дебагере ASM-код

Это как раз не важно в данном контексте. Внимательно читайте на что отвечаете.

Цитата

А то - "Но в этом выражении нет указателя на указатель на указатель" - Это может быть в Си - нет, а в Паскале - есть! Самые настоящие!

И в Си и в Паскале.
В Си аналог вашего кода будет выглядеть так:

typedef struct My * PMy;
typedef struct My {
    int Num;
    PMy *Next;
} TMy;
 
PMy p;

И далее
p->Next
p->Next->Next
p->Next->Next->Next и т.д.

Полный аналог вашего паскалевского примера. И это не "указатель на указатель на указатель" и не "классические паскалевские цепочки", а связный список.

Цитата

вы "хочете" каких то особых песен, так их уже было для вас у меня, всего пару постов назад

Нет, я хочу чтобы вещи называли своими именами.

Цитата

В отличие от теоретических си-шных умствований - как там "В Си было бы бла-бла-бла..."

Вы сейчас о чем? Мои примеры тоже рабочие и проверяемые.

Сообщение отредактировано: D_KEY - 25.03.14, 21:54

Цитата Qraizer @ 25.03.14, 21:20

Экстравагантность заключается в неявности того, что массив хранит

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

http://ideone.com/7ilRbR

Или я уже не понимаю в чем там соль должна быть. =)

Сообщение отредактировано: korvin - 26.03.14, 03:49

Безразмерный массив - ещё одна "экстравагантность" Паскаля. В Плюсах есть только статические массивы, с явным указанием размера которые. (Ну, кроме их extern-объявлений, но за объявления отдельный разговор. По любому с Дельфями тут сравнивать нечего, у него с объявлениями совсем туго.) Даже в C99, допускающего указание размера в run-time, это возможно только для automatic storage duration, т.е. проще говоря, для локальных массивов, которые обычно на стеке. Динамические же массивы возможны только как dynamic storage duration, т.е. располагаемые в хипе. И тип их при этом будет отнюдь не какой-то там массив, а самый что ни на есть обычный указатель.
Получается, что статические массивы и динамический массивы - в Си/Плюсах это совершенно разные типы данных, и переменные этих типов определяются совершенно разным образом. Ну а теперь смотрим в Дельфи, вспоминаем, что он такой же компилируемый и нативный, как и Си/Плюсы, и видим, что совершенно разные структуры данных, представляемые совершенно разными способами, требующих для обслуживания себя совершенно разных методов со стороны компилятора и RTL, ради непонятных идей упрощения непонятно чего представлены в языке одинаковым образом. Что естественно не может не сбивать с толку неподготовленных ребят, только-только постигающих Дельфи. Вот осталось ещё Record-ы объявить "расширенным массивом, допускающим разные типы данных своих элементов", и ввести индексацию именами полей в [].
Не, понятно, что указатели Паскалю без надобности. Они и вводились-то Виртом, если мне не изменяет память, исключительно для поддержки динамических структур данных, типа списков, деревьев, графов итп. Поэтому идеологически указатели Паскалю чужды, и Борландцы всеми правдами и неправдами пытались не допускать их широкое пользование, везде, где только можно, предлагая вместо них их заменители. Как например те же безразмерные массивы. Вопрос же как раз в этом: было ли это оправданным настолько? В конце же концов указатели в программах всё равно используются по причине того, что многие API, и ОСовые, и не только, их требуют. Лично мне С/Плюсовая идеология "не вводить в заблуждение" больше по душе. Вот я вижу в Сишном коде некую конструкцию, и я понимаю, что это, как это работает, какие грабли где могут выплыть, что с этим делать можно, что нельзя, а что с осторожностью. Итп. Плюсовые конструкции вообще могут быть отдизайнены так, что комар носа не подточит. Если их автор соответствующим образом был подкован в соответствующих технологиях и Плюсовых инструментах, пользователь его творения может просто и интуитивно работать с ним безо всякой опаски. Нужна лишь документация на публичный интерфейс компонента, и не надо никаких лишних подкапотных знаний. Но вот слушаем паскалянтов и то и дело умиляемся: "это надо просто помнить, то - ссылки, а это - значения", "любой программер обязан учитывать, что другой программер его класс имеет право хакнуть", "а вдруг агрегат уже разрушен...", "а вдруг агрегат ещё не сконструирован...", "...в виртуальном методе обязательно надо проверять на 0", итп. В Плюсах как-то спокойнее, всё в языке спроектировано единообразно. Всё - значения, нужна ссылка - добавь явно модификатор. Всё - можно сделать ссылочным, добавив модификатор. Всё, что разное, выглядит по-разному, напутать сложно. Написал класс или даже иерархию - никто её случайно не хакнет, только намеренно. Итд.

P.S. Вообще, насколько помню, в Дельфях классы принято хранить в коллекциях. Ну да, массив как бы тоже своего рода коллекция, но я имею в виду те коллекции, которые сами классы.

Цитата Qraizer @ 26.03.14, 05:02

Поэтому идеологически указатели Паскалю чужды, и Борландцы всеми правдами и неправдами пытались не допускать их широкое пользование, везде, где только можно, предлагая вместо них их заменители

Остапа понесло (С)
Если из паскаля убрать указатели и все, что с ними связано, то в сухом остатке получится жалкое подобие бэйсика, которое нафиг никому не нужно. Не надо путать "классический" паскаль с дельфями, т.к. "заменители" со смешанной семантикой типа лонг-стринг, дин.массивов, class и т.п., а также отмена обязательного дереференса указателей появились только в дельфях. А в додельфийском паскале ничего подобного не было - и дереференс указателей был обязателен, и тип object больше соответствовал сишным struct\class в плане возможности выбора размещения в памяти (статическое или динамическое) и обращения (по значению\ссылке или указателю).

Object'а в виртовском паскале не было же.

Цитата D_KEY @ 26.03.14, 06:55

Object'а в виртовском паскале не было же.

Я не только о виртовском говорю, но и о борландовском додельфийско-VCLском

Цитата leo @ 26.03.14, 06:35

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

Их там и нет по сути, leo. Сам посуди, куда их приткнуть-то? Только в интерфейсы с внешним миром. Всё остальное, окромя исходноидейных динамических структур данных, обходится без них. Даже процедурные типы есть вместо указателей на функции.

Добавлено 26.03.14, 11:33

Цитата leo @ 26.03.14, 06:35

...и дереференс указателей был обязателен...

И это правильно. ИМХО.

Добавлено 26.03.14, 11:34

Цитата leo @ 26.03.14, 06:35

...и тип object больше соответствовал сишным struct\class в плане возможности выбора размещения в памяти (статическое или динамическое) и обращения (по значению\ссылке или указателю).

И это правильно. Тут даже без ИМХОа. Только это всё не class. И даже в таком же доДельфийном виде и осталось. Там речь шла именно за классы, которые class, а не объекты, которые object.

Цитата Qraizer @ 26.03.14, 05:02

Получается, что статические массивы и динамический массивы - в Си/Плюсах это совершенно разные типы данных, и переменные этих типов определяются совершенно разным образом

В чем по твоему отличие стат массивов в дельфе от сишных ? Я что то вообще отличий не вижу.

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

Цитата jack128 @ 26.03.14, 12:01

А вот в плюсах дин. массив - это не тип, а хз что. Припудренный указатель, не больше.

Чем это он припудрен? И да, в плюсах есть vector и др. типы.

Цитата D_KEY @ 26.03.14, 12:20

Чем это он припудрен?

Ну, нет в плюсах такого встроенного типа - динамический массив. Только указатель и дополнительные действия вокруг операторов new[] и delete[].

Цитата MyNameIsIgor @ 26.03.14, 12:28

Цитата D_KEY @ 26.03.14, 12:20

Чем это он припудрен?

Ну, нет в плюсах такого встроенного типа - динамический массив. Только указатель и дополнительные действия вокруг операторов new[] и delete[].

Я знаю. Так припудрен-то чем? new[] и delete[]? А если я буду юзать malloc/free или еще что, то это будет не динамический массив?

Цитата D_KEY @ 26.03.14, 12:33

Я знаю. Так припудрен-то чем? new[] и delete[]?

Ага.

Цитата D_KEY @ 26.03.14, 12:33

А если я буду юзать malloc/free или еще что, то это будет не динамический массив?

Смотря какое определение у "динамического массива". И new[]/delete[], и malloc/free - это просто куски памяти, в которых располагаются объекты.

Цитата MyNameIsIgor @ 26.03.14, 12:39

Смотря какое определение у "динамического массива".

Массив, размер которого задается/меняется в рантайме?

Цитата D_KEY @ 26.03.14, 12:45

Массив, размер которого задается/меняется в рантайме?

Ну, в таком случае не будет, потому что у нас не массив, а указатель.

Цитата MyNameIsIgor @ 26.03.14, 12:47

Цитата D_KEY @ 26.03.14, 12:45

Массив, размер которого задается/меняется в рантайме?

Ну, в таком случае не будет, потому что у нас не массив, а указатель.

Это с точки зрения типизации сишной. Так с ее точки зрения в Си вообще нет динамических массивов.

Цитата D_KEY @ 26.03.14, 12:50

Это с точки зрения типизации сишной. Так с ее точки зрения в Си вообще нет динамических массивов.

Ага, нет.

Цитата jack128 @ 26.03.14, 12:01

В чем по твоему отличие стат массивов в дельфе от сишных ? Я что то вообще отличий не вижу.

А нету их. Неудивительно, что не видишь. Разница есть между статическими и динамическими. Причём одинаковая в обоих языках.

Цитата MyNameIsIgor @ 26.03.14, 13:02

Ага, нет.

так лучше бы и синтаксиса не было.
Ну согласись, пи***ц же:

#include <iostream>
using namespace std;
 
void f(int x[]){
    cout << sizeof(x) << endl;
}
int main() {
    // your code goes here
    int x[] = {1,2,4};
    cout << sizeof(x) << endl;
    f(x);
    return 0;
}

Цитата Qraizer @ 26.03.14, 13:19

Разница есть между статическими и динамическими. Причём одинаковая в обоих языках.

ну вот Си ные товарищи говорят, что в С нету дин массивов. А дельфи есть. Так что разница разная ;-)

Сообщение отредактировано: jack128 - 26.03.14, 13:25

Цитата jack128 @ 26.03.14, 13:24

Ну согласись, пи***ц же:

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

Цитата jack128 @ 26.03.14, 13:24

так лучше бы и синтаксиса не было

А синтаксиса и нет...

Цитата jack128 @ 26.03.14, 13:24

Ну согласись, пи***ц же

У массивов много странного, да. Таков уж C

Добавлено 26.03.14, 13:48

Цитата jack128 @ 26.03.14, 13:24

ну вот Си ные товарищи говорят, что в С нету дин массивов.

В C то есть

Добавлено 26.03.14, 13:49

Цитата OpenGL @ 26.03.14, 13:34

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

Первое предложение верно (если убрать "всегда"). А вот второе... как минимум непонятно.

Сообщение отредактировано: MyNameIsIgor - 26.03.14, 13:49

Ошибаешься, jack128. А ну-ка, компильни:

  VAR arr1: ARRAY OF Integer;
 
  PROCEDURE proc(VAR arr: ARRAY OF Integer);
  BEGIN
    SetLength(arr, 100)
  END;
 
BEGIN
  proc(arr1);
  SetLength(arr1, 100)
END.

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

  TYPE DynArray = ARRAY OF Integer;
  VAR  arr1: DynArray;
 
  PROCEDURE proc(VAR arr: DynArray);
  BEGIN
    SetLength(arr, 100)
  END;
 
BEGIN
  proc(arr1);
  SetLength(arr1, 100)
END.

А физиономия у него какая при этом будет? "Ну это надо просто запомнить." © Вот это - трындец, да.
А в С/Плюсах всё в порядке, никаких трындецов. Разные сущности и выглядят по-разному. Мне что-то кажется, лучше б в Дельфях синтаксиса не было.

Цитата MyNameIsIgor @ 26.03.14, 13:46

А вот второе... как минимум непонятно.

За что купил - за то и продаю В этой теме Qraizer говорил именно об этом.

Цитата OpenGL @ 26.03.14, 13:59

В этой теме Qraizer говорил именно об этом.

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

Qraizer Убедил.

ЗЫ Это jack128

Сообщение отредактировано: Rouse_ - 26.03.14, 14:13

Цитата MyNameIsIgor @ 26.03.14, 14:06

и преобразование к указателю здесь ни при чём.

А как же 10[arr] равнозначное arr[10]? Хотя надо в стандарте глянуть.

MyNameIsIgor, нету. Зачем? Операция индексирования определена через сложение и разыменование, каковые определяются для указателей, а массивы умеют кастоваться в указатели, причём в весьма "приоритетном" порядке. Там в 4 Standard conversions в 1) и 2) прямо об этом сказано.
D_KEY, не надо смотреть. Будучи определённой через сложение, каковое, как известно, коммутативно, эта симметрия вытекает сама собой. Да и вообще, там явный коммент есть:

Цитата 8.3.4 Arrays

6 Except where it has been declared for a class (13.5.5), the subscript operator [] is interpreted in such a way that E1[E2] is identical to *((E1)+(E2)). Because of the conversion rules that apply to +, if E1 is an array and E2 an integer, then E1[E2] refers to the E2-th member of E1. Therefore, despite its asymmetric appearance, subscripting is a commutative operation.

Сообщение отредактировано: Qraizer - 26.03.14, 14:22

Цитата Qraizer @ 26.03.14, 14:17

D_KEY, не надо смотреть... там явный коммент есть

Вообще, что б далеко не посылать, вот:

Цитата 4 Standard conversions

1 Standard conversions are implicit conversions defined for built-in types. Clause 4 enumerates the full set of such conversions. A standard conversion sequence is a sequence of standard conversions in the following order:

• Zero or one conversion from the following set: lvalue-to-rvalue conversion, array-to-pointer conversion, and function-to-pointer conversion.
• Zero or one conversion from the following set: integral promotions, floating point promotion, integral conversions, floating point conversions, floating-integral conversions, pointer conversions, pointer to member conversions, and boolean conversions.
• Zero or one qualification conversion.

[ Note: a standard conversion sequence can be empty, i.e., it can consist of no conversions. —end note ]
A standard conversion sequence will be applied to an expression if necessary to convert it to a required destination type.
2 [ Note: expressions with a given type will be implicitly converted to other types in several contexts:

• When used as operands of operators. The operator’s requirements for its operands dictate the destination type (Clause 5).
• ...

Сообщение отредактировано: Qraizer - 26.03.14, 14:32

Цитата Qraizer @ 26.03.14, 11:32

Их там и нет по сути, leo. Сам посуди, куда их приткнуть-то? Только в интерфейсы с внешним миром. Всё остальное, окромя исходноидейных динамических структур данных, обходится без них

Ну как же нет, если нормальные указатели появились еще в турбо-паскале задолго до дельфийских AnsiString, array of и class? Значит было и есть "куда приткнуть", и не "всё без них обходится"?

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

Qraizer
Моя твоя не понимай
С какой стати в си указатели для чего-то нужны кроме new, а в паскале, значит только для "исконного" виртовского new, и каких-то "внешних интерфесов"?! Почему я должен использовать указатели только на динамические переменные, выделенные по new, а взять указатель на произвольную переменную или кусок памяти мне разрешают только для "внешнего интерфейса"? С какой стати в том же односвязном списке Next должен указывать только на динамически выделенную переменную, а не произвольную, например элемент массива? Или сортировать массивы в Паскале нужно исключительно непосредственно, переставляя сами элементы, а использовать внешнюю сортировку массива или дерева указателей категорически запрещено? Разбор\анализ строк и байтовых массивов нужно делать исключительно по индексам s[i], и ни в коем случае не через адресную арифметику с PChar\PByte? А с ООП как работать без указателей, если мы создаем объекты производных классов, а работать с ними нужно как c базовыми\родительскими? И т.д., и т.п.

В си нет new.

Добавлено 27.03.14, 08:43

Цитата leo @ 27.03.14, 08:24

А с ООП как работать без указателей, если мы создаем объекты производных классов, а работать с ними нужно как c базовыми\родительскими?

В паскале да, никак. А в Delphi ссылочная семантика для объектов.

leo, если програмить в Паскале как в Сях, без указателей никуда, не спорю. Ещё можно на Плюсах писать в стиле Паскаля, и на ассемблере в стиле Плюсов.