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)

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

плюсам пошёл 4й десяток, в плюсах появились лямбда-функции

Преимущества лямбд над обычными плюсовыми функторами не очевидны. Просто синтаксический сахар для функций типа сравнения в одну-две строчки

Gvidon ★★★★
()

Ну... да. А что сказать-то хотел?

Miguel ★★★★★
()
Ответ на: комментарий от yu-boot

Я наоборот, не могу вообразить разумного применения ООП где-то кроме GUI.

ООП в GUI хорошо только из-за легаси.

Miguel ★★★★★
()

А ведь предупреждали

нефиг было про хаскели читать, если ц++ в планах.

почему нельзя всё было сделать по-человечески

1. в то время ещё не знали, как можно, или, что более вероятно, 2. а может и нельзя было так сделать как нужно по аппаратным(сначала) экономическим(позже) или ещё каким причинам.

DonkeyHot ★★★★★
()

мёртвородженный язычок.

Этов школе так про твои сочинения говорят?

druganddrop-2 ★★
()
Ответ на: А ведь предупреждали от DonkeyHot

1. в то время ещё не знали, как можно, или, что более вероятно, 2. а может и нельзя было так сделать как нужно по аппаратным(сначала) экономическим(позже) или ещё каким причинам.

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

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

В моей области замена разных лол-деревьев на тупые линейные массивы всегда даёт буст к скорости и к простоте кода. Если же вам аж кушать нельзя как нужны деревья - то C/C++ плохой выбор. Поскольку это ассемблер.

ranka-lee
()
Ответ на: комментарий от buddhist

Назовите где ещё можно применить ООП. Кроме как в GUI. Видеоигры например давно от него отказались, там Entity-Component, тупые POD-структуры и #ifdef вместо разных IRenderDevice.

ranka-lee
()
Ответ на: комментарий от Miguel

Посмотри на историю с концептами. [...] Трупостраус зарубил.

Вранье. Предложение Страуструпа было отклонено комитетом.

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

Назовите где ещё можно применить ООП. Кроме как в GUI

Почитай что-нибудь об АТД (которые абрстрактные типы, не алгебраические). Или, если позволяет интеллект, посмотри на Sage.

Видеоигры например давно от него отказались, там Entity-Component, тупые POD-структуры и #ifdef вместо разных IRenderDevice.

«Давно» - это когда? В той самой презентации Суини ООП вполне было.

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

тупые POD-структуры

Вы так говорите, будто на «тупых POD-структурах» нельзя организовать ООП. Почти все виденные мной проекты на С в той или иной мере используют принципы ООП и как-то не слишком страдают по этому поводу

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

Вранье. Предложение Страуструпа было отклонено комитетом.

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

Я говорю о ДРУГОМ предложении.

Miguel ★★★★★
()
Ответ на: комментарий от ranka-lee

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

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

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

Отсортировать вектор из 100к объектов - нарушает все нормы киотского протокола по выхлопу СО2 с процессора.

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

И да, вектор даже с копированием на практике быстрее списка (при небольшом кол. ве элементов, до полу миллиона)

invy ★★★★★
()
Ответ на: комментарий от ranka-lee

Например, мне понадобилось ООП в моделировании каскадов ректификационных колонн. Без него выходит совсем наколеночный костыльный ад.

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

Да о чём ты ему рассказываешь. У него с++ — ассемблер. О чём тут можно рассуждать.

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

Двоечник. Ты - канонический неосилятор.

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

Ты вообще представляешь, как устроен вектор? Может быть ты путаешь вектор со списком?


Я не вижу решения от маэстро. K-размерное пространство (k=25) из 100к элементов. Вперед.

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

По существу будет что сказать?

Я не вижу решения от маэстро. K-размерное пространство (k=25) из 100к элементов. Вперед.

42

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

Как только ты введёшь линейную упорядоченность в 25-мерном пространстве

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

А вообще типичный ответ - большего я и не ожидал.

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

По существу будет что сказать?

По какому существу? В твоем выхлопе было какое-то существо?

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

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

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

А я понял. Сишком переоценил. Не парься. Иди уроки учи тоже.

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

Да, я тебя спросил, знаешь ли ты, что такое вектор и как он устроен?

Я знаю как устроен вектор. Теперь открой сокраметализм что не так с сортировкой векторов.

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

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

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

Там все упорядочено

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

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

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

Я тебе предложу посмотреть в чем разница между list::begin и vector::begin, а так же на сигнатуру std::sort. И подумать почему так.

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

В общем виде сортировка множества элементов 25-мерного пространства не решается,

И эти люди мешают мне ковырятся в носу...

Там вверху дан тебе учебник.

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

Судя по всему тебе всё ещё нечего сказать. Либо отвечай на поставленный вопрос либо «слив засчитан».

invy ★★★★★
()

Живой не может быть мертворожденным.

Вообще ты действительно просто не осилил, да.

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

Ну это для вектора просто невозможно. Элементы лежат последовательно в памяти. Если надо поменять местами, то как не крути - только копировать. А так да или вектор указателей или список.

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