Архивировано

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

i-maverick

Критика С++

Рекомендованные сообщения

Да бог с тобой! C++ - один из самых простейших языков!

 

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

 

Не стоит путать С++ и ООП.

 

Хмм... Ты вообще о чем? ООП - это методология. С++ - это язык программирования, теряющий свой смысл без данной методологии.

 

Развитая же стандартная библиотека + stl делают решение большинства мелких задач вообще плевым делом.

 

Опять не очень понятно. Что такое стандартная библиотека? А что такое stl?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ты хочешь сказать что у тебя 30гб книг?

Более 5 тысяч.

Сколько из них ты прочитал?

Помнится, я уже отвечал на этот вопрос.

 

 

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

Успокойся, три раза глубоко вдохни и езжай в библиоглобус за самоучителем по с++ :D

 

Хмм... Ты вообще о чем? ООП - это методология. С++ - это язык программирования, теряющий свой смысл без данной методологии.

А если процитированное тобой прочитать еще раз?

Не стоит путать С++ и ООП.

 

Опять не очень понятно. Что такое стандартная библиотека? А что такое stl?

Карманный, краткий и полный справочники по с++ должны помочь в решении данной проблемы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Успокойся, три раза глубоко вдохни и езжай в библиоглобус за самоучителем по с++ :)

Парень, это похоже тебе надо почитать книжку по основам с++. Потому что те твои непричесанные мысли, которые я процитировал - это полный бред. И если ты не умеешь адекватно отвечать на вопросы - так и скажи.

 

А если процитированное тобой прочитать еще раз?

Да сколько ни читай - смысла не прибавится.

 

Карманный, краткий и полный справочники по с++ должны помочь в решении данной проблемы.

Что, даже на такой простой вопрос ответить не можешь? Ты вообще знаешь, что такое std и stl? Ты знаешь, что stl фактически является частью std? Так что в твоем понимании означает "стандартная библиотека + stl"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

интересно, а почему спецификация простого языка C++ заимает так много?

и почему так долго писали компиляторы, полностью реализующию эту спецификацию?

C++ - это уродец, со странным пониманием ООП

хотя бы потому, что ООП с человеческим лицом включает в себя GC

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Более 5 тысяч.

Нету ли случайно среди этих книг такой:

Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation (Pro — Developer) by Charles Petzold (Hardcover — Sep 13, 2006).

Жаба давит 100$ платить за книжку...

 

 

C++ - это уродец, со странным пониманием ООП

хотя бы потому, что ООП с человеческим лицом включает в себя GC

:angry::):)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Unmoored, какое слово в фразе объяснить?

C++ - это попытка создать удобный язык программирования, который бы давал быстрый код, сравнимый с С

попытка хорошая

но при этом С++ всё равно часто неудобен

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну это кому как. Мне лично довольно удобен. Конечно C# поприятнее, но и C++ом не брезгую.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
интересно, а почему спецификация простого языка C++ заимает так много?

И как это связано? Чем больше документация тем хуже язык? Если мне в метро на ногу наступили, то лето будет дождливым?

 

и почему так долго писали компиляторы, полностью реализующию эту спецификацию?

И? Где логическая связь между временем написания компилятора и качеством языка программирования?

 

C++ - это уродец, со странным пониманием ООП

Конечно C++ это не smalltalk, но объясни, что там странного? Возможно ты просто чего-то недопонял.

 

хотя бы потому, что ООП с человеческим лицом включает в себя GC

Ну а вот это кроме как глупостью я назвать не могу. Ладно бы метаклассы вспомнил или что-то еще... но как это относится к ооп лично для меня страшная загадка. Кроме того оно СОВЕРШЕННО не нужно. Если ты умеешь программировать в объектно-ориентированном стиле то маловероятно, что у тебя в коде будут утечки, а если ты умеешь программировать в объектно-ориентированном стиле и имеешь некоторый опыт, то наверняка будешь использовать мные указатели, которые сделают за тебя всю ленивую работу. Некоторые же языки по другому не могут в силу своего нарочно ограниченного дизайна, в них у тебя и контроля меньше.

 

Нету ли случайно среди этих книг такой:

Applications = Code + Markup: A Guide to the Microsoft Windows Presentation Foundation (Pro — Developer) by Charles Petzold (Hardcover — Sep 13, 2006).

