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)

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

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

На си. Сейчас хочу попробовать как раз руст, он декларирует совместимость c/++ по вызовам и умеет шаред обжекты. Рубисту вполне удалось это - http://brson.github.io/2013/03/10/embedding-rust-in-ruby/

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

ну раз для тебя это «факт», то расскажи, откуда ты знаешь, на чём оно написано, ну и пруфы конечно.

Можешь начать отсюда: http://en.wikipedia.org/wiki/NoSQL

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

Может ты хотел сказать «нет ничего лучше»?

Нет - вообще ничего нет пока. Отсутствует. Over9000 - это то откуда плюсы уже вытеснили или где его никогда не было.

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

Ты можешь повторять эту мантру сколько угодно.

Ты можешь повторять эту мантру сколько угодно.

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

Ну, меня тоже позабавил оптимизм Саттера, особенно про «continue to make C++ more accessible». Но в общем он прав - насовсем плюсы не уйдут. Их всего лишь вытеснили оттуда, где без них можно обойтись; но есть задачи, где альтернатив просто нет.

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

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

Вот вот. Точная фраза. Не потому что «хорош» а потому что альтернатив нет. Необходимость альтернатив назрела.

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

Да, у Саттера инфа верная на 146%. Как же артистам то и финансистам в наше время без плюсов прожить. Все ломанулись на курсы по плюсам.

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

Необходимость альтернатив назрела.

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

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

Так может быть «альтернатива» будет просто еще одним С++?

Не будет. Потому что нет такой необходимости.

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

Именно это я и думаю.

они же и дают С++ то, что делает его незаменимым(пока)?

А вот тут не так. Никто особенно не прилагал целенаправленных усилий заменить его. Усилия прилагались на полную его изоляцию в прикладной сфере путем создания совсем других языков - питонорубижабанеты. D хотел создать просто лучший c++ и потому не нужен. То есть целенаправленные попытки его заменить - еще только начинаются. То же смое с си. LLVM тут будет хорошей платформой.

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

Не будет. Потому что нет такой необходимости.

Я верю в эволюцию и естественный отбор. Если С++ столько успешно времени существует, то это не просто так.

Никто особенно не прилагал целенаправленных усилий заменить его.

Значит, никому это особо и не нужно.

То есть целенаправленные попытки его заменить - еще только начинаются

Пока что-то не видно ничего. Раст все же не полноценен.

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

LLVM тут будет хорошей платформой.

Ты тупой? LLVM это самая что и есть С++ платформа. Альтернативы плюсам пока нет и вряд ли будет.

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

Я верю в эволюцию и естественный отбор.

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

Пока что-то не видно ничего. Раст все же не полноценен.

В чем же его неполноценность?

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

Ты тупой? LLVM это самая что и есть С++ платформа.

facepalm

В настоящее время ее можно полноценно использовать только из плюсов.

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

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

Я вижу, что он уходит из сферы гуи-софта. Для меня же сама эта сфера была небольшой и ненужной. Еще он мало захватил из НОВОЙ ниши мобильных развлекательных платформ(хотя и там он есть, что удивительно, а когда Qt будет полноценен для мобильных платформ, я думаю будет всплеск интереса).

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

В чем же его неполноценность?

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

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

когда Qt будет полноценен для мобильных платформ

все будут хуячить на Qt Quick

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

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

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

Ошибки рантайма - самые страшные.

что доказать-то хочешь? Что биться головой апстену больно и не нужно? Даже в каске? Или что каска не нужна?

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

В настоящее время ее можно полноценно использовать только из плюсов.

Там код написан if (!frontend(c++)) llvm->do_glucks()?

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

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

Не будет. Под любой противоестественной для платформы гуйней занимаются только энтузиасты или в специфических случаях - ка кнапример жабская гуяня для жабских IDE когда есть ясное преймущество. «Это не наш случай».

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

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

А писать на чистой сишечке мазохистов мало.

Все эти мазахисты как раз сосредоточены в прошивках.

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

Это не так. Там можно делать свои аллокаторы.

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

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

Короче, язык, компилятор которого не может толком верифицировать твой код, не нужен.

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

Зашитая в язык строгая модель памяти

И это хорошо.

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

