Обсуждение:C++/Архив/1

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

побольше бы

Хорошо бы побольше написать...

///Demon/// — Эта реплика добавлена с IP 195.230.73.2 (о) 07:48, 21 сентября 2004 (UTC)

Конечно, хорошо бы. Напишешь? MaxiMaxiMax 08:16, 21 Сен 2004 (UTC)

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

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

--achp 11:39, 11 марта 2006 (UTC)

Нефиг-нефиг. Энциклопедическая статья должна раскрывать предмет в достаточной мере. Раз язык громоздкий - получайте и статью громоздкую. Тем более, что новички в С++ будут знать, что им предстоит. Arachnelis 15:03, 5 августа 2013 (UTC) Arachnelis

Сократил статью ещё --Urod 02:06, 21 июня 2006 (UTC)

Не писать return 0; в main() это всё-таки дурной тон. Думаю, надо оставить только последний пример с добавлением return 0; .

И ещё нужна ссылка на STL, ибо стандарт и фундаментальная часть языка.

Как-нибудь доберусь -- распишу...

--Maxim Razin 15:33, 4 Янв 2005 (UTC)

---

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

Про STL тоже напишу…

§l1ck Ar7ist 15:28, 14 Фев 2005 (UTC)

В основном всё готово. Недоделки — отсутствие списка внешних адресов. Ну и какую-нибудь картинку можно для красоты поместить. Потом можно и на «лучшее» номинироваться. :) §l1ck Ar7ist 14:32, 16 Фев 2005 (UTC)

Вообще-то, исходя из семантики названия языка, следовало бы переименовать статью в «Си-плюс-плюс» или «Си плюс-плюс»: ведь речь не о том, что к Си прибавляется плюс, а о том, что производится инкрементация. По-моему, если название понятия состоит из равноправных

частей речи (первый плюс ничем не хуже второго), из надо через дефис. Al Silonov 8 июля 2005 12:10 (UTC)

В целом у вас вышел детский сад. Переработал анализ достоинств и недостатков, а также полиморфизм. Arachnelis 15:03, 5 августа 2013 (UTC) Arachnelis

Bjarne

Бьярне Страуструп — верная транслитерация. Ramir 02:42, 2 января 2006 (UTC)

А статья утверждает обратное, да и сам Бьярне, похоже склоняется именно к варианту Строуструп (см. аудиозапись произношения). ~ qvvx 11:10, 4 января 2006 (UTC)

Да. Ramir 08:12, 21 июня 2006 (UTC)

Картинка

А в этой картинке есть какой-то смысл? --Solon 23:13, 29 ноября 2005 (UTC)

Картинка в вводном абзаце не несёт никакой смысловой нагрузки вообще, зато съедает много места. Предлагаю избавиться от неё. ~ qvvx 20:50, 3 января 2006 (UTC)

А, прошу прощения, не заметил сообщение Solon. Ну, раз возражений не последовало, то я убираю картинку. ~ qvvx 21:29, 3 января 2006 (UTC)

Убрал пассаж "что дает серьёзные преимущества по сравнению с другими языками". К сожалению, не указаны ни обоснование, ни источники. Nikov 11:31, 3 ноября 2007 (UTC)

Недостатки языка C++: Отсутствие RTTI и CTTI (Compile Time Type Info)

В первую очередь - остуствие CTTI является недостатком, но никак не отсутствие RTTI. Так как язык C++ - язык построения систем, а никак не язык использования каких то конкретных систем (таких как Garbage Collection и RTTI). Как раз добавление в язык CTTI позволит строить любые RTTI. Поэтому - отсутствие RTTI (и связанных с ним затрат) не является недостатком, а может даже достоинством.

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

Sergey Shandar — Эта реплика добавлена участником Sergey shandar (о • в) 03:37, 20 июня 2006 (UTC)

Раздел "Недостатки" переименовал. Большинство этих «недостатков» сводится к тому, что С++ - не Java. Они не устранимы без превращения С++ в интерпретируемый язык и, соответственно, резкой потери эффективности. Нельзя в статье "автомобиль Форд-Эскорт" в разделе "недостатки" писать, что он не может перевозить многотонные грузы. Я хотел бы вообще выбросить раздел: С++ и Java - языки разных типов, применимые в разных областях и некорректно их сравнивать. — Эта реплика добавлена участником Urod (о • в) 02:06, 21 июня 2006 (UTC)

Так смотря с чем сравнивать. Если сравнивать С++ со Scheme, SML, Forth, Prolog, Smalltalk и Рефал, то он никакой критики не выдерживает. Вообще "критика" - это перечень субъективных, спорных свойств. А в случае с С++ любой достаточно грамотный специалист в Computer Science легко перечислит сотню-другую недостатков, начиная с неполноты и неортогональности системы типов или принципиальной невозможности управления памятью через вывод регионов. Arachnelis 15:57, 5 августа 2013 (UTC) Arachnelis

Согласен. Максимум что оставить - так это различия. Но убрать "сторонников C++" и "сторонников Java". --Sergey Shandar 13:40, 21 июня 2006 (UTC)

Не путаем CTTI и RTTI. Java имеет RTTI, но Java НЕ имеет полноценного CTTI, так же как и средств для метапрограммирования (программирование и вычисление во время компиляции). --Sergey Shandar 12:45, 22 июня 2006 (UTC)

Коллеги, вы вообще о чём? RTTI в C++ как раз есть, это dynamic_cast и typeof (и лично я это рассматриваю как один из самых больших недостатков языка, но тут уже возможны и иные мнения) DrCroco 13:21, 22 января 2008 (UTC)

-- А как же dynamic_cast и typeid ? Это разве не относится к RTTI ? Касательно garbage collection можно радостно использовать shared и auto указатели как альтернативу.

<yurec> — Эта реплика добавлена с IP 195.39.210.202 (о) 22:49, 3 ноября 2008 (UTC)

В C++ не полноценный RTTI, храниться только очень-очень мальнькая часть информации о типе (не вся как в Java или .NET), и то, в многих компиляторах можно выключить польностью. --Сергей Шандар 15:40, 28 апреля 2009 (UTC)

Сравнение с Java

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

Это не совсем правда. Java может компилировать в машнный код. См. JIT

--Sergey Shandar 09:28, 21 июня 2006 (UTC)

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

Неспроста основатель Java и производитель hardware Sun заняла ту позицию, которая она заняла.

--HenryS 16:06, 25 июня 2006 (UTC)

Священная война

Сам факт такой "войны" обязан быть отражён в статье. Я создал два независимых раздела, которые прошу заполнить неон 10:58, 21 июня 2006 (UTC)

Давай, тогда, вынесем это ниже достоинств и недостатков. Хотя по мне - этой войны в статье не должно быть. Лучще найти компромис и объективную информацию. Все эти войны, в основнов, из за не понимания предназначения языка. Например, может быть достаточно дать пару ссылок на RSDN, где эти войны носят тотальный характер и флейм по ним идет на несколько мега страниц... Сразу скажу - я не сторонник ни одного из этих языков. Я их просто применяю там где нужно, каждый в своей области. Например, написать маршалинг интерфейсов лучше на C++, так как необходимо работать с незащищенной памятью, и стеком. А написать GUI лучше, конечно, на Java. Ссылки на войны http://www.rsdn.ru/forum/?group=flame.comp. По поиску можно найти очень много споров что лучще и что хуже.

--Sergey Shandar 13:31, 21 июня 2006 (UTC)

Добавил объективную информацию про анализ общей культуры программирования, с рассмотрением, кто хвалит С++ и почему. В качестве примеров собрал пять ссылок на форумы с участием действительно грамотных людей, которым действительно есть с чем сравнивать тот или иной язык, а не одних только плюсисто-джавистов. Ссылки не пропустил спам-фильтр, поэтому сделал их текстом. Надеюсь, сгодится. Arachnelis 16:07, 5 августа 2013 (UTC) Arachnelis

Согласен насчёт вынести в конец статьи. Кстати хорошо бы и написать про сам факт такой войны и дать эти ссылки - явление знаменательное. Приведите пожалуйста! То что у сторонников Явы больше аргументов, и то что "С не Ява" - тоже закономерно, потому что Яву разрабатывали после С с учётом его недостатков и пытаясь улучшить язык неон 13:47, 21 июня 2006 (UTC)

Например: http://www.rsdn.ru/Forum/Message.aspx?mid=1669546&only=1 - С++ vs C# (я это даже не читаю, не осилил :-) — Эта реплика добавлена участником Sergey shandar (о • в) 13:52, 21 июня 2006 (UTC)

Здорово! Если можете доработать - попробуйте, если лень - я попытаюсь сам :-) Собственно тут не место для теоретических споров, но существующие мнения в обе стороны хорошо бы отразить для потомства. неон 14:01, 21 июня 2006 (UTC)

Попробуйте сами. А я позже гляну :-) — Эта реплика добавлена участником Sergey shandar (о • в) 14:09, 21 июня 2006 (UTC)

Хорошо, попробую, а Вы если что - подправите неон 14:12, 21 июня 2006 (UTC)

Уже лучще :-) С некоторыми пунктами я все еще не согласен. Но, пока, закрою на них глаза --Sergey Shandar 01:12, 22 июня 2006 (UTC)

Почему не надо войны

Например, моя критика на критику :-) :

Критика языка Java сторонниками C++

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

Это не правда :-)Java может компилироваться. Иногда код может быть даже быстрее на Java, все еще зависит еще от того кто писал и как :-)

Критика С++ сторонниками Java

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

- то были неправильные сторонники C++ :-) ни Java ни C++ пока не стоят на месте.

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

- это зависит от КУЛЬТУРЫ программирования. На ассемблере тоже можно писать применяя ООП, а на Java процедурно. Есть и принципы и в C++ по организации (например, см. Boost). Данная гибкость означает только то, что ты свободен в праве выбора, но со свободой появляется и ответственность, и про это многие забывают.

* В языке C++ нет чётко определённых стандартов на ввод-вывод, графику, геометрию, диалог, доступ к базам данных и прочим типовым приложениям.

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

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

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

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

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

--Sergey Shandar 14:10, 21 июня 2006 (UTC)

Хм... Критика не объективная

IMHO: В статье появилось много совсем не признаных или спорных недостатков. Которые, я лично, не считал за недостатки или за очень незначительные. Скорее как особенность языка. Например:

Это только из-за узкого кругозора. Вам не с чем сравнивать, кроме одинаковых и однообразных потомков Алгола. Ознакомьтесь с SML и Smalltalk хотя бы - сразу поймёте, что объективно, а что субъективно.
Arachnelis 15:08, 5 августа 2013 (UTC) Arachnelis

* C++ унаследовал многие проблемы языка C:

Согласен, но наследство можно использовать и как достоинство. Например, затем же C# брал синтаксис из C++, что бы программистам было легче переходить, а не из за того что это красиво.

o Операция присваивания обозначается = , а операция сравнения == . Их легко спутать, и такая конструкция будет синтаксически правильной, но приведёт к труднонаходимому багу. Особенно часто это происходит в операторах if и while, например, программист пишет if (i=0) вместо if (i==0).

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

o Некоторые считают неправильным приоритет операций: например, в выражении (a<b&c<d) сначала будет выполнена операция &.

Ну да, ведь есть еще операция && для булевских операция. А & это битовая операция, поэтому приоритет ОЧЕНЬ ДАЖЕ правильный!

o Операции присваивания (=), инкрементации (++), декрементации (--) и другие выдают значение. В сочетании с обилием операций это позволяет, но не обязывает программиста, создавать сложные для понимания выражения.

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

o Некоторые преобразования типов неинтуитивны. В частности, операция над беззнаковым и знаковым числами выдаёт беззнаковый результат. Например, unsigned u=0; double d=u-1; приведёт к тому, что d будет большим положительным числом, а не -1, как можно ожидать.

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

