Обсуждение: Сравнение Паскаля и Си

ВикиПроект C / C ++	(Номинальный список-класс)
v т е Эта статья находится в рамках WikiProject C / C ++ , совместной работы по расширению охвата C / C ++ в Википедии. Если вы хотите принять участие, посетите страницу проекта, где вы можете присоединиться к обсуждению и увидеть список открытых задач.C / C ++ Википедия: WikiProject C / C ++ Шаблон: статьи WikiProject C / C ++ C / C ++  Список  Эта статья была оценена как List-Class по шкале качества .  ???  Эта статья еще не получила оценку по шкале важности .

Современный Си и Модерн Паскаль [ править ]

Эту страницу необходимо разделить на более конкретные страницы.

Страница 1: Сравнение оригинального языка C и стандартного Паскаля.

Страница 2: Сравнение Modern C / C ++ и Modern Pascal

Слово «Паскаль» чрезвычайно расплывчато. Паскаль, который сегодня широко используется, такой как freepascal и delphi, более сопоставим с современными компиляторами C и C ++. Нельзя сравнивать современный C со стандартным паскалем, если это явно не указано. Нельзя также сравнивать современный паскаль с языком B, если сравнивают паскаль и C.Также мы не можем возвращаться назад и вперед, сравнивая стандартный паскаль со старым C и новый C со стандартным Pascal, поскольку он непоследователен, сбивает с толку и хронологически дезорганизован.

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

Пожалуйста, отличите Modern Pascal от Standard Pascal. Чтобы получить хронологическую ссылку, нужно указать «текущий Паскаль, используемый в freepascal 2.0.4 и в Delphi 7, по сравнению с текущим C, используемым в GCC и Visual Studio». Кроме того, ни текущие компиляторы C ++ / C, ни текущие компиляторы Pascal не соответствуют стандартам. Определите, что такое «стандартный паскаль» и в каком году вы говорите, и определите, что такое «современный паскаль», сославшись на год и версии компилятора, и определите, что такое C и C ++, поскольку ни один компилятор C или компилятор C ++ не реализует ничего » чистый стандарт C ". - LFiveZeroFive

Даже близко к правде говоря, существует несколько полностью совместимых со стандартами компиляторов, от GCC до IP Pascal, Dr Pascal, Irie Pascal и других. То же самое и с C / C ++, для которых соблюдение стандартов является правилом. Честно говоря, я не знаю, откуда вы берете эту информацию. Было бы более продуктивно перечислять компиляторы, которые НЕ совместимы, чем перечислять те, которые совместимы, поскольку практически все компиляторы за пределами Delphi совместимы, а на стороне C / C ++ трудно найти ЛЮБОЙ, который не соответствует.

- Да, эту страницу можно разделить на более конкретные страницы:

1) Сравнение оригинального языка C и стандартного Паскаля.
2) Сравнение оригинального языка C и расширенного Pascal (стандарт: ISO / IEC 10206; ANSI / IEEE 770X3.160: 1989).
3) Сравнение Original C и Turbo Pascal 5.0.
4) Сравнение C ++ и OO Pascal / Delphi.
5) Сравнение оригинального C и C ++.
6) Сравнение C ++ и C #.

(5,6): См. Книгу Andrew Troelsen, C # and the .NET platform, Chapter 1, Apress, 2001.

Tim32 21:09, 11 октября 2007 г. (UTC)

Я, конечно, согласен, но перечислю несколько моментов.

1. Постоянная характеристика языков Delphi и Turbo Pascal как «современных» и других версий Pascal как «устаревших» не требуется и не служит вам никакой цели, кроме как начать мелкую борьбу с пользователями, которые в противном случае могли бы согласиться с вами и помочь тебе. Borland создал диалект Паскаля (несовместимый). Хороший или плохой этот диалект здесь не обсуждается. Borland - это Паскаль, поскольку он совместим с языком Паскаль, который создал Никлаус Вирт. Существует множество реализаций Pascal за пределами семейства Borland, включая GCC, IP Pascal, Dr Pascal, Ire Pascal и другие (и это только те реализации, которые все еще активно поддерживаются). Короче говоря, мы могли бы полностью согласиться, если бы вы (и другие) просто отказались от обзвона.

2. C и C ++ - это разные языки, поэтому на любой странице с участием Delphi или Turbo следует отдельно рассматривать объектно-ориентированные функции. Поступать иначе - значит относиться к C неправильно, т. Е. Сравнивать яблоки с апельсинами.

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

Короче говоря, я думаю, что лучше всего начать со страницы «delphi vs C ++», поскольку она сравнивает два достаточно эквивалентных и поддерживаемых в настоящее время языка. После того, как это будет создано, люди здесь могут решить, нужно ли им больше. Прямо сейчас мы не видим, чтобы кто-то добровольно создавал хотя бы одну страницу, не говоря уже о шести разных страницах, которые вы вызываете! —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 20:21, 26 декабря 2007 г. (UTC)

"требует осмотра экспертом" [ править ]

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

Скотт А. Мур

Не могли бы вы привести нам несколько примеров таких фактических ошибок, чтобы я или кто-то другой мог их исправить? / HenkeB 03:12, 7 сентября 2006 г. (UTC)

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

Теоретически да, но на практике обычно приходится принимать некоторые соглашения низкого уровня, чтобы позволить скомпилированному коду эффективно выполнять семантику конкретного языка на реальных компьютерах. Для K&R C не существовало стандартных документов (кроме неофициальной белой книги), но в большинстве компиляторов K&R C вызывающая сторона отвечала за удаление передаваемых параметров из стека, а параметры перемещались справа налево, поэтому первый (например, формат - строка в printf) была доступна по известному фиксированному смещению от указателя стека; это был (и, вероятно, остается) стандартным де-факто методом разрешения списков переменных и / или параметров времени выполнения в C. / HenkeB 09:33, 25 июня 2007 г. (UTC)

На самом деле нет. У меня действительно нет времени читать вам лекции по компиляторам, брать книгу. Фактически, передача на основе стека была популярна в 1980-х и начале 1990-х годов, и даже тогда в основном на микропроцессорах с низкой производительностью. По сути, это НЕ регистровое соглашение о вызовах (отсюда и название «стек»), и практически все современные операционные системы и языки используют соглашения о вызовах на основе регистров (возможно, вы слышали о Windows или GCC?). —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 00:23, 17 октября 2007 г. (UTC)

Вы грубы и выглядите довольно злым, но я все равно попытаюсь объяснить вам некоторые основные вещи: компилятор AC или Pascal может передавать только несколько параметров непосредственно в регистры, обычно около 1-3 на машинах x86 (Windows), прежде чем он просто кончаются свободные регистры. Для вызовов с большим количеством параметров он должен либо динамически (чтобы разрешить многоуровневые вызовы) выделять область данных для хранения остальных фактических параметров, либо использовать стек (который по своей сути является динамическим, хотя и жестко). Существуют архитектуры ЦП с достаточным количеством регистров для использования параметров, выделенных регистрами, почти вво всех случаях, но x86, конечно, не один из них (и не «микропроцессор с низкой производительностью»). Также имейте в виду, что даже когда параметры передаются на 100% в регистрах, регистры иногда должны быть сохранены (в стеке), чтобы обеспечить возможность многоуровневых и рекурсивных вызовов. HenkeB 02:39, 20 октября 2007 г. (UTC)

опять же, НИЧТО из этого не имеет никакого отношения к языку, который видит пользователь, поэтому ни стандарты для C, ни Pascal не включают такую ​​информацию. —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 20:34, 26 декабря 2007 г. (UTC)

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

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

- Samiam95124, 23:05, 2 марта 2007 г. (UTC)

Я и другие исправили вышеуказанные жалобы и считаю проблему закрытой. —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 20:32, 26 декабря 2007 г. (UTC)

Хорошо, хотя очень жаль, что на странице постоянно появляются предупреждения. Страница выполнила свою первоначальную цель, которая заключалась в том, чтобы убрать аргументы C против Pascal с соответствующих страниц языка Pascal и C. Фактически, это модель того, как решать все подобные языковые проблемы. Я полностью поддерживаю цель создания подстраниц для сравнения конкретных диалектов каждого языка. - Предыдущий беззнаковый комментарий добавлен 148.87.19.210 ( обсуждение ) 00:39, 9 ноября 2013 г. (UTC)

Изменения J7 [ править ]

1.

"Некоторые новые компиляторы Паскаля позволяют объявлять массивы способом, более похожим на C

var x = array [0..9] of integer "

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

2.

Некоторые новые компиляторы Pascal имеют предопределенный строковый тип, который работает как строка с завершающим символом NULL, аналогичная массиву символов в C.

Я думаю, вы говорите о строках UCSD / Borland, и в этом случае утверждение неверно. Эти строки не используют нулевой терминатор.

