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)

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

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

Мне непонятно что тебе непонятно в утверждении «общий случай в с++ на самом деле частный в реальной жизни». Что в большинстве своем плюсовые объекты живут в хипе. То с++ сейчас работает с точностью до наоборот как надо пользователю.

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

D, Go и каких-нибудь других, о которых мы даже не слышали...

D и Go никогда не были убийцами С++ потому что написаны один любителем С++ Александреску который писал с++ «только правильный» (биг мистейк), а второй человеком который потерялся в восьмидесятых и разрабатывал си с csp. А вот руст дизайнится как отдельная херня исходя из современных задач, а не в виде «правильного с++». У него шансы есть.

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

И это утверждение поддержано... чем?

ДВумя соображениями: софт который 10-15 лет писали бы на с++ сейчас на с+ не пишут. То есть его ниша сжимается. А с точки зрения удобства даже там где его можно бы задействовать - уже точат когда конкуренты. Как под JVM когда-то массово начали фигачить языки - из этой свалки вылезли вполне качественные реализации груви, кложура и скала. Точно так же и с нативом - тренд уже пошел, и вырисовывается вполне перспективный руст. LLVM заматереет еще немножко, и кучи народу бросятся писать свои фронтэнды как это было под JVM и CLR.

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

Ну, отправится десктопная платформа на свалку, и что?

Фота вроде кед и его набора софта станет еще меньше.

а там всё равно ObjC/C/C++.

Нету там «все равно». Все равно там только в игрухах. Тот кто будет игратся во все равно на C++ вылетит с рынка по объективным причинам - не успеет за конкурентами.

И ты правда веришь, что они просто выбросили свой офис, написанный на Си++? %)

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

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

Назови всех поименно.

Что всех? python, ruby, jvm-бейсед семейство, clr-бейсед семейство и т.д.

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

ЛУчше чем С много всего.

Назови всех поименно.

Что всех? python, ruby, jvm-бейсед семейство, clr-бейсед семейство и т.д.

/me медленно выпадает в осадок, кружась крупными хлопьями.

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

а теперь расскажи почему это не проблема.

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

То есть ты не допускаешь что ты в деструкторе напишешь некий код вида thirdparty::release_xpeHb() - а он вдруг кинеть исключение?

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

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

Пусть вызывают - ССЗБ.

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

/me медленно выпадает в осадок, кружась крупными хлопьями.

Что тебе не нравится? 15 лет назад то что сейчас на них пишут - писали на C.

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

Ну вот происходит переход на андроеды и макосы, а там всё равно ObjC/C/C++. Качественный переход такой качественный.

На андроиде под C/C++ код имеют достаточно ограниченное количество приложений, это скорее исключение. На OSX/iOS C++ используется в основном при работе со сторонними библиотеками (да и чего не использовать, он на 100% встраивается в код на Obj-C). На платформах от Microsoft .NET и CLR повсюду.

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

...софт который 10-15 лет писали бы на с++ сейчас на с+ не пишут.

LLVM заматереет еще немножко, и...

Взаимно исключающие предложения.

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

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

В смысле пользуются конструкторами?

Если он может кинуть исключение,

Что угодно может кинуть исключение. Или ты тоже дострочно знаешь все чем пользуешься и вызывая что-то типа new QWindow мамой клянешься что несоздаться он не может?

Пусть вызывают - ССЗБ.

ЧИТД.

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

Что тебе не нравится?

То, что таким образом можно объявить, что Python лучше ассемблера.

15 лет назад то что сейчас на них пишут - писали на C.

Ахаха. 15 лет назад «то, что сейчас на них пишут», писали на VisualBasic, FoxPro, Powerbuilder или подобной мути, ну да ладно.

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

Я не понимаю, что именно ты хочешь сказать. Что Си/Си++/ObjC используется и в Андроедах, и в Макосах? Или что он используется не так широко, как я думаю? Или что?

На платформах от Microsoft .NET и CLR повсюду.