o Подключение интерфейса внешнего модуля через препроцессорную вставку заголовочного файла (#include) серьезно замедляет компиляцию, при подключении большого количества модулей. Для устранения этого недостатка, многие компиляторы реализуют механизм прекомпиляции заголовочных файлов Precompiled Headers.

Это реальный недостаток.

o Недостаток информации о типах данных во время компиляции (CTTI).

Аналогично. Так как отсутствие CTTI серьезно затрудняет работу с типами данных в шаблонах.

o Макросы (#define) являются мощным, но опасным, средством. В языке C++, в отличие от C, необходимость в опасных макросах появляется крайне редко, благодаря шаблонам и встроенным функциям. Однако в стандартных библиотеках много потенциально опасных макросов.

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

o Нет проверки выхода за границы массива.

Это очень даже хорошо!!!

Это только в сравнении с потомками Алгола. В языках семейства ML не приходится платить за контроль при проходе по цепочке. Паттерн-мэтчинг на типизированных S-выражениях через хвостовую рекурсию и list comprehensions на простых ситуациях транслируется в то же, что и цикл Си, только не позволяет ошибиться с началом или концом - умышленный пропуск явно бросится в глаза. На сложных ситуациях в ML код будет столь же прост и лаконичен, а в С++ вы замучаетесь отлаживать переменные циклов.
Arachnelis 15:08, 5 августа 2013 (UTC) Arachnelis

o Язык C++ гораздо сложнее для изучения

Это да. Но зато как мощный инструмент после того как научился им пользоватся :-) Как сравнивать ручную коробку передач и автомат.

Точнее, как стамеску и циркулярную пилу. Arachnelis 14:25, 9 августа 2013 (UTC) Arachnelis

o Язык C++ сложнее для компиляции. И?

o Код на C++ после компиляции обычно занимает гораздо больше места. Так, в системе Cygwin программа после компиляции со стандартными флагами занимает 465 килобайт. Аналогичная программа на C после компиляции занимает меньше 9 килобайт.

1. А кто заставляет использовать std::cout? 2. Полностью зависит от компилятора!

* В Стандартной библиотеке шаблонов нет массивов размерности больше 1. Такие массивы приходится представлять как вектора векторов, вектора векторов векторов и т. д. Это неудобно и часто неэффективно.

Boost.multiarray есть. А стандартная библиотека обеспечивает только базовую функциональность.

* Любое поле класса или полностью доступно, или полностью недоступно извне класса. Невозможно сделать поле доступным только для чтения. ???

* Некоторые считают недостатком языка C++ отсутствие системы сборки мусора. Только некоторые так считают. Это не повод добавлять это в статью в раздел недостатки.

Ребята. Давайте называть НЕДОСТАТКАМИ то что нельзя исправить или обойти в той сфере применения для которой предназначен язык C++. А то можно придумать ОЧЕНЬ МНОГО, например: в стандартной библиотеке нет способа общения с базой данных MySQL...

Есть особенности языка, которые накладывают на него определенную область применимости. Например, в C# есть GC, и это для многих систем может быть серьезным "НЕДОСТАТКОМ", хотя на самом деле это особенность языка, которая определяет область применимости!

--Sergey Shandar 13:57, 25 июня 2006 (UTC)

o Некоторые считают неправильным приоритет операций: например, в выражении (a<b&c<d) сначала будет выполнена операция &.

Ну да, ведь есть еще операция && для булевских операция. А & это битовая операция, поэтому приоритет ОЧЕНЬ ДАЖЕ правильный!

Критика правомерна. Но пример был выбран действительно неудачно. В русском издании "Дизайн и эволюция С++" (ISBN 5-469-01217-4) указан более интересный и более часто встречающийся на практике пример: if(x & 0x77 == 0){} (параграф 2.6, страница 52) 91.90.36.250 15:26, 17 мая 2007 (UTC)

Сравнения языков и .т.п

Думаю, что не к месту оно здесь. Пусть это будет отдельные статьи - если очень хочется. А в статье о языке достаточно и необходимо указать область применимости и достоинства и недостатки В ЭТИХ ОБЛАСТЯХ. Все!

--150.101.25.90 05:19, 17 июля 2006 (UTC)

Поэтому и удалил из статьи сравнение C++ с Java. Это как сравнивать носорога с бульдогом. Можно, но не нужно. Совершенно разные подходы и области применимости.

Как же тогда подтвердить утверждения о том, что что-то в С++ плохо? Скажи, что в С++ нет полиморфизма - и первый же проходящий С++ник либо уберёт, либо повесит запрос источника. А так - сослался на языки, типизированные по Хиндли-Милнеру - и вопросов нет. Это верно для очень и очень многих аспектов. Общеизвестные в Computer Science вещи зачастую искренне удивляют С++ников, т.к. в этом языке всё сделано шиворот навыворот. Так что без сравнений никак.
Arachnelis 15:41, 5 августа 2013 (UTC) Arachnelis

--Sergey Shandar 05:21, 17 июля 2006 (UTC)

Очень к месту, особенно для энциклопедической статьи, зафиксировать все мнения за и против. Ява разрабатывалась позже с учетом недостатков языка С++, пока этот спор в памяти людской, надо его отразить. Тут не футбол и не политика :-), речь идет о технических решениях и о причинах по каким одни решения являются предпочтительнее других. Это нельзя умалчивать неон 07:41, 17 июля 2006 (UTC)

Дело в том, что у этих языков разные области применения. Да, в области высокоуровневого программирования Java дает серьезные преимущества. Но никак не на низком/среднем уровне. Статья перегжруженна. Лучще сделать отдельную статью. Так как, такие сравниния C++ и Java в статье о C++ дают ЛОЖНОЕ представление о языках. Почему бы тогда не сравнить с Python или c Nemerle. Почему Java? Java имеет отношения к C++ только частичной похожестью синтаксиса, семантика совершенно другая. Можно посмотреть, например, статью на английском языке. Нет там такого. Есть критика, и ссылки на критику. А не полный список сравнения C++ с Java и т.п.

--Sergey Shandar 04:04, 20 июля 2006 (UTC)

Сравнение языков программирования должно основываться на задачах решаемых этим языком. И успешных и не успешных проектах реализованных на этих языках. Например Линукс это Си, Microsoft Office это С++, OpenOffice это Java. А вдаваться в подробности синтаксиса, в рамках этой статьи, глупо. Лучше дать ссылку на описание синтаксиса. Ссылку на компиляторы свободные и не. Сказать что 98% приложений для платформы Windows написаны на Си++. И тогда споры, из абстрактных материй перейдут к количественным, и эта величина 98, опустится до 96 или до 95. Но смысл этого языка будет уже понятен даже школьнику.

--Дмитрий Лужецкий 21:49, 20 декабря 2007 (UTC)

Недостатки

То что сейчас в статье недостатки - это не недостатки, это критика. Это разные вещи.

--Sergey Shandar 03:59, 20 июля 2006 (UTC)

Осторожно доработал критику, выделил особенности и добавил пару десятков недостатков. Arachnelis 16:10, 5 августа 2013 (UTC) Arachnelis

Твои недостатки - это сравнение с ML, а не недостатки. Зачем вообще сравнивать мейнстримовый язык с функциональной маргинальщиной?

Во-первых, не только с ML. Во-вторых, анализ системы типов и её связи с человеческим фактором - это не сравнение. Если угодно, в крайнем случае, это те самые причины, по которым грамотные люди С++ избегают. Есть теории языков, графов, множеств, типов и др., и с их позиции можно проанализировать любой язык. В-третьих, если где-то сделали лучше, при этом не добавив своих недостатков, то характеристики обсуждаемой технологии автоматически получают статус "недостатков", и вменяемые технические специалисты должны сразу перейти на альтернативу (если не дураки, а действительно технические специалисты). Спорить об "относительности недостатков" можно только, когда их устранение автоматически добавляет другие - но в ML это не так. И любая критическая энциклопедическая статья должна указывать на подобные контр-примеры (иначе всякий проходящий "специалист" с узким кругозором сразу начнёт развешивать запросы на источники). В-четвёртых, причины сравнения обоснованы в самой статье - С++ претендует на "универсальность", так что сравнивать его следует с самыми разными языками, применяемыми в самых разных секторах индустрии. Кстати, OCaml входит в число наиболее популярных в промышленности языков, да и Haskell набирает обороты. Но, судя употреблённому тобой слову "маргинальщина", ты под словом "мейнстрим" понимаешь "поточное производство" в значении "стаемартышачное программирование", когда главный критерий к нанимаемым "специалистам" - низкая цена и высокая доступность, чтобы можно было их менять, как равшанов на стройке. Согласен, при таком подходе сравнение с ML нелепо - тут надо сравнивать с Бейсиком и Дельфи. Увы, это не ко мне. Но, я уверен, желающие показать, что всё то же самое можно делать намного проще, найдутся. (Сравнение с Джавой я подредактировал.) Если же ты употребил слово "маргинальщина" в значении "никем нигде не применяемое средство", то ты ой как ошибся.
Arachnelis 15:59, 9 августа 2013 (UTC) Arachnelis

Размеры статьи

По моему, что то статья совсем испортилась, особенно после добавления этих огромных примеров и сравнений :-( Вообще, это кто нибудь читает? Я имею ввиду обсуждение. Или просто в статью добавляют все что угодно, как в помойную яму? Ау!

--Sergey Shandar 15:53, 1 августа 2006 (UTC)

Примеры можно подсократить - эти примеры ничего не дают. Достоиннства такие что хоть плачь. Их же можно объявить недостатками или залепухами неон 16:03, 1 августа 2006 (UTC)

Рад что ты откликнулся :-) (на ты/Вы?)

• Примеры большие убрать, если очень жалко (мне нет) - то в отдельную статью.
• Достоинства/недостатки. Здесь могу не согласитья (хотя бы с той же масштабируемостью), но это опять уйдет в войны. Предлагаю тогда оставить ТОЛЬКО раздел "Критику", без сравнения с Java и без недостатков/достоинств.

--Sergey Shandar 16:18, 1 августа 2006 (UTC)

Пример "Крестики нолики" убрал. --Sergey Shandar 16:22, 1 августа 2006 (UTC)

Давайте уберем отсюда учебник по ООП. Ну зачем в статье по языку С++ огромный раздел про инкапсуляцию? Имхо, достаточно сказать, что инкапсуляция поддерживается в С++ через модификаторы доступа public/protected/private/friend и дать ссылку на соответствующую статью. Ну и так далее. А то статью совсем читать невозможно. Enerjazzer 04:13, 8 сентября 2008 (UTC)

C# как новый язык

"...фирма Майкрософт предложила язык C# как новый язык, развивающий принципы C++..." Ну это вообще дезинформация! — Эта реплика добавлена с IP 195.218.214.217 (о) 12:20, 3 ноября 2006 (UTC)

Критика ООП

Не совсем по теме, но всё-таки. Проблемы старого подхода несколько неадекватны. Начнём с того, что функции Elem и ChangeElem бредовы. Тупое следование принципам ООП до добра не доводит, особенно если пишешь на не-ООП языке. Вызовы FreeArray и AllocArray ничем не хуже вызовов new и delete, защиту от двойного вызова можно сделать, ну а вообще программист должен знать, что где аллочится, а не уповать на компилятор, что тот в нужном месте что-то удалит или создаст. Другие функции для работы с Array - это то, что надо. Я никогда не понимал, почему у адептов С++ какая-то мания по ограничению доступа себя самого к внутренностям объектов? И потом ещё специальные методы для преодоления таких ограничений (типа friend). Соответственно, мешая менять val и len программист сам себе убивает эффективность программы - отсюда и неэффективные функции Elem и ChangeElem вместо ясных обращений к arr.val[i] (которые эффективны донельзя). Присваивание объектов работает в C и C++ одинаково - копированием памяти (если не перегружен оператор присваивания, что в C эквиванетно вызову функции копирования). Непонятно, как С++ эту проблему решает. В C давно известно, что использовать лучше указатель на структуру, чем её саму, то же самое делается в Delphi (там вообще объекты - изначально указатели) и в C++ (тут уже вручную, объектность С++ ни при чём). В общем, какие-то надуманные аргументы...А вообще, можно было бы более конструктивную критику устроить, если бы был код(ы) на C++, в котором(ых) эти проблемы бы наглядно решались (а то какое-то голословное утверждение, и больше ничего). LRN 14:45, 14 марта 2007 (UTC)

Начнём с того, что функции Elem и ChangeElem бредовы. - конечно, бредовы. О том и речь: если попытаться решить проблему (доступ к 1-мерному массиву с проверкой выхода за границу) на старом С - получатся бредовые функции.

Интересно, зачем осуществлять доступ к элементам массива, которые не существуют (под существованием подразумевается нахождение в пределах границ массива), а если доступ осуществляется только к существующим элементам, то зачем проверка выхода за границу? Если делать проверку - то да, наверное действительно бред получается. И ещё...как аналогичный доступ будет осуществляться в C++? Там есть какой-то магический механизм, делающий функции Elem и ChangeElem класса Array быстрее?

Кстати, надо оговориться, что лично я под "C" понимаю C++ без использования встроенного в C++ механизма классов (и всего, что с ними связано) и некоторых других чисто C++'сных вещей. Это скорее "грязный C", а не "чистый C". В частности, я допускаю применение передачи по ссылке (о ней см. ниже). — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

Тупое следование принципам ООП до добра не доводит, особенно если пишешь на не-ООП языке. - действительно, не доводит. Но указанный код на старом С не следует никаким принципам ООП.

Имелось ввиду, что следуя принципам ООП он загоняет проверку границ внутрь класса Array, в то время как в C проверка границ обычно осуществляется перед обработкой массива. Для конструкции типа for (int i = 0; i < arr->len; i++) {} очень трудно выйти за границы массива. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

Вызовы FreeArray и AllocArray ничем не хуже вызовов new и delete - хуже, в тексте подробно объяснено чем.

защиту от двойного вызова можно сделать - действительно можно, но только за счёт дальнейшего усложнения класса. В С++ такого усложнения не требуется. Другие защиты сделать вообще невозможно.