(Я думаю, он говорит о Delphi, у которого есть тип строки с завершающим нулем (и двойной ноль, начиная с D4) для облегчения перехода к C.Однако он завершается только # 0 # 0 ради C, поскольку все еще существует отдельная длина и тип также может содержать # 0. IOW, правильный код паскаля не должен зацикливаться с проверкой # 0. 88.159.87.12 10:00, 23 июля 2006 г. (UTC))

3.

Типы записей - 3-битное целое число фактически равно 0..7, а не 0..3 (что составляет 2 бита)

Что уместно в примере, как? В статье не говорится, что он должен соответствовать какому-либо конкретному количеству битов. Это просто говорит о том, что конструкция эквивалентна спецификации битового поля в C.

4.

Writeln ('сумма:' + x);

Какой язык вы цитируете? Это утверждение недопустимо для всех существующих Pascal, включая Borland. Заявление, на которое вы его заменили, совершенно верно.

- Samiam95124 20:31, 17 декабря 2005 г. (UTC)

Разделители Паскаля [ править ]

"Это различие проистекает из того, что Паскаль рассматривает всю программу как одно очень длинное, продолжающееся предложение, и поэтому все операторы, кроме последнего конца через точку с запятой и последнего заканчиваются точкой; в то время как C не рассматривает программу как предложение и просто использует точку с запятой в конце оператора "

Это пренебрежительно и непрофессионально. Я не позволю этой странице опуститься до страницы «языковой войны».

- Samiam95124 18:03, 17 декабря 2005 г. (UTC)

Как это "пренебрежительное"? И как это «языковая война»? Это причина того, что Паскаль использует точку (.) После последнего «конца». Он настолько нейтрален, насколько это возможно. - Гнив (крыло), 19:35, 17 декабря 2005 г. (UTC).

Предложение «Это различие проистекает из того, что Паскаль рассматривает всю программу как одно очень длинное, повторяющееся предложение»:

1. Унизительное отношение к Паскалю.

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

Разница между Паскалем и C кратко сформулирована следующим образом: «В Паскале точка с запятой является разделителем операторов, а в C - ограничителем операторов». И об этом, собственно, и говорится сейчас.

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

- Samiam95124 19:55, 17 декабря 2005 г. (UTC)

Это был прекрасный способ выразить, как устроен Паскаль. Я всегда видел "." в конце как очень уродливая бородавка, но все это имеет смысл, если вы рассматриваете программу как большое большое предложение. AlbertCahalan 07:35, 24 апреля 2006 г. (UTC)

Это не имеет ничего общего с разбегом по предложениям. Если мы собираемся делать незрелые утверждения, то я собираюсь сказать, что Роб Пайк (программист на C) заявил, что функции C должны быть написаны так :_this_because_english_prose использует пробелы, а не ThisStyleHere. Таким образом, можно утверждать, что Си пытается стать английской прозой, хотя на самом деле Программы не являются английской прозой и не должны быть разработаны как английская проза. Но давайте постараемся быть рациональными и перестанем делать глупые предположения. Причина, по которой Паскаль использует точку, заключается в том, чтобы можно было отличить конец программы от конца процедуры. Во время редактирования, когда вы наполовину спите и работаете много часов, может быть полезно знать, что это конец программы, а не конец процедуры. Без точки это может привести к глупым ошибкам,например, программа была преждевременно завершена, когда вместо этого вы намеревались завершить процедуру. Причина исключения точки с запятой в операторе else аналогична. Если кодировщик удаляет строку кода, отсутствие точки с запятой приводит к глупым ошибкам, если другое было удалено по ошибке или поздно вечером, когда кто-то находится в полусне, или когда другой программист изменил код в проекте с несколькими разработчиками. Компиляция программы или модуля, в котором отсутствует точка с запятой и не следует ключевое слово else, позволяет программисту знать, что кто-то удалил оператор else, не думая о предыдущей строке кода.отсутствие точки с запятой приводит к глупым ошибкам, если что-то еще было удалено по ошибке или поздно вечером, когда кто-то находится в полусне, или когда другой программист изменил код в проекте с несколькими разработчиками. Компиляция программы или модуля, в котором отсутствует точка с запятой и не следует ключевое слово else, позволяет программисту знать, что кто-то удалил оператор else, не думая о предыдущей строке кода.отсутствие точки с запятой приводит к глупым ошибкам, если что-то еще было удалено по ошибке или поздно вечером, когда кто-то находится в полусне, или когда другой программист изменил код в проекте с несколькими разработчиками. Компиляция программы или модуля, в котором отсутствует точка с запятой и не следует ключевое слово else, позволяет программисту знать, что кто-то удалил оператор else, не думая о предыдущей строке кода.Пользователь: LFiveZeroFive

Голубое, голубое небо [ править ]

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

Я добавил "Blue Sky Pascal", чтобы, надеюсь, объяснить, почему я думаю, что его лучше оставить на определенной странице на конкретном Pascal, чем включать здесь оптом. Основной момент, который следует понять, состоит в том, что комбинация Паскаля и C больше не является ни Паскалем, ни С. Паскаль теряет безопасность типов, а Си теряет свою простоту. Хотя такие комбинации могут быть интересны в другом месте, сравнение Pascal и C как разных языков потеряло бы свой вкус так же, как сравнение стейка и спама, если бы они были смешаны вместе в блендере.

Паскаль имеет ценности, отличные от C. Тот факт, что общая память забыла об этом, не имеет отношения к фактам. Java и C # можно провозгласить «революцией» в области безопасности типов, но это не отменяет того факта, что у Паскаля были такие концепции около 30 лет назад.

Дополнение для вас [ править ]

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

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

Спасибо.

- Samiam95124, 22:01, 22 ноября 2005 г. (UTC)

Да, действительно хорошо писать. Спасибо программисту на паскале и c!

Dunkelfalke

В самом деле! Это было очень приятное чтение. Спасибо и привет от ностальгического фанатика Паскаля. - ActiveSelective 07:24, 25 марта 2006 г. (UTC)

Я также хотел бы добавить свои поздравления за очень четкую и хорошо сбалансированную статью. Дэвид Хеффернан, 12 февраля 2007 г.

Удаляет [ редактировать ]

Если вы удалите раздел и не предоставите то, что, по вашему мнению, является «правильной» интерпретацией, то вы ПЕРЕВЕРНУЕТЕСЬ. Я устал от людей, которые просто отрезают отрывки, которые им не нравятся. Если у вас есть проблемы с тем, как что-то сформулировано, ВЫ это перефразируете. Удаление ничего не делает для продвижения Википедии.

Динамические массивы [ править ]

Исключенный материал:

«Возможность иметь массивы любой длины и иметь возможность проверять их под управлением языка часто называется« динамическими массивами ».

Мистер Берроуз говорит:

Удалены неактуальные / вводящие в заблуждение / неточные ссылки на динамические массивы. «Динамические массивы» обычно относятся к массивам, размер которых можно изменять во время выполнения.

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

Я бы предпочел, если вы собираетесь удалить подобный материал, если вместо этого вы переформулируете его в соответствии со своим представлением о «правильном». Мы пытаемся добавить сюда информацию, а не удалить ее. - Samiam95124 04:00, 6 октября 2005 г. (UTC).

Почему эта страница здесь? [ редактировать ]

Эта страница находится здесь, потому что я чувствовал, что сравнение "лицом к лицу" C и Паскаля неуместно для страницы Паскаля. В худшем случае это вызывает драки между сторонниками соответствующих языков. В лучшем случае это проблематично с точки зрения логистики (должны ли мы добавить раздел для каждого языка, сравнивая его с C? Все языки друг с другом?).

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

Я создал профессиональные компиляторы для языков C и Pascal (и многих других). Я также использую оба языка изо дня в день. Так что я чувствую, что могу провести сравнение. Я постарался сделать материал максимально фактическим и объективным.

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

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

• Паскаль не умеет программировать на низком уровне.

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

• C небезопасен и вызывает проблемы червя, которые мы наблюдаем из-за атак переполнения буфера.

Ничто не мешает программистам на C проверять свои буферы и массивы в целом. Это лень, а не языковая особенность.

• Паскаль неэффективен.

Эффективность зависит от компилятора. Использование оператора C, такого как x ++, не делает ваш код более эффективным, поскольку он компилируется с приращением. Компиляторы Паскаля также знают, как изменить x: = x + 1 на приращение. Фактически, существует очень небольшая разница между характеристиками эффективности двух языков.

• C создает беспорядочные программы

Я видел программы на Паскале, которые следует выбросить (быстро), и программы на C, которые красивы. Все зависит от программиста.

• Паскаль ограничивает вас и не позволяет вам что-либо делать.

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

Да, в самом деле. Вы можете написать эмулятор машины Тьюринга на Паскале, а затем использовать эту машину Тьюринга для реализации компилятора C и среды выполнения C ... но это не будет очень быстрым или удобным в обслуживании. (на самом деле нет, потому что настоящая машина Тьюринга требует бесконечной памяти) AlbertCahalan 07:32, 24 апреля 2006 г. (UTC)

Пожалуйста, подумайте также о сравнениях логически. Многие сравнения, появляющиеся в Интернете, сравнивают яблоки с апельсинами. то есть поговорить о возможностях, которые есть в C, о том, что было в Паскале в 1972 году (!). Знаете ли вы, что раньше в C не было перечислимых типов, оператора typedef и других возможностей? Паскаль тоже не стоял на месте. Если вы собираетесь сравнивать с Pascal, сравните с Pascal как есть, который в большинстве редакций имеет динамические массивы, модульную компиляцию, объекты и другие функции.

Если вы программист на Pascal, познакомьтесь с C, прежде чем проводить сравнение. Если вы программист на C, познакомьтесь с Паскалем. Сравнение языка, которым вы пользуетесь каждый день, с языком, который вы использовали в студенческом компьютере 101, не будет справедливым или ценным сравнением.

Спасибо за внимание. - Samiam95124 02:29, 4 июня 2005 г. (UTC).

Я не понимаю, почему эта страница существует в ее нынешнем виде.

Он сравнивает некоторые старые, давно устаревшие стандарты. Ни один компилятор в настоящее время не поддерживает эти стандарты без ЛЮБЫХ расширений. В частности, описанный здесь Паскаль мертв. Практически все современные компиляторы поддерживают Object Pascal, который для Pascal является тем же, чем C ++ для C. Не говоря уже о том, что большинство компиляторов C на самом деле являются компиляторами C ++ с режимом совместимости с C.

C гораздо лучше стандартизирован, чем Паскаль. То есть компиляторы C более соответствуют стандартам, чем компиляторы Pascal. Некоторые компиляторы, такие как Oxygene, настолько отличаются от стандартного Pascal, что они вообще не заслуживают названия Pascal, несмотря на то, что продаются как таковые (никто не утверждает, что Java - это C, верно?)

Если кому-то нужен «один настоящий Паскаль», то может быть неплохо взять какой-нибудь очень старый стандарт, но он не имеет реальной ценности, так как он очень устарел и никоим образом не является представителем используемых в настоящее время компиляторов Паскаля. - Азариен ( talk ) 22:26, ​​20 февраля 2010 г. (UTC)

a) Программирование на языке Pascal и C не ограничивается разработкой программного обеспечения для Windows и Linux. Компиляторы Pascal и C, доступные для встроенного программирования, например Keil, IAR, MikroElektronica и т. Д., Портативные устройства, например PocketStudio и т. Д., Как правило, имеют очень разные расширения, но все же имеют одно и то же ядро. Если вы знаете о минимальном наборе функций, который, как вы можете разумно ожидать, будет согласованным, и о несовместимых расширениях для конкретной платформы, тогда будет меньше сюрпризов и больше возможностей повторно использовать общий код, когда вам нужно переключиться на другой компилятор.

б) Большинство компиляторов Pascal и C / C ++ реализуют языки, основанные на надмножествах оригинала. Текущие реализации по-прежнему сохраняют недостатки языкового дизайна, которые присутствовали в спецификациях исходного языка. Программисты, осведомленные об этих сравнительных недостатках, могут лучше оценить выбор языка для конкретной задачи. Вместо переопределения Паскаля Вирт обратился к недостаткам Паскаля в Модуле-2 в начале 1980-х и снова в Обероне в 1990-х. Крис Берроуз ( разговор ) 00:15, 21 февраля 2010 (UTC)

Боюсь, Крис, в Википедии нет места для таких оправданий. Википедия не является издателем оригинальной мысли , поэтому либо приведите ваши утверждения, либо мы можем счесть их несуществующими. Вдобавок Азариен выразил обоснованное беспокойство: фактологическая точность этой статьи действительно оспаривается: в этой статье сравниваются две очень старые версии языка. Эта статья в первую очередь вводит в заблуждение читателя, который хочет узнать больше о различиях языка, сообщая ему или ей неверную информацию. Обновление должно быть первоочередной задачей. Командование флотом ( разговор ) 05:32, 21 февраля 2010 (UTC)

