LINUX.ORG.RU
ФорумTalks

Чем так плох С++?


0

0

Постоянно натыкаюсь на форуме на высказывания типа "...разочаровался в С++...", "...ненавижу С++...", "...убить бы того,
кто его придумал..." и т.п. Сам только начинаю изучать С++, и хотелось бы знать недостатки С++, послушать здоровую критику, потому как не понимаю, почему в последнее время все обозлились на него. На гугле и в википедии ничего толкового не нашел, только теоритические высказывания, вытекающие из стандарта языка. А хотелось бы послушать практикующих опытных программистов, потому как эта нелюбовь, IMHO, приходит с опытом. И кстати, также наталкиваюсь на подобные высказывания в сторону ООП. "...разочаровался в ООП, посматриваю в сторону функционального программирования...".
Не ради флейма, хочу понять причины.

Ответ на: комментарий от eg0_dist0rti0n

> Да, я знаю, что на SmallTalke писалась система управления электропоездами метро(? что ли)

На Аде. Ада тоже рулит, но паскакаль - таки сасёт.

Gharik
()
Ответ на: комментарий от eg0_dist0rti0n

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

wanderer
() автор топика
Ответ на: комментарий от eg0_dist0rti0n

> Но моё мнение такое: профи занимающиеся такими задачами не будут тратить время чтобы выяснять, а не гавно ли C++. Но я сомневаюсь что автор слышал именно мнение профи, скорее всего это были те, кто просто неосилил С++.

Я бы так обозначил эволюцию мнений о C++:

1. Новичек: уу сложно || уу клево || уу гавно

2. Средний уровень: ниче так || вроде терпимо

3. Более-менее опытный программист: нормальный удобный язык || писать можно || отличный язык

4. Гуру: гавно неперивариваемое.

Вы где-то на уровне 2 или 3 я так полагаю. Вы видимо даже не представляете себе тех подводных камней, которыми может одарить C++.

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

anonymous
()
Ответ на: комментарий от Gharik

> если взять реализацию ООП в smalltalk и в c++, возникает вопрос о

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

kto_tama ★★★★★
()
Ответ на: комментарий от geek

>как замечательно плюсы позволяют добавлять новые возможности - видно по четырехкратному (емнип) переписыванию движка оперы "с нуля".

Возможно это говорит о криворукости девелоперов Оперы? :)

З.Ы. ФФ - наше всйо.

З.З.Ы. Не я первый начал! :)

anonymous
()
Ответ на: комментарий от wanderer

1) Код на плюсах может работать совершенно не так, как кажется на первый(+ если не особо опытный) взгляд. Тому виной перегрузка операторов, создание врем. копий, virtual/non virtual, макросы, особенности поиска имен. Все эти фичи весьма нормальны, но может так случиться, что код придется читать буквально по-слогам.

2) Нестандартизованный манглинг (преобразование имен в символы), т.е. чтобы использовать из своей проги dll-и компиленные разными компиляторами C++ придется делать сишный интерфейс. Еще одно следствие - кривизна биндингов к плюсовым библиотекам для других языков.

P.S. Imho обычно на лоре плюсы ругают по религиозным причинам. =)

YesSSS ★★★
()
Ответ на: комментарий от anonymous

>>как замечательно плюсы позволяют добавлять новые возможности - видно по четырехкратному (емнип) переписыванию движка оперы "с нуля". Возможно это говорит о криворукости девелоперов Оперы? :)

> З.Ы. ФФ - наше всйо.

Большая часть которого написана на JavaScript (если вы не знали).

anonymous
()

костыли не красят никакой язык... потому и не люблю...

DemonZLa
()
Ответ на: комментарий от watashiwa_daredeska

>т.к. очередная маленькая хотючка заказчика способна поставить раком всю стройную архитектуру
Ну я так скажу: если на C++ смогли сделать ROOT, то всё остальное - это так себе, печеньки. А насчёт такого подхода, что _уточнение_ требований заказчика вдруг делает текущий проект просто набором символов... Хм, мне слышится голос одесской бандерши тёти Сони: "Когда у меня плохо идут дела, я знаю что нужно менять не кровати. Нужно менять девочек."