Говоря об уложнениях - советую посмотреть код, который выполняется при вызове функции new. Кстати, у меня назрел вопрос: как в C++ выделить некоторый участок памяти (допустим - буфер в виде массива unsigned char'ов)? Как это делается с помощью new?

С другой стороны, зачем она нужна, эта защита? Неправильно написанную программу она не исправит, а отдебагить повторный вызов FreeArray - задача относительно простая (программа будет падать во время вызова, искать ничего не надо). А в C++ останется двойной вызов delete (или чем там будет удаляться класс), ибо защита. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

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

Незнание кода, над которым ведётся работа. Программист должен знать, как работает тот модуль, в пределах которого он пишет; и в пределах этого модуля правильно распоряжаться памятью. Если что-то выходит за пределы модуля - оно выходит по определённым правилам, которые заранее оговорены. Поэтому существуют и процветают C'шные библиотеки (как пример модульного кода). Естественно подразумевается, что остальные модули работают как надо, всё-таки и в C++ будет очень плохо искать неправильно описанный класс где-то в другом куске программы, писавшемся 10 лет назад. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

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

Проще найти ошибку в собственном коде, чем найти, почему вызывает ошибку в твоём коде другой код, созданный компилятором (причём сам факт существования этого второго кода нужно знать, т.е. нужно точно знать, что и где будет сгенерировано, и как оно работает). — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

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

В каком месте? В описании класса? Ну, можно все прототипы описать в одном месте - будет то же самое. Нет, конечно можно писать "от души", следуя по пятам за работой мысли, в результате чего код представлят из себя огромную кучу непонятно как связанных функций. А можно сначала прикинуть структуру программы, классов, и писать в соответствии с этим. И прямой доступ к данным будет лишь одним из инструментов (и будет применяться там, где он необходим). В основном это вопрос вменяемости программиста, хотя конечно проще ограничить программиста средствами языка. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

И потом ещё специальные методы для преодоления таких ограничений (типа friend). - см. выше. Доступ к защищённым членам не ограничивается - но все такие доступы должны быть указаны в одном месте. Для того и нужен механизм френдов, чтобы не ограничивать доступ к внутренностям объектов. Без френдов он был бы ограничен.

Присваивание объектов работает в C и C++ одинаково - копированием памяти (если не перегружен оператор присваивания, что в C эквиванетно вызову функции копирования). - неправильно. Присваивание в современном С++ работает вызовом копи-конструктора. В классе class A {std::vector<float> b; int c;} не нужно описывать оператор присваивания или явно описывать копи-конструктор.

Не понял...т.е. описывать копи-конструктор не нужно, но он будет работать. Что, опять компилятор сгенерирует? И как этот копи-конструктор будет работать? Уж не память ли будет копировать? Или вызовет копи-конструктор vector'а, который таки был написан? Тогда крыть нечем, кроме как написанием вручную функции копирования для класса А и вызова её вместо присваивания. Единственное, что портит прекрасную картину автоматически-рекурсивно-иерархического вызова копи-конструкторов - возможная необходимость дебагить эти вызовы. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

Непонятно, как С++ эту проблему решает. - какую проблему?

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

См. ниже. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

то же самое делается в Delphi (там вообще объекты - изначально указатели) - рад за Delphi.

Я тоже. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

и в C++ (тут уже вручную, объектность С++ ни при чём) - это в С вручную: пишутся амперсанды при каждом вызове и звёздочки или -> при упоминании параметра. В С++ амперсанд пишется один раз: в списке параметров. И правильно пишется: иногда (редко) надо передать объект не по ссылке. А ООП тут действительно ни при чём.

В C не пишутся амперсанды, в C пишутся звёздочи при объявлении переменной-указателя на объект. То же самое делается в C++. Потому что new возвращает указатель (без new объекты будут создаваться там, где они объявлены в коде). Так что все объекты хранятся в виде указателей на объекты (за редким исключением), а обращение к параметрам - с помощью -> (кстати, что в нём плохого?). А если после этого вызывать функцию с амперсандом, то как ей передавать объект, который известен только по указателю на него? Дереференсить указатель на объект и послать объект, чтобы компилятор сам сформировал указатель на объект и перадал в функцию? Как-то странно получается. Не, вообще аперсанд удобен - но как раз не для объектов, а для других данных, которые хранятся не в виде укзателей на области памяти, а просто так. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

В общем, какие-то надуманные аргументы...А вообще, можно было бы более конструктивную критику устроить, если бы был код(ы) на C++, в котором(ых) эти проблемы бы наглядно решались (а то какое-то голословное утверждение, и больше ничего). - см. выше. Да вы сами написали аргументы против старого С: и что программист должен знать, что где аллочится (это хорошо известный и убийственный аргумент против С), и что в С часто появляются бредовые функции. --Urod 15:52, 28 марта 2007 (UTC)

Нет, конечно есть области, где без ООП не обойтись, всё-таки наследование в C очень плохо реализуется, да и весь "высший пилотаж ООП" - тоже. Но, простите, обычную модульность и инкапсуляцию (понимая под инкапсуляцией группировку данных и функций в одной сущности) можно и так сделать...Зачем огород городить? Вспоминается бородатый прикол про эволюцию программиста и программу Hello World. — Эта реплика добавлена участником L.R.N (о • в) 11:00, 30 марта 2007 (UTC)

Подводя итоги.

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

P.S. Неправильно назван раздел. Я критикую С++, а не ООП. ООП не виновато, что его применяют где попало и как попало.

LRN 11:00, 30 марта 2007 (UTC)

Препроцессор

Достоинства языка C++

...

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

...

Недостатки языка C++

...

Препроцессор С++ (унаследованный от С) очень примитивен.

Помоему из этих двух утверждений надо выбрать что-то одно(а второе убрать). Либо примитивен, либо мощен. По-моему, cpp действительно примитивен (сравнить например с m4) Страуструп отзывался о препроцессоре отрицательно. К тому же препроцессор связан с языком очень слабо( например, препроцессор обрабатывает MACRO(std::pair<int,int>) как макрос с двумя параметрами --- первый это pair<int , а второй это int>, хотя это не желательно для многих макросов).

Вообщем если никто не будет возражать, препроцессор будет вычеркнут из достоинств языка. — Эта реплика добавлена с IP 91.90.36.250 (о) 16:19, 17 мая 2007 (UTC)

Наличие препроцессора - достоинство. Убогость этого препроцессора - недостаток. Enerjazzer 02:36, 3 июля 2009 (UTC)

"Наличие препроцессора" - не однозначно является достоинством. В общем случае достоинством является наличие макро-подмножества языка, но оно не обязательно воплощается в виде "препроцессора" - наоборот, в более развитых языках макроопределения имеют доступ к возможностям самого языка, да и не всякая грамматика допускает наличие препроцессора. Поэтому перенёс в "Избыточные и опасные возможности" в формулировке: "Средства макроподстановки Си (#define) являются сколь мощным, столь же опасным средством. Они сохранены в C++ несмотря на то, что для решения всех задач, для которых они были предусмотрены в Си, в С++ были предоставлены более строгие и специализированные средства — шаблоны, перегрузка функций, inline-функции, пространства имён, более развитая типизация, расширение применения модификатора const, и др." Так годится? Arachnelis 15:26, 9 августа 2013 (UTC) Arachnelis

Критика и компилятор gcc

Считаю, что нет необходимости публиковать длинные сообщения об ошибке gcc. Во-первых, это больше критика gcc, во-вторых, приведённая ошибка не добавляет энциклопедичности, в третьих, она занимает оцень большое место по ширине, что добавляет прокрукту по горизонтали даже при разрешении 1280 --Pavel Zubkov 20:39, 10 января 2008 (UTC)

Си++ не включает в себя Си

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

Си++ действительно не является надмножеством стандарта C99, однако же C89 является его подмножеством, так действующий на данный момент стандарт ANSI/ISO языка Си++ (принятый в 1998 г.) построен на основе стандарта C89.

Существует и такой верный для Си код, который неверен для Си++.

Опять же, это касается стандарта C99.

Например, следующий фрагмент кода корректен с точки зрения Си, но некорректен с точки зрения Си++:

  typedef struct mystr {
      int a;
      int b;
  } mystr;

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

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

  typedef struct mystr {
      int a;
      int b;
  };
mystr mystr; //ОК для Си++, ошибка в Си

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

struct mystr mystr;// Теперь приемлимо и для Си

Более того, код, верный для обоих языков, может давать разные результаты в зависимости от того, компилятором какого языка он оттранслирован. Например, следующая программа печатает «С», если компилируется компилятором Си, и «С++» — если компилятором Си++. Так происходит из-за того, что символьные константы в Си (например 'a') имеют тип int, а в Си++ — тип char.

#include <stdio.h>

int main()
{
    printf("%s\n", (sizeof('a') == sizeof(char)) ? "C++" : "C");
    return 0;
}

Можно было просто указать, что „символьные константы в Си (например 'a') имеют тип int, а в Си++ — тип char“

217.146.246.8 14:11, 3 мая 2008 (UTC)Vanuan

А как насчёт следующего?

int main ()
{
    int new = 5;
    return 0;
}

Это тривиальное различие основанное на расширении C++'ом множества ключевых слов C. Но не единственное. Мне как-то захотелось реализовать в C++ списки с принудительной связью. Арифметика указателей и преобразования типов, которые работали в C, в C++ работать перестали. Без static_cast обойтись мне не удалось. Это, быть может, не стоит относить к различиям синтаксиса, но именно это делает C несовместимым с C++. Или C++ несовместимым с C, но это уже не столь важно. зы. извиняйте мою лень, но если вам хочеться больше примеров, то возьмите какую-нибудь C-программу (тот же list.h из ядра linux) и попробуйте прогнать её через компилятор C++. 91.190.87.137 08:42, 13 апреля 2009 (UTC)

Однако все же хочется заметить, что автор языка С++ в своей книге (третье издание 2011 года. Перевод под редакцией Н.Н. Мартынова) говорит следующее: "C++ разрабатывался как расширение языка C и за малыми исключениями содержит С в качестве подмножества". Утверждать что С++ не включает в себя C слишком категорично. 86.57.196.100 23:10, 23 января 2014 (UTC)

Stroustrup FAQ - Is C a subset of C++? «In the strict mathematical sense, C isn’t a subset of C++. … C++ is as much a superset of ANSI C as ANSI C is a superset of K&R C and much as ISO C++ is a superset of C++ as it existed in 1985. Well written C tends to be legal C++ also.» Arachnelis 18:58, 24 января 2014 (UTC)

Статья должна быть информативнее

А как же к примеру компиляция программ на C++ для разных режимов ? Где разница и в чём к примеру для создания win32 based приложения и DOS mode приложения, какая роль MFC и вообще есть ли хоть что-либо об этом ? 79.111.9.190 14:10, 19 ноября 2008 (UTC)MisterC++

Какое отношение прикладная библиотека MFC имеет к самому языку? Она, вроде, в стандарт языка не встроена, так что ей тут не место, развечто в обзем списке известных библиотек, если такой вообще нужен, конечно. Enerjazzer 02:38, 3 июля 2009 (UTC)

Народ, а как насчет раздела компиляция?! 94.50.193.189 05:13, 3 марта 2011 (UTC)

А что должно быть в этом разделе? Я добавил ряд ссылок на статьи с RSDN, где сравниваются тонкости разных реализаций - там и про портируемость, и про скорость есть. Рассмотрены особенности раскрутки темплейтов, в одном месте даже упомянул компоновку RTL. Сперва должно идти "что", а уж затем "как", поэтому лучше указывать особенность реализации каждой фичи, а не собирать фичи в разделе про реализацию. Arachnelis 15:31, 9 августа 2013 (UTC) Arachnelis

inline

«inline является не директивой, а рекомендацией компилятору — компилятор не обязан реализовывать подстановку тела для inline-функций, но может, исходя из заданных критериев оптимизации, выполнять подстановку тела для функций, которые не объявлены как inline.»

По-моему последнего "НЕ" не должно быть Wiki vlad 08:15, 3 октября 2009 (UTC)wiki_vlad

• Компилятор может и без объявления inline делать это, поэтому всё правильно.--Angstorm 20:01, 3 октября 2009 (UTC)

объясните мне тогда зачем этот инлайн нужен вообще? Если и без него компиллятор может подставлять тело функии, и с ним может не подставлять? Wiki vlad 13:02, 5 октября 2009 (UTC)

Явное или неявное определение функции как inline изменяет действие правила одного определения на эту функцию.--achp 13:25, 5 октября 2009 (UTC)

А что такое "действие правила одного определения"?--Wiki vlad 12:07, 7 октября 2009 (UTC)

• Видимо он опечатался и имел ввиду "оного".--Angstorm 22:05, 7 октября 2009 (UTC)

Видимо, вам обоим надо ознакомиться с предметом обсуждения, то есть, с языком Си++. Правилу одного определения посвящён раздел 3.2 действующего стандарта.--achp 05:52, 8 октября 2009 (UTC)

Всё равно не понятно. Зачем Инлайн нужен если компилятор сам решает в обоих случаях подставлять или вызывать. «inline является не директивой, а рекомендацией компилятору — компилятор не обязан реализовывать подстановку тела для inline-функций, но может, исходя из заданных критериев оптимизации, выполнять подстановку тела для функций, которые не объявлены как inline» Особенно меня удвляет вторая часть предложения. Даже не инлайн функции компилятор может инлайнить? Всё завсит не от программиста а от компилятора? В учебнике по с++ например [1] ничего подобного не утверждается. Все очень просто: инлайн — подставляется, не инлайн — вызывается. Может быть это учебник по старому стандарту? А где последний стандарт можно почитать? Wiki vlad 06:36, 8 октября 2009 (UTC)

Ссылки на действующий стандарт нет, но есть ссылка на черновик готовящейся новой версии стандарта. Там раздел, посвящённый правилу одного определения, имеет всё тот же номер, 3.2 (к inline имеет отношение абзац 3).--achp 08:31, 8 октября 2009 (UTC)

Что касается оптимизации, то её логика лежит за пределами определения языка. Стандарт определяет только семантику языка. Спецификатор inline был изначально предназначен для того, чтобы воздействовать на оптимизатор, однако это воздействие только рекомендательное. Во-первых, оптимизатору встраивание функции может оказаться просто «не по зубам». Например, рекурсивную функцию встроить невозможно в принципе. Во-вторых, современные оптимизаторы настолько умные и изощрённые, что могут принимать решение сами, не полагаясь на рекомендацию пользователя. Зато тот эффект, который спецификатор оказывает на семантику программы, является обязательным.--achp 08:31, 8 октября 2009 (UTC)

Примеры

Господа, а кто-нибудь вообще читал примеры? Либо я чего-то не понимаю, либо в 5 примере ошибка, сейчас там так:

transformer odds(int n) { return transformer(counter(n), odd); }

transformer squares(int n) { return transformer(counter(n), square); }

но разве должно быть не так:

transformer odds(int n) { return transformer(counter(n), odd(n)); }

transformer squares(int n) { return transformer(counter(n), square(n)); }

80.64.109.156 11:16, 11 февраля 2010 (UTC)Александр

• На самом деле, из приведённого примера нельзя сказать, что там должно передаваться, поскольку тип transformer является шаблоном, определённым где-то в заголовочных файлах, интерфейс нам не показан, и потому нам неизвестно, какие параметры и с какими типами там следует передавать. А если пытаться анализировать смысл этого кода, то, по идее, там нужны именно функции (указатели на них), а не их один конкретный результат, иначе код теряет смысл. PS: А вообще, этот недавно добавленный пример, вероятно, следует либо переделать, упростив, либо вообще убрать, поскольку он не самодостаточен. Я уже не говорю про внешнюю ссылку, которая туда затесалась. -- A^VB^talk 13:09, 11 февраля 2010 (UTC)

• Наличие в примере функций int odd(int i) и int square(int i) все таки дает мне основание полагать, что их нужно использовать, посему, соглашусь с Вами, и предложу внести изменения так:

transformer odds(int n) { return transformer(counter(n), &odd(n)); }

transformer squares(int n) { return transformer(counter(n), &square(n)); }

Спасибо за ответ. 80.64.109.156 13:47, 11 февраля 2010 (UTC)Александр

• Во-первых, применение операция взятия адреса к именам функций излишне. Во-вторых, ваш вариант некорректен, поскольку пытается взять адрес от результата функции, а не самой функции. Вы здесь, видимо, решили повысить читабельность за счёт "изгаляний" над синтаксисом. Это бессмысленно и даже вредно, это попытка заменить (отсутствующий) КОММЕНТАРИЙ с пояснением конструкциями-идиомами из других языков. Это всё равно, как заменять конструкции вроде "a=b[++i]" на более "простые" конструкции вроде "i=i+1; a=b[i]" - такие попытки всего лишь показывают, что язык вам всё ещё недостаточно привычен. -- A^VB^talk 14:05, 11 февраля 2010 (UTC)

• Я не пытался повышать читабельность. Мои познания в с++ на начальном уровне, поэтому я и решил почитать данную статью. И этот пример меня запутал. Я просто хочу понять как будет правильно. Напишите, пожалуйста, верный вариант примера (в предположении, что кусок кода все же самодостаточный).

80.64.109.156 14:44, 11 февраля 2010 (UTC)Александр

• верный вариант примера - тот пример, который есть, как я предполагаю, верен. Проблема только в его несамодостаточности (данный конкретный пример нельзя рассматривать в отрыве от заголовков boost, которые нам не показаны). И я сейчас не готов убрать этот пример или предложить ему замену, поскольку для этого мне нужно пересмотреть всю статью, чтобы оценить, нужен ли этот раздел и нужен ли в нём такой пример. То, что у вас с этим примером возникли проблемы, может свидетельствовать за то, что в таком виде он в статье не нужен. (Учтите, речь ведь не об учебнике, а о кратком обзоре, в котором должны даваться ссылки на внешние источники с более подробной, в том числе и учебной информацией). -- A^VB^talk 20:22, 15 февраля 2010 (UTC)

• Энциклопедия - это не учебник. Согласен добавить пояснения. Александр Чуранов

• Пример добавил я. Отвечу на все вопросы. Он компилируется и работает в том виде, в котором изначально был добавлен, так что править точно ничего не нужно. Цель добавления примера - продемонстрировать, что на С++ возможно и такое написание, радикально отличающееся от предыдущих "упрощёнок". Это необходимо, чтобы у читателя было более полноценное представление о языке. Александр Чуранов

Динамический полиморфизм

Во фрагменте кода, посвящённом динамическому полиморфизму, убрал абсолютно лишние спецификаторы функций virtual в производных классах. Они только захламляют код и совершенно не нужны. Надеюсь, всем ясно, что объявлять функцию как virtual имеет смысл только в базовом классе. ;) Stalker 09:57, 4 ноября 2010 (UTC)