Заявления о соответствии стандартам для компилятора IAR C можно найти по адресу http://www.iar.com/website1/1.0.1.0/466/1/, а для компилятора Keil - по адресу http://www.keil.com/support/man. /docs/armccref/armccref_Cheifhbg.htm .

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

Работы Вирта перечислены в разделе «Дополнительная литература» статьи: Никлаус Вирт: Воспоминания о развитии Паскаля. 333-342, Уведомления ACM SIGPLAN, том 28, выпуск 3, март 1993 г. Крис Берроуз ( доклад ) 12:37, 21 февраля 2010 г. (UTC)

Спасибо за полезные источники, Крис. Однако они не цитируют ваши утверждения, которые вы использовали для оправдания фактической точности статей (т. Е. Устаревших). Тем не менее, эта статья никуда не денется: отсутствие актуальной информации не является проблемой, которая может служить основанием для удаления статьи. Возможно, в ближайшем будущем я смогу уделить больше времени и заняться этим вопросом. Командование флотом ( разговор ) 13:27, 21 февраля 2010 г. (UTC)

Общие комментарии [ править ]

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

В целом, я думаю, что он хорошо иллюстрирует различия между языками. Мне она больше нравится как отдельная статья, чем как часть страниц C или Pascal. 209.193.109.10 23:40, 4 июня 2005 г. (UTC)

Извините - я не вошел в систему. Эти комментарии от: Gary D Robson 23:41, 4 июня 2005 г. (UTC)

Идентификаторы [ править ]

В разделе «Идентификаторы» автор сначала говорит об «идентификаторах», а затем о «ярлыках». У меня создалось впечатление, что идентификаторы и метки - это одно и то же. В таком случае слово «идентификатор» следует использовать исключительно во избежание двусмысленности. - Серебро, 09:28, 21 июня 2005 г. (UTC)

Избавился от очевидных - Samiam95124 00:32, 25 июня 2005 г. (UTC).

Вложенные функции в C99? [ редактировать ]

С каких это пор в C99 есть вложенные функции? Я что-то упустил? Стандарт не читал.- J I P | Обсуждение 09:47, 21 июня 2005 г. (UTC)

Двумя наиболее интересными дополнениями к C99 были вложенные функции и структурированные параметры VALUE. Все верно, C с каждым днем ​​все больше становится похожим на Паскаль: -) - Samiam95124 00:34, 25 июня 2005 г. (UTC)

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

Я точно не видел этого в стандарте. Дорогой мой, это было бы дурным тоном. Структуры данных могут логически вкладываться. Функции не могут. Я пытаюсь представить это на уровне сборки ... Я думаю, что должен быть прыжок через внутреннюю функцию. :-) Конечно, так не делается, потому что вложенные функции - это иллюзия. Вложенные функции создают множество странных проблем, связанных с областью видимости. Они также делают сообщения об ошибках компилятора менее полезными, потому что компилятор в меньшей степени может определить, когда пользователь перестал закрывать "}". AlbertCahalan 07:28, 24 апреля 2006 г. (UTC)

Это односторонний аргумент. Посмотрите на это с двух сторон. Можно утверждать, что отсутствие процедур и функций локальной области в C приводит к глобальному спагетти-коду, поскольку C не имеет модулей, пространств имен или единиц. Отсутствие процедур и функций локальной области видимости, а также модулей / модулей загрязняет пространство имен в современном C или исходном C. Современный C не поддерживает отдельные модули или пространства имен (в то время как C ++, конечно, поддерживает). У функций и процедур локальной области есть недостатки, но есть и недостатки у глобальных объектов. Функции и процедуры, не определенные локально или в отдельном модуле, иногда могут быть столь же подвержены бедствиям, как и глобальные переменные, учитывая проблемы перегрузки и загрязнения пространства имен. Ни одно из решений не является Святым Граалем. Я бы сказал, что большинство функций локальной области видимости в Паскале можно было бы вместо этого поместить в отдельные блоки,но всякий раз, когда модули помещаются в предложение uses, это по-прежнему означает, что функции и процедуры доступны глобально, поэтому функции с локальной областью видимости могут по-прежнему защищать пространство имен и по-прежнему иметь свои преимущества. Другая идея - иметь предложения Uses внутри процедуры, чтобы можно было вызывать модуль только внутри локальной процедуры (рядом с предложениями VAR и CONST). Таким образом, область видимости будет защищена, а функции и процедуры внутри другого модуля могут быть локальными только для одной процедуры, сохраняя при этом удобочитаемость и раздельную компиляцию. Одна из проблем с вложенными функциями заключается в том, что они могут растягиваться по экрану слишком далеко по вертикали, и потеря концентрации происходит, если гнезда достаточно глубокие и достаточно длинные по вертикали.чтобы можно было вызывать модуль только внутри локальной процедуры (рядом с предложениями VAR и CONST). Таким образом, область видимости будет защищена, а функции и процедуры внутри другого модуля могут быть локальными только для одной процедуры, сохраняя при этом удобочитаемость и раздельную компиляцию. Одна из проблем с вложенными функциями заключается в том, что они могут растягиваться по экрану слишком далеко по вертикали, и потеря концентрации происходит, если гнезда достаточно глубокие и достаточно длинные по вертикали.чтобы можно было вызывать модуль только внутри локальной процедуры (рядом с предложениями VAR и CONST). Таким образом, область видимости будет защищена, а функции и процедуры внутри другого модуля могут быть локальными только для одной процедуры, сохраняя при этом удобочитаемость и раздельную компиляцию. Одна из проблем с вложенными функциями заключается в том, что они могут растягиваться по экрану слишком далеко по вертикали, и потеря концентрации происходит, если гнезда достаточно глубокие и достаточно длинные по вертикали.Одна из проблем с вложенными функциями заключается в том, что они могут растягиваться по экрану слишком далеко по вертикали, и потеря концентрации происходит, если гнезда достаточно глубокие и достаточно длинные по вертикали.Одна из проблем с вложенными функциями заключается в том, что они могут растягиваться по экрану слишком далеко по вертикали, и потеря концентрации происходит, если гнезда достаточно глубокие и достаточно длинные по вертикали.LFiveZeroFive

GCC поддерживает вложенные функции, а C99 - нет. C поддерживает передачу объектов, имеющих структурированный тип, в качестве аргументов функций со времени стандарта C90 (и их возврат). Дерек Фарн 11:11, 24 апреля 2006 г. (UTC)

Borland не правит [ править ]

Было добавлено множество специфичных для Borland языковых элементов, таких как приведение типов, создание строк из указателей и т. Д. Это не «Borland и C», а «Паскаль и C». Если вы хотите сравнить Borland и C, сделайте это отдельной страницей. Помимо Borland, существует МНОЖЕСТВО реализаций Паскаля.

Я не могу согласиться. Будучи программистом на паскале в течение очень долгого времени, я знаю, что все основные компиляторы паскаль в настоящее время поддерживают эти функции, включая Free Pascal и GNU Pascal. Я серьезно сомневаюсь, что вы можете найти еще развитый, который этого не сделал. - Фелипе Монтейро де Карвалью 13:26, 27 августа 2005 г. (UTC)

Так? Borland - это сильно расширенная версия Паскаля. Ваши комментарии полностью подходят для страницы, которая будет называться "Borland Pascal and C". Здесь нет настоящего конфликта. Даже если вы чувствуете, что Borland является доминирующей версией Паскаля, эта статья просто о Паскале в целом, а не о Borland в частности. Пожалуйста, создайте страницу "Borland Pascal и C". Вы даже можете ссылаться на эту страницу и добавлять только то, что различается между версиями Pascal и Borlands (фактически, версиями) и C. Это почти то же правило, которое применялось для страницы языка Pascal. Он документирует все Паскали, кроме того, существуют определенные страницы на Borlands с различными его версиями. Даже если вы ДЕЙСТВИТЕЛЬНО сделали эту страницу конкретной Borland, вам придется выбрать, какую версию Borland обсуждать здесь, от Turbo до Delphi.- Samiam9512422:30, 30 августа 2005 г. (UTC)

Вместо этого я хотел бы называть "Borland Pascal" "диалектом Borland". Я сомневаюсь, что используемая сегодня версия паскаля позволяет программисту определять точную длину «массива символов». Строка уже стала основным типом, длина которого записана в 0-м байте. (на диалекте Borland точно; uncertein на диалекте Mac) Покажите мне парня, который все еще использует паскаль, не относящийся к «диалекту Borland», для серьезной / несерьезной работы в настоящее время. Если вы пойдете изучать Паскаль, практически невозможно выучить диалект, отличный от Borland, если вы не ненавидите Borland. А где МНОГИЕ реализации, не поддерживающие диалект Borland? Назовите мне тот, который все еще активно разрабатывается и / или широко применяется в наши дни. Но может ты и прав. Должно быть две страницы: одна "Паскаль и C (когда они были несколько десятилетий назад) "и один" Паскаль и C (в сегодняшнем мире) ";)

Я являюсь таким пользователем чужого диалекта, и я использую Паскаль дольше, чем существует Borland, с 1980 года. Есть много компиляторов, не относящихся к Borland, в том числе GPC, IP Pascal, Prospero Pascal, Irie tools, DR Pascal, и я уверен, что другие. Я не собираюсь вдаваться в аргументы «кто популярнее». Если вы чувствуете, что вам нужна страница «Borland Pascal vs.C», то обязательно сделайте это. Нет никаких причин превращать общую страницу Pascal, такую ​​как эта, только в Borland. Borland Pascal может иметь свою собственную отдельную страницу, и я даже обозначил некоторые минимальные требования, согласно которым было бы уместно перечислить функции Borland на этой странице (а именно пометить их как функции Borland). короче, нет, другие Паскали, кроме Borland, на самом деле не вымерли, и нет,изменение всех страниц, посвященных Pascal, специфичных для Borland, нецелесообразно и не обязательно. У Borland есть свои страницы. Обратите внимание, что все реализации Паскаля подчиняются этому требованию. Для каждого конкретного Паскаля существует определенная страница, и общие страницы Паскаля говорят в основном о том, что у них общего. На общих страницах Паскаля есть конкретные детали реализации, но они четко помечены в отношении того, какой конкретный Паскаль упоминается. Я также отмечаю, что версии Паскаля Borland (их больше одной) упоминаются на общих страницах Паскаля больше, чем ЛЮБАЯ другая реализация Паскаля.а общие страницы Паскаля говорят в основном о том, что у них общего. На общих страницах Паскаля есть конкретные детали реализации, но они четко помечены в отношении того, какой конкретный Паскаль упоминается. Я также отмечаю, что версии Паскаля Borland (их больше одной) упоминаются на общих страницах Паскаля больше, чем ЛЮБАЯ другая реализация Паскаля.а общие страницы Паскаля говорят в основном о том, что у них общего. На общих страницах Паскаля есть конкретные детали реализации, но они четко помечены в отношении того, какой конкретный Паскаль упоминается. Я также отмечаю, что версии Паскаля Borland (их больше одной) упоминаются на общих страницах Паскаля больше, чем ЛЮБАЯ другая реализация Паскаля.