Такой нет.

 

 

C++ - это попытка создать удобный язык программирования, который бы давал быстрый код, сравнимый с С попытка хорошая

Сам себе противоречишь.

но при этом С++ всё равно часто неудобен

Приведи примеры.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вы отходите от темы... :)

Мне нравиться с++, но напрягает (лично меня) перевод типов, формошлепство...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И как это связано? Чем больше документация тем хуже язык? Если мне в метро на ногу наступили, то лето будет дождливым?

это говорит о сложности языка

я считаю эту сложность надуманной

к тому же давай не называть спецификацию документацией

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

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

 

И? Где логическая связь между временем написания компилятора и качеством языка программирования?

излишная сложность языка

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

 

Конечно C++ это не smalltalk, но объясни, что там странного? Возможно ты просто чего-то недопонял.

странно для ООП: отсутствие GC, указатели

С++ - это "объектно-ориентированный ассемблер"

 

Ну а вот это кроме как глупостью я назвать не могу. Ладно бы метаклассы вспомнил или что-то еще... но как это относится к ооп лично для меня страшная загадка. Кроме того оно СОВЕРШЕННО не нужно. Если ты умеешь программировать в объектно-ориентированном стиле то маловероятно, что у тебя в коде будут утечки, а если ты умеешь программировать в объектно-ориентированном стиле и имеешь некоторый опыт, то наверняка будешь использовать мные указатели, которые сделают за тебя всю ленивую работу. Некоторые же языки по другому не могут в силу своего нарочно ограниченного дизайна, в них у тебя и контроля меньше.

Такой нет.

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

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

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

 

Сам себе противоречишь.

ты просто не думаешь над прочитаным

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

попытка плохая, потому что удобным C++ назвать нельзя

 

Приведи примеры.

например, отсутствие анонимных функций. аналог lambda

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

читаемость кода от этого страдает, про то, чем я предпочитаю забивать мозг написано выше

так же можешь не рассказывать про бустовый lambda - это костыль

 

с хорошей подборкой аргуметнов против C++ можно ознакомиться по адресу

http://www.faqs.org/docs/artu/why_not_c.html

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ildar, ты тут покритиковал много, теперь похвали что-нибудь. Ты сам-то что предпочитаешь?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ildar, ты тут покритиковал много, теперь похвали что-нибудь. Ты сам-то что предпочитаешь?

C++ :)

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

 

а так python, lisp

 

Вы отходите от темы... :)

по теме то, что C++ - не лучшее с чего стоит начинать программировать

если только не программировать divx кодирование или ядро ОС

да и то там С пользуют

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

TWINc, перенеси пожалуйста сюда мессаги по этой теме.

 

это говорит о сложности языка

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

 

я считаю эту сложность надуманной

Если сложность надуманная, то она отсутствует.

 

излишная сложность языка

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

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

Я могу привести в пример туже java со всеми ее исключениями из правил и всеми этими хитростями вложенных/локальных/анонимных классов, связанными с ними областями видимости, порядками и особенностями инициализации и инстанцирования. А если еще сюда прибавить static/final да еще и модификаторы доступа, то вообще получится мрак. Однако, если все это знаешь, то никаких особых проблем не возникает и все эти "недостатки" превращаются в полезные фичи. Тем же кто их не освоил все это использовать совсем не обязательно. Язык богат и в нем много всего другого, что может использовать менее подготовленный программист. Тоже самое и с с++: не знаешь как что-то работает - бери книжку или используй другие возможности языка.

 

странно для ООП: отсутствие GC, указатели

Назови хоть одну книжку по ООП, где упомянается gc. Для меня такими книгами являются Буч, справочник по uml и справочник по паттернам. Может я не то читаю, но связи между ними абсолютно не вижу. И уж тем более мне не понятно чем указатели разрушили ООП. Указатели - это просто глупые ссылки - такой же инструмент как скажем оператор присваивания. Как это связано с ООП?

 

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

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

 

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

Ну я вот много уже услышал о проблемах, но пока ни одного примера. Это наводит на мысли....

 

например, отсутствие анонимных функций. аналог lambda

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

 

с хорошей подборкой аргуметнов против C++ можно ознакомиться по адресу

http://www.faqs.org/docs/artu/why_not_c.html

А из своего опыта? Адресовать-то к чужому легко...

 

