Обсуждение:Си (язык программирования)

Кажется мне, что главу == Проблемы == лучше переделать и, заодно, переименовать. У языка не может быть проблем - он не живой.SergDkv 04:34, 4 апреля 2006 (UTC)Ответить

Как это не живой? --qvvx 19:37, 18 апреля 2006 (UTC)Ответить

А, видимо, Вы имеете в виду, что язык не является живым существом. Ну, в данном случае имеются в виду проблемы при использовании языка, а не проблемы самого языка (и это должно быть достаточно понятно из текста), так что не вижу ничего плохого в таком названии. А насчёт переделывания раздела — правьте смело, или, если хотите, сначала предложите изменения здесь. --qvvx 21:18, 18 апреля 2006 (UTC)Ответить

Хм. А почему C называется Си, а другие -- C#, C++, а не Си# Си++ ? Может стоит называть все одинаково? --unplaced — Реплика добавлена в 20:58, 29 ноября 2006 (UTC)Ответить

По традиции. Язык Си начал так называться очень давно, Кроме этого, обозначения С++, С# ни с чем не спутаешь, а С - предлог русского языка. SergDkv 01:41, 30 ноября 2006 (UTC)Ответить

По какой традиции? Когда давно? До каких пор? Кто его так называет сейчас? Каково соотношение "Си" к "C" по употрелению в современной литеритуре? 89.250.82.10 08:23, 15 мая 2010 (UTC)Ответить

Вообще-то считается, что авторами языка были Дэнис Ритчи и Брайан Керниган (K&R). — Эта реплика добавлена с IP 217.15.17.41 (о) 14:35, 14 декабря 2006 (UTC)Ответить

Кем считается? --qvvx 11:04, 16 декабря 2006 (UTC)Ответить

А в английской автором считается Денис Ритчи. :-) SergDkv 12:53, 18 декабря 2006 (UTC)Ответить

В оригинале ясно написано, что язык Си был _изобритен_ Деннисом Ритчи. gsap 17:33, 23 августа 2008 (UTC)Ответить

Почему среди авторов языка фигугирует имя Кена Томпсона, если сам язык изобрёл Денис Ритчи. Брайан Керниган помог Денису книжку написать? так ведь... 31.173.240.97 18:41, 11 января 2016 (UTC)Ответить

А почему в "реализациях" С++ указан? 88.200.185.110 23:39, 21 марта 2008 (UTC) АнонимусОтветить

Где указан? Здесь?

"Основные реализации: GCC, Microsoft Visual C++, Borland C++ Builder, Watcom, Sun Studio C compileк" SergDkv 09:35, 22 марта 2008 (UTC)Ответить

MSVC++ или борланд соберет С99? — Эта реплика добавлена участником Lovesan (о • в) 07:35, 15 августа 2008 (UTC)Ответить

• C99 может и не соберут (мало кто из компиляторов може похвастаться полным соответствием последним стандартам что C, что C++), но не забывайте, хотя в названии указан только C++, фактически в комплекте всех этих студиев два компилятора, для обоих языков. -- A^VB^talk 02:53, 19 декабря 2008 (UTC)Ответить

Вообще-то, общеизвестно, что борланд С++ дебилдер или MSVC++ это компиляторы именно C++, а не Си. Зачем пихать их сюда? Добавьте в статью про С++

Да, Си не является подмножеством С++ уже 10 лет как. Проблема "C99 compliance" это не проблема компиляторов, это проблема тех, кто говорит и пишет "С/С++"Lovesan 22:44, 18 декабря 2008 (UTC)Ответить

• общеизвестно, что борланд С++ дебилдер или MSVC++ это компиляторы именно C++, а не Си - чушь. Си не является подмножеством С++ уже 10 лет как - он с самого начала не являлся подмножеством C++ (точнее, наоборот: C++ не были надмножеством в формльном смысле этого понятия) - например, в C++ изначально не применялся каст char к int. И что с того? Вас цепляет "C++" в названии компиляторов? Не волнуйтесь, это всего лишь название, фактически же программы на обоих языках обрабатываются отдельно. А в том же Open Watcom C и C++ компиляторы вообще идут отдельными экзешниками (которые, правда, можно вызывать единым стабом - WCL). -- A^VB^talk 02:53, 19 декабря 2008 (UTC)Ответить

Мне не нравится фраза о том, что объявление функции болжно предшествовать её использованию. По-моему, у К и Р было явно сказано, что порядок объявления не играет роли. 88.201.200.21 08:16, 23 апреля 2008 (UTC)Ответить

Да, а некоторые компиляторы (Open Watcom C, например), даже не отображают warning. C Builder 2007, в свою очередь - отображает, но линкует нормально. — Эта реплика добавлена участником Alexanderwdark (о • в) 11:10, 20 октября 2008 (UTC)Ответить

• порядок объявления не играет роли - вы плохо знаете язык. Порядок объявлени ИГРАЕТ роль - другое дело, что "классический C" позволяет использовать функции до/без описания их протитипов (что ведёт к катастрофическому рост ошибок в программах). даже не отображают warning - во-первых, варининги никто не ОБЯЗАН отображать, стандарт требует в обязательно порядке только диагностику ошибок, а ANSI C для совместимости с K&R C допускает непрототипированное использование функций. Во-вторых, никто вам не мешает ВКЛЮЧИТЬ варнинги - в Open Watcom за это отвечает ключик -w (рекомендую ВСЕГДА использоваться -wx для максимальной диагностики). -- A^VB^talk 02:44, 19 декабря 2008 (UTC)Ответить

Мне одному кажется, или вот это действительно какая-то дикая дурь?
в разделе "набор используемых символов":
Более старые языки вынуждены были обходиться более скромным набором — так, Фортран, Лисп и Кобол использовали только круглые скобки ( ), а в Си есть и круглые ( ), и квадратные [ ], и фигурные { }. Кроме того, в Си различаются заглавные и строчные буквы, а более старые языки использовали только заглавные.
В Лиспе один тип скобок не потому, что при создании Лиспа не было ASCII и/или квадратные скобки было проблематично имплементировать. Lovesan 17:10, 5 сентября 2008 (UTC)Ответить

• дикая дурь - Дурь, конечно. А регистрозависмость имён в Си не потому, что он "новее" (он старее многих других языков), а потому, что создавали его люди, для которых регистрозависимость была привычна. Вот они под себя язык на коленках и слабали. -- A^VB^talk 02:48, 19 декабря 2008 (UTC)Ответить