Говорят, на WindowsRT приложения родные. Впрочем, как указано выше, речь о «макосах и андроедах».

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

То, что таким образом можно объявить, что Python лучше ассемблера.

А почему он по твоему появился вообще питон? Нахрен он нуен когда есть ассемблер?

15 лет назад «то, что сейчас на них пишут», писали на VisualBasic, FoxPro, Powerbuilder или подобной мути, ну да ладно.

Всякие FoxPro появились уже тогда чтобы на си это не писать уже тогда.

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

что таким образом можно объявить, что Python лучше ассемблера.

А почему он по твоему появился вообще питон?

Вот честно - мне пофиг. Я было подумал, что пропустил какого-то интересного преемника Си, но речь, прости господи, о Ruby и .NET.

Всякие FoxPro появились уже тогда чтобы на си это не писать уже тогда.

Всякие FoxPro (FoxBase, Clipper, dBASE и прочие 4GL) появились 25-30 лет назад. Не 15.

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

Я было подумал, что пропустил какого-то интересного преемника Си, но речь, прости господи, о Ruby и .NET.

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

появились 25-30 лет назад. Не 15.

Ну и ? Чего ж на правильном си то не писали?

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

Они появились и вытеснили си из везде где он раньше был почти в очень узкую нишу

Еще раз, медленно и печально: «его ниша сжимается» != «не имеет перспективной ниши». Си++ свою нишу занял и конкурентов пока не видно.

Чего ж на правильном си то не писали?

См. выше, только s/Си++/Си/

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

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

Ага, а сервисность делать на С++(бэкенды).

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

В смысле не умеют работать с ресурсами.

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

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

Ага, а сервисность делать на С++(бэкенды).

Да щаз:) Не надо их уж совсем за идиотов держать.

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

Си++ свою нишу занял и конкурентов пока не видно.

Ну а rust чем не конкурент?

Rust еще не существует. Если он выйдет раньше, чем через год, я буду удивлен.

Кроме того, нужно учитывать одну важную вещь - Си++ развивается. Си++11 - это уже совсем не тот Си++, который ты помнишь. А к моменту, когда Rust будет готов конкурировать, ему придется конкурировать даже не Си++11, а с более новой версией.

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

Кроме того, нужно учитывать одну важную вещь - Си++ развивается.

Он добавляет новые фичи. Старые проблемы никуда не деваются.

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

Он не делает «C++ IDE». Он добавляет С++ в AppCode - под эппл есть деманд такой поддержки. Это не потому что C++ а потому что иначе они не покрывают рынок эпловых девелоперов с обжектив-с - трудно конкурировать с XCode без этой поддержки. Вынужденная мера.

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

И вообще жетбрейнс написали классный продукт - глупо не использовать его если есть хоть какой-то рынок.

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

Он не делает «C++ IDE»

Вроде как раз отдельная от AppCode кроссплатформенная IDE будет.

Это не потому что C++ а потому что иначе они не покрывают рынок эпловых девелоперов с обжектив-с - трудно конкурировать с XCode без этой поддержки.

Для MSVS в Resharper еще раньше выпустить обещали, тут XCode/AppCode вообще ни причем.

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

Си++ развивается.

Он добавляет новые фичи. Старые проблемы никуда не деваются.

«Старые проблемы» отчасти решаются, отчасти становятся известными и перестают быть проблемами (как тот фрагмен кода, что ты привел).

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

а теперь расскажи почему это не проблема.

А ви таки хотели бы, чтобы деструктор X в этом случае не вызывался? Ви таки уверены, что так было бы лучше?

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

О, у си++ еще остались поклонники?

Синдром утенка же.

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

Копирование в плюсах это особенность реализации.

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

вот именно. Копирование — это как ты сделал. А ты — никак не сделал.

Пользователю в большинстве случаев так неудобно

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

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

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

Мы о языке говорим.

А я думал, что об управлении памятью.

а я думаю, что для r это одно и то же.

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

