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)
Ответ на: комментарий от ranka-lee

Ниасиляторы и используют не по назначению.

сколько дебилов вокруг, как страшно жить... умри, нуб!

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

C++ это лучшее что сейчас есть, просто по тому, что у вас нет мозга

okay

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

Где еще нужен верифицируемый в рантайме байт-код?

Ты это - телефоны видел? И в перспективе именно то для чего жабу клепали - телевизоры и прочие хрени?

Либо реализации неудачные, либо сама идея AOT-компиляции для Java себя технически не оправдывает.

Никому нафиг не нужно - вот и все.

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

Совершенно верно! Только в каких пропорциях? Я думаю, 1 к 9 JIT к AOT.

Особенно для всяких телевизоров.

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

Ты это - телефоны видел?

Ты J2ME имеешь в виду?

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

Шикарно! Я программирую высоконадежные сервера на платформе, предназначавшейся для телевизоров и всякой прочей хрени. Это еще комедия или уже фарс? :)

Никому нафиг не нужно - вот и все.

Скорее не так. Там, где AOT на практике нужен, Java как платформа оказалась несостоятельна. Я имею в виду настольные приложения. И дело было не в HotSpot.

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

Особенно для всяких телевизоров.

Для телевизоров - и подавно.

aist1 ★★★
()

Негде программистам выговориться.

Всё скинули в кучу, сравнивают C++ и Haskell, другие считают что python это самое лёгкое что может быть.

C++ действительно ассемблер. Нет модульности в языке. Макросы подстановки текста.

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

tp_for_my_bunghole
()

C++ правильнее всего сравнивать с Object Pascal, и последний по всем параметрам лучше кроме оптимизации кода в существующих компиляторах.

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

С каких пор он в составе платформы?

А какое это имет значение?

Ты J2ME имеешь в виду?

Нет - андроед в том числе.

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

Нет - на платформе которая может обеспечивать и сервера и телевизоры. В серверах тоже есть песочницы.

Я имею в виду настольные приложения.

Есть куча тулзов где джава настольная. А большинство популрных настольных приложений или исторически сложившуюся платформу имеют или могогамныё отношения с окружением - вроде гномов и кед. Жаба не сильно встраивалась в различные окружения потому что доминировала идея переносимости. Там где эта идея доминируеь (банковские клиенты например), или инструмент предоставляет нетривиальный функционал - например IDE - жаба вполне себе живет на десктопе. А ноутпады на ней не пишут - это да.

Для телевизоров - и подавно.

Для телевизоров не в смысле эмбеддеда а в смысле приложения третьих лиц которые должны работать в песочнице.

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

А какое это имет значение?

Большое. У меня есть либо AOT, либо JIT. Но ни то, ни другое одновременно. Чтобы я мог сделать прекомпиляцию только статической части приложения.

песочнице.

Ты не те аргументы приводишь. Вот история с виртуальной машиной HipHop для PHP. Сначала они сделали именно транслятор с PHP на C++. Но потом задолбались с отладкой и сопровождением такого решения. И приделали JIT.

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

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

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

У меня есть либо AOT, либо JIT. Но ни то, ни другое одновременно. Чтобы я мог сделать прекомпиляцию только статической части приложения.

Есть же Excelsior JET:

Using the Excelsior JET Optimizer, you convert the classes into highly optimized native x86 or x64 code and create a conventional executable for Windows or Linux. This technique is called Ahead-Of-Time (AOT) compilation.

The Excelsior JET Runtime includes a JIT compiler that transparently loads Java classes to the running application.

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

Я думаю стоит добавить аргументов.

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

Достаточно посмотреть как реализованы Units во Free Pascal, и подумать почему 20 лет назад это не появилось в C++.

Попробовать скомпилировать KDevelop для C++, и Lazarus с самим компилятором Free Pascal. Совершенно разные ощущения.

Тривиальность парсинга синтаксиса Object Pascal. Один проход, все конструкции однозначны.

C/C++ всегда вызывают непреодолимое желание использовать скриптоту. В Object Pascal принято написание unit'a и моментальная перекомпиляция.

Ассемблерные финкции и ассемблерные вставки в Object Pascal как часть синтаксиса.

Разные конвенции передачи параметров в функции, на уровне ассемблера. В C обратный порядок передачи параметров, это связано с возможностью передачи произвольного числа параметров. В Object Pascal это реализовано на основе типов(array of const), но и все C-шные модификаторы деклараций функций доступны(cdecl, varargs).