Всем может и ясно, однако это все же энциклопедическая статья, рассчитанная на широкий круг читателей, а не только на "гуру". Так что стоит оставить. К тому же, наличие этих спецификаторов в наследнике позволяет распознать, какие методы являются виртуальными, а какие нет. 78.155.193.36 17:46, 6 июня 2011 (UTC)

Так всё-таки C или Си?

Поскольку даже дети лейтенанта Шмидта заключили между собой конвенцию, предлагаю и авторам сей статьи (статей) установить соглашение: либо везде писать англоязычное название языка C, либо русскоязычное Си. В известных мне переводных книгах Бьярна Страуструпа по C++ переводчики выбрали именно англоязычный вариант C. Имхо предпочитаю также англоязычный вариант из уважения к оригиналу. Аргументы в пользу русскоязычного варианта вроде возможной путаницы из-за сходства с предлогом "С" считаю несерьёзными: человек, изучающий C/C++, прекрасно разберётся, где предлог, а где название языка. Иначе ему вообще нет смысла браться за слишком сложный для него предмет. ;) Stalker 10:24, 4 ноября 2010 (UTC)

Статья в википедии пишется для широкого круга читателей (большинство из которых вообще не программисты), а не для изучающих C/C++. Mathaddict 06:52, 28 ноября 2010 (UTC)

Согласен. И, между прочим, статья про сам Си называется именно Си (язык программирования) Arachnelis 15:44, 5 августа 2013 (UTC) Arachnelis

• Против "Си" и За "C" не следует уподобляться некому кандидату на позицию программера, у которого в резюме я встретил в списке языков не существующий язык Ci (Idot 16:35, 4 ноября 2013 (UTC))

Ошибка в правильном произношении C++.

Ошибка в правильном произношении C++.

Добрый день. Хочу поправить. С++ читается(прозиносится) как "Си плас плас" а не "Си плюс плюс".

С уважением Иван. 93.72.161.159 13:35, 1 декабря 2010 (UTC)

Поправлять не надо - на русском говорят "плюс плюс". Добавляйте, с примечанием, что так произносится в английском языке. -- X7q 13:53, 1 декабря 2010 (UTC)

Уберите Шилдта из списка рекомендованной литературы

В буржунете даже есть такое слово "Bullshildt" 81.195.20.101 18:26, 2 декабря 2010 (UTC)Vasya

А вы, Vasya читали его книги? Уверен, что нет 78.155.193.36 17:50, 6 июня 2011 (UTC)

Я читал. Дрянь. Enerjazzer 15:24, 27 августа 2013 (UTC)

На него там как раз есть ссылка из раздела "Критика" как на пример неправильной идеологии компонентности. Так что пусть остаётся Arachnelis 15:45, 27 августа 2013 (UTC) Arachnelis

Макросы

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