Я заключу с тобой сделку. Я буду гораздо более склонен оставлять ссылки на конкретные Borland, если они помечены как специфические особенности Borland. У меня также нет проблем с разговором о расширениях к Паскалю (как уже упоминалось в статье), если это обсуждается в общих чертах. Например, фраза «многие Паскаль предоставляют оператор case по умолчанию» не связывает ее с одним конкретным Паскалем и говорит о реализациях Паскаля в целом. Я не являюсь пользователем Borland, однако вы заметите, что я также не пытался включить в этот документ конкретные функции языка Pascal, который я использую. Правило Википедии - NPOV, нейтральная точка зрения. Давайте поговорим о Pascal в целом (и о C в целом!). - Samiam95124 22:51, 30 августа 2005 г. (UTC).

Мне нравится идея отмечать функции из расширений, поскольку это повышает общее качество информации и предотвращает создание «Borland pascal vs C». Я предлагаю отметить эти функции как «Object Pascal». Утверждать, что эти функции принадлежат Borland, совершенно неверно, особенно с появлением сильных проектов с открытым исходным кодом, таких как Lazarus, FreePascal, GnuPascal и других.

Из http://en.wikipedia.org/wiki/Object_Pascal :

Object Pascal был создан Никлаусом Виртом и Ларри Теслером. Он был создан в Apple Computer в начале 1985 года в результате их сотрудничества. Он добавил объектно-ориентированные расширения к существующему языку программирования Pascal. .... В 1986 г. компания Borland представила аналогичные расширения, также называемые Object Pascal, для продукта Turbo Pascal для Macintosh, а в 1989 г. - для Turbo Pascal 5.5 для DOS.

Как видите, "Object Pascal" очень старый и хорошо стабилизированный =) - Фелипе Монтейро де Карвалью 01:56, 8 сентября 2005 г. (UTC)

В целом, у меня нет проблем с этим, но у меня есть вопросы по этому поводу. Во-первых, Apple в значительной степени отказалась от своего Pascal, так что это похоже на историческую справку. Во-вторых, собираетесь ли вы исследовать, что есть, а что нет в Object Pascal и Borland? Большинство модификаций, которые я видел, похоже, происходят непосредственно из версий Borland Pascal. - Samiam95124 20:53, 8 сентября 2005 г. (UTC).

Я считаю, что хорошее исследование этого предмета улучшило бы страницу на стороне Паскаля. Не стесняйтесь исследовать, как хорошо =) - Фелипе Монтейро де Карвалью 23:44, 9 сентября 2005 г. (UTC)

Предостережения относительно языка [ править ]

Я опытный программист на C / C ++ (15+ лет). Но все же иногда делаю ошибку / опечатку:

