LINUX.ORG.RU

Какое же говнище этот ваш С++

 


11

7

Решил намедни углубить свои знания по плюсам, чувствуя, что скоро нехило так потребуются по работе. Теперь сижу, обмазываюсь тут всякими трупами страусов, Скоттом Майерсом и другими. Г-пди, как же можно на этом писать, особенно после знания божественных лиспов, хаскелей и прочих матанских агд (sic!). Это какая-то пытка, честное слово, мне натурально мерзко и противно читать как люди пытаются вырезать гланды через задний проход да ещё и хвалятся этим, поглядите, мол, как это круто. Такое ощущение, будто плюсисты все поголовно латентные мазохисты.

template <typename T>
class Rational
{
    public:
    ...
    friend const Rational operator*(const Rational& lhs, const Rational& rhs)
    {
        return Rational(lhs.numerator() * rhs.numerator(), // same impl
            lhs.denominator() * rhs.denominator()); // as in Item 24
    }
}

An interesting observation about this technique is that the use of friendship has nothing to do with a need to access non-public parts of the class. In order to make type conversions possible on all arguments, we need a non-member function (Item 24 still applies); and in order to have the proper function automatically instantiated, we need to declare the function inside the class. The only way to declare a non-member function inside a class is to make it a friend. So that's what we do. Unconventional? Yes. Effective? Without a doubt.

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

Перемещено mono из talks

★★★★★

Последнее исправление: mono (всего исправлений: 1)

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

Заменить что? Это пример что с памятью можно играться как угодно. Можно оставить ее GC можно с помощью raw pointers страдать фигней самостоятельно.

ты тут довольно много написал, и не только ты. Повтори ещё ссылку на этот твой raw pointers, и объясни тормозу, чем он лучше перезагруженного new?

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

очевидно, что такие

Для плюсистов норма называть tcp/ip «прошивальщиком» :) прошивальщик там jtag + openocd, посмотри кстати на чем он написан.

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

А я не агитирую за Бейсик. Посмотри теги в моем профиле

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

И да, осиль цитирование. Это не личная переписка. Тут много народу.

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

Ага, при этом это не интегрировано в язык нормально, как в С++. Т.е. для раста это извращение.

Оно как раз интегрировано правильно - потому что так играться с памятью - это редкое извращение. Ключевое слово - редкое. Именно поэтому оно повсеместно не надо. А в тех редких случаях когда нужно - оно доступно.

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

Повтори ещё ссылку на этот твой raw pointers, и объясни тормозу, чем он лучше перезагруженного new?

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

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

прошивальщик там jtag ... посмотри кстати на чем он написан.

На чем написан jtag ??? ты упоролся ?

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

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

Можно раскрыть мысль, хотя бы тезисно?

(для Ъ: как понимаю, речь об F# и Scala)

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

На чем написан jtag ???

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

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

играться с памятью - это редкое извращение.

Это в прикладном софте. Оттуда С++ рано или поздно итак уйдет. А вот даже в игрушках это вполне нормально. Я уже не говорю о железках, где всегда свои аллокаторы. Да и в серверной хрени те же задачи.

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

Вот как раз тем что эти равпоинтеры - это крайний редкий случай. То есть вынесен именно туда куда надо - в дальний сарай.

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

Кстати, если я сделаю свой аллокатор в расте, я смогу пользоваться стандартной библиотекой и пр.?

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

А вот даже в игрушках это вполне нормально.

Если в программе для полутора объектов надо поиграться с памятью - это не значит что для остальных стопицот объектов это тоже надо. В том то и суть. Стопицот объектов будет забоксено, а поизвращаются только с полутора.

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

И да, осиль цитирование. Это не личная переписка. Тут много народу.

Осилю )

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

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

В каком месте Scala - Бейсик?

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

точно так же, как в с++ большинство объектов будут на стеке, под управлением unique_ptr и shared_ptr(с редкими weak_ptr).

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