Например? Какие именно алгоритмы невозможно реализовать на raw pointers?

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

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

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

Например, мне удобно в своей библиотеке для 3д графики с SSE/NEON использовать операторы. Я знаю, что у меня есть типы Vector4f, Vector4i, Matrix4f, Matrix4i и для них определены операторы и методы. Никаких виртуальных типов там нету, plain old data проверенная static_assert(std::is_pod<t>::value);

в итоге операторы удобнее и эффективнее и читабельнее.

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

И к слову, ядро на с++ писать можно.

кто-то говорил, что там нельзя использовать конструкторы но это бред. fglrx их использует и в ядре икспишки работал. в ядре нельзя использовать exceptions, rtti (их там нет), и обычный new. вместо new надо выделять память самому и потом если не NULL, делать placement new. можно делать это макросом. И всё, С++ в ядре работает. Нужно ошибку из конструктора возвращать - передаем int& error_code во все конструкторы и смотрим, не метнул ли кто-то туда ошибку.

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

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

Из того что ты перечислил на C++ только игры и продолжают писать

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

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

Не надо тут путать с си. Прошивки пишут на сях

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

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

Именно для замены. И всё-таки что нельзя сделать на raw pointers?

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

Ты не поверишь, но многие «прошивальщики» только сейчас начинают переходить на С++.

О каких «прошивальщиках» вообще речь ?

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

Пишут и на Си, и на С++. Причем некоторые переходят с сей на плюсы.

Это все мышиная возня - некоторые и на асме до сих пор пишут. В основной массе все равно С.

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

Ну маршрутизаторы там всякие, софтсвичи и пр.

Какая-то узкая ниша. На С++ видел конечно для процессоров загрузчики, но прикол - исходники есть но завязаны на венду и чтобы перенести на другую ОС там надо все переписывать нахрен. Другой пример - программаторы на tcl/tk, работает практически без переработки на любой платформе - написали один раз и забыли. Выбирать как говорится вам :)

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

А ты как данные пересылаешь? Строками? Были ли попытки заюзать ei? Я попытался разок, неплохо получается. Очень удобно со стороны сервера. binary_to_term и у тебя готовый терм для матчинга.

Может у тебя есть проекты на гитхабе? Дай ссылки если можешь.

Спасибо.

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

А ты как данные пересылаешь? Строками?

Бинарями.

Были ли попытки заюзать ei?

Пока нету.

Может у тебя есть проекты на гитхабе?

proprietary. Чуть позже кое что появится.

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

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

ну и кто спорит? Конечно исключение в рантайме хуже ошибки компиляции. Но сегфолт и/или дыра ещё хуже.

Короче, язык, компилятор которого не может толком верифицировать твой код, не нужен.

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

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

в итоге операторы удобнее и эффективнее и читабельнее.

и с этим я согласен. А вот с Линусом — не согласен. И тем не менее, ядро пишет он, а не я (:

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

И к слову, ядро на с++ писать можно.

можно конечно.

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

бред.

в ядре нельзя использовать exceptions, rtti (их там нет), и обычный new. вместо new надо выделять память самому и потом если не NULL, делать placement new. можно делать это макросом. И всё, С++ в ядре работает. Нужно ошибку из конструктора возвращать - передаем int& error_code во все конструкторы и смотрим, не метнул ли кто-то туда ошибку.

можно это всё. Я и не спорю. Тут вопрос «почему Линус против?».

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

И ты правда видишь, что это чем-то круче С++ и может его заменить?

Заменить что? Это пример что с памятью можно играться как угодно. Можно оставить ее GC можно с помощью raw pointers страдать фигней самостоятельно. Страдать фигней при эотм надо когда без этого ну никуда. А не всегда. Так что таки да - машина дужна работать а человек думать. При чем человек должен думать над прикладной задачей, а не как заставить машину - таки работать.

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

Это пример что с памятью можно играться как угодно.

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

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

можно это всё. Я и не спорю. Тут вопрос «почему Линус против?».

он с++ не осилил, как и проц который разрабатывал - просрал

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

можно это всё. Я и не спорю. Тут вопрос «почему Линус против?».

он с++ не осилил, как и проц который разрабатывал - просрал

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