eg0_dist0rti0n
()

Моё имхо:

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

Ну и всякие вкусные возможности типа void* и возможности вернуть указатель на стековый объект.

Теперь про ООП.

Вооще, как такового определения ООП, в отличие от ФП нет. Каждый производитель языка и каждый программист понимает данный термин по-разному. Конечно есть некие общие термины типа класс, оъект, метод, наследование, инкапсуляция, полиморфизм... Но и они определены достаточно абстрактно. Например в питоне - функция это оъект, и класс это объект, значит и то и другое можно хранить в какой-то переменой, возвращать и т.п. А попробуйте в С++ вернуть класс?

Те кто пишут "... разочаровался в ООП", как правило либо п$$$$т, либо только-только начали изучать ФП и не поняли еще что ФП и ООП не являются парадигмами-антагонистами.

В ООП на понятие "класс" можно смотреть с 3-х позиций: "класс-как-тип", "класс-как-интерфейс" и "класс-как-поведение" плюс еще "класс-как-АТД" (но это смешение всех трех сразу), в хаскеле, например, акцент смещен в сторону "класс-как-тип" и что с того? Никуда ООП оттуда не делся.

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

Например, в том же хаскеле намного легче написать реализацию паттернов Composite-Visitor, которые обычно применяют для работы с рекурсивными стпуктурами данных, чем в С++.

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