Чепуха. Delphi регистр вообще ингорирует. Хотя его язык куда новее C. — Эта реплика добавлена участником Alexanderwdark (о • в) 11:11, 20 октября 2008 (UTC)Ответить

• Вовсе не чепуха. Раньше действительно была такая проблема. В старых языках нельзя было использовать широкий набор символов, так-как у большинства выпускаемых в то время машин набор символов был очень ограничен. Кстати, как вы думаете, насколько сложно было в 1958 году имплиментировать в LISP квадратные скобки если это делалось на IBM 704, а на IBM 704 были 6-битные символы?

А delphi игнорирует регистр для удобства пользователя и по историческим соображениям (совместимость с языком Паскаль была одной из целей разработчиков). В Си регистр не игнорируется по историческим соображениям. SergDkv 00:10, 23 октября 2008 (UTC)Ответить

• В старых языках нельзя было использовать широкий набор символов - ага, и именно поэтому APL использует свой набор символов, который шире ASCII? (уточняю: это риторический вопрос с сарказмом). -- A^VB^talk 02:48, 19 декабря 2008 (UTC)Ответить

• • Понятно, что в универсальной ЭВМ возможно использование любого набора символов, но осмысленно ли использование специального уникального набора символов для языка общего назначения? Нет, и даже о специализированном APL в en-wiki сказано - APL has always been criticized for its choice of a unique, non-standard character set. Вообще, на старых больших ЭВМ расширение набора символов приводило к необходимости заменять наборы символов в пишущих машинках и прочим не слишком осмысленным действиям. SergDkv 11:28, 7 января 2009 (UTC)Ответить

• осмысленно ли использование уникального набора символов - осмысленно или не осмысленно, это другой вопрос. Речь же о том, что утверждение "В старых языках нельзя было использовать широкий набор символов" неверно, что с успехом и опровергает АПЛ. и прочим не слишком осмысленным действиям - тем не менее, насколько я помню, в ИБМ на АПЛ даже операционка была написана и работала. -- A^VB^talk 00:12, 23 января 2009 (UTC)Ответить

Скорее опыт APL подтверждает нецелесообразность использования расширенного набора символов. :-) Понятно, что теоретически возможно все. Например написание и продажа Doom-1 для пользователей компьютеров линии IBM-360 или PDP-11. Процессор быстрый, памяти достаточно... А насчет ОС написанной на APL - существует множество мертвых неинтересных проектов. Эта ОС - в их числе. SergDkv 06:25, 28 января 2009 (UTC)Ответить

Моё личное подозрение, правда пока ничем не подтверждённое но и не опровергнутое, что регистрозависимость Си связана с регистрозависимостью линукса. 95.78.138.230 23:46, 22 января 2009 (UTC)Анохин А.М.Ответить

• Моё личное подозрение - вы меня конечно извините, но ваши подозрения тут не играют НИКАКОЙ роли. Тем более, что они прото беспочвенны: Си был разработан Ритчи в 1972 году, а Линукс Торвальдс начал писать только в 1991 году. -- A^VB^talk 00:12, 23 января 2009 (UTC)Ответить

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

95.78.140.189 13:55, 23 января 2009 (UTC)Анохин А.М.Ответить

"В Си есть три разных способа выделения памяти "

на стеке, статическая и динамическая. Э-э-э, а как же регистры? Не, я конечно понимаю, что регистры многие и за память не считают. А во многих языках, кроме assembler и C, работать с регистрами нельзя. Но поскольку, в C, можно работать именно с регистрами процессора, и помещать туда объекты, то это надо оговорить. Или я не прав? Артём-Талипов 08:12, 5 марта 2012 (UTC)Ответить

В Си, строго говоря, есть три вида памяти, прописанных в стандарте (сейчас точно не помни где, но при желании могу предоставить): статическое, динамическое и автоматическое. Автоматическое на архитектуре Intell и Amd может быть реализовано через стек и через регистр. Но это уже особенность эти конкретных архитектур, а не языка.--extern 08:23, 5 марта 2012 (UTC)Ответить

Кстати, расскажите, как в Си поместить объект в регистр.--extern 08:23, 5 марта 2012 (UTC)Ответить

Насколько я помню, именно для этого используется ключевое слово register.

Но я не буду утверждать, если бы я был уверен, в своей правоте, то сразу бы отредактировал статью. А так, только поднял вопрос. Артём-Талипов 00:56, 6 марта 2012 (UTC)Ответить

Это только подсказка компилятору. Он может ничего и не помещать в регистр. -- X7q 01:03, 6 марта 2012 (UTC)Ответить

"Статическое выделение памяти: пространство для объектов создаётся в сегменте данных программы в момент компиляции; время жизни таких объектов совпадает со временем жизни этого кода. Изменение таких объектов ведёт к так называемому в стандарте «неопределённому поведению» (англ. undefined behaviour)".

А можно указать это место в стандарте? Вроде бы статический объект != константный. -- Ad.edelweiss 17:21, 29 ноября 2012 (UTC)Ответить

"Си был создан для использования в операционной системе (ОС) UNIX." Не верно. Си создавался для написания Юникса. Юникс тем и известен что был первой ОС, написанной на языке высоко уровня.

Раздел «Проблемы» написан как-то по-детски. Автору стоит знать что массивы и указатели по сути своей примерно одно и то же (и, кстати, не только в си), а по сему зачем городить огород? Получилась каша масляная с маслом. Обращение к несуществующему элементу массива то же самое что и обращение к адресу «абсолютно любого объекта в памяти» . Поясню: Имя массива представляет собой указатель на первый его элемент. Индекс используется для определения смещения относительно начального элемента. АдресПроизвольногоЭлементаМассива = АдресПервогоЭлемента + РазмерОдногоЭлемента*Индекс. В то же время не указаны реальные недостатки Си: Дело в том, что благодаря своей «низкоуровневости» опасно использовать язык скажем при создании web-сафтов. Этими низкоуровневыми возможностями может воспользоваться злоумышленник. Именно по-этому в некоторых случаях происходит переход на Java (Изначально Java – объкто-ориентированная обрезанная версия языка Си++ которая затем была расширина большим количеством библиотек).

В разделе «Связь с C++» говорится о несовместимости Си и Си++. В то же время в разделе «Некоторые известные компиляторы Си» речь идёт именно о Си++