Ты так говоришь, как будто в С++ «играться» с памятью нужно всегда.

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

Я уже не говорю о железках, где всегда свои аллокаторы.

Смотря что называть «своим аллокатором».

Да и в серверной хрени те же задачи.

В Яве вообще нет средств, чтобы написать аллокатор, и при этом она является самым распространенным серверсайд-языком.

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

и при этом она является самым распространенным серверсайд-языком

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

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

распространенность мало о чем говорит

Она говорит о том, что инструмент выполняет свою задачу.

Т.е. время разработки, легкость поддержки, громкие слоганы, «надежность»(не по факту, а как реклама), простота замены кадров.

Всё развитие SE - это уменьшение времени разработки и облегчение поддержки.

А мы тут вроде о программировании.

http://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_...

В programming-in-the-large Ява вполне себя зарекомендовала. Насчет programming-in-the-small - недавно в Development был топик «как переписать с Си++ на Яву, чтобы не тормозило».

Впрочем, топик-то не о Яве. Rust как эволюция языка системного программирования - это признание факта, что прогресс (аппаратные ресурсы и компиляторные технологии) изменил tradeoff-ы так, что трюки, характерные для Си++ 80-90-х годов, сейчас не нужны. Да, с использованием этих трюков можно написать более эффективную программу, но увеличение эффективности уже не окупается усложнением разработки.

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

Видно, что си потерял ещё больше.

если си потеряет вообще тенденцию, ты потеряешь работу, компУтер, и интернет потому что на горизонте в ближайшие миллион лет не видно _н_и_о_д_н_о_й_ ОС которая набирает обороты на одном из хваленых языков типа java,haskell,go,rust, и им подобных унылых ненужных отбросах

зы и все остальные словоблудники в этой теме, прежде чем рассказывать о своих хваленых языках не забывайте какую ОС вы сейчас используете, и на каком языке она написана, почти большая часть линукса на asm+СИ, ядро виндовс asm+СИ+С++

anonymous
()

Г-пди, как же можно на этом писать, особенно после знания божественных лиспов, хаскелей и прочих матанских агд (sic!).

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

m0rph ★★★★★
()
Последнее исправление: m0rph (всего исправлений: 1)
Ответ на: комментарий от m0rph

Программирование - это ремесло, если ты здесь ищешь науку, то ты видимо делаешь что-то не то.

Ничего личного, но УБИВАТ за такие слова. И да, бомбануло.

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

Rust как эволюция языка системного программирования - это признание факта, что прогресс (аппаратные ресурсы и компиляторные технологии) изменил tradeoff-ы так, что трюки, характерные для Си++ 80-90-х годов, сейчас не нужны.

Такие заявления еще рано делать. Посмотрим на полет Rust'а. Я, например, пока не вижу плюсов от перевода плюсовых проектов на Rust. Небольшие новые, может быть, попробую. Но пока не вижу чего-либо, что даст какие-то преимущества по сравнению с С++.

А другим языкам Rust вряд ли является конкурентом. Разве что так же еще не взлетевшему Go.

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

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

+100500

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

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

Может, кстати, кто-нибудь расскажет в паре предложений?

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

Я, например, пока не вижу плюсов от перевода плюсовых проектов на Rust

Перевод? O_o Никто не говорит об этом.

А другим языкам Rust вряд ли является конкурентом

ИМХО, помимо Си и Си++, Rust конкурент всему серверсайдному. Конкурент пока хреновый за отсуствием библиотек, но кто знает, как повернется дело.

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

В Rust очень ограниченные возможности метапрограммирования и обобщенного программирования. В текущем варианте C++ оно, конечно, имеет вырвиглазный синтаксис и неудобно в использовании (нет отладки, сложные сообщения об ошибках). Что-то большое на нем написать и сопровождать — это вызов. Но кто осилил, тот понимает, что такое настоящий С++.