То есть по твоему запихнуть список простых обёктов на стеке в вектор - это не самая простая реализация?

STL == одна из реализаций. Это тебе так сложно понять?

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

нет. Я же привёл даже пример.

Чего - создания типов?

я тебе привёл пример, что в C++ ты можешь сделать _свой_ Integer сбиш. Со своими правилами, какими захочешь. Потому утверждать, что «в C++ плохо копируется int» — просто глупо. Не нравится? Сделай свой, который будет копироваться «хорошо». Указателей это тоже касается: (не)нравится ручное управление? (не)делай ручное управление _своими_ указателями. Т.е. у тебя выбор:

1. ручками. Аки с malloc(3)/free(3)

2. автоматически, со своим GC сбиш.

Да, подефолту п1, потому-что Страуструп хоть и умный, но откуда ему знать правила твоего блекджека, и характер твоих шлюх?

«а правда-ли, что приложение на ФП-бейсике будучи тупо скопировано в C++11+STL будет работать быстрее?»

Оно не было тупо скопировано.

если-бы оно было нормально написано, то оно-бы так не тормозило. Я не знаю, в чём твоя конкретная ошибка, т.к. своего конкретного «не тупого» кода ты не привёл.

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

Да и потом ObjC няшка и просто образец красоты по сравнению с приплюснутым уродцем.

не, это всё-же канал #anime...

Всё, ухожу с канала, со своими тупыми вопросами про C/C++...

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

decltype(T{} + U{}) это немного другое — конструируются дефолтные значения типов T и U, они складываются и тип результат достаётся с помощью decltype, то есть это способ получить sup от двух регулярных типов которые можно складывать (подразумевается что они подтипы какой-то абелевой полугруппы).

Например:

template <typename T>
struct S {
    T x;
    explicit S(T const& x_) : x(x_) {}
    template<class U>
    friend S<decltype(T() + U())> operator+(S<T> const& a, S<U> const& b) {
        return S<decltype(T() + U())>(a.x + b.x);
    }
};

struct A {
    short x;
    A() : x(0) {}
    explicit A(short const x_) : x(x_) {}
};

struct B {
    int x;
    B() : x(0) {}
    explicit B(int const x_) : x(x_) {}
    friend B operator+(A const a, B const b) { return B(a.x + b.x); }
};

#include <cstdio>

int main() {
    S<A> a(A(1));
    S<B> b(B(2));
    auto c = a + b;
    printf("sizeof(a) == %ld\nsizeof(b) == %ld\nsizeof(c) == %ld\n",
           sizeof(a), sizeof(b), sizeof(c));
    S<B> c2 = a + b; // ok
    S<A> c3 = a + b; // nope
}

скоро выйдет 7.8 и там будут включены typelevel-naturals нормальные

Нормальные как раз в С++ :) Т.е. индексация любыми числами, enum-ами и вообще объектами (если делать ссылки на constexpr).

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

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

ты не совсем прав. Например подумай: нужен ли GC в интерпретаторе PHP? Это конечно терминальный пример, но я думаю понятно, о чём я.

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

не пойму, чем сишный код легче для понимания, чем с++ с классами, но без шаблонов? ну вот где он легче, в каком месте?

ну когда ты пишешь в C++ return x=(a+b)*(c+d); это достаточно стрёмно разбирать, в случае если x,a,b,c, и d — объекты хрен знает каких классов, каждый со своими перезагруженными операторами. В сишечке попроще, ибо там ты видишь функцию, и по её прототипу знаешь, что у неё на входе.

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

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

Ничего личного, но в самом начале 90-х, после выхода книг Страуструпа и Вирта на русском, в студенческой среде именно неосиляторы указателей и адресной арифметики в Си ухватились за ОО парадигму и «плюсы» как за соломинку. И начали моделировать мир объектами. По другому у них получалось плохо.

Осиляторы, ознакомившись с идеями, продолжали кодить на Си.

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

Так а в чем проблема то? То же можно сделать и с функциями, и даже на жабе можно изобразить. Может тогда вообще не писать программы?