В разделе «Некоторые известные компиляторы Си» перечислены не компиляторы а среды разработки, использующие как базовый язык Си++. 91.144.145.5 19:06, 6 января 2009 (UTC)Анохин А.М. alan2006@mail.ruОтветить

1. Unix не был первой ОС написанной на языке высокого уровня. С другой стороны, Си создавался для использования в ОС UNIX, и использовался для написания частей ядра ОС, системных и прикладных программ, языков программирования и многого другого.

2. Раздел "Проблемы", по большей части, был переведен из en-wiki. Написан этот раздел хорошо и понятно. Далее, по пунктам. Указатели и массивы это не одно и то-же, это разные сущности которые выражают разные аспекты программы. Кроме создания Web-сАфтов существует множество других областей, в которых Си неадекватен. Неважно, какой базовый язык используют среды разработки, если они используются программистами для компиляции программ написанных на Си, и их можно рекомендовать к использованию (например в целях изучения языка), то их можно включить в данный список. SergDkv 11:45, 7 января 2009 (UTC)Ответить

я бы не рекомендовал MSVC++ для изучения языка Си, знаете ли. Lovesan 23:59, 12 января 2009 (UTC)Ответить

Полностью согласен. Но MSVC++ *используется* как для обучения программированию на Си, так и для практического программирования. SergDkv 08:07, 13 января 2009 (UTC)Ответить

«Раздел "Проблемы", по большей части, был переведен из en-wiki. Написан этот раздел хорошо и понятно.» И что о чём говоит? Проблема не в непонятности раздела а в том что, он слишком поверхностный. Такое чувство, что написан неопытным программистом(если программистом вообще).

«1. Unix не был первой ОС написанной на языке высокого уровня. С другой стороны, Си создавался для использования в ОС UNIX, и использовался для написания частей ядра ОС, системных и прикладных программ, языков программирования и многого другого.»

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

«Указатели и массивы это не одно и то-же, это разные сущности которые выражают разные аспекты программы.»

Да ладно? Смотрите документацию. Имя массива есть указатель на первый элемент. После которого последовательно расположены отсальные элементы. Другой вопрос что память под статические массивы выделяется статически. Хотя ничто не мешает создавать динамические массивы. Пример1:

... int arr[2]; int* a; arr[0] = 1; arr[1] = 2; a = arr; printf("%d\n", *a); a += 4;// 4 - размер в байтах int printf("%d\n", *a); ....

На экране будет: 1 2

А вот если попытаться добавить ещё две строчки:

... a += 4; printf("%d\n", *a); ...

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

Верно и обратное. Пример2:

... int l; printf("введите длинну массива\n"); scanf("%d\n", &l);

int* arr = new int[l] for (int i = 0; - < l; i++) {

printf("Введите %d-й эл-т массива", i);
scanf("%d", &(arr[i])); //аналогично можно написать строчку scanf("%d", (arr + (i * 4)));

} ....

Пример функции, выводящей на экран массив и обнуляющей его:

void func(int* arr, int length) {

  for (int i = 0; i < length; i++)
     {
        printf("%d", arr[i]);
        arr[i] = 0;
     }

} Отработает нормально(при условии что на вход фцнкции будут переданы корректные параметры).

Резюмируя: Хоть массивы и указатели не совсем одно и то же но не такие уж и далёкие вещи. А вот перечисленные проблемы по сути одни и те же.

«Кроме создания Web-сАфтов существует множество других областей, в которых Си неадекватен.»

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

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

Список тогда должен быть назван "Среды программирование, использующие компилятор си". Иначе по аналогии можно в списко "двигатели внутреннего сгорания" включить такие позиции как "Жигули", "БМВ" и так далее...

«я бы не рекомендовал MSVC++ для изучения языка Си, знаете ли.» А какой рекомендовал бы? Мне, к примеру, больше нравится Борландовский си (но не билдер) для обучения. 95.78.138.230 19:03, 22 января 2009 (UTC)Анохин А.М. alan2006@mail.ruОтветить

текстовый редактор(напр. Vim) + компилятор. И все. - Lovesan 20:01, 25 января 2009 (UTC)Ответить

Кстати: в статье про юникс Unix#Первые UNIX описано какой юникс был написан на си. Можно сказать что оба утверждения не совсем коректны - си был создан и для написания ОС Unix и для рабты в ней. Хотя, как мне кажется, скорее для написания юникса. — Эта реплика добавлена с IP 95.78.138.230 (о) 23:37, 22 января 2009 (UTC)Ответить

• Си создавался для написания Юникса - не написания, а переписывания и облегчения переноса уникса на другие машины с платформы PDP-11. Раздел «Проблемы» написан как-то по-детски - ВП:Правьте смело! Именно по-этому в некоторых случаях происходит переход на Java - безопасность - не единственная причина выбора Явы для написания веб-софта. Далеко не единственная. Как насчёт автоматической сборки мусора? Как насчёт портабельного байт-кода? в разделе «Некоторые известные компиляторы Си» речь идёт именно о Си++ - "если на клетке слона написано "буйвол", не верь глазам своим" (c) Козьма Прутков. То, что в названии какого-то компилятора написано "C++", вовсе не означает, что он не может компилировать программы на C. И не потому, что эти языки близки, а потому, что перечисленные компиляторы включают компиляторы для обоих языков. Я об этом же говорил, но вы как-то этот момент благополучно проигнорировали. перечислены не компиляторы а среды разработки - а что делать, если компилятор является часть среды разработки и не доступен/поставляется как отдельный пакет? Больше не считать его компилятором?

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

• я бы не рекомендовал MSVC++ для изучения языка Си - а где в статье есть такая рекомендация, позвольте спросить? Проблема не в непонятности раздела а в том что, он слишком поверхностный - ВП:Правьте смело! Если не верите мне и нет под рукой документации - деассеблируйте программу и посмотрите как идёт работа с массивом - а ещё лучше и правильнее - почитать стандарт языка по этому вопросу. Поскольку отдельные реализации ещё не авторитет в вопросе идеологии языка. си как раз таки адекватен. Зачастую не адекватен программист - три раза ХА. "кто из вас без греха, первый брось на нее камень" (Иоан. 8:7). Предлагаете считать всех, кто упал с узкого мостика без перил, неадекватными? Типа, мостик без перил - это нормально, это адекватно, не нужны ему перила, а падающие сами виноваты? Злоумышленник может воспользоваться уязвимостями - вы путаете разные вещи: одно дело злой умысел, другое дело - когда язык не то, что не защищает, а даже провоцирует на ошибки. То, что язык позволяет компилировать сорсы, в которых функции используются без прототипов (при том, что сам компилятор о функциях ничего не знает), без единого сообщения об ошибке или варнинге - это прямая и неприкрытая диверсия. Мне, к примеру, больше нравится Борландовский си - сколько угодно. А мне он не нравится. Поскольку борланд выпускает продукт, который не свободный и плохо поддерживается. И что? Какой это имеет отношение к статье? В ней ведь нет рекомендаций использовать тот или иной компилятор. -- A^VB^talk 00:43, 23 января 2009 (UTC)Ответить