если (а = 0) {...

Это совершенно законный C (хотя некоторые компиляторы предупреждают об этом). Эта ошибка невозможна в Паскале, где сравнение равно =, а присваивание: =

На самом деле, даже если бы они были одним и тем же оператором в Паскале, это все равно было бы незаконно, поскольку назначение не является оператором в Паскале. - Samiam95124 04:00, 6 октября 2005 г. (UTC)

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

Я не собираюсь останавливаться на достигнутом. Между тем, как C и Pascal обрабатывают присваивание, есть существенные различия и разные причины, стоящие за этим. В C присваивание - это оператор выражения. В Паскале это заявление. Вот почему вы можете выполнять присваивание в любом месте выражения в C. Чтобы быть справедливым по отношению к C, он не перегружает оператор «=», как, например, в Basic. «=» означает присваивание, и есть отдельный оператор равенства «==». Итак, чтобы быть точным, очень распространенная ошибка использования assign там, где имеется в виду равенство, связана либо с тем фактом, что присваивание «выглядит» как равенство, либо с тем фактом, что равенство и присваивание являются операторами, и поэтому непреднамеренная ошибка не является ошибкой. обменять их.

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

Другими важными отличиями являются способ создания типов в объявлениях переменных и способ обработки массивов. Все остальное для меня - синтаксический сахар. Вы можете делать то же самое с другим синтаксисом, и есть различия в доступных операторах. Со временем операторы превратились в практический набор (я все еще скучаю по инструкции with из Паскаля). Сконден ( разговор ) 18:33, 6 октября 2010 (UTC)

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

Ваш последний абзац здесь имеет большой смысл, особенно сравнение с gotos, я считаю, что это материал, который хорошо подошел бы к основной статье! / HenkeB 17:10, 25 июня 2007 г. (UTC)

- Samiam95124 22:15, 22 ноября 2005 г. (UTC)

Чтобы быть более точным, если (а = 0) не является почти никогда не фактической намеченной операцией , в связи с == и = быть очень легко опечатка и очень легко упустить из вида. ИМО стоит отметить это как языковую оговорку - тот факт, что C допускает такие выражения, поддается легко игнорируемым ошибкам , где более строгий язык не допускал бы таких ошибок. Стоит отметить, что Министерство обороны долгое время обязало ADA, которая имеет оценку стиля паскаль и другие языковые конструкции, которые помогают сделать его «более безопасным» языком, чем C. Говоря в общих чертах, Паскаль является более безопасным языком, чем C.

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

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

Пока я занимаюсь этим (а также балансирую), мои личные проблемы со стандартным / турбо-паскалем заключались в невозможности объявлять вещи внутри блоков begin-end (например, "действительно локальные" переменные) и очень жесткой обработке массивов (длина как часть типа), что, на мой взгляд, усложняет программирование, не добавляя дополнительной безопасности.

Подобные препятствия являются центральными для практического использования языков и должны быть доступны для обсуждения (вежливой манерой) также в статье, без начала «языковой войны». Было бы совершенно разумно представить две разные точки зрения бок о бок, чтобы дать читателю более полную картину; возьмем, к примеру, скалярную семантику C, для меня это семантическое ограничение, для многих программистов на C это по своей сути элегантная функция (или ее отсутствие). / HenkeB 17:10, 25 июня 2007 г. (UTC)

Я согласен. Вы можете это добавить? Я также часто делаю эту ошибку в C ++. - Фелипе Монтейро де Карвалью, 23:32, 5 декабря 2005 г. (UTC)

Я тоже согласен, я тоже часто делаю эту ошибку. Сиддхартхаганди, 03:01, 11 ноября 2006 г. (UTC)

Я не согласен. безопасностиаргумент носит слишком общий характер и несет негативный оттенок. Описание должно быть более конкретным. Ошибка (в некоторой степени) обычна при написании программ на C, но семантически маловероятна при написании программ на языке Pascal. Так как они приучили себя следить за этим, опытные программисты с меньшей вероятностью совершат ошибку и с большей вероятностью обнаружат ее, когда все же сделают. Однако ошибка может увеличить время отладки, потому что программист должен будет определить наличие проблемы (что не всегда очевидно, особенно с условными выражениями), определить ее причину (что может занять некоторое время с большими или сложными программами) и затем исправьте его (что должно быть относительно легко после определения и изолирования). Вывод о том, что один язык безопаснее другого, должен сделать читатель:хотя это может быть представлено как общее мнение программистов на языке Pascal (и даже C). Это не должно быть представлено как действительное заявление без каких-либо оговорок.Кболино 04:13, 28 января 2007 г. (UTC)

Название [ править ]

Разве эта статья не должна быть озаглавлена ​​«Сравнение Паскаля и Си» для соответствия стандартам? Кроме того, я считаю, что MirrorVax был прав в своих изменениях в категории - это не статья о языке программирования, это статья, в которой сравниваются два языка, и ее следует обозначить соответствующим образом. .:. Джарет .:. ^babelfish 05:18, 18 декабря 2005 г. (UTC)

Теги очистки [ править ]

Я добавил в эту статью четыре тега очистки:

• Тон: Проза в этой статье написана в неформальном стиле эссе и перемежается чрезмерным количеством примеров кода.
• Противоречие: статья противоречит сама себе в нескольких местах, особенно в последних двух частях текста («Паскаль« Голубое небо »» и «Эпилог»).
• Без ссылок: в статье делается ряд безотзывных заявлений об отсутствии определенных функций, особенно в C. Внимательное чтение спецификации C99 показывает, что многие из этих нецитированных утверждений являются ложными.
• Важность: Какая информация в этой статье еще не доступна на языке программирования C и языке программирования Pascal ?

- donhalcon, ^╤ 05:57, 6 марта 2006 г. (UTC)

Я согласен с тегом "Без ссылки". Объясните, пожалуйста, остальные три тега.

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

• «Важность». Во-первых, сама эта тема много раз была в центре многих дискуссий. Затем, читая как язык программирования C, так и язык программирования Pascal, я мог только сделать вывод о различиях, но не найти их. (вы действительно хотите переместить эту отдельную страницу на страницы C и Pascal? Есть и другие теги для этого предложения. Что еще более важно, помимо избыточности, это сделает страницу C о Pascal, а Pascal о C, а редактирование непрактично)
• «Противоречие» - противоречий не нашел. Я только обнаружил, что читателям нужно сосредоточиться на той части, которую вы упомянули, потому что многое сказано всего несколькими словами и не так структурировано. Статья действительно нуждается в помощи, это правда, но
  • Нет противоречия между утверждением, что языки структурно очень похожи (если, для, пока, функции, АЛГОЛ-происхождение), но обработка типов параметров отличается (очень строгие и динамические).
  • Кроме того, нет противоречия между практической целью обработки различных типов и тем, что программист в принципе мог бы программировать таким образом (слишком сложным для практики), что это различие было бы преодолено.
  • Ни одно противоречие не говорит о том, что эволюция компиляторов сближает программирование.

- ActiveSelective 09:26, 25 марта 2006 г. (UTC)

POV [ править ]

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

Однако это не делает мои возражения недействительными. В статье описывается оригинальный Паскаль 1970-х годов. Это личная точка зрения, что современный Паскаль заимствовал черты языка C и, следовательно, был бы равен C. Факты таковы:

• • Современный Паскаль намного лучше, чем Паскаль 70-х годов.
  • Некоторые функции, которые были добавлены, также присутствуют в C, например, приведение типов, арифметика указателей.
  • Многие из них - нет, то есть единицы, строки, свойства, интерфейсы.
  • C также взял особенности Паскаля, то есть логические значения, перечисления, вложенные процедуры и параметры var.

Почему-то в статье нет проблем с сравнением C99 с Паскалем 70-х годов. Тот факт, что некоторые функции C присутствуют, не делает Pascal C, как предлагается в статье. Паскаль остается строго типизированным языком, по-прежнему нечувствителен к регистру, по-прежнему имеет ограниченные массивы, по-прежнему предотвращает ошибки «if (a = b)» и так далее. И C не стал Паскалем, взяв на себя функции Паскаля.

Тот факт, что Borland ввела множество расширений, не может служить оправданием. Расширения Borland реализуются всеми компиляторами Pascal, Delphi, Virtual Pascal, Free Pascal, и код между этими компиляторами совместим. Даже GNU Pascal, который не реализует диалект Borland, реализовал расширения Borland. Также необходимо сказать, что многие люди, которые приписывают расширения Borland, не знают своей истории, поскольку многие функции диалекта «Borland» происходят от USCD-Pascal. Это факт, что расширения не были формализованы в стандарте ISO, как в случае с C. Это правильное сравнение, и в статье также необходимо обсудить особенности расширенного стандарта ISO Pascal.

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

Точка зрения, которую вы здесь описываете, принадлежит вам. У меня не было и не было проблем с вашим предположением о Dephi, но это должно быть четко обозначено «Delphi vs. C», а не «Pascal vs. C». Borland больше не описывает свой продукт как «Паскаль», и на то есть веские причины.

Описание оригинального Паскаля как «несуществующего» языка - это ваше собственное мнение, причем весьма пристрастное. Фактически существует несколько таких реализаций, см. Страницу Pascal. То, что вы описываете, в худшем случае - языковой фанатизм. Значит, вам нравится диалект вашего конкретного языка. Отлично. Однако вы чувствуете необходимость оскорбить оригинальный Паскаль. Если вас беспокоит существование другого диэлектрика Паскаля, это ваша личная проблема, а не наша.

В любом случае вы получили то, что хотели. Эта страница превратилась в страницу «Delphi vs. C». Итак, все счастливы, правда?

- Samiam95124 23:25, 2 марта 2007 г. (UTC)

нл: Гебруйкер: Даниэльм

Я думаю, было бы справедливо рассмотреть возможности Паскаля, которые идентичны во всех популярных компиляторах Паскаля, не слишком много играясь с переключателями командной строки. Нельзя сосчитать то, что реализовано иначе. Вы не можете сосчитать и Borland, и возможности ISO, если популярный компилятор не может поддерживать обе функции одновременно. (то есть с той же командной строкой) Примечание: если вы это сделаете, то вы должны будете сказать, что современный Паскаль не определен никаким стандартом. Вы можете предпочесть придерживаться второго стандарта ISO, чтобы сказать, что Паскаль стандартизирован. AlbertCahalan 07:17, 24 апреля 2006 г. (UTC)

Стандартизация Паскаля - определенно проблема, и статья должна сказать правду в этом отношении. Проблема второго стандарта ISO состоит в том, что он является только стандартом на бумаге, а не стандартом, который реализуется совместимыми компиляторами. (GNU-Pascal - единственный компилятор, который реализовал его до сегодняшнего дня.) Это потому, что он несовместим с действующими стандартами (компилятор ISO не может компилировать код USCD, Turbo Pascal или Delphi), поэтому промышленность не могла сделать их компиляторы совместимы с ISO без нарушения всего существующего кода.

Если вы хотите поговорить о стандартизации Паскаля, лучше всего рассматривать оба стандарта ISO в качестве отраслевого стандарта, который является языком, разработанным с помощью USCD, Turbo Pascal и Delphi (а также реализуется Free Pascal, Virtual Pascal и многими другими. компиляторы). нл: Гебруйкер: Даниэльм

В приведенном выше утверждении есть несколько ошибок. Во-первых, несколько компиляторов реализуют стандарт ISO, а не только GNU (см. Страницу Pascal для этого). Во-вторых, стандарт ISO появился ДО Turbo / Delphi, поэтому проблема не в том, что стандарт ISO нарушит существующие реализации, а в том, что Borland предпочла игнорировать стандарт. Это делает последний пункт нерелевантным, поскольку задача стандарта - не изменять до несовместимости, чтобы адаптироваться к более поздним компиляторам, которые проигнорировали первый стандарт. Если бы стандарт Borland существовал, это был бы отдельный стандарт.

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

- Samiam95124 23:15, 2 марта 2007 г. (UTC)

Действительно мой POV. Давайте отделим POV от фактов, сначала факты:

1. Стандарт ISO появился * после * UCSD Pascal.
2. Такие языковые функции, как строки и единицы измерения, являются функциями UCSD Pascal. Процедуры библиотеки времени выполнения, такие как fillchar, также являются функциями UCSD.
3. Поэтому стандарт ISO игнорировал чрезвычайно влиятельный компилятор.
4. Borland проигнорировал стандартный, но не UCSD Pascal. Диалект Turbo имеет замечательную обратную совместимость с диалектом UCSD-Pascal.
5. Think (на платформе Macintosh) не игнорировал стандарт, но также не игнорировал UCSD-Pascal.
6. Мне не известно о каких-либо поломках в диалекте Borland, за исключением переключения с Turbo Pascal -> Delphi
7. То, что в статье считается "Паскалем", - это Паскаль 1970 года.

Теперь точка зрения: некорректно сравнивать Паскаль 1970 года с современным C99. нл: Гебруйкер: Даниэльм

Может, стоит разделить на две статьи? Что-то вроде «Историческое сравнение» и «Современное сравнение»? Клег 23:57, 14 июня 2007 г. (UTC)

Я не против, но не думаю, что это необходимо; статья уже намного лучше, чем раньше; особенно оригинальный раздел "Blue Sky Pascal" действительно наводил на размышления. Существуют две основные ветви языка Паскаль, ISO и UCSD. Люди программировали не на Паскале 1970 года, а на компиляторах, которые реализовали одну из этих ветвей.

Чтобы сделать статью более сбалансированной, необходимо провести это различие. Т.е. недавно был адаптирован раздел о струнах, и я поддерживаю это изменение, но это не полная история, и здесь оригинальный POV имеет смысл. Давайте составим график развития языка Pascal вместе с датами появления влиятельных компиляторов (на самом деле я не считаю GNU влиятельным компилятором, но я перечисляю его, поскольку он является наиболее заметным представителем ISO Extended Pascal):

 Паскаль | Паскаль: 1970 / \ UCSD: 1977 / \ ISO: 1983 UCSD ISO Turbo: 1984 / \ / \ Думаю: 1986 / \ / \ ISO в расширении: 1990 / Думайте \ Free Pascal: 1995 Borland | ISO расширенный Delphi: 1995 | Метроверкс \ GNU: 1989 | | | Метроверкс: 1994?

Текущий текст о строках отдает должное всем компиляторам примерно после 1990 года и компиляторам из ветви UCSD задолго до этого. Мы бы плохо проинформировали читателя, если бы сказали, что в Паскале были только массивы символов 1970 года, как в исходном тексте. Однако, чтобы правильно проинформировать читателя, мы не можем опустить информацию о том, что строка появилась не сразу, и, что наиболее важно, ISO Extended имеет синтаксис, отличный от UCSD. (Я думаю, что именно здесь ISO потерпел неудачу, в 1990 году индустрия уже давно приняла метод UCSD как универсальный.)

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

нл: Гебруйкер: Даниэльм

С большим согласием не могу, во всяком случае, не особо. / HenkeB 13:55, 25 июня 2007 г. (UTC)

Я собираюсь перейти к этому еще раз. Вышеупомянутое - сложное произведение, но это сложное художественное произведение. Идея состоит в том, чтобы представить идею о том, что UCSD является ответвлением от «исходного» Паскаля, затем ISO возник в завершение с этим, затем Borland был основан на «альтернативной» ветви UCSD. О, я не сомневаюсь, что авторы этому верят. Однако он не соответствует какой-либо доступной документации.

UCSD был создан как несовместимый диалект Паскаля. Это было несовместимо из-за нескольких упущений, преднамеренных или иных, из Wirths 1973 Pascal, как указано в Отчете. ISO просто стандартизирует язык Паскаль 1973 года. Кроме того, Borland также не совместим с UCSD. Фактически, UCSD реализует несколько стандартных элементов, таких как обработка файлового буфера и процедуры get () и put (), чего нет в Borland. Вот и все, что Borland является «филиалом» UCSD.

Давайте сделаем это просто. Не будет реалистичного обсуждения такого рода вещей до тех пор, пока пользователи Borland / FreePascal отказываются проводить даже базовые исследования истории, языка и стандартов Паскаля. Вы читали стандарт ISO? Вы читали отчет Вирта за 1973 год? Я не говорю, что это отрицательно, просто если бы вы прочитали оба, вы бы поняли, что ISO Pascal и Wirth 1973 Pascal - это один и тот же язык, так же как вы бы поняли, что UCSD и Borland - нет.

—Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 01:51, 17 октября 2007 г. (UTC)

Позвольте мне также добавить эту простую идею. Вышеупомянутое обсуждение, очевидно, было создано людьми FreePascal. Если вы потратили ПОЛОВИНУ столько же работы, сколько и ПОСТАВКА исходного языка Паскаль и стандарта на реализацию небольших различий между исходным Паскалем и FreePascal в вашем компиляторе, все это не будет проблемой. Это даже не борьба FreePascal. Это была бесполезная борьба, которую Borland начал «доказывать» свое превосходство, изменив исходный язык на собственный язык по своему выбору.

GPC (GNU Pascal) последовал разумному пути создания компилятора, совместимого как с Borland, так и с исходным языком, и на самом деле большинство различий даже не противоречат друг другу. Например, функции get (), put () и доступ к файловому буферу могут быть добавлены в компилятор, совместимый с Borland, без какого-либо влияния на его совместимость с Borland.

Суть в том, что вы здесь идете по тонкой линии. Если вы продолжаете утверждать, насколько ГЛУПОЧЕН оригинальный язык Паскаль, то почему он был достоин того, чтобы на нем был основан ваш замечательный FreePascal? Это настоящая причина, по которой люди, работающие с FreePascal, должны «доказать», что стандарт ISO 7185 каким-то образом незаконнорожденный. —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 19:46, 6 ноября 2007 г. (UTC)

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

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

Имейте в виду, что пропаганда ISO возвращается к нам так же, как вы понимаете точку зрения и различия Borland.

Что касается включения стандартных функций iso: Флориан уже заявил, что исправления, исправляющие функциональность ISO, приветствуются в период 1997-1998 годов, и с тех пор это неоднократно повторялось (например, в comp.lang.pascal. *). Разработчики Apple Pascal выпустили ряд патчей (и даже большую работу), но ни один из них не был особенно заинтересован в стандартах. Количество других исправлений, касающихся соответствия ISO, равно нулю .

88.159.74.100 ( разговорное ) 14:19, 29 июля 2009 (UTC) (Марко)

Простые типы [ править ]

В статье говорится, что C поддерживает различные размеры и режимы со знаком / без знака для целых чисел с помощью таких модификаторов, как long, signed, unsigned и т. Д. Точное значение результирующего типа int зависит от машины. В Паскале тот же конец выполняется путем объявления "поддиапазона" целых чисел.

Однако я помню, что у паскала были разные «целочисленные» размеры: логическое, короткое, char, байтовое, целое, слово (беззнаковое целое), longint и двойное слово / кардинал (беззнаковое longint). Они могут зависеть от компилятора и платформы, но все компиляторы pascal, которые я помню (turbo / borland pascal, gpp, freepascal + несколько других), поддерживали их, что означает, что они являются стандартами де-факто и поэтому должны быть упомянуты или, в качестве альтернативы, статья переименована на Сравнение стандартов Pascal и C вместо текущего названия, что подразумевает более практические различия в использовании (в этом случае изображение Паскаля, которое изображается в статье, ужасно устарело). - G3, 13:25, 3 апреля 2006 г. (UTC)

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

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

- Samiam95124 23:31, 2 марта 2007 г. (UTC)

"type longint = -2147483648..2147483647", определенный в системном блоке, не противоречит никакому правилу языка Pascal. Да, я считаю (это моя точка зрения) это часть языка, поскольку большинство баз кода Pascal использует его. Покажите мне живую базу кода в оригинальном Паскале, и мы поговорим. нл: Гебруйкер: Даниэльм

Я думаю, вы неправильно поняли. Никто не спорит, что расширения Паскаля (например, longint) могут и имеют право на существование. Мы обсуждаем, должны ли расширения каждой реализации Паскаля уместны на странице, посвященной языку Паскаль. Определенно есть место для обсуждения longint для Delphi и C, но это страница «Delphi vs. C», и вы можете написать ее и дать ссылку из этой статьи на нее. —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 20:01, 26 декабря 2007 г. (UTC)

Указатели функций C против функциональных аргументов Паскаля [ править ]

Интересно, стоит ли включать сравнение между указателями функций C и функциональными аргументами Паскаля. Я считаю, что это различие имело важное историческое значение.

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

Хм? Тогда не используйте вложенные функции, если не хотите. Используйте указатели на обычные функции. Вы можете хранить ссылки на функции в структурах данных в FPC / Delphi.

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

Хм? Вы можете сохранить указатель на функцию в структуре данных в FPC / Delphi.

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

Это сделало возможным в программах на C то, что было сложно или невозможно в программах на языке Pascal. Например, структура, содержащая указатели на функции, может использоваться как объект в объектно-ориентированном программировании.

Хм? В FPC / Delphi и других популярных языках Pascal вы также можете подделывать объектную ориентацию, используя указатели на функции, а также подделывая SELF. Указатели на функции, хранящиеся в записи, действуют как методы получения / установки. Чтобы смоделировать ориентацию объекта, все, что вам нужно сделать, это объявить структуру данных записи с указателями функций и передать параметр SELF в каждую функцию, которая ссылается на запись. Поскольку процедурный код ничего не знает о SELF, структура данных записи должна быть передана каждой функции, и она действует как self. Точно так же в C вам придется сделать то же самое.

Драйверы ядра Unix могут храниться в таблице, содержащей указатели на код для обработки каждого типа устройства. Клег 15:19, 2 сентября 2006 г. (UTC)

Конечно, я верю, что ваш текст выше может быть более или менее вставлен «как есть» прямо в статью. Я лично не люблю формулировки типа «первоклассный», однако лучше напишите их, «можно хранить и манипулировать» или что-то в этом роде.

Cheers / HenkeB 01:10, 3 сентября 2006 г. (UTC)

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

Хм ... мне также приходит в голову, что, возможно, стоит упомянуть, что логические операторы в Паскале не замыкаются, в то время как операторы в C делают. Что ж, я постараюсь написать несколько дополнений, если у меня будет время, но я не обижусь, если кто-то меня опередит. Клег 17:20, 4 сентября 2006 г. (UTC)

Обязательно стоит упомянуть. / HenkeB 17:43, 5 сентября 2006 г. (UTC)

Думаю, вопрос заключается в том, должно ли это быть историческое сравнение или современное сравнение. Если мы включим как расширения gcc в C (например, вложенные функции), так и расширения Delphi в Pascal (например, указатели на функции), мы потеряем некоторый исторический контекст. Если мы сравним исторические версии C (скажем, K&R или K&R 2) с историческими версиями Pascal (такими как версия, описанная в Pascal User Manual and Report ), у нас будут поклонники обоих языков, постоянно указывающие на то, что современные версии имеют больше возможностей. Kleg 18:58, 30 января 2007 г. (UTC)

Это нормально. Альтернативой является попытка в этой статье сравнить две непрерывно движущиеся цели. Почему бы не открыть его и для C ++, поскольку многие версии Паскаля имеют объектную ориентацию? Суть в том, что явно существует официальный C и столь же явно официальный Паскаль, оба возникли примерно в одно и то же время, оба были стандартизированы примерно в одно и то же время. Если цель состоит в том, чтобы сравнить «современные» [1] версии языков друг с другом, тогда это нормально, это просто должно быть на отдельной странице, например, «delphi vs. C» или что-то еще. [1] Я заключил слово «современный» в кавычки, потому что этот термин часто используется в качестве отрицательной коннотации для языка Borlands, который несовместим с Паскалем (стандартная спецификация языка или спецификация оригинального языка Wirths). На самом деле существует несколько «современных»компиляторы, которые также реализуют оригинальный Pascal, GCC, IP и другие. —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 19:56, 19 декабря 2007 г. (UTC)

Должна ли существовать статья? [ редактировать ]

Я не думаю, что он должен существовать. Эти два языка в лучшем случае слабо связаны, и один на самом деле не произошел от другого. Эта статья объясняет несуществующую «связь». Сиддхартхаганди 03:00, 11 ноября 2006 г. (UTC)

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

Теперь эта страница, если она вообще существует, должна быть «сравнением Delphi и C», поскольку она охватывает язык Delphi, а не Паскаль.

- Samiam95124, 22:58, 2 марта 2007 г. (UTC)

Я согласен с тем, что сравнение современных диалектов C и Delphi не очень полезно, но сравнение «Standard Pascal» с K&R или K&R 2 имеет историческое значение. Си и Паскаль были основными языками системного программирования на протяжении многих лет. То, как функции, которые у них были в то время, взаимодействовали с потребностями программистов того времени, и характер оборудования, которое они использовали в то время, оказали примечательное историческое влияние. Клег 00:16, 6 марта 2007 г. (UTC)

Я согласен, это было то, о чем я думал, когда делал свой вклад - сравнение первоначальных целей дизайна Вирта и Ричи. Довольно скоро некоторые люди начали утверждать, что C = C99 (чтобы иметь возможность сказать, что C имеет логические типизированные переменные и тому подобное), и это заставило меня почувствовать, что я зря трачу время. Тем не менее, я определенно поддерживаю идею сделать это в двух отдельных статьях, таких как « Паскаль против K&R C» (1978, когда C стал достаточно стабильным) и « Delphi / FreePascal против C99 / C ++» (сегодня) / HenkeB 09:02, 25 июня 2007 (UTC)

Я нашел эту статью достаточно интересной для чтения, но, хотя основной план статьи хорош, детали сравнения в самом тексте выглядят нечетко. Я голосую за удаление этой страницы, если только это «нечеткое» не будет удалено. (Строки идут от C до Паскаля без реальной границы, это затрудняет чтение и окончательное понимание различий.) Коэн Лермакерс 21:03, 6 марта 2007 г. (UTC)

Тип экранирования [ править ]

Пример C не имеет особого смысла:

int a;float b;а = (число) и б;

Я подозреваю, что это должно было быть:

int a;float b;a = * (int *) & b;

Первый переводит указатель на b в a; это не неопределенное поведение. Последнее является неопределенным поведением, но действительно на многих машинах сохраняет некоторые биты float b в int a.

Меняю статью. - Дероберт 17:29, 12 апреля 2007 г. (UTC)

Я не думаю, что этот пример демонстрирует что-то полезное. По сути, последний оператор можно синтаксически упростить до следующего:

а = (int) b;

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

int * a;float * b;а = (int *) b;

Что кажется более полезным (вместо того, чтобы создавать указатель из примитива, чтобы просто изменить его тип, а затем разыменовать его обратно на примитив). В качестве примечания: я думаю, что вы использовали «прежний» и «последний» неточно, поскольку чтение вашего сообщения не имеет никакого смысла в зависимости от того, что вы предприняли. - Кболино 05:21, 13 апреля 2007 г. (UTC)

LL (1) синтаксический анализ [ править ]

В этом я не совсем уверен, но я, кажется, помню, как читал или слышал, что Паскаль - это LL (1), а C - нет. Если это правда, это очень важно и заслуживает упоминания в разделе «синтаксис», возможно, в части «Реализация». - Andyluciano 17:57, 10 июля 2007 г. (UTC)

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

Я создал интерфейсы как для Pascal, так и для C, я ручаюсь за нестандартный синтаксис C. C, безусловно, поддается синтаксическому анализу, но в значительной степени полагается на зависимости от контекста. Это не ошибка. Вы можете создать язык, который является регулярным до такой степени, что его можно будет проанализировать, не учитывая тип объявленных в языке символов. На самом деле практически нет языков, соответствующих этой высокой планке. Паскаль терпит неудачу только в одном пункте, в том факте, что присваивание (a: = n) требует контекста символа для его анализа («a» может быть функцией или даже результатом функции). Язык C был создан с идеей, что его нотация должна быть как можно короче, включая использование декларативной информации для управления синтаксисом.

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

В любом случае трудности с синтаксическим анализом C являются трудностями для разработчика, а не для пользователя, что, возможно, является одной из причин не упоминать об этом здесь, поскольку эта статья в первую очередь посвящена пользователям. Единственное чистое влияние на пользователя заключается в том, что ошибки, как правило, менее исправимы в C, чем в Pascal (то есть синтаксические ошибки, как правило, приводят к рассинхронизации компилятора с исходным кодом), что приводит к правилу, что «все ошибки после первое следует игнорировать ". —Предыдущий комментарий без подписи, добавленный 66.28.253.185 ( обсуждение ) 19:53, 26 декабря 2007 г. (UTC)

Работа над заменой [ править ]

В верхней части текущей страницы написано, что требуется помощь специалиста. Будучи одним из них, я решил завести страницу. Вы можете получить доступ к нему на пользователя: PGSONIC / Pascal и C . Не стесняйтесь добавлять или удалять информацию (но я всегда буду редактировать). Когда я чувствую, что на странице достаточно, эта страница будет заменена. - PGSONIC 20:12, 22 июля 2007 г. (UTC) (исправлена ​​ошибка PGSONIC 20:15, 22 июля 2007 г. (UTC))

Я не знаю, почему вы считаете, что страницу нужно заменить,

но простой взгляд на вашу страницу показывает серьезные ошибки:

ПРОГРАММА X; VAR

 A: УПАКОВАННЫЙ Массив [1..5] СИМВОЛОВ; B: УПАКОВАННЫЙ Массив [1..6] СИМВОЛОВ;

НАЧИНАТЬ

 A: = 'Привет'; B: = "Планета"; ЕСЛИ A <> B ТО В: = А;

КОНЕЦ.

Вышеупомянутая программа не является действующей программой на Паскале. A и B несопоставимы, на самом деле это не совместимые типы во всех известных реализациях Pascal, включая Borland. Эта программа не будет компилироваться, о чем вы бы узнали, если бы действительно попробовали.

Вы хотите переосмыслить свою историю о том, что вы «эксперт» по Паскаля (как вы утверждаете выше)?

Кажется, что пар, выходящий из ваших ушей, затуманивает ваше зрение. Обратите внимание, что он заявил: «... следующая программа недействительна» Крис Берроуз ( выступление ) 23:18, 26 декабря 2007 г. (UTC)

Использование точки с запятой [ править ]

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

if(0) { } else { }

2. Использование точки с запятой в объявлении - я действительно ненавижу неструктурированное письмо, которое требует большого количества синтаксического анализа . это не лучший вариант, но я чувствую, что всю страницу нужно сделать похожей. —Предыдущий комментарий без подписи, добавленный 84.16.123.194 ( обсуждение ) 17:03, 25 февраля 2008 г. (UTC)

Является ; утверждение? [ редактировать ]

Я прочитал это утверждение на Паскале. Но если бы это был оператор, то он был бы разрешен между if и else, * righ before * else. Может кто это прояснить? 84.16.123.194 ( разговорное ) 17:31, 25 февраля 2008 (UTC)

«есть» не является утверждением. Это оператор типа «+» или «и». —Предыдущий комментарий без знака добавлен 217.168.74.9 ( обсуждение ) 14:56, 23 мая 2008 г. (UTC)

Нет, ";" это не заявление. Это разделитель утверждений. Таким образом, в «if x then;» точка с запятой отделяет оператор if от следующего оператора. Также случается, что в качестве контролируемого оператора «then» добавляется пустой оператор, что совершенно законно. Таким образом, «if x then; else ...» не является законным утверждением, потому что следующий оператор после if - «else ...», который не является допустимым утверждением.

Я не знаю, почему у людей так много проблем с этим, это соответствует использованию английского языка и имеет смысл в целом. Вы говорите: «Я приготовил обед, А ЗАТЕМ я убрал комнату, А ЗАТЕМ спал», таким образом: «Я приготовил обед; я убрал комнату; я спал». Не лучшее использование, но без намерения. Сравните это с идеей других языков, которые всегда требуют «терминатора», такого как точка с запятой. Это все равно что сказать: «Я приготовил обед И». И что?

Источник [ править ]

Источник, который было бы полезно процитировать: http://portal.acm.org/citation.cfm?id=14947.14950&coll=GUIDE&dl=GUIDE&CFID=606445&CFTOKEN=44901229 —Предыдущий комментарий без подписи, добавленный 137.222.107.22 ( обсуждение ) 15:32 , 9 ноября 2008 г. (UTC)

Хорошее предложение. Выполнено. Крис Берроуз ( разговор ) 22:52, 9 ноября 2008 г. (UTC)

Поддиапазоны, продвижение [ править ]

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

Есть ли в оригинальном Паскале тип «BYTE»? Определяет ли исходный Паскаль, что целое число должно быть не менее 16 бит?

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

Если не 8 бит, о каком еще "поддиапазоне" может быть речь в этом разделе, который мог бы сделать C эффективным? —Предыдущий комментарий без подписи, добавленный 203.206.162.148 ( обсуждение ) 04:36, 9 декабря 2009 г. (UTC)

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

В C обычно результирующий тип операции между двумя целыми числами имеет точность, равную точности двух операндов. Обычно это приводит к неэффективному коду, поскольку перед операцией вам необходимо привести операнды к более высокой точности. - Предыдущий неподписанный комментарий добавлен 203.206.162.148 ( обсуждение ) 07:52, 30 ноября 2011 г. (UTC)

Связывание, эпилог [ править ]

Фундаментальное различие между Original C и Original Pascal состоит в том, что Original Pascal не определял и не предусматривал связывание внешнего источника, объектов или библиотек. Никлаус Вирт обратился к этому на своем следующем языке (Modula), и компиляторы обратились к нему по-разному. В то время по этому аспекту языкового дизайна велись серьезные споры.

C, «небольшой язык всего из 32 ключевых слов» - это пустой язык без библиотеки C, которая была системной библиотекой, которая была операционной системой. (Определение POSIX по-прежнему включает полное определение библиотеки «C»). Это означает, что вы можете реализовать C без реализации библиотеки, вы можете заменить библиотеку и иметь явный контроль над тем, какие части библиотеки вы хотите использовать или реализовать. Это сделало C особенно подходящим для ситуаций, когда у вас нет библиотеки или вы не хотите использовать библиотеку: в частности, для написания ОС или частей ОС или драйверов ОС. По умолчанию все функции C являются общедоступными, то есть доступны для внешних ссылок. А стандартным способом написания программ на C была серия независимых исходных объектов, которые были скомпилированы,затем связаны таким же образом, как и системная библиотека. Однако отдельные объекты и стандартный интерфейс связывания накладывают фундаментальные ограничения на оптимизирующий компилятор.

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

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

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

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

Кратковременным результатом стало то, что компиляторы Паскаля генерировали небольшие, быстрые, правильные программы, но были непригодны для системного программирования. C был более подходящим для системного программирования, но компиляторы C создавали приложения, которые были небольшими и быстрыми только по сравнению с Lisp, а не по сравнению с FORTRAN или Pascal.

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

Способ получения небольшого, быстрого кода C аналогичен тому, как они получили небольшой быстрый код Pascal: поместите весь свой код в один файл, объявите все свои функции как статические (то есть локальные, частные) и избегайте использования (внешних) библиотечные функции. В свое время программисты использовали файлы .INC и .DEF и включали код в файлы .H. Встроенные компиляторы и компоновщики C теперь имеют нестандартные языковые расширения, чтобы помочь вам в этом, например -fWhole-Program в GCC.

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

Дело не в том, чтобы сравнивать исполняемые файлы из Паскаля и C (кого это волнует?). Дело в том, что было оригинальное дизайнерское решение (автономная программа против связанных объектов), которое имело внешние и внутренние эффекты. —Предыдущий комментарий без подписи, добавленный 203.206.162.148 ( обсуждение ) 05:44, 9 декабря 2009 г. (UTC)

Строки в Паскале [ править ]

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

var  somestring :  строка ;begin  somestring : = 'Wikipedia,'  +  # 0  +  //  Пустой символ 'The Free Encyclopedia' ;  WriteLn  ( SomeString ) ;  // Результат: Википедия, конец бесплатной энциклопедии

У меня есть целых десять надежных источников в письменных книгах и электронной документации для этого моего утверждения. Но прежде чем я переписываю раздел String, я хотел бы услышать объяснение того, кто сделал это, казалось бы, неверное утверждение, не ссылаясь на надежный источник . Командование флотом ( разговор ) 19:10, 3 февраля 2010 г. (UTC)

http://standardpascal.org/The_Programming_Language_Pascal_1973.pdf

В котором вы увидите «строки ... это ... упакованный массив [1..n] of char»

То есть есть строки, но нет строкового типа.

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

Эта статья о языке, который был разработан в конце 60-х - начале 70-х годов. Тот факт, что язык был разработан без строкового типа, является интересным и важным моментом именно потому, что строковые типы настолько важны, что реализации добавляли их (формализовано 20 лет спустя в стандарте ISO 1990 года). Паскаль и Си были частью последнего поколения языков, которые проектировались без строковых типов. Это уже было известно как ограничение FORTRAN, было исправлено в BASIC и исключено в COBOL. —Предыдущий комментарий без подписи, добавленный 203.206.162.148 ( обсуждение ) 03:03, 8 февраля 2010 г. (UTC)

Во-первых: ваша ссылка не работает. Посмотрим, смогу ли я получить его через Google Cache или Web Archive.

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

На данный момент я помечаю эту статью как устаревшую. Я посмотрю, исправлю ли я это позже. Командование флотом ( разговор ) 08:50, 8 февраля 2010 г. (UTC)

Боже! Вы читали какую-нибудь статью? Или этот раздел разговоров? Вернись и сделай это снова!

Я не писал эту статью. Смысл и цель этой статьи ясны. И вы собираетесь это «исправить»?

Хочу отметить, что предоставленная ссылка все еще работает. 203.206.162.148 ( разговорное ) 00:40, 17 февраля 2010 (UTC)

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

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

В-третьих, нет, мне, наверное, некогда в жизни. Я занятой человек. Но я также не сижу, когда читатели Википедии приходят к этой статье, читают фактически неточные материалы и получают дезинформацию. Так что я делаю все, что мог: помечаю это. Командование флотом ( разговор ) 11:37, 17 февраля 2010 (UTC)

Прочтите статью еще раз и обратите внимание, в частности: «Здесь задокументирован Паскаль Никлауса Вирта, стандартизированный как ISO 7185 в 1982 году». Существует более поздний стандарт, датированный 1990 годом, но определение строк не изменилось. Есть и было так много несовместимых различных расширений Паскаля, что любая попытка охватить их здесь сделала бы всю статью неуправляемой. Вы можете получить копию Стандарта по ссылке на странице Паскаль (язык программирования) . Ваше представление о строковом типе указывает на то, что вы могли быть введены в заблуждение ссылками на нестандартные версии Паскаля.

Глобальные теги особенно бесполезны. Пожалуйста, определите ласки слова. Крис Берроуз ( разговор ) 12:32, 17 февраля 2010 г. (UTC)

«То, что здесь задокументировано, - это Паскаль Никлауса Вирта», поэтому оно устарело и фактически неточно. Обновите его, чтобы отразить факты, независимо от того, соответствуют ли факты этому устаревшему стандарту или нет.

Тот факт, что он старый, не делает его фактическим неточным. При разработке стандарта ISO были внесены лишь минимальные изменения. Более поздних версий с 1990 года не было. Не путайте определение Паскаля с различными реализациями Паскаля. Как говорится в предисловии к Руководству пользователя и отчету Pascal: «Разработчик должен рассматривать задачу распознавания Standard Pascal как основное требование своей системы ... Конечно, отдельные реализации могут предоставлять дополнительные возможности, которые, однако, должны быть четко определены. помечены как расширения ".

Строковый тип Паскаля - это расширение, например, Delphi (он же Object Pascal) имеет полдюжины встроенных «строковых типов». Фактически было бы правильно указать, что такой строковый тип существует в статье, которая, например, сравнивает Turbo Pascal с Microsoft C или Embarcadero Delphi с Microsoft Visual C ++. Утверждать, что Standard Pascal имеет строковый тип, неверно. Крис Берроуз ( разговор ) 00:50, 18 февраля 2010 г. (UTC)

Что касается ласковых слов , их нельзя не заметить: они повсюду.

Вот несколько примеров:

Статья начинается с:

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

Я подчеркнул ласковые слова.

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

Как видите, глобальные теги очень полезны. Если вы намеренно не закроете глаза на ласковые слова, вы увидите их на протяжении всей статьи. Для получения дополнительной информации посетите WP: WEASEL и WP: Слова, которых следует избегать . Командование флотом ( разговор ) 22:54, 17 февраля 2010 г. (UTC)

Эти примеры были удалены. Слова ласки субъективны по определению. То, что вам может показаться ласковыми словами, может не показаться таковым другим. Удалите все, что вам известно, и я перепровечу, чтобы убедиться, что вы не нарушили фактическую точность статьи. Крис Берроуз ( разговор ) 00:50, 18 февраля 2010 г. (UTC)

ПЕРВЫЙ: Пожалуйста, будьте осторожны! Вы только что добавили больше ласковых словечек. Можно с пользой , без источника, - еще одно ласковое слово. Зачем вы вообще так пишете? Полезно или нет, часто сравнивают или нет, хорошо или плохо, и по какой бы то ни было причине в этой статье они сравниваются. Вам не нужно алиби для того, что не является незаконным!

ВТОРОЙ: В WP: WEASEL существует довольно серьезное руководство, и совершенно очевидно, что такое ласка, а что нет. По небольшой проблеме мы всегда можем поговорить. Однако есть один способ обратиться к ласковым словам: Источник! Вы используете, казалось бы, ласковые слова, но затем приводите цитату из заслуживающего доверия источника. Это не ласковое слово. Командование флотом ( разговор ) 10:01, 18 февраля 2010 г. (UTC)

Слова ласки к вам, и все же вы без сожаления делаете то, что было описано в этом предложении: «сравнивая» два языка (Паскаль и языки, с которыми вы знакомы) «Иногда горячо», я не могу измерить вашу температуру, но Хочу отметить, что в ходе обсуждения вы изменили изложенные вами аргументы и заявленные намерения: в нормальном обсуждении это означает, что эмоции пришли на смену рациональному обсуждению. В этой теме использование ВСЕХ ЗАГЛАВНЫХ букв означает то же самое. Это не ласковые слова: это прямое описание того, что прямо здесь происходит.

В любом случае, если не считать эмоций, вы сейчас указали, что у вас нет времени читать и проверять статью. Иди с миром. —Предыдущий комментарий без подписи, добавленный 203.206.162.148 ( обсуждение ) 23:46, 3 марта 2010 г. (UTC)

Спасибо, это был лучший обзор моей работы, который я когда-либо получал. Это меня рассмешило. Я сейчас Уизель уйду отсюда. - Предыдущий беззнаковый комментарий добавлен 148.87.19.210 ( обсуждение ) 01:00, 9 ноября 2013 г. (UTC)

Смешно устаревший Паскаль в статье [ править ]

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

Никто больше не использует этот старый Паскаль, поэтому смешно говорить, что это «Паскаль». Паскаль - это современная реализация Free Pascal и Delphi, которые являются стандартом де-факто. - Фелипе Монтейро де Карвалью ( разговор ) 10:47, 6 ноября 2010 г. (UTC)

Вы ведь один из основных разработчиков Free Pascal? Если это так, вместо того, чтобы пытаться переписать историю, вам следует подумать о переименовании «Free Pascal» в «Free Object Pascal» или «Free Delphi», поскольку это будет более точным названием. Если вы хотите написать статью о (диалекте Borland) Object Pascal, было бы смешно сравнивать его с C. C ++? Крис Берроуз ( разговор ) 11:11, 7 ноября 2010 г. (UTC)

Что ж, было бы правильно сказать «сравнение старого исторического языка Си со старыми историческими версиями Паскаля». Проблема в том, что C тоже претерпел значительные изменения. - Предшествующий беззнаковый комментарий добавлен 148.87.19.210 ( обсуждение ) 01:02, 9 ноября 2013 г. (UTC)

WEB и C [ править ]

Некоторые функции WEB позволяют использовать некоторые C-подобные функции в программах на языке Pascal. Вот некоторые из этих функций:

• Макросы препроцессора
• Условная компиляция (реализована с использованием макросов препроцессора)
• Шестнадцатеричные и восьмеричные числа
• Символьные константы, преобразованные в номер ASCII этого символа
• Постоянные выражения вместо чисел

Не все возможности языка C можно использовать в WEB. Побитовых операций по-прежнему нет. - zzo38 ( ✉ ) 6:11, 7 ноября 2010 (UTC)

Строки в C [ править ]

Раздел «строки» прямо подразумевает, что C не имеет никакой поддержки или определения для строк вообще, но при пересмотре проекта стандарта C99 (ISO / IEC 9899: TC3, n1256.pdf ) раздел 7.1.1 Определения терминов :

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

Я предлагаю переформулировать это утверждение, чтобы указать, что C не имеет строкового типа , однако у него есть официальное определение для «строки» как представления. - Предшествующий неподписанный комментарий, добавленный Плеббе ( обсуждение • вклад ) 07:48, 19 декабря 2010 г. (UTC)

Эээ, вы говорили о:

C не имеет встроенной строки или присваивания массива, поэтому строка на самом деле не передается в p, а вместо p указывается на постоянную строку в памяти.

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

Copyvio [ править ]

Раздел « Проблемы реализации» - это копия из Let's Build a Compiler из 1988 года (ищите «Когда Никлаус Вирт разрабатывал Паскаль»). Он был добавлен 30 мая 2007 года . Цезарь ( разговор ) 21:28, 19 июня 2011 (UTC)

Передача по ссылке в C [ править ]

C не имеет механизма передачи по ссылке. Передача параметров через указатели по-прежнему осуществляется по значению. Так что это нужно исправить в статье. Ахваджа ( разговор ) 00:54, 30 сентября 2011 (UTC)

Я не вижу нигде, где написано, что это так. - Предшествующий беззнаковый комментарий добавлен 148.87.19.210 ( обсуждение ) 01:10, 9 ноября 2013 г. (UTC)

Массивы по ссылке [ править ]

В статье следует упомянуть существенное исключение в C: массивы эффективно передаются по ссылке, поскольку они всегда являются указателями. Т.е. массивы, в отличие от структур и простых переменных, не копируются при передаче в функции и из них. Следует также упомянуть, что массивы в аргументах функций не имеют размера, и поэтому обычно добавляют отдельный аргумент размера, чтобы обойти это. 78.82.155.234 ( разговорное ) 17:33, 29 марта 2020 (UTC)

Известность [ править ]

Кто-нибудь может показать, что эта тема соответствует WP: GNG ? ButOnMethItIs ( обсуждение ) 10:57, 17 октября 2011 (UTC)

Как вы действительно видите, находится ли переменная в наборе, то есть в паскале для целого числа i, вы можете сделать, если i IN [1,5,9,12], затем DoSomething () - предшествующий беззнаковый комментарий, добавленный 118.92.183.141 ( обсуждение ) 01:02, 29 сентября 2013 (UTC)

наблюдение о строковых методах [ править ]

Я восстановил строку «Метод Паскаля, вероятно, быстрее, потому что не выполняется интерпретация, но метод C очень расширяем.», Потому что единственным оправданием для его удаления было то, что средство удаления лично не знало, что это правда. На него следует ссылаться. К сожалению, когда я ищу ссылки, все, что я нахожу, - это наблюдения о том, что sprintf и другие методы, использующие встроенную интерпретацию строк формата, безнадежно медленны, а не сравнение на том же языке предварительно скомпилированных и интерпретируемых строк формата. Такое сравнение теперь должно существовать, потому что теперь есть компиляторы C, которые будут выполнять скомпилированную интерпретацию аргументов sprintf.

Внешние ссылки изменены [ править ]

Привет, друзья Википедии,

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

• Добавлен архив https://web.archive.org/web/20050314152247/http://www.cs.inf.ethz.ch/~wirth/books/Pascal/ на http: //www.cs.inf.ethz. ch / ~ wirth / книги / Паскаль /

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

По состоянию на февраль 2018 г. разделы страницы обсуждения «Изменены внешние ссылки» больше не создаются и не отслеживаются InternetArchiveBot . В отношении этих уведомлений на странице обсуждения не требуется никаких специальных действий, кроме регулярной проверки с использованием приведенных ниже инструкций инструмента архивирования. Редакторы имеют разрешение удалить эти разделы «Внешние ссылки изменены» на странице обсуждения, если они хотят убрать беспорядок на страницах обсуждения, но перед массовым систематическим удалением просматривают RfC . Это сообщение динамически обновляется с помощью шаблона (последнее обновление: 15 июля 2018 г.) .{{sourcecheck}}

• Если вы обнаружили URL-адреса, которые бот ошибочно считал мертвыми, вы можете сообщить о них с помощью этого инструмента .
• Если вы обнаружили ошибку в каких-либо архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента .

Ура. - InternetArchiveBot ( Сообщить об ошибке ) 16:35, 11 августа 2017 г. (UTC)

Инициализация массива [ править ]

Замечание «Паскаль не имеет ни инициализации массива (за исключением строк), ни средств определения произвольных размеров массива во время компиляции» верно лишь наполовину.

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

Компилятор My Pascal не возражает против таких конструкций, как:

Данные :  массив [ 0 .. 9 ]  из  целого числа  =  ( 10 , 20 , 30 , 40 , 50 , 60 , 71 , 80 , 90 , 91 ) ;

. Я прав, или я что-то упускаю?

- Bloksma ( разговор ) 08:40, 26 октября 2018 (UTC)

Это «нестандартное расширение языка» в вашем компиляторе Pascal, и оно должно быть обозначено как таковое в документации вашего компилятора. Если вы на 100% уверены, что когда-либо захотите запускать свой код только в той системе, в которой он сейчас работает, вам не нужно об этом беспокоиться. Однако чем больше нестандартных функций вы используете, тем больше проблем вы столкнетесь, если когда-нибудь захотите запустить свой код в другой системе. Крис Берроуз ( разговор ) 22:06, 26 октября 2018 (UTC)