Самое сложное в Хаскелле, на мой взгляд, то что в нем используется комбинаторная логика. Т.е что то типа someprog | grep "regexp" | sort "key" вместо a = someprog; b = grep(a,"regexp);c = sort("key",b);print(c);

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

Macil ★★★★★
()

Чем плох C++?

Плох тем, что он - ни рыба, ни мясо. Он низкоуровневый, как C, но с потугами на наличие высокоуровневых конструкций, которые ничего кроме разочарования не вызывают.

В C++ якобы есть метапрограммирование. Есть даже Тьюринг-полный язык шаблонов. Можно им пользоваться? Хрен там, нельзя им пользоваться. Даже банальный foreach этим якобы "метапрограммированием" изобразить невозможно. Из каждой щели все равно будут глядеть низкоуровневые конструкции, что не позволяет создавать на этом языке решения, специализированные под требования какой либо конкретной предметной области. То есть, даже эффективного разделения труда не получится с C++, такого, чтобы высококвалифицированный программист реализовывал низкоуровневую функциональность и предоставлял бы простой высокоуровневый интерфейс к ней специалистам предметной области.

В C++ якобы есть ООП. Так думают все те, кто ничего кроме C++ не знает. Те же, кто видели Smalltalk и CLOS, не считают что в C++ есть ООП.

В C++ якобы есть сильная система типов. Так думают все те, кто ничего кроме C++ никогда не видел. Те, кто знаком с Ada, SML, Haskell - никогда не назовут систему типов в С++ строгой и консистентной.

Продолжать, или уже хватит?

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

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

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

> А насчёт такого подхода, что _уточнение_ требований заказчика вдруг делает текущий проект просто набором символов... Хм, мне слышится голос одесской бандерши тёти Сони: "Когда у меня плохо идут дела, я знаю что нужно менять не кровати. Нужно менять девочек."

Чувак, ты сам то хотя-бы на 10000 строк кода писал что-нить на плюсах? Похоже что нет, ни разу.

anonymous
()
Ответ на: комментарий от Macil

> Те кто пишут "... разочаровался в ООП", как правило либо п$$$$т, либо только-только начали изучать ФП и не поняли еще что ФП и ООП не являются парадигмами-антагонистами.

Однако, при корректном использовании ФП просто нет необходимости в OOD - можно пользоваться более мощными и гибкими методиками проектирования. Так же нет и необходимости в ООП как в механизме модульности и инкапсуляции - средства, предоставляемые современными ФП языками делают это гораздо лучше, чем классы-шмассы. А ведь 90% случаев употребления ООП - это именно что модульность+инкапсуляция, и только 10% - полноценное объектное моделирование. Из этих 10%, однако, только 1% объектного моделирования, примененного по делу, в остальных же случаях нужны существенно иные мат. модели предметной области.

anonymous
()
Ответ на: комментарий от anonymous

>Однако, при корректном использовании ФП просто нет необходимости в OOП

Не согласен, в том же хаскелле монада определена как класс Monad, многие все числа как класс Num и т.п. Все дело в точке зрения.

В остальном - согласен.

Macil ★★★★★
()
Ответ на: комментарий от wanderer

Тогда вам, как новичку, чтобы не испортить окончательно и фатально своё мышление надо не ограничиться изучением C++ (я уверен, что каждый из критиков C++, как и я, считает всё равно изучение C++ обязательным этапом в карьере каждого программиста). Изучайте параллельно Scheme, Haskell и Forth. После этих трёх - Prolog и Smalltalk. Это не сложно, это очень даже легко. И с таким багажом знаний вы очень легко увидите не только все глюки и подводные камни в дизайне C++, но так же и относительно приемлимые способы эти подводные камни обходить.

Заметьте, кстати: C++ хвалят только те, кто не знает ничего другого (всякие там Pascal, Java и C# за другие языки считать нельзя, они от C++ отличаются чисто косметически, если про темплейты забыть). Те же, кто знает и C++ и несколько существенно других языков, про C++ высказываются уже совсем не так оптимистично.

anonymous
()
Ответ на: комментарий от Macil

> Не согласен, в том же хаскелле монада определена как класс Monad

Какое СОСТОЯНИЕ инкапсулировано в инстансе класса Monad? Какие СООБЩЕНИЯ ему можно посылать?

Никакого? Никаких? Ну так это не ООП. И термин "класс" тут употреблён в более математическом его смысле (могли бы и "категория" сказать, раз уж функтор назвали функтором), и к каноническому Кеевскому ООП отношения не имеет.

anonymous
()
Ответ на: комментарий от anonymous

>Возможно это говорит о криворукости девелоперов Оперы? :)

>З.Ы. ФФ - наше всйо.

ФФ изнутри тоже похож на кучу говна. Увы и ах, но это лучшее, что есть в OSS из браузеров

geek ★★★
()
Ответ на: комментарий от Macil

>разное понимание различных тонкостей языка разными компиляторами Вообще то есть компиляторы, которые уже под несколько платформ заточены, и на разных платформах можно компилить одним и тем же компилером. К тому же если особо не извращаться, то нормально всё переносится. Да на тот же пресловутый DOOM3 посмотреть. Перенёсся как милый.

eg0_dist0rti0n
()
Ответ на: комментарий от anonymous

>Какое СОСТОЯНИЕ инкапсулировано в инстансе класса Monad? Какие СООБЩЕНИЯ ему можно посылать?

Почитай http://www.parc.com/csl/groups/sda/publications/papers/Kiczales-TUT95/for-web...

Очень интересная штука... Особенно про сообщения объектами. В CLOS, например, вместо них используюся general functions. И такой подход приносит много плюшек, типа таких, что методы являются объектами первого класса.

А говорить про состояние в чисто ФП реализации не совсем корректно...

Класс Monad не совсем удачный пример, более удачный пример класс Num

Macil ★★★★★
()
Ответ на: комментарий от eg0_dist0rti0n

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

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

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

Macil ★★★★★
()
Ответ на: комментарий от eg0_dist0rti0n

> Моё мнение такое: это красивый, удобный, мощый и пр. язык, но становится он таким э-э-э в голове,

Он остаётся таким в голове до тех пор, пока голова относительно пуста. Если же эта голова изучит Scheme или Common Lisp, Haskell, Forth и Prolog, то C++ снова станет похожим на говно, и на этот раз уже безвозвратно и неотвратимо.

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

>>разное понимание различных тонкостей языка разными компиляторами

> Вообще то есть компиляторы, которые уже под несколько платформ заточены, и на разных платформах можно компилить одним и тем же компилером. К тому же если особо не извращаться, то нормально всё переносится. Да на тот же пресловутый DOOM3 посмотреть. Перенёсся как милый.

ЫЫЫ... нашел чем прикрыть кривость языка... А ежели по каким-то причинам требуется использовать все-же платформенно-специфичные компилеры? Например тот-же gcc очень неохотно интегрируется с Platform SDK от MS.

DOOM3 -- это ты тоже загнул, ты бы еще пакмана вспомнил, умнег мля...

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

> Ну я так скажу: если на C++ смогли сделать ROOT, то всё остальное - это так себе, печеньки.

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

> А насчёт такого подхода, что _уточнение_ требований заказчика вдруг делает текущий проект просто набором символов...

Ты с заказчиками когда-нибудь работал? С настоящими, а не преподами на лабах. Суть в том, что заказчик: 1. не знает, чего он хочет, 2. не знает, насколько трудоемко то, что он хочет. Точнее, знает: "Да, я забыл, мне нужны еще суммы по такому-то параметру при группировке по такому-то. В реальном времени. Это плюс одно окошко к программе, значит больше $100 стоить не должно", а то, что этих данных для суммирования гигабайты, и лопатит их кластер, и как их синхронно в реальном времени суммировать никто никогда не думал, его не волнует.

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от anonymous

Ага. Понеслось... Не, я в таких спорах участвовать не буду. Возможно и есть проекты которые лучше пойдут на этих языках, но C++ как бы на всё хватает, вот в чём дело. И почему такие радикальные заявления что мол гавно? Да вот сегодня прожигал из K3B. Всё очень миленько работает. Мне что тут сейчас начнут рассказывать, что всё было сделано неправильно, и нужно из С++ всё пе-ре-ре-а-ли-зо-вать на Common Lisp или вообще поржигалку сделать на Prologe? А вот не смешите мои тапочки.

eg0_dist0rti0n
()
Ответ на: комментарий от anonymous

>DOOM3 -- это ты тоже загнул, ты бы еще пакмана вспомнил, умнег мля...
А что плохой пример? Я конечно не знаю, сколько там строк кода, знаю что писАлось всё несколько лет. Если отбросить все уровни, и прочий лимонад, то сам движок думаю получился не маленький. И всё роскошно идёт и под виндой и под линуксом. То есть это всего лишь пример того, что объёмный код на С++ вполне нормально переносится под разные платформы. И потом, я говорил о том, что _можно_ писАть переносимый код. А насчёт того, что есть непереносимые фишки, то это не значит что нет альтернативного решения, которое позволило бы решить задачу в кроссплатформенном исполнении. Нравятся какие-то особенноси MSVC? Пиши для виндоус. Хочешь сделать нечто переносимое? Выбирай другую среду. Понимаешь о чём речь? Ну а поводу не сути, но формы в которую было оформлено возражение: знаешь, я просто должен настоятельно порекомендовать тебе придушить мой XXX губами.

eg0_dist0rti0n
()
Ответ на: комментарий от eg0_dist0rti0n

> Возможно и есть проекты которые лучше пойдут на этих языках, но C++ как бы на всё хватает, вот в чём дело.

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

Как обычно - C++ хвалят ТОЛЬКО те, кто не знает и знать не желает ничего другого.

> Да вот сегодня прожигал из K3B. Всё очень миленько работает.

Всё с тобой и с твоим уровнем ясно. Можешь больше на эту тему не высказываться. Ты ведь ещё и студент, небось, в дополнение ко всем прочим недостаткам?

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

>>DOOM3 -- это ты тоже загнул, ты бы еще пакмана вспомнил, умнег мля...

>А что плохой пример? Я конечно не знаю, сколько там строк кода, знаю что писАлось всё несколько лет. Если отбросить все уровни, и прочий лимонад, то сам движок думаю получился не маленький. И всё роскошно идёт и под виндой и под линуксом. То есть это всего лишь пример того, что объёмный код на С++ вполне нормально переносится под разные платформы.

Пример ужасный. Игрушка не идет ни в какое сравнение с действительно сложным кодом. Писалось несколько лет -- это что: различные спец-эффекты, красивые взрывы, карты, текстуры, вот над чем там народ трудится. Кода там реально раз два и обчелся, и наверняка вместо STL и прочих "std::" используются свои кастомные библиотеки, что-бы не возится с переносимоститью. А переносимость ценой "переписать std::" -- это не переносимость.

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

Ахтунг, среди нас пидар!! (настойчивый пидар)

anonymous
()
Ответ на: комментарий от wanderer

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

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

watashiwa_daredeska ★★★★
()
Ответ на: комментарий от watashiwa_daredeska

>Ты с заказчиками когда-нибудь работал? В конторе в которой раньше довелось трудиться (банк), вводили новую систему, то есть я был "по ту сторону колючей проволоки". То что раньше шевилилось на FoxPro пофилиально, связали воедино в одну паутину, так скажем. Меня впечатлило: как там вообще умудрились всё реализовать и при этом по большому счёту ничего не напутать. Хотя всё равно косяки были. Я не знаю как там всё делалось. И для того же банка наверняка было затруднительно сразу представить, что же именно он хочет. Мне что-то подсказывает, что такие большие проекты хорошо бы сначала разложить по косточкам силами какого-нибудь UML, чтобы для начала узреть, а что же вообще входит в модель. Ведь как-то же такие проекты делаются. А у тебя получается следствие Боярского из теоремы Стокмайера: "Любую работу выполнить абсолютно невозможно." Но вообще, мой довод в пользу С++ таков: если пришёл вот такой запрос >Да, я забыл, мне нужны еще суммы по такому-то параметру при группировке по такому-то. В реальном времени. Это плюс одно окошко к программе/ То справится с ним проще, при прочих равных условиях, если всё делалось изначально именно в плюсах. А если такой же запрос поступит для некого "решения" в Дельфи, то попа будет гораздо более полная.

eg0_dist0rti0n
()
Ответ на: комментарий от eg0_dist0rti0n

> Мне что-то подсказывает, что такие большие проекты хорошо бы сначала разложить по косточкам силами какого-нибудь UML, чтобы для начала узреть, а что же вообще входит в модель.

Мы подходим к сути проблемы!!!! Часто C++, очередное требование заказчика потребует небольших изменений в UML схеме и переделки 99% процентов кода по факту!

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

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

Мне что-то подсказывает, что твой убогонький опыт дерьма не стоит. И что тебе ещё учиться и учиться. Рановато тебе собственное мнение иметь, и тем более высказывать.

Сразу видно, что кроме C++ и такого же говна Дельфи ты ничего не видел. И, что характерно, ты и знать ничего не желаешь, ты не считаешь себя убогим, не готов признать, что ты - пустышка. Был бы готов - давно бы уже по результатам этого обсуждения побежал изучать Common Lisp и Haskell.

anonymous
()
Ответ на: комментарий от eg0_dist0rti0n

> Да, я забыл, мне нужны еще суммы по такому-то параметру при группировке по такому-то. В реальном времени. Это плюс одно окошко к программе/ То справится с ним проще, при прочих равных условиях, если всё делалось изначально именно в плюсах.

Пришел запрос: "я забыл, база должна быть децентрализована и каждый байт должен быть трижды продублирован на разных хостах." И что? Раком все встанет

anonymous
()

Все очень просто. Си - гениальный язык на века. Чист, прост, мощен, дальновиден, элегантен и пр.. С++ - объектно ориентированный, но ООП на нем сделано крайне неудачно, сильно недоработано. К тому же, из-за стремления к совместимости с Си (которой он, как это не пародоксально, не располагает), и при этом введения новых языковых конструкций, язык стал похож на БОЛЬШУУУУЮ ПОМОЙКУ. Я не могу без мата видеть, как в одном языке употребляются И #define И const; И структуры со встроенными функциями, И классы и т.д.. Также нет присущих языкам высокого уровня черт, такий как встроенные в синтаксис динамические массивы. Классы С++ хрен импортируешь в другие языки программирования. Вот D - он хоть до ума доведен. С++ должен умереть. Либо нормальный низкоуровневый Си, либо нормальное ООП на D. А вообще ООП - глупость. Разве стоит так все усложнять только ради того, чтобы писать a->substring(2,5) вместо substring(a,2,5) ????

xTERM ★★
()
Ответ на: комментарий от xTERM

> Разве стоит так все усложнять только ради того, чтобы писать a->substring(2,5) вместо substring(a,2,5) ????

ООП служит не для этого. Учись студент.

anonymous
()
Ответ на: комментарий от anonymous

<А переносимость ценой "переписать std::" -- это не переносимость. Переносимость-непереносимость. Да KDE3 можно и под мак ос и под виндоус запустить(ч-з cygwnin правда, но это говорит только о том, что немного напильника и пойдёт ч-з mingw), так что переносимость налицо. Это я говорю о том что уже есть, а вообще если ты не в курсе 4-ку собираются делать изначально переносимой. С появлением Qt, которая прилизала все синтаксические разночтения, проблема невозможности что-то перенести вообще не стоит. Я не пойму что тебя вообще не устраивает? То что код для MSVC не пойдёт под другими платформами? Ну так ты определись - или ты делаешь всё под виндоус, и используешь эксклюзивные бонусы от MS, или выбираешь другой компилятор, поторый портирован под разные оси, и результаты будут везде одинаковые. >Ахтунг, среди нас.. А нету тут никаких "нас". Это сообщение tet-a-tet. От меня к тебе. И потом, почему такой пошлый ход мыслей? Я вообще за X-ами - подразумевал аббревиатуру USB. И то что ты с превеликой радостью готов присосаться к тому что там тебе померещилось, говорит только о твоих собственных наклонностях, я тут не при чём, ты сам себя выдал.

eg0_dist0rti0n
()
Ответ на: комментарий от anonymous

>> Разве стоит так все усложнять только ради того, чтобы писать a->substring(2,5) вместо substring(a,2,5) ????

>ООП служит не для этого. Учись студент.

P.S. В ADA95, обращение к методам обьекта осуществляется как "substring(a,2,5)"

anonymous
()
Ответ на: комментарий от anonymous

>Был бы готов - давно бы уже по результатам этого обсуждения побежал изучать Common Lisp и Haskell. Я вижу сюда заходят великие гуру, временами.

eg0_dist0rti0n
()
Ответ на: комментарий от xTERM

> писать a->substring(2,5) вместо substring(a,2,5) ????

Очень удобный механизм.

Например в Руби: "test string".split(" ") Теперь в ПХП: explode(" ", "test string");

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

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

Cris
()
Ответ на: комментарий от eg0_dist0rti0n

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

anonymous
()
Ответ на: комментарий от xTERM

>Я не могу без мата видеть, как в одном языке употребляются И #define И const

подумай, в чём разница между ними

>И структуры со встроенными функциями, И классы и т.д...

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

>Также нет присущих языкам высокого уровня черт, такий как встроенные в синтаксис динамические массивы.

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

>Классы С++ хрен импортируешь в другие языки программирования

бейсик от этого не умрёт

frame ★★★
()
Ответ на: комментарий от xTERM

> С++ - объектно ориентированный, но ООП на нем сделано крайне неудачно, сильно недоработано.

Что именно? Имхо, из ООП там нет разве что мультиметодов, всё остальное нашпиговано.

> Также нет присущих языкам высокого уровня черт, такий как встроенные в синтаксис динамические массивы.

Чем они лучше std::vector-а?

> Вот D - он хоть до ума доведен. С++ должен умереть. Либо нормальный низкоуровневый Си, либо нормальное ООП на D.

Это разные языки с разными философиями. C++ : платишь за то, что используешь, больше ни за что не платишь. D отошёл от этого принципа.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

Доходчиво объяснили? Интересно... Доходчиво - это значит несколько раз повторить, что есть языки кроме С++, и тот кто их не рассматривает в качестве приемлимых - тот наипоследнее чмо? А ты посмотри на ситуацию с другой стороны: для решения тех задач которые вставали передо мною (в своё время это были нейросети), мне С++ хватило за глаза. А ты значит более крут, ты значит возможностями С++ не ограничиваешься, ты значит осваиваешь более сложную граматику и т.д. и т.п. Но вопрос: зачем? Если для себя, для саморазвития то и колупайся в своё удовольствие, кули ты мне советуешь что мне надо знать, а что не надо? Я считаю что дебилизм как раз таки в том, чтобы гробить время на излишнюю сложность. SpacePen. Слышал про такое - русские писали в космосе карандашами, а в штатах тратили бешеные ресурсы на создание пишущей ручи. Образно выражаясь я пишу карандашом и мне вполне хватает, а ты надрываешься чего ради? Чтобы сделать всё то же самое более завёрнутым способом? Или ты профессиональный разработчик? Настолько профессиональный, что работаешь где-нибудь в запредельной сфере вроде разработки авиационных навигационных систем. И считаешь С++ недоязыком. Так - да? Ну-ну. Обычно такие люди не тратят своё время на то чтобы в _грубой_ форме воевать на форумах. Я не думаю что ты вообще в состоянии написать хоть что-либо жизнеспособное на тех языках что ты упомянул. Доказать сможешь? Может у тебя где-нибудь на SourceForge есть своя страничка? Не? Нету? Поэтому соси мой USB, ты понял о чём я, да.

eg0_dist0rti0n
()
Ответ на: комментарий от eg0_dist0rti0n

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

http://catb.org/~esr/writings/unix-koans/ten-thousand.html

Legioner ★★★★★
()
Ответ на: комментарий от eg0_dist0rti0n

> Не? Нету? Поэтому соси мой USB, ты понял о чём я, да.

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

Cris
()
Ответ на: комментарий от eg0_dist0rti0n

> Доходчиво - это значит несколько раз повторить, что есть языки кроме С++, и тот кто их не рассматривает в качестве приемлимых - тот наипоследнее чмо?

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

> А ты посмотри на ситуацию с другой стороны: для решения тех задач которые вставали передо мною (в своё время это были нейросети), мне С++ хватило за глаза.

Это ТЫ так считаешь. По незнанию. По скудоумию. Ты не догадываешься, насколько лучше и эффективнее ты бы эти задачи мог решить, если бы не пользовался C++. И не желаешь знать, что характерно.

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

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

> Чтобы сделать всё то же самое более завёрнутым способом?

Всё то же самое я делаю гораздо, неизмеримо проще и быстрее чем ты.

> Или ты профессиональный разработчик?

Да, профессиональный. Уже лет 13 как профессиональный. А что, тут ещё и непрофессиональные неразработчики высказаться посмели?

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

Зачем навигационных систем? Компиляторы экзотических языков под экзотические платформы, инженерные CAD-ы, data mining, визуализация научных данных, кое какие финансовые приложения, задачи оптимизации, экспертные системы и некоторые другие приложения искусственного интеллекта. Ничего запредельного.

> И считаешь С++ недоязыком. Так - да?

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

> Обычно такие люди не тратят своё время на то чтобы в _грубой_ форме воевать на форумах.

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

Вот здесь, например, вопрос задал новичок. Человек ещё не испорченный. Хорошие и умные люди ответили ему, почему не стоит любить C++, и почему он обязательно должен ознакомиться с альтернативами. Плохие, глупые и подлые люди (в том числе и ты) начали по глупости своей с умными спорить, бедного новичка запутывая окончательно. Ты все еще считаешь, что ты не заслуживаешь грубости?

anonymous
()
Ответ на: комментарий от Macil

>Теперь про ООП.

>Вооще, как такового определения ООП, в отличие от ФП нет. Каждый производитель языка и каждый программист понимает данный термин по-разному.

Хм, что за!? http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented вот же есть определение. http://c2.com/cgi/wiki?ObjectOrientedProgramming

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

> Вот здесь, например, вопрос задал новичок. Человек ещё не испорченный. Хорошие и умные люди ответили ему, почему не стоит любить C++, и почему он обязательно должен ознакомиться с альтернативами. Плохие, глупые и подлые люди (в том числе и ты) начали по глупости своей с умными спорить, бедного новичка запутывая окончательно. Ты все еще считаешь, что ты не заслуживаешь грубости?

+100

Cris
()
Ответ на: комментарий от eg0_dist0rti0n

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

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

> справится с ним проще, при прочих равных условиях, если всё делалось изначально именно в плюсах. А если такой же запрос поступит для некого "решения" в Дельфи, то попа будет гораздо более полная.

Т.е. твои знания заканчиваются на C++ и Delphi? И ты думал, что я, например, хаю C++ в пользу Delphi? Удивительно, как превратно может один человек понять другого. Все, что я говорил о C++ применимо и к Delphi тоже.

watashiwa_daredeska ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.