Object Pascal just makes sense.

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

А библиотеки это дело наживное.

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

В коммерческих играх альтернативы C++ нет. Microsoft вроде бы решил вернуться к C++, a XNA(или как его там) как историческое наследие от продвижения C#.

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

О, они это уже умеют. Ну, чудненько. Спасибо за разъяснение. Жалко, что это не в составе платформы. Ну, кому надо, тот купит.

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

Ты не те аргументы приводишь.

В каком смысле не те?

Но потом задолбались с отладкой и сопровождением такого решения. И приделали JIT.

Для сервера. как ты нативный код ограничишь в песочницу в телевизорах и телефонах?

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

В каком смысле не те?

как ты нативный код ограничишь в песочницу в телевизорах и телефонах?

Песочница тут ни при чем. Организуется она средствами MMU и OS, там, где MMU поддерживается. Т.е. практически везде уже давно. И в телевизорах, и в телефонах.

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

Организуется она средствами MMU и OS,

И это будет уже совсем другая платформа. Про какую-то там переносимость не может быть и речи.

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

На уровне исходников? :)

В том числе. Ты что собственно перенести хотел если ты пермишены в OS запихаешь? И как ты будешь эти пермишены ограничивать если они например....юзерские и ограничивают доступ к другой либе? Или даже не юзерские - а расширяемые - все время ОС переписывать?

Ты по сути споришь с безопасностью апплетов по сравнению с безопасностью плугинов. Плугины делают что хотят. А пплеты только в песочнице итолько с разрешения. В том же андроеде приложения имют безопасность апплетов. Жаба имеет архитектуру построения подобной безопасности. AFAIK никакая OS подобной не имеет. Что призводителям телеков легче - жабаплатформу туда запихнуть или свою ОС пилить?

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

И как ты будешь эти пермишены ограничивать если они например....юзерские и ограничивают доступ к другой либе?

Зачем огораживать библиотеки, если огораживать нужно ресурсы, которые всё равно предоставляются OS? JAAS и JSSE я знаю, если что :)

все время ОС переписывать?

Зачем переписывать OS, если ACL сразу всегда делаются расширяемыми?

AFAIK никакая OS подобной не имеет.

SELinux?

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

Зачем огораживать библиотеки, если огораживать нужно ресурсы, которые всё равно предоставляются OS?

Ограничивать можно так же действия с этими ресурсами и контекст. Нпример не удалять фотографии с тагами «жина» в полнолуние. Жаба вполне позволяет такое ограничивать архитектурно. А что ты можешь на уровне ос?

SELinux?

SELinux это контроль доступа в модели субъект-объект-acl. Для вышеописанной бредовости оно не подходит, по причине того что оно настраивается к объектам для субъектов. Модель хорошая - я в больших проектах такую применял - но она заточена на статические универсальные настройки для разных объектов. В жабе же ты сам себе телемастер - хоть свой секурити менеджер подсовывай если надо.

r ★★★★★
()

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

Если же вы, как программист не хотите вливаться в коллектив, то для вас есть несколько путей развития:

Не хочешь зарабатывать - учи lisp, haskell и прочие «элитные» языки.

Хочешь немного зарабатывать, не выходя из дома - учи php, ruby, python и прочее веб-говно.

Хочешь зарабатывать, иногда выходя из дома - 1С, java, С# и прочее интерпрайз-говно к вашим услугам.

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

А что ты можешь на уровне ос?

То же самое, если организовать вычислимые ACL.

SELinux это контроль доступа в модели субъект-объект-acl.

Это статическая декларативная модель. JAAS позволяет организовать процедурную модель безопасности. Но для песочницы статичных ACL более чем достаточно. Процедурные ACL тоже можно организовать, как ты можешь догадаться :)

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

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

Модульность там ручная, от Си взятая. Кроме того, для ООП программ модульность делается на уровне классов и объектов.

В общем, давай рассмотрим какой-нибудь пример на модульность.

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

Кстати, есть же предложение в стандарт новый, по поводу явных модулей для С++.

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

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

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

То же самое, если организовать вычислимые ACL.

Я не имею ввиду «написать подсистему внутри OS». Написать можно что угодно. Но фреймворка сейчас нет подобного.

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

Но фреймворка сейчас нет подобного.

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