Можно сослаться на "Герб Саттер, Андрей Александреску. Стандарты программирования на С++" (http://ru.wikipedia.org/wiki/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:BookSources/9785845903518). --193.232.174.16 13:05, 18 января 2011 (UTC)

Сделал ссылку на имеющуюся у меня книгу Страуструпа. --Dr.Stein 08:28, 19 января 2011 (UTC)

Статически типизированный? Ой-ли?

А как же механизм шаблонов, templates? Не он ли позволяет назвать язык C++ именно динамически типизируемым, а не статически? 159.224.21.3 18:13, 3 мая 2012 (UTC)student

• Ой-ли, ой-ли. Шаблоны полностью обрабатываются на этапе компиляции и от них как от механизма не остаётся следов в исполняемой программе (разве что внутри дебаг-релизов можно видеть манглированные имена, порождённые шаблонными именами, которые нужны для более удобной отладки). Отсюда, кстати, и бешеное раздувание кода C++-программ, поскольку шаблоны должны порождать экземпляр кода для каждого типа среди их параметров (и оптимизаторы кода с этим как правило справляются плохо). -- A^VB^talk 18:20, 3 мая 2012 (UTC)

Исправьте ошибкуЁ! Статический полиморфизм

В статье неправильно преподносится "Статический полиморфизм", "Статическим полиморфизмом" называют перегрузку и шаблоны, а в статье приводится пример раннего связывания. Заменил "Статический полиморфизм" на "раннее связывание"(чтобы по крайней мере не вводить в заблуждение тех, кто в гугле искал "статический полиморфизм"), а тот, кому не лень, исправьте все остальное 128.73.110.23 18:13, 19 июня 2012 (UTC)liduk

Комментарии

Нужно побольше комментариев к участкам кода. А то новичкам сложно понять что к чему.91.196.7.134 06:09, 13 декабря 2012 (UTC)

Ресурсы в Интернете

Вот по ассемблеру есть замечательный ресурс WASM.RU А нет ли ничего подобного по C++? Всё таки самый "модный" язык Iskatel 14:04, 20 мая 2013 (UTC)

Есть http://www.cplusplus.com/ и http://cppreference.com/, не знаю, нужно ли добавлять в статью и как лучше это сделать? --andrybak 17:21, 9 января 2015 (UTC)

Достоинства и недостатки

Раздел "Достоинства языка и его критика" был написан на уровне детского лепета. Полностью переработал. Ничего не удалял, кроме объективных ошибок, но сгруппировал и обосновал. Зато многое добавил в него, а также сделал "Влияние и альтернативы", т.к. в разделе про Java тоже был детский лепет про всё подряд вплоть до Nemerle. Энциклопедичность изложения облизал языком. Если будет принято решение выделить всё это в отдельную статью - не возражаю. Но если у кого есть возражения (а я уверен, что у тех, кто любит С++, они будут) - прошу сперва сюда, а не обвешивать сразу статью запросами на общеизвестное. Arachnelis 15:51, 5 августа 2013 (UTC) Arachnelis

Очень не хватает критики С++ от программеров BrainFuck и J за многословность, от Питона за невнимание к отступам, от Паскаля за скобки вместо begin/end, и от Whitespace　за преступное пренебрежение пробелами. Надо обязательно расширить раздел критики соответствующими длинными двуязычными цитатами программеров на этих языках. Enerjazzer 21:08, 25 октября 2013 (UTC)

Так, я всё исправил, теперь объясняю. Поскольку ты не знаешь ничего, кроме С++ и прочих одинаковых и однообразных потомков Алгола, то многие аргументы тебе либо не понятны, либо ошибочно кажутся ненужными, но я готов объяснить и ответить на вопросы. Так вот, главная ошибка С++ников вроде тебя - программирование воспринимается вами не как всего лишь средство решения задач, от которого можно и нужно отказываться по возможности - а наоборот, как простор для самореализации. По этой причине ваша братия и пишет фразы типа "хорошего GC в С++ не будет, потому что он в нём не нужен". На самом деле не нужен тот язык, в котором нет возможности забыть о каких-либо низкоуровневых операциях, если они тебе сейчас не нужны - такой как С++. Программист должен стараться любой ценой поднять производительность своего труда, а не изобретать оправдания за её низкий уровень вроде "я не могу производить код быстрее и качественнее, потому что мне Сам Страуструп запретил". Твои попытки сократить статью за счёт раздела критики - это ввод читателя в заблуждение. Если язык объективно является уродством, и все грамотные специалисты это знают, то в энциклопедии это должно быть отражено. По другим языкам статьи не случайно короче - эти языки реально позволяют получить тот же функционал за меньшее время и с лучшим качеством, т.е. являются более совершенными инструментами для тех, кто воспринимает ЯП как инструмент, а не простор для самореализации. Так что сперва изучи альтернативы, а потом лезь в критику языка. Пока же занимайся лучше верхней частью, а я, если что, подкорректирую. Критику - обсуждай, а не исправляй.
Теперь по твоим откатам конкретно. Ты пробовал снимать константность с this? Во всех компиляторах? Что в Си глобальные переменные являются нормой - не ОРИСС, а традиция. Для примера почитай K&R - там и про #define, и про рекурсивные структуры, и про полиморфизм, и много про чего. Да чего там - если бы ты реально хоть раз решал задачу, которая действительно ТРЕБУЕТ Си (т.е. не допускает какой-нибудь Питон), типа микроконтроллера реального времени - то ты бы и не спорил - там и машинного времени на параметры не хватит, и нужды в том нет, т.к. код сравнительно невелик. А вот каким образом отсылка к Qt искажает рассмотрение темплейтов - я не вкуриваю. Ну да, я знаю, что С++ники наивно верят, что непортируемость - якобы временная и преувеличенная проблема, ну так на то и ссылка. Или мнение разработчика одной из лидирующих в Линухе библиотек - это на АИ? Про GC у тебя красиво получается: "Нужна автоматическая память? Ну так есть smart_ptr! Не тянет по скорости? Ну так надо слушаться Страуструпа и тормозить дальше! Ведь чего нет в С++, того и знать не обязательно! Это же Самый Супер Крутой И Мощный Язык Всех Времён И Народов, его нельзя упрекать ни в чём!" Что касается цитаты Торвальдса - то, насколько я знаю, так положено по правилам Википедии. Английский текст удалим, только если админы так велят.
Arachnelis 09:07, 26 октября 2013 (UTC)

Ваш поток сознания было очень интересно прочитать, но ему не место в энциклопедии. Если Вам так неймется, если Вы сделали соответствующее исследование С++ с т.з. Ваших любимых языков, опубликовали его в приличном рецензируемом месте и оно таким образом стало АИ, то мы обязательно сошлемся на него из раздела "критика", примерно так: "Некоторые специалисты (ссылка) считают С++ объективным уродством". А километровое полотенце в энциклопедии не нужно: энциклопедия - это не учебник и не издательство. В энциклопедии вполне достаточно простой ссылки на километровое полотенце, если оно АИ. Я не вижу, о чем тут можно дискутировать. И так понятно, что программеры на любом языке найдут кучу недостатков в любом другом. Не нужно все это тянуть сюда. Хотите обсудить K&R, препроцессор, голые указатели - идите в статью про Си. Посмотрите на статьи обо всех остальных языках - ни в одной нет подобного огромного флеймового раздела - везде объективное и, главное, _короткое_ описание особенностей языков, без навешивания ярлыков. Здесь же идет обыкновенное поливание грязью (причем как самого языка, так и программистов на нем). Выплескивайте свою ненависть/презрение к С++ в другом месте. Enerjazzer 10:10, 26 октября 2013 (UTC)

И прекращайте войну правок, здесь это не поощряется. Enerjazzer 10:22, 26 октября 2013 (UTC)

Я ничего не выплёскиваю, а терпеливо объясняю, почему я внёс в статью то, что в ней должно быть. Си, кстати, классический пример DSL, который вообще не проектировался для разработки БОЛЬШИХ приложений, и потому в нём не предусмотрены средства модульности. Именно поэтому глобалки в нём являются нормой. Плохо другое - ты в моём глазу соринку видишь, а в своём бревна не замечаешь. "Грязью" тебе кажется критика языка, которую ты воспринимаешь на свой личный счёт по причине того, что ничего другого знать не желаешь. Гвозди микроскопами забивать никто не запрещает, но С++ критикуют всегда только с позиции "эту вот задачу было удобнее решить на другом языке, но народ других языков упорно знать не желает". Прекратить войну правок я тебя пытаюсь убедить уже месяц, и повторю в очередной раз: сперва обсуди момент, который тебе не понравился, а по итогам обсуждения, если стороны пришли к общему мнению, или их рассудил админ - то уже не важно, кто эту правку внесёт. Arachnelis 10:26, 26 октября 2013 (UTC)

Кстати, насчёт учебника. Это как раз ты пытался удалять рассмотрение НЕДОСТАТКОВ С++, которые были унаследованы им из СВОЙСТВ Си - тем самым вынуждая читателя ИЗУЧИТЬ Си прежде, чем заказывать разработку С++-программистам. А если ты утверждаешь, что "программеры на любом языке найдут кучу недостатков в любом другом", и на этом основании требуешь удалить критику С++, то будь добр, приведи тут парочку существенных недостатков какого-нибудь диалекта ML в сравнении с С++ (не считая распространённости, разумеется,- исходя из предположения, что разработчик перед началом крупного проекта знает оба в равной степени и имеет свободу выбора) - тогда глядишь я и соглашусь, что это не недостатки. Я не случайно указал на ML, т.к. именно из него С++ унаследовал добрую половину свойств, отличающих его от Си.
Arachnelis 11:54, 26 октября 2013 (UTC)

Для участника с ником "Русские Идут!" Благодарю за дополнение про управление памятью. Правда, вполне вероятно (возможно, когда-нибудь это будет доказано объективно), что в уравнении несколько переменных: на Java разработка длиться долго по другим причинам, с лихвой перекрывающим выгоду от GC. Хорошее сравнение (к сожалению, я пока не видел публикации его результатов в АИ) есть на ffconsultancy - там не со скриптами сравнивают, а с компилируемыми статически типизируемыми языками, и выгода отмечена серьёзная. Arachnelis 14:53, 26 октября 2013 (UTC)

Не за что. Русские идут! 16:09, 26 октября 2013 (UTC)

И я тоже склоняюсь, что, возможно, другие причины компенсируют выгоду от GC в скорости разработки на Java. Русские идут! 16:12, 26 октября 2013 (UTC)

Позвольте, «Благодарю за дополнение … к сожалению, я пока не видел публикации его результатов в АИ» — это вы за ОРИСС благодарите? Почему информация в период войны вносится без АИ? --Higimo 02:07, 28 октября 2013 (UTC)

Участник Arachnelis поблагодарил меня вот за эти правки. Там и источник, и ОРИССа вроде нет.

А в войне правок я не участвую. Это мои первые правке в этой статье за долгое время. Русские идут! 15:35, 28 октября 2013 (UTC)

Спасибо за разъяснение. --Higimo 16:48, 28 октября 2013 (UTC)

Нашёл. {{статья |автор = Bernard Berthomieu |заглавие = OO Programming Styles in ML |издательство = LAAS Report #2000111, Centre National De La Recherche Scientifique Laboratoire d'Analyse et d'Architecture des Systèmes |год = 2000 |ссылка = http://homepages.laas.fr/bernard/oo/ooml.html |ref = Berthomieu - OO Programming Styles in ML }} На страницах 67-70 приводится элементарный, интуитивный код построения иерархии классов для детской задачи (точки и линии) на двух языках со сборкой мусора - Java и OCaml. Невооружённым глазом видно, что код на Окамле в полтора-два раза меньше по объёму, чем на Джаве, т.к. в последней много всякого синтаксического мусора типа public и return. И это ещё не анализируется гибкость языков (а модификации занимают много времени в разработке сложных проектов). Предлагаю в статье после вашей ссылки подписать что-то вроде ", хотя Java очень многословна в сравнении с другими языками с GC[АИ]". Этот же материал можно также использовать для критики развитости полиморфизма в С++ (хоть там код на Java, но повторяются многие свойства С++). Arachnelis 19:56, 23 декабря 2013 (UTC)

• Эти Достоинства и недостатки всегда очень тонкая тема. Даже разные АИ могут быть диаметрально-противоположного мнения. Думаю, что критика должна происходить от авторитетных экспертов по языку. Языки программирования создавались с определёнными целями, и потому отсутствие встроенного комплексного типа нельзя рассматривать как недостаток С, как и быстродействие Python. Межъязыковую критику нужно сводить к минимуму, так как она описана ещё Дж.Свифтом. РоманСузи 17:56, 26 октября 2013 (UTC) Почитал... Статья сильно полегчала бы от выделения Д и Н C++ в отдельную статью. Мне кажется, раздел Д и Н нужно сильно сократить, как того требует нейтральная точка зрения. А так получается, что источники только и делают, что критикуют: около трети часть статьи занята критикой! РоманСузи 18:06, 26 октября 2013 (UTC)
  • Ну так каков предмет статьи - такова и доля критики. Виноват в этом только Страуструп. Это не противоречит нейтралитету. Он пытается объять необъятное, при этом ничего не создавая, а паразитируя на чужих творениях. И это не чьё-то субъективное мнение, это факт. Субъективным как раз можно считать отсутствие понимания этих вещей из-за недостатка грамотнсти. Как я уже сказал, я охотно проясню ЛЮБОЕ предложение в разделе "Достоинства и недостатки". Спрашивайте. Arachnelis 06:08, 27 октября 2013 (UTC)
    • Вся неприятность в том, что хотя я могу подписаться под почти всеми недостатками С++, в военное время (я имею в виду ведущуюся здесь войну правок) нужно обосновать выставленные требования источников ссылками на авторитетные источники, вплоть до страницы. Скажем, громоздкость синтаксиса. Я могу верить Вам или другому гуру или просто сам выработать некое мнение. Но для Википедии чем более радикальное заявление, тем более весомый источник употребляется. Есть ли таковой для громоздкости? Отставив в сторону моё личное отношение к С++, программы, написанные с использованием готовых библиотек, могут быть даже короче и яснее, чем написанные на C. Громоздка грамматика? Возможно — можно дать цифры. Недостаток ли? Это требует АИ и по возможности АИ с противоположным мнением. Таким образом, нужно найти источник(и) и не писать в статью ничего, что несёт даже каплю субъективности. Это сложно и тяжело, но на результат будет тяжело посягнуть, так как на удаление текста, обставленного хорошими источниками, смотрят очень плохо. Есть, конечно, еще ВП:НТЗ — доля текста статьи об определенном аспекте должна примерно соответствовать вниманию, которое этому аспекту уделяют источники — и так как я не видел такой диспропорции в источниках относительно недостатков, я поставил шаблон о нарушении НТЗ. То есть, проблема не в том, что у С++ так много недостатков относительно достоинств, а в том, что разделу ДиН уделено слишком много внимания. РоманСузи 07:55, 27 октября 2013 (UTC)
      • Я понял. Поищу конкретные страницы - только, конечно же, не прямо на днях, а по мере наличия времени. Меня интересует отношение Вики к понятию очевидности. Например, про громоздкость я как раз добавил сравнение со Схемой. Очевидно, что само по себе число "200" не является громоздким, но если 12 строк БНф *В ПРИНЦИПЕ* хватает для создания языка, то вот тогда 200 явно свидетельствуют, что где-то перестарались. Это не считается очевидностью? И возвращаясь к поднятому вопросу - почему не откатывают удаление текстов, содержащих факты, особенно со ссылками? Я на многие куски статьи готов закрыть глаза, но то, что Троллтеховцы открытым текстом объясняют, что вместо использования темплейтов они потрудились сделать собственный препроцессор по причине непортабельности темплейтов - это очень важно для статьи. Это АИ, подтверждающий факт непортабельности С++. Arachnelis 20:29, 30 октября 2013 (UTC)
        • Мне кажется, или со времён, когда кьют писали «тролли» ситуация с портабельностью шаблонов значительно улучшилась? --be-nt-all 02:18, 31 октября 2013 (UTC)
          • Вам кажется. Портабельность - это когда код легко переносится на любой АКТУАЛЬНЫЙ компилятор. А есть люди, у которых продакшен на Builder6 идёт, потому что лицензия, наработки, коньюнктура и т.п. Однако, к АИ это отношения не имеет. Главное, что разработчик видной библиотеки затратил КУЧУ усилий на дублирование того функционала, который якобы уже есть в языке, только лишь потому, что оригинал его не удовлетворил. Пусть Enerjazzer попробует доказать, что это недостойно ссылки из Википедии. Arachnelis 14:36, 4 ноября 2013 (UTC)
            • Тем не менее 6-е версии сибилдера и визуалЦПП на сегодняшний день (пусть они используются кем-то в продакшене) это очевидная маргинальщина. И их недостатки - это не совсем недостатки языка. Dixi --be-nt-all 07:12, 5 ноября 2013 (UTC)
        • Тем не менее, чтобы говорить, что громоздкость С++ порождает массу проблем, требуется некий доктор от computer science, который в своей монографии об этом напишет, приложив некоторый анализ, мол, такие-то и такие проблемы, выявленные при анализе 100 проектов. Ну или хотя бы широко известный практик, скажем, генеральный разработчик Qt в интервью ведущему в отрасли журналу. Например, в книгах Макдоннелла много примеров таких вставок: для убеждения читателя используются данные исследований, с соотв. ссылками (несмотря на то, что Макдоннелл и сам гуру). В Википедии аналогично. Если Вы сами провели исследование и «публикуете» его в Википедии — такое проходит пока не заметят. Это не дом с четырьмя этажами. Даже если длину описания (БНФ) можно в какой-то мере считать объективным описанием синтаксиса ЯП, само по себе это еще нельзя считать недостатком. Громоздкий синтаксис может привести к компактным и интуитивным описаниям и т. д. — а просто сказать о проблемах — это слишком популярно. Без АИ нельзя сказать. В конце концов, «любовь» к ЯП — дело вкуса, воспитания, опыта — не знаю чего еще. (Заметьте, что я не отстаиваю свою точку зрения — с моей личной точки зрения в C++ самое удачное — это идеи обобщенного программирования, всё остальное можно в раздел критики. Я скорее пытаюсь объяснить идеологию Википедии, которую с различным успехом понимают участники проекта.) Если кратко: на абстрактные темы «очевидное» может быть обманчивым. РоманСузи 18:30, 4 ноября 2013 (UTC) Посмотрите раздел недостатков из какой-нибудь избранной статьи о языке программирования Википедия:Избранные_статьи ;-) РоманСузи 18:38, 4 ноября 2013 (UTC)
          • (Как раз обобщённое программирование в С++ реализовано крайне плохо. Почитать об этом можно в недавно перевёденной мной с английской статье "Полиморфизм") Arachnelis 15:05, 18 ноября 2013 (UTC)
            • В указанной статье C++ даже не упомянут. РоманСузи 16:28, 18 ноября 2013 (UTC)
              • Дан пример с описанием, что параметрический полиморфизм компилируется в ad hoc. Код, перенесённый из английской статьи, оформлен как С#, но без упора на какие-то особенности, он чисто демонстративный, т.е. в полной мере применим к С++. Можете изобрести С++ный аналог кода, чтобы коротко и показательно, и заменить в статье. Arachnelis 19:01, 18 ноября 2013 (UTC)

C как часть C++

То, что Си является подмножеством С++ - это разве новость? В статье это раз сто написано. Не понимаю, чему тут удивляться. Arachnelis 14:30, 4 ноября 2013 (UTC)

увы, не совсем... "обычный код" на C - да, будет работать точно также и на C++, но совместимость отнюдь не 100%, вполне вероятны случаи когда код на C не будет работать абсолютно также и на C++ (и даст трудноуловимую ошибку), потому что они не 100% совместимы. то есть если в программу C++ включить модули написанные на C то всё OK!, но вот если в код написанный на C++ просто вставлять копи-пастой куски кода на C, то гарантий безошибочной работы нет (Idot 16:32, 4 ноября 2013 (UTC)) PS по слухам C входит в язык Objective C и 100% с ним совместим --Idot 16:32, 4 ноября 2013 (UTC)

Я знаю, что формально ANSI C перестал быть подмножеством С++ с 1999 года. Но язык определяется в первую очередь семантикой и психолингвистикой, а уж потом синтаксисом. И в этом плане отличие современного Си от "Си-подмножества С++" даже меньше, чем между современным Си и его ранними реализациями (Си когда-то был 8-битным, бестиповым, многого не имел вообще - т.е. он тоже эволюционировал, но не в такой степени, как С++; и к Си, в отличие от С++, претензий особо нет). Суть спора в другом - если отрезать от С++ RTL (САВСЭМ отрезать, а не перебросить её функциональность в другое адресное пространство, назвав другими словами) - то какой язык получится? Это будет "почти тот же С++", или "уже почти Си"? Объективные данные указывают на второй вариант - если нет new/delete и try/catch, то от С++ остаётся код, который с минимальными синтаксическими коррективами будет проглатываться компилятором Си. Enerjazzer'а вот эта новость повергла в шок. Arachnelis 17:51, 4 ноября 2013 (UTC)

C++ отличается от C своей ориентированностью на объекты. И если синтаксис C гарантирует определённое поведение кода, то в C++ вступают неявные вызовы конструкторов, что объективно делает код менее управляемым, и побуждает программиста к большей осмотрительности. И когда мы пытаемся описать достоинства и недостатки языка программирования, мы должны себе задавать простой вопрос: является ли то, что мы описываем, достоинством или недостатком языка. Иначе мы рискуем свалить в кучу абсолютно всё, что попалось на глаза. А это существенно ухудшает статью. Проще и полезнее описывать конкретные факты, по возможности, подавая «достоинства» и «недостатки» в нейтральном ключе именно как его неотъемлемые особенности, и только тогда, когда есть очевидный аспект, освещённый в авторитетном источнике, который показывает нам проблему, то именно он будет достоин освещения в одном из разделов статьи. --OZH 08:49, 5 ноября 2013 (UTC)

зачастую ответ: на "простой вопрос" является ли то, что мы описываем, достоинством или недостатком языка зависит от выполняемой задачи, и то что в одном случае явлеяется достоинством в другом может оказаться недостатком. например, если нужна максимальная скорость то на сборку мусора лучше полностью забить, а код писать так чтобы не было потребности в сборке мусора (потому что сборка мусора - прямой ущерб скорости), а вот если скорость не нужна, но нужна надёжность то лучше иметь сборку мусора (Idot 10:09, 5 ноября 2013 (UTC))

Ребят, не в обиду: расширяйте кругозор. Все ваши рассуждения ведутся в рамках "голый Algol style императив vs. то же самое, но в Simula style оковах". Это как анализировать пользу и вред от алкоголя на примере сравнения денатурата с метанолом. А существует ещё как минимум шесть других подходов к построению языков (красное вино, пшеничное пиво, медовуха и пр.). И к проектированию есть другие подходы, кроме того, что может в принципе предложить С++ в силу своей семантики. А самое сильное программирование вообще уничтожает грань, отделяющую проектирование от программирования (в связи с чем, кстати, большой ошибкой русской Википедии является разделение статей "Инженерия ПО" и "Разработка ПО" с пометкой "не путать" -- в английской такого нет) - чего С++ не позволяет в принципе. И для КАЖДОГО (без исключения) случая использования С++ существует средство и/или методология, которая позволяет получить неизмеримо более качественный результат с неизмеримо меньшими усилиями. Т.е. самым главным недостатком С++ является он сам, как образ мышления программиста. Он состоит из одних анти-паттернов. Но увидеть это дано лишь под иными углами - отличными от тех, которые навязывает сам С++.Arachnelis 14:52, 18 ноября 2013 (UTC)

upd: Вообще, вы ушли от вопроса. Напоминаю: утверждается, что С++ физически невозможно затолкать в 8-битный микроконтроллер, в который вполне умещается Си, из-за тяжеловесного рантайма, и что если этот рантайм отрезать, то это сразу превратит С++ обратно в Си. Arachnelis 14:27, 18 ноября 2013 (UTC)

Вновь критика

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

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

Сюда приглашу всех участников конфликта. Сам подозреваю, что имеет место оригинальное исследование. --Higimo 01:05, 11 ноября 2013 (UTC)

• Тут надо всю статью целиком переписывать. Мне было бы проще исходить из заранее заданной структуры статьи. Предлагаю выбрать вариант, приемлемый для описания статьи о произвольном языке программирования, и строго его придерживаться. Так заведомо не будет возникать конфликтов, а каждый факт, если он имеет подтверждение, найдёт своё оптимальное место в тексте статьи. --OZH 12:04, 11 ноября 2013 (UTC)
  • Структура статьи задана. Переписывайте каждый раздел согласно АИ. Никто слова против не скажет. Если вы хотите выработать универсальное определение ЯП в вводной части статьи, вам на Проект:программирование. Здесь обсуждается критика не имеющая под собой подтверждения. --Higimo 22:57, 11 ноября 2013 (UTC)
  • Тоже не вижу смысла менять структуру. Моё возражение было только к относительному объёму раздела недостатков. РоманСузи 04:20, 12 ноября 2013 (UTC)
    • А Вы считаете допустимым, когда в статье, посвящённой языку программирования, почти во первых строках говорится о некой философии языка, хотя то, что написано в разделе «Философия языка», скорее, относится к его истории, причём синтаксис в статье не описывается каким-либо внятным образом (вместо этого приводится нагромождение «возможностей»), и такой необходимый в статье раздел «Синтаксис» попросту отсутствует! Статья «С++» должна быть обзором всего языка программирования. С одной стороны, у нас есть стандарты, которые должны во всех подробностях описываться в соответствующих статьях, а, с другой, у нас есть различные реализации языка программирования в виде компиляторов, которые никогда не реализуют какой-либо стандарт, хотя и могут довольно близко к нему приблизиться. Попытка написать обобщающую статью означает обзор того, как различные компиляторы реализуют выбранные стандарты. Также было бы полезно иметь раздел «Связь с другими языками программирования», где можно было бы собрать воедино то, что раскидано в статье про «Си», «Джава» и «Си шарп». Одного этого достаточно для того, чтобы понять: нынешняя структура статьи неудовлетворительна. И Вы никогда не перепишете критический раздел, пока не добьётесь приемлемой структуры, поскольку Вы рискуете сократить важную информацию, но которая должна была бы быть упомянута в другом месте статьи, и из-за этого в статье будет наблюдаться война правок. --OZH 06:28, 12 ноября 2013 (UTC)
      • Возможно даже так. Предложите свою структуру. Полагаю также, что можете править смело, снабжая текст, там где необходимо, ссылками на источники. РоманСузи 06:34, 12 ноября 2013 (UTC)

Итог?

Создал резервную копию статьи. Если в ближайшее время не поступит никаких (принципиальных) возражений, я уберу из статьи всё, что никак и ничем не подтверждено, и начну выстраивать новый вариант статьи. Было бы неплохо совместными усилиями нескольких участников сделать к Новому году хорошую статью. С наскока такие статьи просто не пишутся. Также попробую несколько переформатировать страницу обсуждения, чтобы максимально упростить совместную работу. Если эксперимент окажется удачным, то его можно будет повторить. С хорошим выходом для Википедии. ;-) --OZH 21:17, 13 ноября 2013 (UTC)

• Я поддерживаю инициативу. Но существенного дополнения статьи не обещаю. Следить за статьей буду. --Higimo 22:20, 13 ноября 2013 (UTC)
• Тоже поддерживаю, хотя начал бы с кровопускания в разделе Критики, если Вы планируете сразу удалять (на мой взгляд, итеративный процесс был бы лучше). Помочь мало чем могу (под рукой нет источников). Совет. Определитесь в самом начале, на какую версию нужно ориентироваться. Например, в статье про Pascal было большое сопротивление по расширению классического Паскаля. И еще. Задайтесь целью получить избранную статью, а не просто хорошую. Успехов! PS. Все ходы записаны: Версия до изменений РоманСузи 06:42, 14 ноября 2013 (UTC)

Комментарий: Большое спасибо за воодушевление. Но есть одно «но»! В одиночку такие дела не делаются. Тут нужная команда. Если мне удастся стать хотя бы точкой кристаллизации, то… Что-что, а источников по C++ хватает с избытком. Сделать на их основе избранную статью (например, к Новому Году) — планы амбициозные. Но если равномерно распределять нагрузку и хорошо прорабатывать детали, то, я думаю, желаемое станет действительным. :-) --OZH 07:08, 14 ноября 2013 (UTC)