• Как насчёт автоматической сборки мусора? Как насчёт портабельного байт-кода?

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

• Предлагаете считать всех, кто упал с узкого мостика без перил, неадекватными? Типа, мостик без перил - это нормально, это адекватно, не нужны ему перила, а падающие сами виноваты?

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

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

А что вы хотите защищать и от кого? На стадии компиляции, сколько видится мне, вам нужно защищаться от самого себя не более. А вот на стадии работы преиложения нужно защищаться от злоумышленника. И ещё: а как язык должен защищать и от чего? Вот даже на стадии компиляции.. У него что искуственный интелект и он может угадывать специально вы испоользуете функци без прототипа или просто забыли?

• ...И что? Какой это имеет отношение к статье?

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

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

Ну слава богу, кто-то кроме меня об этом знает. А то я уж испугался.

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

В этом случае делать следующее: 1. Посимотреть документацию на среду программирования где наверняка указано хотя бы рабочее название компилятора и его версия. Просто к примеру есть MSVS 98 и есть 2003 и более новые. Так вот компиляторы там различаются. В некоторых случаях компилтор одного не компилирует код, который легко компилирует компилятор второго.

2. Переименовать раздел в "Среды програмирования, использующие компилятор си".

95.78.136.216 09:13, 23 января 2009 (UTC)Анохин А.М. alan2006@mail.ruОтветить

• На самом деле более новые версии Си собирают мусор - реализации языков C/C++ не имеют права этого делать по определению. безопасная ферсия си. Отсюда и использование ява-машины - вообще-то, виртуальная машина нужна из-за ориентации на гетерогенные (разнородные) сетевые среды. Безопасность обеспечивается другими средствами. А что вы хотите защищать и от кого? - не от "кого", а от "чего" - от ошибок программистов. Не существует непогрешимых людей. В принципе. А для случая, когда защиту нужно обойти осмысленно, должны предоставляться явные средства. К примеру, в Турбо Паскале для отключения проверок диапазонов есть прагма. В Аде для отключения проверок отдельных указателей есть прагма. А некоторые барьеры вообще нельзя разрешать обходить - в C++ правильно сделали, что запретили непрототипированное использование функций. на стадии работы преиложения нужно защищаться от злоумышленника - это вопрос несколько из другой оперы. Но и здесь Си - это просто чудо природы. Чего стоит хотя бы функция gets()! Вы про ошибки класса buffer overflow слыхали? Вот как раз такие функции, как gets(), sprintf() и т.п., которые В ПРИНЦИПЕ не позволяют защититься от переполнения - это тоже диверсия. Точнее, мина замедленного действия, изначально подложенная под фундамент языка.

• У него что искуственный интелект и он может угадывать специально вы испоользуете функци без прототипа или просто забыли? - а зачем вообще позволять компилировать без прототипа? В принципе? Я предвижу только одно возражение - "мне лень вбивать прототипы". Ну, даже если проигнорировать тот вопрос, что нормальный язык должен быть модульным и компилятор сам должен выискивать прототипы между и внутри модулей, то всё равно вы НЕ ДОЛЖНЫ вбивать прототипы вручную, это чревато опечатками. Для этого в Си используются "заголовочные файлы", в которых однократно собираются (копируются) нужные прототипы. Единственная фича, реально присутствующая от массивов в Си - это типизация ...и выделение нужных объёмов памяти не только кучи (глобальное или стековое). [это я дополнил свою сентенцию]

• MSVS 98 и есть 2003 ... компиляторы там различаются. В некоторых случаях компилтор одного не компилирует код, который легко компилирует компилятор второго - ясен перец. Стандарты реализуются постепенно (мы ведь говорим о стандартном языке и не о расширениях), старые редакции компиляторов могут не поддерживать какие-то фичи. Но ведь это не зависит от того, поставляется ли компилятор отдельным экзешником, входит в какой-то многофункцимональный пакет (как OpenWatcom, в котором много чего кроме собственно WCC и WPP есть) или не доступен для отдельного запуска, а только из среды-редактора. Переименовать раздел в "Среды програмирования, использующие компилятор си" - а с каких пор, к примеру, OpenWatcom стал "средой программирования"? Нет, редакторы и визуальные отладчики там конечно есть, но они "сбоку припёка". А DJGPP? Вообще не среда. А Borland C++? Нет, IDE (BC.EXE) там конечно есть, и она широко и активно использовалась, но я, к примеру, (к сожалению) давным давно перестал ею пользоваться (из-за её падучести) и вызываю компилятор BCC.EXE напрямую. С каких пор BCC.EXE - это "среда программирования"? Так что я не думаю, что стоит так усложнять статью (которая посвящена отнюдь не компиляторам) - хотя, полагаю, можно вставить после списка кратенький абзац о том, что большинство позиций в списке представляют из себя интегрированные среды разработки, включающие собственно компиляторы. -- A^VB^talk 10:14, 23 января 2009 (UTC)Ответить

• не от "кого", а от "чего" - от ошибок программистов. Не существует непогрешимых людей.

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

• Но и здесь Си - это просто чудо природы. Чего стоит хотя бы функция gets()! Вы про ошибки класса buffer overflow слыхали? Вот как раз такие функции, как gets(), sprintf() и т.п., которые В ПРИНЦИПЕ не позволяют защититься от переполнения - это тоже диверсия.

Не могу вспомнить языков в которых в явном виде существовала бы защита от подобных ошибок. В других языках, с более строгой типизацией, к примеру, при попытки считать из консоли символ в переменную значения "не правильного типа" так же происходит ошибка. Почти во всех языках есть ошибка i/0 и что это всё диверсия? Чаще всего это ошибки программиста, не предусмотревшего "защиту от дурака".