Иными словами, для безопасности приложений ОС предоставляет всё необходимое уже давно. Безопасный же код нужен только для организации песочницы внутри приложений. Как например, в javascript браузерах.

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

Того, что есть, вполне достаточно для простой и не очень песочницы.

Если писать ее на уровне OS. То есть по сути разрабатывать свой андроид. Может когда нибудь дело и упростится - но на сегодняшний момент ставить андроеды или запиливать jvm на arm jazelle попроще для телевизиров чем пилить отдельный линукс.

Как например, в javascript браузерах.

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

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

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

Можно наверно, но почему-то все эти сапры, браузеры, офисы и прочие фотошопы пишут на плюсах.

Вообще, на сколько я знаю, сам Бьярн мало что поимел от того, что создал самый популярный язык общего назначения.

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

Может когда нибудь дело и упростится - но на сегодняшний момент ставить андроеды или запиливать jvm на arm jazelle попроще для телевизиров чем пилить отдельный линукс.

А кто там на андроиде JVM пилит? Dalvik это ни разу не JVM же. Кроме того, всё более-менее производительное на андроиде - нативное. И тоже в общей для всех песочнице.

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

Dalvik это ни разу не JVM же.

С точки зрения программирования - без разницы.

Кроме того, всё более-менее производительное на андроиде - нативное.

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


И тоже в общей для всех песочнице.

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

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

С точки зрения программирования - без разницы.

Ты там ARM + jazelle упоминал. Jazelle с Dalvik не стыкуется никак.

Это не помешало ни флешам ни жабаскрипту ни всему прочему...

Мы уже забыли, с чего начали. А начали мы с того, что без байткода на телевизорах и телефонах не обойтись. Оказывается, прекрасно можно обойтись. Ну, кроме случая барузеров. Apple подтверждает.

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

Не, ну ты даешь! А высокоуровневая VM с JIT-ом и сборкой мусора — это так себе работенка, любой её налабает на коленках.

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

И, наконец, не надо делать SELinux. Этот сервис уже давно есть.

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

Вы для себя неправильно решили. Отлично пишут на С++ в одиночку

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

Ты там ARM + jazelle упоминал. Jazelle с Dalvik не стыкуется никак.

С далвик не стыкуется а с jvm стыкуется.

А начали мы с того, что без байткода на телевизорах и телефонах не обойтись.

Нет мы начали с того сколько это будет стоить.

Оказывается, прекрасно можно обойтись.

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

Apple подтверждает.

Эппл туда запихнул ObjectiveC чтобы обходиться без ++.

А высокоуровневая VM с JIT-ом и сборкой мусора — это так себе работенка, любой её налабает на коленках.

Нет - ею пользуются созавм минимальную инфраструктуру для нее - файлы-файлы-сокеты-линукс.

Не говоря уж о необходимости нативной компиляции под кучи железяк в случае отстутствия абстракции над железом.
Юзера не хотят. Доказано андроидом.

VM гораздо сложнее будет.

VM не надо разрабатывать вендорам железа. Все написано до них.

И, наконец, не надо делать SELinux.

SELinux очень ограничен. С фазами луны там проблемы.

r ★★★★★
()

Мда... Почитал тут. Сколько же на ЛОРе школоты, которая ничего сложнее хеллоуворлда себе и представить не в состоянии - рукалицо. Ещё сравнивают зажигалку с автогеном.

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

Если же вы, как программист не хотите вливаться в коллектив, то для вас есть несколько путей развития:
Не хочешь зарабатывать - учи lisp, haskell и прочие «элитные» языки.
Хочешь немного зарабатывать, не выходя из дома - учи php, ruby, python и прочее веб-говно.
Хочешь зарабатывать, иногда выходя из дома - 1С, java, С# и прочее интерпрайз-говно к вашим услугам.

Паразительная точность в суждениях, в реальном мире все так и есть, поэтому пишу веб и бекенд говно. Еще яваскрипт там есть.

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

Ага, а ты сам-то в кучу не мешаешь ли? :)

Всё бы хорошо с вашим Object Pascal, вот только за begin..end руки оторвать создателю хочется :( как будто на PL/SQL каком-то пишешь ё-моё.

vitalif ★★★★★
()

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

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

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

Копии в общем случае не будет. Смотри в сторону оптимизаций RVO/NVO.

неубедительно звучит, 100% гарантии нет что оно применит NRVO или RVO, хотя по хорошему компилятор должен так сделать, в помощь ему я бы inline добавил.

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