• Если вы будете указывать онлайн источники, то дополнять из этого источника и я помогу. Можно конкретнее какая помощь вам нужна? У меня кроме справочника по С++ от Г. Шилдта ничего нету. --Higimo 08:44, 14 ноября 2013 (UTC)
• Думаю, что у коллеги OZH есть некий замысел по структуре. Было бы интересно начать хотя бы с ознакомления с этим замыслом, так как Вы заявили о необходимости полной реструктуризации, а я например не вижу смысла перерабатывать все подряд — только то, что плохо. РоманСузи 15:51, 14 ноября 2013 (UTC)
• Я и сам планировал переработать (скорее автономно, а не в онлайне), только за сроки не ручаюсь. Поскольку вскипание спора - отчасти моя вина (лежала себе статья, хоть и кривая, но никто не трогал, она и не пахла) - с извинениями от себя лично разрешаю просто поудалять всё, что вызывает хоть малейшие сомнения, не тратя сил, и оставить в качестве примера определённый объём критики. Я потратил месяц на эту критику и не пожалею потратить ещё десять раз по столько. Как соберу ссылки - выложу черновик раздела отдельной статьёй, и уже с обсуждений будем перекидывать. Нормальный вариант? Главное - следить, чтобы в дальнейшем не появлялось той фигни, что была раньше, типа раздела "Контраргументы" с жалобными попытками отбиться без намёка на энциклопедичность. Пока для желающих укажу главный источник критики - статья Яна Джойнера (в ссылках есть) - это чистый АИ, с копирайтом и изданием в нескольких научных журналах, 90 страниц поливания С++ грязью научным языком. Более мелкие порицания надо собирать долго, перебирая надмозговые статьи по ФП и ЯОП, которые мельком упоминают что-то вроде "почти то же самое есть и в С++, но...". Arachnelis 14:38, 18 ноября 2013 (UTC)
  • Всё, что потребуется, в статье будет. Только не надо ничего «поливать грязью». И авторы, даже если они выступают с довольно нелицеприятной критикой языка программирования, не «поливают его грязью», а чётко и по пунктам разбирают различные элементы языка. Давайте не будем превращать страницу обсуждения статьи, в форум обсуждения самого языка программирования. Задача статьи не сказать плох язык или хорош. Необходимо описать то, что есть. Никто не расчитывал на то, что C++ — это универсальный язык для получения оптимальных решений, и никакие недостатки языка не помешали написать на нём множество высококачественного кода. И… если, уж, я взялся за эту статью, то я, заранее видя, потенциальную конфликтность, готов выступить в этой статье посредником, заранее предупреждая возможные войны правок. Не стоит волноваться. Всё, что потребуется, будет в статье отражено самым тщательным образом. --OZH 16:08, 18 ноября 2013 (UTC)
    • Да я просто метафорически выражаюсь. Это что, даже в обсуждении нельзя? Arachnelis 18:56, 18 ноября 2013 (UTC)
      • А где у Вас метафора? ;-) --OZH 19:54, 18 ноября 2013 (UTC)
        • Например, словосочетание "поливание грязью". На деле у Джойнера объективная, рассудительная критика. Я бы даже сказал обходительная и осторожная. Arachnelis 20:24, 18 ноября 2013 (UTC)
          • Давайте всегда оставаться рассудительными. --OZH 20:30, 18 ноября 2013 (UTC)
    • Кстати, вы ошибаетесь, что "Никто не расчитывал на то, что C++ — это универсальный язык". Цитирую из раздела история: "При создании C++ Бьёрн Страуструп хотел: - получить универсальный язык..." Это очень важно, т.к. именно поэтому к нему столько претензий. На какие задачи замахивается - с тех позиций и критика. Проложист тоже мог бы раскритиковать Си, но Си не претендует на решение задач ИИ. Arachnelis 20:40, 18 ноября 2013 (UTC)

• P.S. Собрал историческую часть в один раздел. Буду выверять и исправлять стиль. Хотелось бы ещё написать подраздел об истории компиляторов, которые поддерживали()эт C++. --OZH 16:08, 18 ноября 2013 (UTC)

• Я свое мнение относительно раздела "Критика" уже высказал выше. Я вполне верю, что уважаемый Arachnelis способен написать диссертацию в 256 страниц о недостатках С++ с точки зрения всех известных ему языков программирования, благо мотивации ему не занимать. Но я категорически не согласен с тем, что она должна быть составной частью Википедии. Более того, я вообще не считаю, что раздел "Критика" должен заниматься критикой с точки зрения других языков - это бессмысленно и бесперспективно, так как все эти языки можно точно так же критиковать с точки зрения С++. Аргумент "это должно помочь ПМам выбрать правильный язык" не выдерживает никакой критики, поскольку просто не соответствует целям Википедии. Википедия - не учебник для ПМов. Опять же, сравните объем написанного Arachnelis-ом здесь с объемом критики в статьях обо всех остальных языках программирования, включая английскую вики - они все вместе взятые не перебьют написанного здесь Arachnelis-ом. Так что я считаю, что всему этому не место в вики. Если Arachnelis-у так неймется - пусть пишет статью и публикует ее в авторитетном журнале - мы с удовольствием поставим на нее линк. А пока что это все - балансирование между жонглированием цитатами и прямым враньем ОРИССом. Я не знаю, почему Arachnelis так ненавидит С++ и обливает помоями где только можно (гугл в помощь) как сам язык, так и программистов на нем (да и не очень это интересно), но давайте хотя бы Википедию от этого убережем. Раздел должен быть радикально очищен и сокращен или даже убран вообще - вполне достаточно раздела "особенности". Критике С++ с т.з. других языков, имхо, тут не место (как и сравнению С++ с Java, как и учебнику по ООП, к слову). Сравнение языков программирования - это тема отдельной большой статьи, и она уже есть. Если и делать раздел недостатки - то это должны быть недостатки, с которыми сталкиваются сами программисты на С++, а не то, что не нравится в С++ программистам на других языках. Enerjazzer 13:36, 7 декабря 2013 (UTC)
  • Я не прочь опускать критику, при условии, что не будут преувеличиваться достоинства. Тут проблема как раз в том, что критиков С++ обвиняют в предвзятости, а сторонники все ходят шёлковые и причёсанные, и пишут в статью откровенную ложь, подкрепляемую ссылками на источники, которых можно смело обвинять в предвзятости (я уж не говорю о фразах, не подкреплённых ничем вообще), и, что ещё хуже - не только в эту статью, но во все прочие, относящиеся к программированию. Единственная тому причина - в количественном соотношении критиков С++ с поклонниками. Почему я ненавижу С++? Да банально потому, что могу сравнить его с другими языками. Только и всего. Я легко накатал бы такой же объём критики о PL/1 и о Коболе, но они мне безразличны, ибо мне не приходится каждый день трахаться с глючным монструозным софтом, который был бы написан на них. Почему я сразу понял, что ты не знаешь ничего, кроме С++? Потому что эмпирически достоверен факт: С++ хвалят ТОЛЬКО те, кто не знает ничего другого (всякие там Pascal, Java и прочие потомки Алгола за другие языки не считаются - со знанием С++ изучить их можно за считанные дни, а коды транслировать автоматически). Твоё утверждение о том, что с позиции С++ можно раскритиковать любой язык, ложно (и в определённых кругах телесно наказуемо, так что ты по-осторожнее). Про "недостатки, с которыми сталкиваются сами программисты на С++". Словосочетание "сами программисты на С++" у тебя уже само по себе построено с ошибкой. Дело в том, что есть такая аказия - психолингвистика. Из-за неё получается, что хороший "программист на С++" - это не "С++-программист", а программист, т.е. такой человек, который руководствуется фундаментальными обоснованиями всех аспектов инженерии программных систем, а не ремесленным опытом, присущим одному инструменту, хорошо ориентируется в рабочем инструментарии, умеет сам себе разрабатывать инструменты, и никогда не забивает гвозди микроскопом. Такой человек может писать на С++ аккуратно и качественно, очень матюкаясь при этом, т.к. предпочитает делать всё то же самое на языке, более подходящем под задачу. Такие программисты стоят дорого, встречаются редко и по объявлениям о найме "С++-программистов" не находятся. А вот "сами С++-программисты" не сталкиваются с недостатками С++ не потому, что их нет, а потому что они изначально программируют в рамках этих самых недостатков. И в результате С++ выступает не "всего лишь инструментом", а "ментальной реальностью", рамки которой наш "программист" покинуть не способен, т.е. он пишет "в С++", и соответственно, его отношение к нему будет исключительно предвзятым. Arachnelis 12:49, 8 декабря 2013 (UTC)

Здесь находятся завершившиеся обсуждения. Просьба не вносить изменений.

*** Ну что, у почтенного собрания нет больше сомнений в предвзятости тов. Arachnelis? Имхо, его чистосердечного признания в ненависти к С++ вполне достаточно, чтоб относиться к его сентенциям соответствующе. Попытки телепатии и психоанализа по фотографии я оставлю тут без комментариев - пусть все насладятся. Enerjazzer 14:31, 15 декабря 2013 (UTC)

• • Но ты так и не обосновал удаление моей критики вместе со ссылками. Всякую спорную фигню ты не трогал, а ключевые пункты - удалил, причём настойчиво. Меня интересует два пункта: что разработчики QT отказались от темплейтов из-за непортабельности, и что С++ никак нельзя сделать столь же нетребовательным к ресурсам, что и Си (т.е. или компактность, или классы с исключениями и STL/Boost, но никак не одновременно). Изволь объясниться, обсуждение для того и существует. Arachnelis 12:34, 8 декабря 2013 (UTC)
    • Ну что ж, я несколько раз дал тебе возможность сохранить лицо, но ты с упорством, достойном лучшего применения, настаиваешь на детальном разборе? Что ж, изволь. Во-первых, статье сто лет в обед. Во-вторых, ты статью вообще читал? После того, как он описывает тогдашние проблемы с реализацией шаблонов в компиляторах того времени, он пишет следующее: However, we do not perceive these problems as a serious limitation in our work. Перевод нужен? Дальше он пишет: Even if all our users had access to a fully standards compliant modern C++ compiler with excellent template support, we would not abandon the string-based approach used by our meta object compiler for a template based signals and slots system. Here are five reasons why - и дальше пять причин, почему так называемая "непортабельность" шаблонов не является главной причиной отказа от них. Это просто чтоб продемонстрировать твою ложь. В-третьих, в QT есть шаблонные контейнеры: http://qt-project.org/doc/qt-4.8/containers.html. В-четвертых, разработчики QT сам давно говорят о том, что плохое отношение в QT к шаблонам С++ - это бред:
      i asked today in the #qt irc channel, and some of the dudes working for trolltech told me they think about using some c++1x stuff when gcc4.5 comes out, like variadic templates and perfect forwarding.
      @piotr, I asked them, they said saying Qt doesn't use template is 15 years old FUD oO
      Qt sources contain the pattern "template <" 1280 times in src/corelib alone. I fail to see how this can be mistaken as "Qt is known not to use templates"
      http://stackoverflow.com/questions/846015/how-modern-is-c-language-used-in-qt
      В-пятых, в тобой же цитируемой статье разработчики Qt расхваливают С++:
      C++ is a standarized, powerful and elaborate general-purpose language. It's the only language that is exploited on such a wide range of software projects, spanning every kind of application from entire operating systems, database servers and high end graphics applications to common desktop applications. One of the keys to C++'s success is its scalable language design that focuses on maximum performance and minimal memory consumption whilst still maintaining ANSI C compatibility.
      Но ты, естественно, как правоверный ненавистник С++, все это цитировать в своей "нейтральной" писанине и не намеревался. Ну другого от тебя и не ожидалось. Enerjazzer 14:31, 15 декабря 2013 (UTC)

Очень прошу не устраивать переходы на личности! Сейчас, всё-равно, приходится заниматься языком Си. Но когда я закончу с ним, я смогу привести в чувство и Си++. --OZH 18:37, 15 декабря 2013 (UTC)

• Уважаемый OZH, если в статье о Си Вы будете делать раздел критики, пожалуйста, сделайте так, чтоб пункты оттуда не дублировались в статье про С++. И заодно уберите из статьи про С++ учебник ООП - не место ему здесь, а занимает он львиную долю. Я б и сам прибил, но куда-то ж надо это деть (в Викиучебник, видимо?) Enerjazzer 15:15, 16 декабря 2013 (UTC)
  • А где там учебник-то? Почему в статье по языку программирования нельзя описать особенности ООП в данном языке? В крайнем случае можно выделить в отдельную статью. Насыпьте тогда уж всю соль на раны: Python#Объектно-ориентированное программирование — Объектно-ориентированное программирование на Python (и это после выделения части материала в Викиучебник). (этот вопрос лучше обсудить в рамках проекта). Вот если бы кто-тама мог саму статью по ООП привести в божеский вид... РоманСузи 18:20, 16 декабря 2013 (UTC)
    • Особенности - можно и нужно, но то, что там сейчас - это не особенности, а по сути учебник. Особенности - это типа таблички, которую я в свое время сделал про уровни доступа и наследование. Если есть желание - могу набросать прямо здесь, а вы перенесете в статью, если понравится. Enerjazzer 13:06, 18 декабря 2013 (UTC)
    • «Тама» — это где, в Викиучебнике? Вы имеете в виду вот это? --OZH 19:56, 16 декабря 2013 (UTC)
      • Нет. Я имел в виду Википедия:Кто-то там. РоманСузи 20:43, 16 декабря 2013 (UTC)
        • Это какой-то особый википедический юмор. :-) Боюсь, пока кто-то здесь не придёт и не сделает своё дело, ничего и не получится. Давайте направим свои килобайты в основное пространство! ;-) --OZH 06:50, 17 декабря 2013 (UTC)
          • Про ООП попробую причесать как-нибудь. У меня по-любому получится непредвзято и объективно, т.к. я к ООП отношусь совершенно прохладно и в работе не использую, если язык явно этого не требует, ибо это далеко не лучший способ декомпозиции. (upd: Впрочем, по той же причине много времени не уделю.) Для примера недостатки текущей статьи: нет ссылки на пионеров ООП Луку Карделли и Барбару Лисков; Симулу Алан Кэй прямо низверг из позиции "первого ООЯ"; нет классификации объектных моделей. Arachnelis 19:34, 23 декабря 2013 (UTC)
    • Что ж, изволь. Ответ не принимается. Нет желания проверять нынешнее состояние дел по С++, но то, что проблемы с портируемостью ушли в прошлое, не означает, что их теперча можно убрать из статьи. Так и запишем: "Первоначально разработчки Qt отказались от темплейтов по тому-то, но позже изменили своё отношение". Не забываем, что эволюция - признак плохого языка, и один из ключевых недостатков С++. Язык не должен эволюционировать вообще. Т.е. изданием книжки D&E Страуструп как бы сам провозгласил своё творение убожеством. Хороший язык не нуждается в развитии, т.к. любую новомодную фишку, будь то ООП, или АОП, или это ваше "обобщённое программирование", или что ещё (что угодно), можно легко реализовать средствами самого языка, без изменения компиляторов и тем более стандарта. В крайнем случае - поверх стандарта, чтобы не требовалось изменять рабочие коды (и каждый будет сам волен решать - использовать эту надстройку или игнорировать). Для хороших языков стандарты перевыпускаются лишь на основании многолетнего опыта, после того как выясняется, что чего-то не хватает или что-то лишнее - и такие изменения молниеносно и с радостью воплощаются сразу во всех компиляторах вплоть до игрушечных. Один из признаков хорошего языка - полное отсутствие сколь-нибудь заметных проблем с портированием кода между компиляторами, не говоря уж о портировании между разными ОС. Заметьте - даже Си обладает лучшей портируемостью, чем С++ (что вроде как абсурдно, т.к. по идее Си - язык более низкого уровня), и Линус Торвальдс это справедливо отметил. В хорошем языке стандарт подчинён языку, а не язык - стандарту. Поэтому то, что проблемы с портируемостью были, нельзя опускать. Тем более, что С++ чисто физически никогда не сможет сравниться по портируемости с более высокоуровневыми языками (и АИ тому уже стоитЪ). Arachnelis 19:20, 23 декабря 2013 (UTC)
    • То, что ты большой поклонник С++ - это "психоанализ по фотографии"? Скорее уж это "капитан очевидность" :) Остальное - факты, и ничего, кроме фактов. То, что ты с этими фактами не знаком, и "наслаждаешься" их вздорностью, не означает их вздорность, тем более, что ты сам являешься их предметом. Arachnelis 06:55, 24 декабря 2013 (UTC)
    • С++ - один из немногих языков, где автор диктует помимо самого языка ещё и правила его применения, но его советы не всеми соблюдаются, так что общая идеология С++ размыта. В частности, его создатель даже издал единственную в своём роде книгу - Design&Evolution - в которой он, во-первых, выдаёт эволюцию за должное, во-вторых (опровержимо) уродует понятия "стандарта" и "языка", в-третьих, ещё и оправдывается за то, что «пока только намазывается хорошо». Изложение в энциклопедии должно идти в стиле "о вечном" - а значит, надо писать, что С++ является непрерывно эволюционирующим языком, т.е. пока он жив, всегда будут проблемы обратной совместимости, и всегда будет необходимость изменять уже отлаженные программы. Сейчас изложение идёт примерно так: «вот, наконец, дождались... нет, вот, теперь наконец дождались... ой, тут придётся исправить старую проблему... нет, эта проблема определена стандартом, а значит она не проблема... а, теперь проблема устранена, можно признаться, что да, она была проблемой... ой, тут ещё одна проблема... зато язык стандартизирован!!! И будет ещё неоднократно стандартизирован! Самый стандартный язык из всех, с чётко определёнными стандартом проблемами!». К слову, OCaml имеет те же недостатки - непрерывная эволюция и страшно громоздкий синтаксис - но на него и стандартов не выпускается, и реализация всего одна, портабельная подо что угодно сама по себе безо всяких стандартов - т.е. для него эти недостатки являются относительными (выиграли в одном, проиграли в другом), тогда как для С++ эти же недостатки являются абсолютными (непортабельный согласно официальному стандарту язык). Trolltech учитывали именно это, хоть ты и не хочешь это признавать. Это АДЫН. Язык темплейтов не предоставляет никаких средств для оптимизации, поэтому эффективность библиотек заведомо ограничена, и ad hoc решение в частном случае может оказаться эффективнее. И это тоже важная причина создания собственного препроцессора, такого как MOC. Вообще, ни для одного языка, предоставляющего собственные средства кодогенерации, нет такого количества внешних кодогенераторов. Т.е. любой внешний препроцессор для С++ самим своим существованием позорит язык темплейтов. Это ДЫВА. Про раздувание кода темплейтами объективно и непредвзято уже написано в статье параметрический полиморфизм, так что "спор ссылок" о том, значительно это раздувание или терпимо, становится бессмысленным: в С++ оно просто есть, а в некоторых других языках (даже в Си) его нет. Arachnelis 15:34, 4 января 2014 (UTC)
  • Разница между учебником и статьёй в энциклопедии заключается в различии целей: цель учебника — научить программировать, цель статьи —— дать общее представление о предмете. Если в статье необходимо описать то, как именно в данном языке программирования используется (реализовано) ООП, то оно обязательно должно быть описано. Это означает, что существенная часть информации в Википедии и в Викиучебнике будет дублироваться, но способ подачи будет также существенно различаться. --OZH 19:56, 16 декабря 2013 (UTC)
    • Вот и я о том же. С удовольствием прочитаю про ООП на C++. Когда-то давно, изучая ООП на примере С++, я это самое ООП не понял. И не понял я главного: зачем оно такое как в С++ нужно. К счастью, со временем изучил Python и понял, что такое ООП, зачем и когда оно нужно. Надеюсь, что Вы сможете написать так, чтобы у других такой проблемы с С++ не возникло. Думаю, что вопрос «зачем» важен не меньше, чем «как». И много места на ответ не требуется. РоманСузи 20:43, 16 декабря 2013 (UTC)
      • Ага, так обычно и бывает. С++ - это просто императивный язык, а никакой не мультипарадигменный, просто в него перректально введены (а иначе не получалось) неправильно понятые идеи из хороших языков. То, что в С++ есть ООП, думают только те, кто не знает ничего, кроме С++. Те, кто видел Smalltalk, CLOS, OCaml, да хотя бы и Python,- не считают, что в С++ есть ООП. Шаблоны классов - якобы гениальная вещь, без которой просто классы были бы недостаточно гибки, либо тормознуты. Так говорят те, кто не трогал ООП в том же OCaml. В С++ якобы есть сильная система типов. В этом уверены все, кто не писал ни на чём, кроме Си, С++, Java. Те, кто сталкивался с SML и Haskell, никогда не назовут систему типов в С++ целостной, строгой, полной и ортогональной. В С++ якобы есть рефлексивность. Это мнение тех, кто даже поверхностно не знаком с Lisp, Smalltalk, Tcl, Python. Доступ к низкоуровневым возможностям в любом месте по желанию - это якобы хорошо. Так считают все, кто никогда не сращивал прикладную логику с низкоуровневыми фичами посредством чего-то вроде NLFFI. И так далее. Чем объективнее взгляд на С++, тем больше заявляемых присущих ему качеств превращаются в потуги на пародии и перекачёвывают из "достоинств" в "критику". Поэтому любая похвала (или просто перечисление широты охвата возможностей С++ без акцента на их взаимной несовместимости и подводных камнях) всегда предвзяты по определению. Arachnelis 19:20, 23 декабря 2013 (UTC)
        • Я бы очень хотел, чтобы Вы отдели себе отчёт: то, что Вы здесь только что написали (если это всё привести к нейтральной точке зрения и убрать «лишние» словечки), вполне ёмко описывает ситуацию и перекрывает многое, что написано в критическом разделе. Вот почему, я предлагаю перейти к написанию текста и перестать выяснять отношения с языком программирования. Замечу, только, что ООП — это именно что «ориентированное на», в то время как перечисленные Вами Smalltalk, CLOS и OCaml — совсем не «ориентированное на» объекты, а самые что ни есть объектные языки. Одно дело, когда берётся существующий язык программирования и к нему привешивается ещё и объектная ориентированность, другое — когда объекты — это базовые (исходные) сущности языка. Вот, собственно, и всё. Так что, давайте обойдёмся без разведения «холиваров». :-) --OZH 08:17, 24 декабря 2013 (UTC)
          • Я не холиварю. Критика имеет смысл лишь в сравнении с чем-нибудь, но не сама по себе. Потому ООП в С++ и ПЛОХО реализовано, что в других языках оно реализовано ХОРОШО, и нет такого понятия как "чисто объектный язык" - его выдумывают только те, кто склонен (сиречь предвзят) к использованию языков, в которых ООП реализовано ПЛОХО. upd: РоманСузи дал хороший контр-пример: Python. В нём конструкторы имеют стандартные имена, что значительно упрощает переименование классов и повышает code reuse. Arachnelis 09:31, 24 декабря 2013 (UTC)
          • Термин "объектно-ориентированное программирование" означает, что программист в своей работе ориентируется на работу в терминах объектов, на объектную декомпозицию. Его мышление и все методологии исходят из того, что любой самостоятельный элемент системы представляет собой связку из изменяемого состояния и изменяющих его функций, а само решение представляет собой заданную последовательность изменения состояний разных объектов. Т.е., что бы ему в конкретном месте не требовалось, он это что-то либо подвесит к существующему объекту, чтобы не болталось, как в проруби, либо превратит в самостоятельный объект, вне зависимости от того, нужно оно или нет. Это и есть ориентация, ибо это происходит на уровне мышления, а не на уровне клавиатурного набора. Почитайте Исполнение в Королевстве Существительных. А опосля в оффтопик призадумайтесь, почему функциональное программирование называют просто "функциональным", а не "функционально-ориентированным" (прямого ответа в гугле на этот вопрос вы не найдёте, чтобы его дать, нужно обрести просветление). Arachnelis 07:18, 4 января 2014 (UTC)

Итог

Инициировано обсуждение: Обсуждение проекта:Информационные технологии#Статьи о языках программирования. Приглашаются все желающие. :-) --OZH 05:36, 21 ноября 2013 (UTC)

Кртк. - стр. тлнт.!

Такой вопрос - а на википедии есть что-то вроде свёртки блоков текста? Это могло бы решить текущую пробему: в статье ставится общая объективная фраза, а детали анализа со ссылками, из которого она вытекает, спрятаны для любознательных или спорящих, чтобы не засорять сущностное изложение. В этом случае даже не обязательно выделять огромный раздел критики, изложение может изначально вестись объективно (сейчас критика пытается вернуть на место чашу весов, дав оценку многочисленным преувеличениям из описания выше, и в результате статья как бы сама с собой спорит). Вот, например: по одному источнику разработчики на С/С++ тратят 30-40% времени на ручное управление памятью, по второму - на Java, несмотря на сборщик мусора, скорость разработки всё равно та же, что на С++; по третьему - код на Java в полтора раза многословнее, чем на другом языке с GC из-за особенностей грамматики. Если всю эту цепочку тянуть в основной материал, то уже будет ужас, а этим, скорее всего, данный контекст не ограничится, ведь каждый адепт С++ захочет приписать какую-нибудь демагогию в качестве похвалы языка, несмотря на недостатки. Для статьи вполне достаточно сказать, что разработка прикладных задач на С++ требует куда больше времени, чем на более высокоуровневых языках, из-за невозможности абстрагироваться от низкоуровневых деталей, и что это далеко не всегда оправдывает С++ обеспечением лучшей эффективности или каких-то других показателей качества. Так две строки текста могут заменить пару экранов деталей, интересных далеко не всем. Как свернуть обоснование? Или может, сделать две статьи - "С++" и "С++ (развёрнуто)", и основную сразу заблокировать от изменений? Или попросту в обсуждении сделать один раздел этой самой развёрнутой статьёй, а в основной писать "см. обсуждение, раздел 1"? Я могу написать целиком нормальную, объективную статью о С++, к которой уже отдельно можно будет подклеивать эти рассусоливания в том или ином виде, но надо уже определиться со структурой. Всё же, "война источников" - это лучше, чем война правок, а противостоять натиску слепых полуграмотных фанатов С++ с их предвзятым отношением к единственному, что они знают, тяжело из-за их численного превосходства. Arachnelis 20:00, 23 декабря 2013 (UTC)

• Техническая возможность есть (точно не помню названия шаблона), но вопрос: а зачем? Лучше выбрать два-три качественных, более независимых источника и по ним написать критику, ответ на критику и т.п. Наверняка за столько лет исследования проводились и кое-какие факты выявлены (я бы даже не стал притягивать сюда провалы больших проектов из-за неправильно выбранного языка). А детализировать сильно не не требуется. В Википедии не нужно сильно что-то доказывать (ВП:НЕТРИБУНА). Если статья написана объективно, то это будет видно. Можно будет смело отметать менее авторитетные источники. РоманСузи 20:26, 23 декабря 2013 (UTC)
  • Да вот не работает так. Я уже давал пример объективной непредвзятой строчки для головы статьи, которую никогда не пропустят напрочь предвзятые религиозные фанатики вроде Enerjazzer'а, с остекленелым взоров восхваляющие этот уродливый язык: "С++ часто используется для разработки большого и сложного программного обеспечения, несмотря на то, что плохо подходит для этого." Для её доказательства я из одного только Джойнера могу наковырять на пол-экрана текста, а есть и масса других источников. Именно такая объективность и вызывает войны правок, ведь люди не понимают, в чём разница между "всеми обожается" и "объективно является говном". Arachnelis 06:48, 24 декабря 2013 (UTC)
    • Попробуйте! :-) А то как-то уж много получается килобайтов вокруг да около пресловутой критики, а в сухом остатке в виде вклада в текст статьи ничего пока не обнаруживается. :-( Какая, там, у таланта сестра?! ;-) --OZH 08:20, 24 декабря 2013 (UTC)
      • Дайте пока перевести дух от уже сделанного вклада :) А то от такой дозы С++ несварение желудка начнётся. Буду делать параллельно пару статей о разных языках - заодно и структуру отлажу. Arachnelis 10:42, 24 декабря 2013 (UTC)
    • "Всеми обожается" и "Объективно является..." — разве взаимоисключающие вещи? Что-то мне не верится, что если взять представительную совокупность АИ по С++, то они хотя бы треть текста посвятят критике. Критика должна занять столько места, сколько ей посвящают источники, и близость этого места к началу тоже от этого зависит. Это и есть правило ВП:ВЕС. ПОэтому если Вы представите список, например, А. сс. 10-300 из 500, Б сс. 100-400 из 600, В сс. 5-15 из 30 и т.п. со страницами разделов критики на источники, то и Enerjazzer ничего не сможет. РоманСузи 09:33, 24 декабря 2013 (UTC)
      • Тогда у нас возникает прямое противоречие между "объективностью" и "обзорностью". Да, "большинством" и "объективно" - это взаимоисключающие вещи, что вытекает из гауссианы вариативности популяции, в которой плюс-минус три сигмы составляют небезызвестное "правило 95%", если эту цифру сопоставить с данными валидности психометрических тестов (по Равену, вообще лишь 2% людей имеют интеллект выше среднего). Arachnelis 09:40, 24 декабря 2013 (UTC)
        • Насколько я помню, правило трех сигм говорит о 99 с лишним процентах для нормального распределения. Википедия не является попыткой приблизиться к истине, а отразить знания человечества. Поэтому вполне возможно, что какая-нибудь маргинальная на сегодня теория является истинной, а большинство ошибается. РоманСузи 09:56, 24 декабря 2013 (UTC)
          • Ну, я примерно. А предвзятость источников мы в рассмотрение не берём, только их количество? Кухарки будут управлять государством? Arachnelis 10:49, 24 декабря 2013 (UTC)
            • Требования к источникам хорошо известны. Ясно, что в данном случае явно аффилированные источники брать не стоит. РоманСузи 15:15, 24 декабря 2013 (UTC)
              • Наконец-то! Это же просто чудесно! Получается, что ссылаться на Страуструпа можно только из критики, но не из достоинств и основного раздела, т.к. уж кто-кто, а создатель к своему детищу явно предвзято относится! И изложение тогда будет строиться от первичных академических источников, от которых С++ сильно отошёл в процессе развития, с указанием самодеятельности Страуструпа. В академических кругах С++ только критически упоминается, но никогда практически не применяется. Arachnelis 15:46, 24 декабря 2013 (UTC)
              • Только сейчас сообразил - это ведь ещё одна особенность С++. Все языки используются и развиваются как "вещи в себе", и их философии и традиции формируются естественным образом, а развитие отвечает запросам пользователей. И только Страуструп умудряется параллельно с диктованием языка ещё и диктовать правила его использования и философию развития. Причём, что интересно, на практике есть огромное количество адептов С++, которые видят С++ по-своему и прут супротив советов Страуструпа, а общая субкультура в итоге формируется под этим двояким влиянием. Итого: есть свод принципов С++, которые диктует папаша, а есть свод принципов С++, формирующийся естественным образом на практике. С позиции объективности язык необходимо рассматривать, не слушая рассуждений автора о нём, как готовый результат, который получился таким, каким получился. Если результат не соответствует ожиданиям автора - это также должно отмечаться. Arachnelis 17:55, 24 декабря 2013 (UTC)

в примере №5 что не то

надо исправить либо

typedef boost::transform_iterator <counter, int (*)(int)> transformer;

либо

return transformer(odd, counter(n));

FeelUs 14:54, 12 августа 2014 (UTC)

Исторический этап развития

Талица под названием «Исторический этап развития» некорректная. Вы её бездумно копировали из какой-то книги. Язык Си -- это отдельный язык, C++ не является логическим продолжением языка Си.
Только не рассказывайте сказочки о якобы совметимости этих языков. Данная таблица ущербна в том плане, что она создает у читателя неправильное представление, о том, что C++ якобы является усовершенствованным вариантом языка Си. --31.173.241.82 16:24, 12 июля 2016 (UTC)

• Согласен, история С++ начинается от "Си с классами", всё предыдущее можно смело удалить, а то и от машин Бэббиджа или кого там начинать можно. Arachnelis (обс) 15:49, 14 июля 2016 (UTC)

Некорректный перевод терминов

Слово "map" переведено как "карта". "map" переводится "отображение"(математический термин).93.185.20.96 00:15, 10 августа 2016 (UTC)

В таких случаях - правьте смело. gjrfytn (обс) 06:56, 10 августа 2016 (UTC)