Претензии к С++ касаются, в основном, устаревшего уже стандарта С++03. Этот вариант языка, действительно, ужасен. Единственное, что побуждает программировать на нем — это ручное управление ресурсами, возможность ручных оптимизаций, легкий доступ к оборудованию, быстро появляющаяся поддержка новых моделей вычисления и т.п.

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

Диагностика ошибок в clang выше всяких похвал. Сlang всё еще выдает многостраничные простыни для шаблонного кода, но эти простыни хорошо структурированы и аннотированы. Читать их не сложнее, чем читать stack trace JVM. Считаю, что эта проблема решена.

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

Облегченные концепты будут в следующих версиях стандарта, это сильно упростит «большое» метапрограммирование.

Так что ребята, пока вы тут соревнуетесь в неосиляторстве и ищете замены для С++, язык стремительно развивается. Саттер на GN'13 говорил, что работа комитетов стандартизации языка резко ускорилась в последнее время. А производители компиляторов уже соревнуются, кто быстрее и точнее начнет поддерживать нововведения стандарта.

Rust имел бы смысл, если бы C++ не развивался. Разработчики Rust ставят перед собой целью создать первоклассный язык для параллельного программирования, но точно такую же цель ставят сейчас себе и «отцы» C++. И у них получается. Просто работа идет относительно медленно из-за груза гигантской унаследованной кодовой базы, которую нельзя ломать.

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

вы все так говорите о С++, только есть один ньюанс сам язык С++ и его вспомогательные библиотеки, типа std:: и внешние аля boost и прочих, так вот сам язык С++ прекрасен, и пренетзий к нему нет вообще, хают его и не осиливают именно из за этих библиотек к которым у меня такое же отвращение как и у других

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

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

Хороша гонка - http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ Или Intel с M$ в гонке не участвуют?

Разработчики Rust ставят перед собой целью создать первоклассный язык для параллельного программирования

Это только одна из целей. Первая (и более важная, ИМХО) - сделать язык, «безопасный по умолчанию».

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

...так вот сам язык С++ прекрасен, и пренетзий к нему нет вообще, хают его и не осиливают именно из за этих библиотек к которым у меня такое же отвращение как и у других

Всё верно. С библиотеками была проблема именно из-за недоделанного метапрограммирования. Проблему осознали уже давно и пытались решить через концепты, но в предложенном виде их не осилили. Старуструп предложил облегченную версию концептов, которой должно хватить для радикального изменения ситуаций с библиотеками. Микрософт грозится её реализовать в 2014-м, gcc и clang пока помалкивают.

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

Саттер (или Страуструп?) на GN'13 говорил, что у них есть намерение сделать С++ лучшим языком для библиотек. Судя по тому, что в этом направлении уже сделано, и что сейчас делается (например, начальная поддержка моделей уже есть в clang), у них всё может получиться.

Смотреть надо в будущее, время пролетит незаметно. Пока что никто, кто хотел сделать «лучший с++» особого успеха в этом не добился. И для этого есть объективные причины.

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

Хороша гонка - http://cpprocks.com/c11-compiler-support-shootout-visual-studio-gcc-clang-intel/ Или Intel с M$ в гонке не участвуют?

Да, претензия по существу.

Я могу здесь пересказать часть тезисов Саттера из его доклада на GN'13, но боюсь переврать. Так что лучше смотри сам, он обстоятельно говорит о том, что было раньше и что изменилось сейчас в развитии языка. Говорит с графиками и конкретными числами.

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

А пока что да, MS в плане поддержки С++11 сильно отстает, потому что им пришлось свой компилятор почти полностью переписывать для поддержки некоторых вещей.

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

Это прекрасно, но на гонку похоже мало

я б тоже не назвал это гонкой

Разве что это гонка тормозов.

а вот тут не согласен, С++11 привнес очень много нового, и его реализация проходит очень быстро, и кстати благодаря ему, тот же M$ поддержит, наконец, С99

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