• а зачем вообще позволять компилировать без прототипа?

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

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

На самом деле более новые версии Си собирают мусор - реализации языков C/C++ не имеют права этого делать по определению

Давайте определимся говорим ли мы сейчас о класических стандартах или о их расширении?

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

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

95.78.136.216 16:53, 23 января 2009 (UTC)Анохин А.М. alan2006@mail.ruОтветить

• ряд продуктов, созданных на си живут и работают вполне хорошо - даже тупым ножом можно хлеб нарезать. (Ну или наоборот - топором побриться). Но стоит ли? ассемблер вообще не защищёный - но ассемблер на многое (например, на высокоуровневость или портабельность) и не претендует. В отличие от Си. если многие не умеют пользоваться возможностями языка то скорее всего не стоит писать на нём. Но не стоит считать что это недостаток - одно дело - "не уметь", другое дело - дефекты дизайна, для обхода которых требуются ДОПОЛНИТЕЛЬНЫЕ знания, умения и усилия. Проблема же тут в "политике". Возьмём для примера Турбо Паскаль: там на порядок лучший конструктив языка (ТП - это почти Модула) и из-за этого у него весьма приличное качество кода (например, компактность экзешников), а также большаая пригодность для обучения, что привело к весьма заметному сообществу. Однако убожество реализации (нет стандарта языка - это и не Паскаль, и не Модула, а не пойми что; ограниченная библиотека; доступен только на одной платформе; примитивный оптимизатор; в конце концов - он коммерческий) привело к тому, что это сообщество теряет свои позиции. Вот вам и политика - если бы сразу изначально были широко доступны компиляторы языка типа Ада (C++ многие его возможности только спустя 15 лет потихоньку начал перетягивать), то шансы Си на распространение сократились бы на много порядков.

• вы же не обвиняете в том, что забыли ключ от домофона сам домофон - понятное дело, что снимать вину с человека за все ошибки и перекладывать на внешние условия - это не правильно. Но проектировать изначально так, чтобы провоцировать ошибки - это точно вина создателя продукта. Если домофон будет бить током при прямом прикосновении к нему - то кто будет виноват в ударе меня током, если я этот самый домофон (случайно) зацеплю? При том, что здесь заведомо дефект производства или даже конструкции домофона. Не могу вспомнить языков в которых в явном виде существовала бы защита от подобных ошибок - извините, значит, вы плохо знаете языки программирования. Я вам назову как минимум одно название: язык Си, в реализации которого для подобных функций в библиотеке стоят заглушки (насколько я помню, в clib под FreeBSD для gets() как раз и стоит заглушка) и добавлена библиотека типа Safe C (с безопасными строковыми и функциями ввода-вывода - у них есть параметры, говорящие о размере буферов). Жаль только, что это будет уже не стандарт. Дебилизм: те люди, которые сидят в комитете стандартизации языка, параллельно же разрабатывают стандарты на безопасные реализации, исправляющие дефекты дизайна оригинального языка. "не правильного типа" так же происходит ошибка - извините, вы путаете проверку значение и прямую выдачу ошибок и тихую, никак и нечем неконтролируемую порчу (данных и кода), результат которой непредсказуем, а нередко и недетерминирован (так называемая "мистическая ошибка"). Чаще всего это ошибки программиста, не предусмотревшего "защиту от дурака" - вы либо не хотите понять, либо не понимаете. Расскажите мне, КАК вы защититесь от ошибки, которую можно получить, если в программе используется стандартная (!) gets()?

• При написании частей программы на ассемблере существует возможность варьировать количество параметров и возвращаемый результат. Думается мне, в этом и цель - я мог бы сейчас целый трактат написать о том, что такое высокоуровневый язык и что значит "портабельность", на звание которых претендует Си, но ограничусь тем, что замечу: потеря контроля типов в Си (при использовании непрототипированных вызовов) НЕ добавляет возможности "варьирования". Но это лишь моё предположение - на самом деле, вполне вероятно, что авторы (Ритчи с Томпсоном) из этого и исходили. Но здесь ярчайший случай, когда потенциальный выигрыш в микроскоп не разглядеть, а реальным потерям счёт на миллиарды. "Хотели как лучше, а получилось как всегда" (c) сами знаете кто. Давайте определимся говорим ли мы сейчас о класических стандартах или о их расширении? - простите, но я лично говорю о языке Си, а не о "расширениях". А вообще, мы вылезали далеко в офтопик и эту тему надо активненько завязывать. -- A^VB^talk 11:08, 25 января 2009 (UTC)Ответить

• даже тупым ножом можно хлеб нарезать. (Ну или наоборот - топором побриться). Совершенно верно... Полностью согласен но и не совсем в Вашем контексте. Пример продуктов написанных на си - те же Юникс-подобные системы. Разве это тупой нож?

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

• одно дело - "не уметь", другое дело - дефекты дизайна, для обхода которых требуются ДОПОЛНИТЕЛЬНЫЕ знания, умения и усилия.

Честно говоря не совсем понял о каких деффектах дизайна идёт речь(видимо по тому, что в основном пишу на си++. На чистом си писал несколько простеньких программочек) однако про знания и уменя соглашусь.. Чтобы более-менее качественно писать на си нужно хотя бы общее представление о том, что происходит на уровне команд процессора. Да, действительно, это шаг в сторону низкого уровня.. Но си изначально задумывался как язык для переписывания ядра Юникса. Мою позицию можно свести к следующему: Си - не "плохой язык" в каких то вопросах он намного лучше всё тех же java и TP... Но это ничего не значит. Они просто созданы с разными целями.

Кстати, к слову, создавал Модулу тот же разработчик, что и ТП... В модуле был использован опыт, полученный при создании паскаля и устранены паскалевские недачёты... Так что можно считать эти языки родственными... Эт я для полноты информации просто написал...

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

Это весьма и весьма абстрактно. Станислав Ленц сказал "Если кого-то возбуждает чтение учебника биологии не стоит считать этот учебник порнографией.". Для избежания таких вот "зацепаний" есть документация, есть здравый смысл, есть тестеры...

• Я вам назову как минимум одно название: язык Си, в реализации которого для подобных функций в библиотеке стоят заглушки

Опять же, давайте решим, говорим мы сейчас о языке в целом или о конкретных реализациях?

• вы путаете проверку значение и прямую выдачу ошибок и тихую

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

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

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

• НЕ добавляет возможности "варьирования".