а так python, lisp

Уж не lisp-ли стоит обучать молодых программистов? :lol:)

 

python - тоже не выход. Культура программирования вырабатывается дааалеееекоооо не сразу, а у некоторых она так и не появляется - отступы станут ну ооочень большой проблемой. Кроме того, я бы не назвал синтаксис python относящийся к классам легче синаксиса с++. Да и list/dictionary/tuple будут для неподготовленного человека не хуже static_cast/const_cast/reinterpret_cast.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

не бОльшую, примерно половину

Если сложность надуманная, то она отсутствует.

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

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

язык в целом сложен

если брать некоторое подмножество С++, то оно вполне удобно и просто

Назови хоть одну книжку по ООП, где упомянается gc. Для меня такими книгами являются Буч, справочник по uml и справочник по паттернам. Может я не то читаю, но связи между ними абсолютно не вижу.

формально написать программу в ООП стиле можно и на asm, и на C

например windows, если не ошибаюсь то у егошных окошек вполне так ООП интерфейс

есть классы окон, есть функция, обрабатывающая сообщения для данного класса окон

но всё это реализованно на C

ООП - это идея

но реализация этой идеи без gc неудобна

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

И уж тем более мне не понятно чем указатели разрушили ООП. Указатели - это просто глупые ссылки - такой же инструмент как скажем оператор присваивания. Как это связано с ООП?

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

бустовые weak и shared pointer'ы - это костыль

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

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

Ну я вот много уже услышал о проблемах, но пока ни одного примера. Это наводит на мысли....

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

 

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

я вынужден писать 20

пример: http://www.paulgraham.com/accgen.html

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

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

анонимная функция - часный случий анонимного класса

это добавит лёгкость программирования на языке

А из своего опыта? Адресовать-то к чужому легко...

ты прям как не программист

зачем делать то, что отлично сделано другими

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

Уж не lisp-ли стоит обучать молодых программистов? :))

я знаю об успешный попытках на ВМК МГУ

python - тоже не выход. Культура программирования вырабатывается дааалеееекоооо не сразу, а у некоторых она так и не появляется - отступы станут ну ооочень большой проблемой. Кроме того, я бы не назвал синтаксис python относящийся к классам легче синаксиса с++. Да и list/dictionary/tuple будут для неподготовленного человека не хуже static_cast/const_cast/reinterpret_cast.

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

а во втором категориями ассемблера

для обучения программированию в общем первое полезнее

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Цитата

хотя бы потому, что ООП с человеческим лицом включает в себя GC

 

Ну а вот это кроме как глупостью я назвать не могу. Ладно бы метаклассы вспомнил или что-то еще... но как это относится к ооп лично для меня страшная загадка. Кроме того оно СОВЕРШЕННО не нужно. Если ты умеешь программировать в объектно-ориентированном стиле то маловероятно, что у тебя в коде будут утечки, а если ты умеешь программировать в объектно-ориентированном стиле и имеешь некоторый опыт, то наверняка будешь использовать мные указатели, которые сделают за тебя всю ленивую работу. Некоторые же языки по другому не могут в силу своего нарочно ограниченного дизайна, в них у тебя и контроля меньше.

 

вот ТУТ интересный тред, где обсуждается в итоге плюсы/минусы GC и вообще плюсы/минусы C/C++

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

тут помоему вы спор из-за сапога устроили

С++ и питон,лисп и порчие ОЧЕНЬ РАЗНЫЕ ЯЗЫКИ

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

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

а вы тут начали

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

и С (и его последователь с двумя плюсиками) создавался как язык,упрощающий работу програмистам,знакомым с принципами как работает МАШИНА,а не ВИНДА

и все эти проблемы с работой с памятью и пр. это от незнания,а не от того что язык плохой

КАЖДОМУ дано своё.и КАЖДЫЙ пишет на своём.и ненадо мешать это в одну кучу.

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