ckotinko ☆☆☆
()

Не понимаю таких срачей про языки. Если человеку платят за кодинг на Cpp и у него все получается то зачем ему эти ерланги, лиспы и прочая one-time маргинальщина? Зачем ему тратить время на изучение того что ему не интересно и что от него не требуется в рабочем процессе?

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

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

Так а в чем проблема то?

проблема в том, что суть операции зависит не только от операции, но и от типа данных. Причём эта зависимость нигде(кроме какого-то кода) не прописана и не документирована. Ну например в JavaScript ты точно знаешь, что такое a+b: Это либо сложение чисел, либо конкатенация строк. И то и другое подробно документировано в спеках ЯП. А вот если ты видишь a+b в C++, то это a.operator+(b) (впрочем, возможно это дружественная глобальная функция). Мало того, даже если ты знаешь, что такое a, то ты всё равно не знаешь, что это за оператор+, ибо он может быть и перезагружен, и в рантайме там вообще может быть всё что угодно.

Да, это фича, а не баг. Но в коде вроде ядра, лучше обойтись без таких потенциально опасных фич, которые ВНЕЗАПНО могут заработать совершенно неожиданно(даже для автора класса!). А вот в юзерспейсе это ИМХО вполне себе допустимо.

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

дело в «количестве свободы». В C++ свободы слишком много. Линус полагает, что _слишком_ много. Ну это же проект Линуса, ему виднее.

Конечно всё это _можно_ сделать и в сишечке и в brainfuck'е. Вот только в C++ это такой style life. Для программиста на C++ это также естественно, как дышать.

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

Я не понимаю, что именно ты хочешь сказать. Что Си/Си++/ObjC используется и в Андроедах, и в Макосах? Или что он используется не так широко, как я думаю? Или что?

Да, C++ используется вынуждено в дополнение к основному языку.

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

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

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

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

Вот так всегда. Язык говно, а виноваты почему-то программисты.

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

подумай, как его реализовать например в системе кодов x86, и всё поймёшь

А как реализовать в системе кодов x86

(a + b) * (c + d)

? Очевидно

r0 = a
r0 += b
r1 = c
r1 += d
r0 *= r1

А теперь паттерн-матчинг:

data Term a =  a :+ a | a :* a | L a

t x = case x of
  (L a :+ L b) :* (L c :+ L d) -> (a + b) * (c + d)
  ...

и (наиболее тупой) результат компиляции:

t2 x =
  if isProd x
  then let l1 = getProdLeft x
           r1 = getProdRight x
       in if isSum l1
          then let l2 = getSumLeft l1
                   r2 = getSumRight l1
               in if isSum r1
                  then let l3 = getSumLeft r1
                           r3 = getSumRight r1
                       in if isLit l2
                          then let l2' = getLit l2
                               in if isLit r2
                                  then let r2' = getLit r2
                                       in if isLit l3
                                          then let l3' = getLit l3
                                               in if isLit r3
                                                  then let r3' = getLit r3
                                                       in (l2' + r2') * (l3' + r3')
                                                  else ...
                                          else ...
                                  else ...
                          else ...
                  else ...
          else ...
  else ...

дальше нужны тайптеги у типов-сумм, typeof-ы для них и акцессоры. Это можно оптимизировать минимизируя branching, но в целом всё довольно просто и в духе zero cost (Страуструп одобряет, вместе с разработчиками Rust и Cyclone). Необходимость в тайптегах подобна необходимости в vtbl у виртуальных функций, сам паттерн-матчинг даёт лёгкость расширения наборов функций для фиксированных (закрытых) типов данных (по отношению к expression problem, виртуальные функции ООП наоборот — лёгкость расширения данных предоставляющих фиксированные наборы интерфейсных функций).

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

C++ используется вынуждено

Т.е. без Си++ - никуда %)

в дополнение к основному языку.

Пойнт был в том, что «основной язык» всё равно C-based.

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