Пока что никто, кто хотел сделать «лучший с++» особого успеха в этом не добился.

Я бы не назвал Rust «лучшим Си++», так же, как Си не был «лучшим PL/I» (да, на PL/I тоже писались ОС).

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

Я бы не назвал Rust «лучшим Си++»,

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

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

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

есть намерение сделать С++ лучшим языком для библиотек

Имеется ввиду только для source level библиотек или уже и стандарт на ABI намереваются сделать?

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

Имеется ввиду только для source level библиотек или уже и стандарт на ABI намереваются сделать?

Об этом, к сожалению, речи не было. Но кое что я сам нарыл в исходниках clang.

В первую очередь нужно понимать, что метапрограммирование (на что опирается С++) и ABI — вещи ортогональные. Пре-инстанцированные шаблоны есть уже сейчас, но пользоваться ими без дополнительных инструментов не представляется возможным. Впрочем, инструменты эти совсем не сложные.

Важнее другое. Библиотеки «тормозят», много не наподключаешь. И вот как с этим собираются бороться.

Clang поддерживает прекомпилированные исходники в виде бинарного AST. Причем формат этот очень гибкий и представляет из себя что-то типа функциональной базы данных. Несколько файлов AST могут объединяться в цепочку, при этом может происходить подмена определений. Компилятор не нужно загружать весь прекомпилированный исходник в память, он читает только нужные ему фрагменты определений.

И вот над этим всем хозяйством в clang собираются сделать систему модулей, которая решит 99% самых вопиющих проблем библиотек в С++. Модули в clang смогут существовать в прекомпилированном виде, это здорово ускорит компиляцию в условиях большого количества библиотек.

Как с прекомпилированными исходниками в gcc, я не знаю.

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

И какие компиляторы его придерживаются? Можно ли в плюсовом проекте смешивать библиотеки, собранные разными компиляторами?

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

Можно ли в плюсовом проекте смешивать библиотеки, собранные разными компиляторами?

Можно, если эти компиляторы поддерживают единый C++ABI. Например, gcc и clang прекрасно дружат. На счет Intel ничего не знаю. С виндой есть проблемы, там ABI немного другой. Mingw с VC линковаться по дефолту не будет. Но, вроде бы, есть инструменты, которые и это лечат.

Куда серьезнее проблемы линковки с различными CRT в той же винде.

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от kamre

И какие компиляторы его придерживаются?

ЕМНИП, GCC и Intel (изначально это был Itanium C++ ABI). Но само наличие стандарта не гарантирует его поддержки.

Можно ли в плюсовом проекте смешивать библиотеки, собранные разными компиляторами?

На Linux только один компилятор, так что ХЗ :) А на венде, если верить SO, MSVC сам с собой несовместим: http://stackoverflow.com/questions/11682748/is-clang-abi-same-as-g

tailgunner ★★★★★
()

Автор молодца, Си крут как никогда, а вообще судя по высказываниям, ассемблер вечен =\

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

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

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

Ну да, ему уже всё объяснили в коментах.

Интересно, мы когда-нибудь увидим действительно годный критицизм С++? Получается, что что-то лучше в haskell, что-то — в D, что-то прекрасно сделано в Go, а что-то намереваются довести до идеала в Rust. Но так, чтобы было всё в одном, пусть и далеко не в идеальном, но вполне годном виде, то это С++.

Может я не прав?

aist1 ★★★
()
Последнее исправление: aist1 (всего исправлений: 1)
Ответ на: комментарий от aist1

Ну да, ему уже всё объяснили в коментах.

Что «всё»? В комментах сказали ровно две разумные вещи - нужно следить за локальностью данных и использованием кэша, и то, что иногда в задачах возникают сложные разделяемые структуры.

Но так, чтобы было всё в одном, пусть и далеко не в идеальном виде, то это С++

Это называется kitchen sink syndrome.

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