и когда начинается спор что лучьше,С++ или ПЕРЛ я говорю-почитайте как эта машина работает,а потом уже судите.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Смешно. Смешно когда говорят что какой-то язык хороший, а другой полный отстой. Я видел очень успешные проекты на VBA и полностью провальные С++. Но больше всего бесит когда приходит ко мне супер специалист по С++, который в совершенстве владеет его спецификацией, гонит про темплейты, stl, множественное наследование, но впадает в ступор когда его просят нарисовать на экране окно с кнопкой. Не язык надо учить, а библиотеки и технологии. Почему русские программисты изобретают собственные интерфейсы и протоколы? Всё от незнания и нехотения читать документацию. Нафига нам какой-то DCOM, SOAP, OLEDB? Сейчас мы быстренько свой велосипед изобретем и поедем. Пусть он будет кривой, косой и ни с чем не совместимый, зато свой родной. Ведь как приятно самому ходить по граблям, а не пользоваться опытом тех кто по ним уже ходил!!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Как говорит Линус "легче написать 20 строчек на С чем одну на Perl". Это конечно же шутка, т.к. области применения их различны. Но доля правды есть.

 

И не нужно путать языки и компиляторы, например java или с++ или python это языки (синтаксис если так понятнее) и это ни как не связано с тем, что java работает при помощи виртуальной машины, а бэйсик вообще интерпретирумый.

Естественно бинарный код получаемый из кода с/c++ один из самых быстрых. "С -это такой переносимый асемблер" непомню кто это сказал, но действительно программы написаные на с++ работают на различных архитектурах. Да и компилятор (gcc) умеет затачивать код под определенную архитектуру и даже под определенный процессор (пример этому мой Gentoo Linux заточенный под Prescott).

 

Наверное это всё. Пишите больше кода. Делайте как я, делайте лучше меня.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С++ хорош своей универсальностью. Это достаточно высокоуровневый язык, в то же время позволяющий писать очень производительные программы (при наличии головы и прямых рук, естественно). Ни один другой высокоуровневый язык (жаба, питон и ежи с ними) не сравнятся с С++ по производительности программ. Здесь где-то звучало утверждение, что "программы на С++ почти такие же производительные, как и на С". Чушь! Программы на С++ ПРОИЗВОДИТЕЛЬНЕЕ, чем программы на С (при наличии достаточной квалификации у автора)! Я сам фанат эффективности. Знаю 5 ассемблеров и очень хорошо владею их макропроцессором, намисал turbo vision подобную "библиотеку" под DOS целиком на ассемблере и имею очень хорошее представление об эффективности времени выполнения. Так вот, увидев код, который генерирует любой более-менее приличный оптимизирующий компилятор (тот же VC++ от мелкософта) В РЕЛИЗНОЙ КОМПИЛЯЦИИ могу сказать, что С++ ПОЗВОЛЯЕТ писать программы почти такие же эффективные, как и написанные на ассемблере, а иногда даже и лучше. Лучше в том плане, что компайлер очень хорошо раскидывает переменные по регистрам. Руками такое сделать сложно. Знаете, что такое intrinsic? А зря...Меня поразил такой пример:

void foo()
{
 int x,y,CopyLng;
 //---Идет работа с памятью, копируются блоки. Длина задается CopyLng.
 //---Далее программист видимо по инерции пишет следующее:
 CopyLng = sizeof(int);
 memcpy(&x , &y , CopyLng);
 // дальше тоже идет код.
}

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

mov edx, ecx

ВСЁ! Одна команда! Этот пример стал для меня поворотной точкой, с которой я отказался от паблик данных и стал делать функции-аксессоры

class MyClass
{
 protected:
 int m_a;
 public:
 inline int GetA() const {return a;}
 inline void SetA(int NewA) {a=newA;}
};

Потому что этот подход хоть и добавляет писанины, но НИКАК не сказывается на эффективности времени выполнения, зато гибкости и контроля типов будет гораздо больше. Захочу, вообще уберу m_a, а функции Get и Set сделаю виртуальными и напложу потомков моего класса. И на остальной части программы это никак не отразится. После осознания всей мощи оптимизатора (особенно если ему в этом помочь шаблонами и инлайн-функциями), я оставил ассемблеру место только в таких специфический областях, как длинная арифметика и прямой доступ к оборудованию (портам). Ну не поддерживаются в С/С++ флаг переноса, регистровая пара EAX/EDX в операциях умножения/деления и команды циклического сдвига, а в длинной арифметике на них все и построено - тут сям с ассемблером конечно не тягаться. Если бы не перечисленные выше причины - ассемблер можно было бы выкинуть на свалку истории. Но даже сейчас такие вещи, будучи реализованными на ассемблере, "упаковываются" в классы C++ и юзаются уже в больших проектах на C++. К чему то бишь я? К тому, что мне не очень хочется критиковать С++. Да, у него есть недостатки. Язык шаблонов громоздок и неудобен. Да, лоханулись они с auto_ptr. Но по эффективности (времени выполнения) с ним не сравнится ни один другой язык. А потребность в garbage collector-e свидетельствует о кривизне дизайна программы имхо. На крайний случай есть boost::shared_ptr или самодельный подсчет ссылок, который нужен очень редко. И из-за нескольких переменных запускать garbage collector? Мне бы было жалко процессорного времени. Так что учитесь программировать, учитесь думать (кстати думать надо на любом языке программирования), а не критикуйте С++.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Меня поразил такой пример:

void foo()
{
 int x,y,CopyLng;
 //---Идет работа с памятью, копируются блоки. Длина задается CopyLng.
 //---Далее программист видимо по инерции пишет следующее:
 CopyLng = sizeof(int);
 memcpy(&x , &y , CopyLng);
 // дальше тоже идет код.
}

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

mov edx, ecx

ВСЁ! Одна команда!

 

 

По поводу примера - охренеть...

 

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

 

Охренеть....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
а бэйсик вообще интерпретирумый.
это только VB. друие бейсики - вполне себе компилируемы.

 

Программы на С++ ПРОИЗВОДИТЕЛЬНЕЕ, чем программы на С (при наличии достаточной квалификации у автора)!
тесты твои слова не подтверждают. разница в производительности между c и с++ такая же как и между с++ и с#.

 

Знаю 5 ассемблеров и очень хорошо владею их макропроцессором, намисал turbo vision подобную "библиотеку" под DOS целиком на ассемблере
нафига изобретал велосипед?

 

Меня поразил такой пример:
примитивнейший вариант.

- мой сынок гений!

- почему вы решили?

- он ответил, что два жды два будет четыре!

- и сколько вашему сынку лет?

- 18!

- мда...

 

Потому что этот подход хоть и добавляет писанины, но НИКАК не сказывается на эффективности времени выполнения
ассемблер хоть и добавляет писанины... :censored:

 

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

 

Ну не поддерживаются в С/С++ флаг переноса, регистровая пара EAX/EDX в операциях умножения/деления и команды циклического сдвига
ну, в стандарте может и не поддерживаются, а вот на билдере я точно помню юзал циклический сдвиг.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

давайте переименуем тему в "область применения С++"

критерием пусть будет стоимость написания и эксплуатации системы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С++ ПОЗВОЛЯЕТ писать программы почти такие же эффективные, как и написанные на ассемблере, а иногда даже и лучше ??????

 

 

ну это полнейший бред сколько не ковырял программы в отладчике ни о какой оптимизации сопоставимой с программой на ассемблере написаной вменяемым программистом не может идти и речи. Программы на С++ иль С во многом зависят от компилятора. Использование чистого API весьма трудоемко и будет по трудозатратам сопостовимо с написанием программ на ассемблере а работодателю как правило требуется скорость разработки а не чистота языка. Ну подумаешь программа весить 100 мегов и жрет 256 мегабайт оперативки ерунда какая пускай юзеры идут в магазин за новым железом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

знаете, мой школьный преподаватель по информатике когда его спрашивали какой язык программирования "лучше" отвечал: "вот скажите, вы поедите на оперу в большой театр на кразе? или вот ещё, вы за картошкой на дачу поедете на ролсройсе?". Суть изречения(не цитаты, дословно не помню) уже ясна(я так дУмаю): для каждой ситуации своё. Конечно, если выражаться в этих терминах, то если у тебя нету ролсройса, то в театр прийдётся на кразе тащиться, но если ваша машина - краз(хотя не важно), естественно ей вы пользуетесь чаще по прямому приминению, иначе зачем было её вообще покупать. Так и здесь можно на с++ писать сайты, но если вы так делаете, то это я думаю говорит о том, что сайты вы пишите не часто и изучать php для единичного случая вам не хочется(хотя это при знании С за 2 дня делается). Так вот, каждому случаю своё, можно извратиться, но это случайность и/или лень программиста. Хотя есть ещё такое явление природы как заказчик=)) ну вот хочется ему иметь свой почтовый клиент, написаный на ассемблере (маразм, но и такое случается), хотя зачастую всё же удаётся объяснить человеку, что это не имеет смысла, но поверьте, бывают и те, которым на слова ваши плевать с большой колокольни, это в основном небедные ребята, у которых есть знакомый "программист"(акцент на кавычки), который уверен в магическом действии ассемблера. Ну тут хоть тресни, благо таких людей красит их кредитка и стрести с них можно нехило. Хотя вообще чушь я тут пишу, и если вы дочитали - слава вам, но забудьте, ибо это тупое забивание коры головного мозга.

 