Пожалуйста, поясните.

AnoAM 23:43, 31 января 2009 (UTC)Ответить

Часто утверждается, что в языке Си массивы и указатели являются почти синонимами, и при этом ссылаются на код, генерируемый компилятором. Это не так. Посмотрим на следующий код, void func() {

  static int buf[_SOME_BIG_VALUE + 10];
  int length = sizeof(buf)/sizeof(buf[0]);
  for (int i = 0; i < length; i++)
     {
         buf[i] = 0;
     }

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

SergDkv 05:22, 28 января 2009 (UTC)Ответить

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

6.5.2.1  Array subscripting
Constraints
[#1] One of the expressions shall  have  type  ``pointer  to
object type, the other expression shall have integer type,
and the result has type ``type.
Semantics
[#2] A postfix  expression  followed  by  an  expression  in
square  brackets  []  is  a  subscripted  designation  of an
element of an array object.  The definition of the subscript
operator  []  is that E1[E2] is identical to (*((E1)+(E2))).
Because of the conversion rules that apply to the  binary  +
operator,  if E1 is an array object (equivalently, a pointer
to the initial element of an array  object)  and  E2  is  an
integer, E1[E2] designates the E2-th element of E1 (counting
from zero).

повторю: if E1 is an array object (equivalently, a pointer to the initial element of an array object). Или вот:

6.5.6  Additive operators
Semantics
[#7]  For  the  purposes  of these operators, a pointer to a
nonarray object behaves the same as a pointer to  the  first
element  of  an  array  of  length  one with the type of the
object as its element type.

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

extern int x[];
int f (int y []) { return sizeof x + sizeof y; ]

и скажите, что же должна вернуть функция f()? -- A^VB^talk 07:33, 28 января 2009 (UTC)Ответить

А что, вы, собственно, пытаетесь доказать? Я привел пример кода (аналог приведен в книге Practice of Programming Кернигана, Пайка) в котором явно используются отсутствующие у указателей свойства статических массивов. Уже одно это говорит о том, что статические массивы и указатели различны. Я не говорю уже о том, что в случае их идентичности статические массивы можно выкинуть из языка и никто не заметит разницы. SergDkv 07:50, 28 января 2009 (UTC)Ответить

• что, вы, собственно, пытаетесь доказать - разве это я начал данную тему? :) А так, я хочу сказать, что в Си массивы неполноценны - нельзя присваивать, нельзя передавать в качестве аргументов (именно сам массив передавать, а не его адрес - иными словами, передавать "по значению", а не "по ссылке"). Про другие операции (типа сравнения) я уже молчу. Массивы с неконстантными размерами тоже появились только в C99 (почти через 30 лет после создания языка). Структуры, кстати, изначально тоже нельзя было по значению передавать, но это быстро исправили. в случае их идентичности - и опять вы не слышите... Цитирую опять (стандарт, между прочим): "array object (equivalently, a pointer to the initial element of an array object". Поймите, речь идёт не о выделении памяти, а об использовании объектов соответствующего типа. Да, векторный типа в Си есть. Но толку от этого мало, поскольку использование объектов мало отличается обычных указателей. Что у нас там кроме sizeof (работающего не во всех случаях - например, не для параметров функций) и проверки типов (при присваивании переменных-массивов указателям) есть? -- A^VB^talk 09:06, 28 января 2009 (UTC)Ответить

• С тем, что в языке Си нет полноценных массивов полностью согласен. Более того, печально то, что смоделировать в Си настоящие массивы невозможно. К сожалению развитие языка Си - язык С++, в котором можно смоделировать массивы, слишком сложен для меня. Некоторое время назад думал над выбором переносимого подмножества С++, в котором были бы решены проблемы связанные с массивами, списками, деревьями, строками (UTF-16 или UTF-32 для хранения строк и любые кодировки на ввод-вывод, как в python) и выбрать такое подмножество не смог. SergDkv 04:28, 29 января 2009 (UTC)Ответить

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

AnoAM 22:29, 31 января 2009 (UTC)AnoAMОтветить

MULTICS. Хотя я еще помню времена когда говорили ОС XXX написана на ассемблере и поэтому круче ОС YYY. SergDkv 06:34, 28 января 2009 (UTC)Ответить

• MULTICS

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

• Хотя я еще помню времена когда говорили ОС XXX написана на ассемблере и поэтому круче ОС YYY.

Маэстро, я Вас не понимаю :(

• Это ответ на "Обзорно", где говорится следующее «Си создавался для написания Юникса. Юникс тем и известен что был первой ОС, написанной на языке высоко уровня». Далее, большинство программистов долгое время придерживалось той точки зрения, что ОС следует писать именно на ассемблере. SergDkv 01:32, 16 августа 2009 (UTC)Ответить

Первый приоритет: >>Постфиксные операции : [] () . -> ++ --

Что за ересь? постфиксные инкремент/декремент всегда были последними по приоритету. Надобно исправить.

Вы имеете в виду, что ++n увеличивает значение выражения после того, как оно будет использовано? Если да, то это не имеет отношения к приоритетам. Если нет, поподробнее, пожалуйста. Caesarion 19:10, 17 января 2011 (UTC)Ответить

Я собираюсь полностью переписать статью за ближайшие одну-две недели. Сначала я приведу её к заданной структуре, затем уберу все неподтверждённые оценочные суждения, далее начну переписывать раздел за разделом. По дороге буду заниматься ещё и выверкой написанного. Поскольку статья про язык программирования «C++» (а, затем, ещё и про «C#» и «Java») существенно опирается на данную статью, то мною было решено начать именно с неё. --OZH 18:21, 26 ноября 2013 (UTC)Ответить

• Надеюсь, под «заданной структурой» вы понимаете вот эту ? Arachnelis 18:42, 28 февраля 2014 (UTC)Ответить

Я предлагаю в этом разделе описать всё то, что является неотъемлемой частью языка программирования Си. Этот раздел должен существенным образом опираться на раздел «Синтаксис Си», но содержать семантику выражений на Си. Я предполагаю, что такое чёткое разделение, которое довольно просто произвести для императивных языков программирования, крайне важно иметь в энциклопедической статье, поскольку это сильно облегчает понимание того, что предлагает язык на уровне синтаксиса (и тогда в разделе про синтаксис можно сконцентрироваться исключительно на синтаксисе и не задумываться о примерах применения), и что предлагается делать при составлении реальных программ на Си. Можно сказать, что элементы языка — это элементы программирования на этом языке, то есть, те сущности, которые определяют облик программирования на описываемом языке программирования. А уже дальше, на основе этих элементов, можно рассказать о решении прикладных задач в одном из следующих разделов под названием «Программирование на Си». --OZH 07:13, 29 ноября 2013 (UTC)Ответить

• Сомневаюсь, что нужно настолько отделять синтаксис от семантики по нескольким причинам. Во-первых, мы пишем для людей и несколько странно в одном месте узнать о синтаксисе, скажем, оператора if, и где-то еще узнать, как он работает. Во-вторых, размер статьи сильно увеличится из-за повторения вводных слов (или Вы предлагаете диаграммы Бекуса-Наура, как источники по Паскалю делают?). В-третьих, такое разделение менее гибко и, значит, эффективно. Полагаю, что лучше всего материал воспринимается, когда он приведён вокруг некоторых опорных точек и важных моментов. Как я заметил, практически все книги, кроме плохих Reference Manual, организуют материал именно таким образом. Кроме того, синтаксис можно дать и на примере, оставив формальности «полным руководствам» по языкам. Я начал в статье Erlang именно так, но потом быстро пришёл к выводу, что как читать, так и писать легче, когда изложение понятие-синтаксис-семантика и примеры идут параллельно. Конечно, попробуйте, может в случае С++ получится. РоманСузи 17:38, 29 ноября 2013 (UTC)Ответить

Всё таки, а есть ли разница в Си между "Процедурой" и "Функцией"? --85.26.231.148 10:19, 28 июля 2014 (UTC)Ответить

Таки есть. Процедуры в Си тупо отсутствуют по спецификации языка. Их можно симулировать посредством использования типа void. Arachnelis 18:41, 29 июля 2014 (UTC)Ответить

"Отсутствие определения ранее определённой функции является ошибкой"

в разделе Синтаксис Си -> Функции Flyelog (обс) 13:28, 15 сентября 2014 (UTC)Ответить

Воевать с запятыми по 17 правок за раз у меня нет времени, поэтому поясню для патрулирующих. "такой как" пишется БЕЗ запятой, поскольку это не сравнение. "Однако," - вводное слово, обязательно выделяется запятой. Arachnelis 18:01, 17 марта 2015 (UTC)Ответить

Нету Раздела "Критика". Язык неидеален.

• Ну, критикуют таки поменьше, чем C++. Я бы взял в качестве источника для начала эссе А. В. Столярова «Язык Си и начальное обучение программированию» Хотя там критика в основном с точки зрения, почему Си не должен быть первым языком. Ну а дальше видимо про потенциально опасные в промышленном программировании последствия низкоуровневости (по нынешним временам Си — почти ассемблер), недаром ведь Расты с Циклонами пишут --be-nt-all 20:28, 24 января 2016 (UTC)Ответить

• На всякий случай подчеркну, что одним из ключевых источников критики Си необходимо брать Джойнера. У него треть статьи отведена общей критике Си и применима к большинству потомков. Arachnelis 19:11, 8 февраля 2016 (UTC)Ответить

• Если не замечали, я уже года два ваяю критику С++. От доброй половины источников достаётся на орехи обоим языкам. Возможно, статью даже надо будет переименовать в "критика Си и С++". Если кто видел только раннюю мою версию, то скажу, что сейчас много раскрыто о критике, и существенно повышена энциклопедичность, но готово лишь наполовину. Желающие могут помочь (я таки шибко предвзят). Arachnelis 19:04, 25 января 2016 (UTC)Ответить

• Понимаете, Си и Си++ это два разных языка. Нельзя бездумно, "недостатки" Си++ натягивать на язык программирования Си. Может быть у них есть схожие недостатки, но С++ по сравнению с чистым Си просто монстр. --31.173.240.236 18:45, 29 января 2016 (UTC)Ответить

• Вы мне это не объясняйте, я уважаю Си и презираю С++. Я сказал, что если перебрать АИшечки и вылизать языком две разные статьи, то в конце концов окажется, что две трети «критики Си» дублируются в «критике С++», и рано или поздно поступит предложение «к объединению». Так зачем зря тратить время? Проще дробить на абзацы: мол, вот это сказано в адрес обоих языков, а вот здесь критик ругает именно С++. Arachnelis 19:56, 31 января 2016 (UTC)Ответить
• upd: Впрочем, если подумать, то лучше не стоит. У меня уже 300Кб критики С++, и там лишь вскользь затрагивается как «а приори уже известное читателю» присущие черты Си — сложное поведение между точками следования, адресная арифметика и препроцессор. На детальном рассмотрении этих вещей с нуля ещё 100Кб сделать запросто. Для одной статьи это перебор. Так что надо таки писать «критику Си» отдельно. Такие источники как Джойнер будут дублироваться, но браться из них будут другие фразы. Arachnelis 20:45, 31 января 2016 (UTC)Ответить

• У Никлауса Вирта есть скажем так критические статьи. Советую его, это старый, уважаемый и опытный человек. --31.173.240.236 18:40, 29 января 2016 (UTC)Ответить

• Но явно предвзятый. У него споры с линией языков, которую сейчас представляют С/С++, ещё со времён Algol 68 (каковой Страуструп любил, ценил и из которого заимствовал идеи, да и в чистом Си влияние есть, начиная с фигурных скобочек, хотя в А68 было чуть по другому). А Паскаль, это прямой потомок Виртовского ALGOL W^[англ.], модифицированного Алгола-60, который тот предлагал в качестве альтернативы. Так что статьи Вирта тут будут первичным источником. --be-nt-all 19:36, 29 января 2016 (UTC)Ответить

• В данном случае «предвзятость» значения не имеет. Некий авторитетный автор высказался критично — можно сослаться и описать в общем и целом, о чём конкретно он говорит. Соглашаться с ним или нет, придавать ему значение или нет — это уже дело читателя. Таки энциклопедия! Arachnelis 19:56, 31 января 2016 (UTC)Ответить

• «Некий авторитетный автор» — ну зачем же так. Никлаус Вирт — человек с мировым именем. Он никогда языки программирования просто так не критиковал, на то всегда были веские основания. Мое скромное мнение таково: "это тот человек, к которому надо прислушиваться". Кстати, его любит прослойка людей из академической науки. --31.173.242.226 17:00, 2 февраля 2016 (UTC)Ответить

• Во-первых, не придирайтесь к словам. Во-вторых, Вирта на фоне Хоара иногда высмеивают. Давайте не будем здесь холиварить, достаточно сойтись на том, что ссылаться из критики Си и/или С++ на Вирта очень даже можно. Arachnelis 17:10, 3 февраля 2016 (UTC)Ответить

А воз и ныне там. Где раздел "Критика"? Какой-то невразумительный раздел: "Преимущества и недостатки". Пытаетесь отделаться общими и туманными фразами. Сейчас на вас натравлю злого Паскальщика (шутка :)  :) --31.173.243.82 12:08, 2 марта 2016 (UTC)Ответить

• Воз никто и не толкал. Терпение, друг мой. Москва не сразу строилась. Arachnelis 15:00, 2 марта 2016 (UTC)Ответить

@D6194c-1cc:, вы отменили правку по удалению данного раздела. Предлагаю обсудить.

Почему раздела не должно быть в данной статье?

1. Представление в памяти специфично для конкретной архитектуры и конкретной ОС. А си абстрагируется от специфичных для платформы вещей.
2. Подобное представление не имеет отношение к Си, а имеет отношение к любой запущенной программе в ОС. В си данный раздел я внёс когда-то давно, потому что большинство софта написано на си. Те же джава и питон запускают интерпретатор, который точно так же представлен в памяти. Данный раздел абсолютно так же применим к статьям про С++, паскаль, rust, swift и уйму других языков, транслирующихся в машинный код.

Я немного адаптировал раздел, убрал некоторые косяки, но тем не менее считаю, что данная тема должна рассматриваться только в Процесс (информатика)#Представление процесса в памяти. Грамотнее было бы просто оставить ссылку в статье. Одна статья IMO должна описывать только одно явление, но делать это хорошо, как по принципу KISS. Yanpas (обс.) 14:29, 4 октября 2017 (UTC)Ответить

• Вряд ли Вы найдёте архитектуру, которая будет сильно отличаться от той, которая описывается. Как минимум везде есть стек и куча. Разве что у контроллеров нет виртуальной памяти. Программирование на Си является низкоуровневым и неразрывно связано с пониманием устройства памяти процесса, поэтому здесь должно быть хотя бы краткое описание на разные случаи архитектур. В качестве решения предлагаю вынести представление процесса в памяти в отдельную статью (тема очень широкая), а раздел сделать ссылкой на эту статью. То же самое можно сделать со статьёй Процесс (информатика)#Представление процесса в памяти. Если сделаете, я добавлю краткое описание под ссылкой на основной раздел, где будут, в частности, указаны опции компиляции под конкретные модели памяти с примерами, а также опишу PIE. D6194c-1cc (обс.) 16:08, 4 октября 2017 (UTC)Ответить

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

Я взялся за рефакторинг и улучшение данной статьи, попробую довести до статуса хорошей, если хватит свободного времени. Сейчас статья разрослась до размеров, близких к 250 Кб. В связи с этим, раздел «История» был вынесен в отдельную статью, причин для именно этого раздела несколько. Во-первых, много информации, не несущей значительной практической пользы для большей части аудитории. Во-вторых, значительно уменьшено оглавление статьи, что делает его более читабельным. -- D6194c-1cc (обс.) 12:31, 3 февраля 2019 (UTC)Ответить

В свою универскую бытность встретил впечатливший меня пример работы с индексами ^[1]:

- валидной является даже такая форма обращения по индексу: 1[arr], где arr - это некий массив;

- так как arr[1] == *(arr + 1) == *(1 + arr) == 1[arr].

Понятно, что так в реальной жизни никто не пишет, но пример на понимание связи адресной арифметики с индексами массива мне кажется очень хороший. Коллеги, как думаете, стоит ли добавлять в статью или лишнее? Kirlf (обс.) 22:55, 5 января 2022 (UTC)Ответить

• А зачем? Ну то есть, в чём практическая ценность такой информации? На практике это просто забавный факт или пример того, как делать не нужно (по крайней мере в последних вариантах). Пригодиться это может разве что на конкурсе по самому запутанному коду. как мне кажется. -- D6194c-1cc (обс.) 08:09, 6 января 2022 (UTC)Ответить

• • "Понятно, что так в реальной жизни никто не пишет, но пример на понимание связи адресной арифметики с индексами массива мне кажется очень хороший." - вот моя основная мысль. Я просто рассуждал с точки зрения статьи о языке и его особенностях, а не с точки зрения паттернов или антипаттенов написания кода. Могу согласиться, что информация может быть избыточной с точки зрения формата статьи в Википедии. Собственно, поэтому и задал вопрос... Kirlf (обс.) 21:45, 7 января 2022 (UTC)Ответить
    • На самом деле немного эта тема затронута, но в разделе «Отсутствие контроля над адресной арифметикой» как пример недостатков языка. Если такая информация добавляется, то должна добавляться не как пример того, как можно делать, а как пример того, что в языке делать опасно или нежелательно. -- D6194c-1cc (обс.) 10:20, 8 января 2022 (UTC)Ответить

"Оператор" в статье используется в двух смыслах: англ. statement и англ. operator. Это может сбивать читателей с толку.

Не лучше ли переводить "operator" как операция и оставить оператор только как перевод англ. statement?

Подобная терминология тому, что я предлагаю, содержится, как минимум в старых книгах по Паскалю. Я не знаю о современной терминологии на русском языке, так как читаю главным образом по английски. VictorPorton (обс.) 12:58, 2 декабря 2022 (UTC)Ответить

• Если рассматривать, например, операцию сложения, то это операция, а знак + является оператором. В случае +=, например, операцию сложно будет как-то отдельно обозначить, поскольку это всё ещё операция сложения, а вот оператор в данном случае – +=. Поэтому лучше всё таким рассматривать в таких случаях операторы, как мне кажется. Для примера, операция сложения строк в разных языках может быть через разные операторы (+, ., ..), операция одна, а операторы – разные (в Си такой операции нет, разумеется). D6194c-1cc (обс.) 13:38, 2 декабря 2022 (UTC)Ответить
• Ну и в стандарте тоже рассматриваются операторы. Операции можно упоминать там, где это удобно по контексту. D6194c-1cc (обс.) 13:53, 2 декабря 2022 (UTC)Ответить

1. ↑ Гриффитс, Гриффитс: Изучаем программирование на C, - М. Эксмо, 2013. - С. 77 - 139