Обсуждение:C++

Обсуждение:C++

Содержание

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

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

--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)

Недостатки

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

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

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

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

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

--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)

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

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

* 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 Нет проверки выхода за границы массива.

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

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

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

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)

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

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

Критика языка 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)

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

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

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

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


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

Например: http://www.rsdn.ru/Forum/Message.aspx?mid=1669546&only=1 - С++ vs C# (я это даже не читаю, не осилил :-)

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

Попробуйте сами. А я позже гляну :-)

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

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

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

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

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

Sergey Shandar

///Demon///

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

---

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

---

Не путаем CTTI и RTTI. Java имеет RTTI, но Java НЕ имеет полноценного CTTI, так же как и средств для метапрограммирования (программирование и вычисление во время компиляции).

--Sergey Shandar 12:45, 22 июня 2006 (UTC)

Сокращение статьи

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

А по-моему, хорошо бы меньше. Уж больно статья рыхлая получилась. Всё как-то раскидано по разным частям текста, много дублирования. С вашего позволения, я постараюсь её причесать.
Для начала переписал вводную часть, так чтобы в ней осталась только важнейшая выжимка сведений о языке.
--achp 11:39, 11 марта 2006 (UTC)
Сократил статью ещё --Urod 02:06, 21 июня 2006 (UTC)

Старые сообщения

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

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

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

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

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

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)

"...фирма Майкрософт предложила язык C# как новый язык, развивающий принципы C++..." Ну это вообще дезинформация!

 
Начальная страница  » 
А Б В Г Д Е Ж З И Й К Л М Н О П Р С Т У Ф Х Ц Ч Ш Щ Ы Э Ю Я
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
0 1 2 3 4 5 6 7 8 9 Home