Что касается С++ - им я пользуюсь чаще других, больше и не скажешь ничего=)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм, для меня слова о неудобстве C/C++ - пустой звук. Мне удобно. Даже очень. И проблем у меня нет никаких. Нужно просто не лениться и научиться грамотно писать. Мне не мешают указатели (скорее даже наоборот), у меня нет проблем при работе с памятью. Зато C научил меня точности и аккуратности.

 

Согласен, некоторые задачи решать на нем неудобно, скажем графические интерфейсы клепать, но в быстродействии ему не откажешь. Видел я некоторые приложения в Fedora Core 6, написанные на скриптовых языках, так они жестоко тормозят даже на P4 Core Duo 2 6300. (Интересно было бы посмотреть на какое-нибудь серверное приложение, написанное на скриптовом языке, когда к нему валом повалят клиенты).

 

Так что каждый выбирает свое. Вот уже 12 лет мне ближе С/C++.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хмм... Ты вообще о чем? ООП - это методология. С++ - это язык программирования, теряющий свой смысл без данной методологии.

;) С++ хорошо поддерживает ООП, но смысла без нее не теряет. :)

 

 

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

:lol:

 

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

 

Только от этого он не перестанет быть высококлассным профессионалом и дефицитным специалистом... Пусть даже любая бландинка, после недельного инструктажа научится создавать формы с кнопками c помощью VB. ;)

 

Развитая же стандартная библиотека + stl делают решение большинства мелких задач вообще плевым делом.
;) Да уж, перл еще тот... :)

 

stl требует высокой дисциплины, большого опыта и знаний... О ясности отладочных сообщений stl вообще можно говорить очень долго и с большим чувством... ;)

 

stl - штука, конечно, замечательная... но с "плевым делом" у опытного программиста никак не может ассоциироваться... :)

 

python - тоже не выход. Культура программирования вырабатывается дааалеееекоооо не сразу, а у некоторых она так и не появляется - отступы станут ну ооочень большой проблемой. Кроме того, я бы не назвал синтаксис python относящийся к классам легче синаксиса с++. Да и list/dictionary/tuple будут для неподготовленного человека не хуже static_cast/const_cast/reinterpret_cast.

static_cast/const_cast/reinterpret_cast - столь уродливые конструкции в язык введены намеренно.

 

Идея в том,

 

1 чтобы применяя их, программист лишний раз задумался, а нельзя ли иначе?

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

 

 

 

 

C++ - это уродец, со странным пониманием ООП

хотя бы потому, что ООП с человеческим лицом включает в себя GC

:lol: Ох уж мне эти пуристы, ох уж эти теоретики борьбы за светлое будущее. :blink:

 

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

 

 

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

бустовые weak и shared pointer'ы - это костыль

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

 

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

Да считай чем хочешь... ;) ... есть возможность сделать тоже самое на чем-то другом? ;) ... бесплатный сыр только в мышеловке. ;)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С++ отличнейший язык,интересен в изучение и применении на практике

 

С++ язык кодеров и богов

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
С++ язык кодеров и богов

Так всё-таки кодеров или богов :(? http://xkcd.com/c224.html

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так всё-таки кодеров или богов :D? http://xkcd.com/c224.html

 

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

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

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

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

 

Когда кто-то говорит, что язык такой-то супер, а то что используешь фигня, мне все всегда вспоминается америкосская реклама, где тебе впарят совершенно бесполезный предмет на **.95 и при этом если позвоните сейчас вы еще и получите в подарок второй, не менее бесполезный предмет, которые выкинете сразу))

 

Хоть сам я и пишу на С/С++/Дельфи ( чаще С++ ), потому что чувствую, что С, С++ и Дельфи - это мое

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

:)

 

Речь не мальчика, но мужа! :)

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах