LINUX.ORG.RU

[C++?] Серьезный вопрос.


3

2

Просьба ответит серьезно, желательно с аргументами за или против.

Предистория:
Когда то давным давно (я тогда еще только закончил 9-ый класс) я увидел в газете объявление о наборе в летнюю группу по изучению классического программирования. В тот момент я был с компьютером на ты и "очень" хорошо в них разбирался (переустанавливал Windows каждый месяц, хаял Microsoft просто потому, что после моих настроек W приходилось постоянно переустанавливать). Группа по классическому программированию так и не набралась, но набралось 1 человек на Visual Basik for Applications. Я соглсился быть вторым и начались занятия.
Все, что мне там объясняли я схватывал быстро. Меня пригласили продолжить обучение в сентябре на курсе "моделирование".
Там уже был Pascal, который я тогда совсем не знал. Сам курс был очень разношорстный: мы изучали и использование мыши через прерывание, готовились к различным олимпиадам. Параллельно я изучил Pascal.
Потом был Delphi. К концу 10-го класса я уже неплохо владел приемами программирования и вовсю клепал бесполезные программулины. Потом поступил в универ на программиста. Там тоже был Delphi, и я особо не напрягаясь писал все лабы (к моменту поступления я уже был знаком с логикой указателей, самописные стеки и графы, etc).
На 2-ом курсе в гостях у знакомого я разобщался с человеком, который уже насколько лет работал в нерезиновой программистом. Он мне и открыл глаза на мир: "Delphi здох. Его уже похоронили и забыли. Сейчас необходимо знание C++, C#. Необходимо занание паттернов проектирование". Вобщем много чего он мне наговорил. Книжек умных насоветовал, подкинул MSVS 2008, кучу электронных книжек. Я изучил C# по книжке Шилдта. Читал "Идеальный кол" (автора уже не помню). Потом купил(!) себе книжку Шилдта про С++. Мне понравился язык. Тем более что мне казалось, что именно он и есть общепринятый стандарт. Наиболее удобный язык для программиста.

А недавно в соседней теме за упоминание это С++ меня чуть было не съели со всем чем можно. Так-то.

Собственно вопрос: Так стоит ли изучать дальше С++ (а я уже достаточно углубился в книжку Страуструпа, подробно изучая все подводные течения)? Какой язык стоит изучать? Какие из них более востребованны?

Спасибо всем, кто осилил это многобукаф.

★★★★★

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

>>>Все остальное -- это сборище компромисов и посредственных решений.

>Каких нафиг компромиссов?

Почитайте "Дизайн и эволюцию языка C++", там все написано.

>Нас ибут, а мы крепчаем.

Смело вы о своей ситуации рассказываете, откровенно.

>Позиция взрослого человека, да.

Взрослый человек воспринимает жизнь такой, какова она есть. Ребенок -- так, как хочет ее видеть.

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

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

>Почитайте "Дизайн и эволюцию языка C++", там все написано.

Это типа попытки индульгироваться со стороны Строуструпа?

>>Нас ибут, а мы крепчаем.

>Смело вы о своей ситуации рассказываете, откровенно.

Профессионал (судя по блогу) защищающий С++ выглядит слишком уныло.

>>Позиция взрослого человека, да.

>Взрослый человек воспринимает жизнь такой, какова она есть. Ребенок -- так, как хочет ее видеть.

У ребенка больше жизненных альтернатив впереди и тонус более бодрый.

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

> Строуструп написал препроцессор который конвертирует class A : B, C { ... } в struct A { struct B __Aparent0; struct C __Aparent1; ... } и т.п в том же роде. Потом это художество лет десять гнило и обрастало костылями и в итоге получилось то что мы имеем.

Вы будете смеяться, но Бертранд Меейр сделал в точности тоже самое. И до сих пор его Eiffel-евский компилятор из состава EiffelStudio транслирует Eiffel-евский код в C, а затем из C уже в объектный код.

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

> >Почитайте "Дизайн и эволюцию языка C++", там все написано.

> Это типа попытки индульгироваться со стороны Строуструпа?

Нет, нормальный рассказ о том, что и почему.

> Профессионал (судя по блогу) защищающий С++ выглядит слишком уныло.

Имидж ничто. Мне давно уже пофигу -- говно C++ или это самый лучший язык. Работы на нем много, сменить его не на что. А вот читать придурков, которые обвиняют его во всех грехах, как и придурков, которые его превозносят до небес, временами настолько противно, что молчать не хочется.

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

>Вы будете смеяться, но Бертранд Меейр сделал в точности тоже самое. И до сих пор его Eiffel-евский компилятор из состава EiffelStudio транслирует Eiffel-евский код в C, а затем из C уже в объектный код.

Мне вообще ООП кажется сомнительной идеей. Операции над множествами заметно улучшили бы ынтерпрайзный код: Типа вычислить пересечение трех множеств {бизнес-операция, товар, кастомер} и получить функцию calc_steel_price_for_goverment если бизнес-операция это calc_price, товар - steel, а кастомер - goverment. При том что мы имеем в С++ и Джаве иерархии текут изо всех щелей.

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

> Мне вообще ООП кажется сомнительной идеей...При том что мы имеем в С++ и Джаве иерархии текут изо всех щелей.

Это не проблема ООП. Это следствие того, что ООП в последние лет 10 поназасовывали во все возможные дырки.

Во многих случаях C++ лучше Java тем, что в нем есть свободные функции и свободные шаблонные функции. Что позволяет эффективно решать некоторые задачи вообще без ООП (разве что используются контейнеры из STL и std::ostream).

В Java же довели ситуацию до маразма -- только ООП и ничего кроме. Поэтому там даже HelloWorld, и тот ООП-шный.

Хорошо хоть, что в Scala от этого избавляются. Хоть какой-то луч света в царстве JVM.

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

> Вывод: окамль оказался не так ужасен, как я о нем сначала подумал, однако отставание на 83% (а у меня всего лишь два ядра) говорит о том, что для числодробилок он слабоват.

В текущем ocamlopt не реализована поддержка SMP. Возможно, стоит попробовать JoCaml.

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

>где гойджим (петунский jabber-клиент) имеет RSS в районе 380 MB. Здорово, правда?

Ходят слухи что ты выдумываешь про такую быструю серверную часть мейл.ру. А еще ходят слухи что ты гей. И вообще предпочитаешь маленьких худых еврейских мальчиков с грустными карими глазами. Что там жрет петунский клиент мне пофигу, потому что жаббер открыт и можно написать на чем угодно, и клиент выбрать наиболее подходящий. Что бы пресечь хождение слухов - мы от тебя ждем серверную часть быдломессенжера мейл.ру, что бы устроить открытое независимое тестирование. url пожалуйста дай. Сравним с ejabberd.

гыгылол. Клоун, блин %)

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

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

Успокойся, с производительностью у С++ на многих задачах всё ОК. С выразительностью хреново.

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

>С выразительностью хреново.

Давай-ка сюда аналог openmp, который параллелит вычисления одной директивой, для ваших хацкамлей.

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

> Давай-ка сюда аналог openmp, который параллелит вычисления одной директивой, для ваших хацкамлей.

Тебе опять привести список того, чего в плюсах нет? Так ты опять начнёшь пищать, что потребности в колбасе нет...

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

> Мне вообще ООП кажется сомнительной идеей. Операции над множествами заметно улучшили бы ынтерпрайзный код: Типа вычислить пересечение трех множеств {бизнес-операция, товар, кастомер} и получить функцию calc_steel_price_for_goverment если бизнес-операция это calc_price, товар - steel, а кастомер - goverment. При том что мы имеем в С++ и Джаве иерархии текут изо всех щелей.

А вот отсюда поподробней сформулируй задачу.

В частности, почему не:

enum Commodity {....};
enum Customer {....};
template<Commodity commodity, Customer customer> Money<customer> calc_price(Unit<commodity > amount) {....}

Да-да, в яве так бывает нельзя.

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

>В частности, почему не:

Тут все типы - динамические.

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

> Давай-ка сюда аналог openmp, который параллелит вычисления одной директивой, для ваших хацкамлей.

Как раз таки в Хаскелле распараллеливание происходит элементарно с помощью par и pseq:

http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parall...

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

>Тебе опять привести список того, чего в плюсах нет?

Ах да, в плюсах нет всякого говнеца вроде лямбдозамыканий, без которых не получается просто и изящно закодировать упражнение из книги "обучи себя хацкилю за 7 простых упражнений". Ничего, что openmp чрезвычайно удобная и практичная вещь для распараллеливания алгоритмов? А на синтаксический сахар всем как-то фиолетово.

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

>Как раз таки в Хаскелле распараллеливание происходит элементарно с помощью par и pseq

Чего ты мне ссылки на какую-то документацию кидаешь? Давай сюда рейтрейсинг на хацкиле, распараллеленный рейтрейсинг на хацкиле и мы посмотрим, в какой именно окрестности параши находится место хацкилля.

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

Кстати:

>Portability: non-portable

>Stability: experimental

И это против стабильного и переносимого OpenMP? Все окрестные водоемы просто взорвались метаном!

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

> И это против стабильного и переносимого OpenMP?

Его в g++ только в 4.2, кажется, начали поддерживать?

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

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

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

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

>Его в g++ только в 4.2, кажется, начали поддерживать?

Если что, на дворе уже gcc-4.4.1

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

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

Ты уже распараллелил рейтрейсинг на окамле?

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

> Чего ты мне ссылки на какую-то документацию кидаешь?

Это то, что ты просил.

> Давай сюда рейтрейсинг на хацкиле, распараллеленный рейтрейсинг на хацкиле и мы посмотрим, в какой именно окрестности параши находится место хацкилля.

Тебе всё равно не понравится. Там у тебя на получится онанировать на адресную арифметику.

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

>>С выразительностью хреново.

> Давай-ка сюда аналог openmp, который параллелит вычисления одной директивой, для ваших хацкамлей.


В лиспе - plet из библиотеки eager-future (или pmap из cl-pmap местного товарища swizard'а). Заметь, параллельные абстракции в язык добавляются всего лишь подключением обычной библиотеки. Компилятор ковырять не нужно. Это и называется - хорошая выразительность.

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

> Ты уже распараллелил рейтрейсинг на окамле?

Ты уже доказал, что icc выигрывает у gcc в 6 раз, и у окамла в 36?

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

> Ничего, что openmp чрезвычайно удобная и практичная вещь для распараллеливания алгоритмов? А на синтаксический сахар всем как-то фиолетово.

Удобно - это параллельный аналог map, там даже алгоритм переделывать не нужно.

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

> Ты уже написал вычисление тройного интеграла на С без void* ?

Да пусть хоть с войдом. Всё равно без слёз на такое смотреть можно только в том случае, если программа ничего больше не делает и никогда не будет.

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

> Что-то плюсофилы совсем унылыми стали... страниц 10 назад интереснее тред был.

Время уходит, кресты со всех сторон поджимают. Дядька Страуструпп не успевает модные фичи в язык запихивать, не взорвав мозг компиляторописателям. Вот крестофагам и приходится всё унылее и унылее троллить: "Кресты быстрее на математике!", "Как, уже не быстрее? А вот у нас icc есть, заточенный под конкретный процессор, на нём таки быстрее!", "А вот ещё позавчера ещё один костылёк прикрутили, чтобы распараллеливать циклы!"...

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

>Ты уже написал вычисление тройного интеграла на С без void* ?

Скажи, а вещественную арифметику, встроенную в язык можно использовать или надо писать свою с произвольной точностью?

P. S. где рейтрейсинг на хацкиле?

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

>Это и называется - хорошая выразительность.

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

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

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

Держи: (pmap function sequence). Функция function применится на всех процессорах, обработав равную долю sequence.

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

Ну зачем так... Его надо на голодном пайке держать, а то я так и не дождусь эпического доказательства превосзодства icc над ocaml'ом в 36 раз.

PS: Я вот думаю, когда ж он родит "доказательство" вида "берём icc+OpenMP и 128процессорную машину и сравниваем с однопоточным кодом на окамле в интерпретаторе (а то с компилятором фигня получается, больше пятнадцатикратного выигрыша не выходит)" 8))

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

Держи: http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html

Я взял оптимизированный вариант...

$ ghc -O3 -fvia-C -funbox-strict-fields -optc-O3 -fexcess-precision -optc-ffast-math -funfolding-keeness-factor=10 ray.hs -o ray

ray.hs:7:0:
    Warning: No explicit method nor default method for `*'
    In the instance declaration for `Num Vector'

ray.hs:7:0:
    Warning: No explicit method nor default method for `abs'
    In the instance declaration for `Num Vector'

ray.hs:7:0:
    Warning: No explicit method nor default method for `signum'
    In the instance declaration for `Num Vector'
$ time ./ray > hs.pnm
ray: user error (Pattern match failure in do expression at ray.hs:90:4-13)


real	0m0.001s
user	0m0.008s
sys	0m0.000s

ROFL

P. S. icc на оптимизированном варианте показал 2.7s и 1.67s (без openmp и с openmp соответственно).

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

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

>>Тебе опять привести список того, чего в плюсах нет?

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

В плюсах вообще нет ни одной хорошей идеи сверх того что есть в Си. В той жабе хоть объектная модель и говно взятое из другого говна (С++), но там родной мультитрединг, gc и опенсорцные либы на все случаи жизни есть. А насчет лямбд-замыканий - мне на них пофиг по большому счету. Только С++ и как чисто императивный язык слабоват - система типов слабенькая, сетов нет, на массивы даже Саттер с Мейерсом ругаются и охают по Фортрану (даже и не заикайся насчет std::), работа с памятью тоже слабенькая: оператор new надо было делать перегружаемым не по типу а по контексту вызова.

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

>Дядька Страуструпп не успевает модные фичи в язык запихивать, не взорвав мозг компиляторописателям.

Вообще-то мозги компиляторописателей он никогда особо не жалел. И правильно.

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

>В плюсах вообще нет ни одной хорошей идеи сверх того что есть в Си.

Это ты про шаблоны, пространства имён, исключения и перегрузку операторов (без которой длинная арифметика на жабе выглядит как мегагавно)?

>но там родной мультитрединг

Такой же убогий как synchronised(this)?

>gc

Обязательный не отключаемый учёт каждой ссылки - это достоинство?

>опенсорцные либы

Даже гуя нормального нет, страх и тормоза.

>на все случаи жизни

Хаха.

>А насчет лямбд-замыканий - мне на них пофиг по большому счету

Как выяснилось, что они даже на си делаются (без гарбыдж каллектара, OMFG!!11) - так сразу пофиг.

>Только С++ и как чисто императивный

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

>система типов слабенькая

Что конкретно _ты_ под этим понимаешь? А то я наслушался трактовочек...

>сетов нет

Сетов - это тех, которые Вирту так нравятся? Сделай, ёмана.

>оператор new надо было делать перегружаемым не по типу а по контексту вызова.

Что ты понимаешь под "контекстом вызова"? Вазу луны?

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

> Думаю, на этом можно завершить сомнения о применимости хацкиля к вычислительной математике.

Аргументы не ввёл. Кстати, кресты тоже тогда вычёркивай, atoi в g++-4.4 из коробки нет.

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

>запускать хаскелевский бинарник надо было ./ray 9 512

[code]$ time ./ray 9 512 > hs.pnm

real 0m3.801s user 0m3.780s sys 0m0.016s[/code]

На 40% медленнее icc и на 35% медленне, чем gcc (оба без OpenMP). Тормозная функциональщина.

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

>Кстати, кресты тоже тогда вычёркивай

С чего вдруг? Там по умолчанию 9 и 512 подставляются.

>atoi в g++-4.4 из коробки нет

Лолшто? atoi -- это часть сишного стандарта, ее не может не быть. Другой вопрос в том, что кое-кто забыл #include <stdlib.h>, а я уже замечал, что написанный этим человеком плюсовый код -- говно.

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

форматирование fixed

запускать хаскелевский бинарник надо было ./ray 9 512

$ time ./ray 9 512 > hs.pnm

real 0m3.801s user 0m3.780s sys 0m0.016s

На 40% медленнее icc и на 35% медленне, чем gcc (оба без OpenMP). Тормозная функциональщина.

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

>Даже гуя нормального нет, страх и тормоза.

Есть биндинги Qt и GTK, родной swing + много чего еще.

>>на все случаи жизни

>Хаха.

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

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

Да вот повесили на него ярлык мультипарадигменного. На деле это не так.

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

> На 40% медленнее icc и на 35% медленне, чем gcc (оба без OpenMP). Тормозная функциональщина.

Ой, опять не в 6 раз относительно gcc и не в 36 раз относительно icc? Ну нада же!!!

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

> Да вот повесили на него ярлык мультипарадигменного. На деле это не так.

Мультипарадигменный он. Любая парадигма на нём может реализована одинаково (по модулю) странным образом.

kemm
()

http://www.ffconsultancy.com/languages/ray_tracer/benchmark.html

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

добавил import Control.Parallel.Strategies

и переопределил picture как

picture = 
    parFlatMap 
        (seqList rwhnf) 
	    (\y -> [toEnum $ truncate $ scale $ pixel_vals n scene y x | x <- [0..n-1]])
        [n-1,n-2..0]

здесь parFlatMap в моём понимании выступает как паралелльный аналог concatMap

компиляция:

rm -f ray ray.hi ray.o; ghc --make -O3 -fvia-C -funbox-strict-fields -optc-O3 -fexcess-precision -optc-ffast-math -funfolding-keeness-factor=10 -threaded ray.hs -o ray

запуск:

time ./ray +RTS -N4 -RTS 9 512 > 1.pnm

где -N4 - количество запускаемых потоков

Результаты на C2Q 6600:

$ time ./ray +RTS -N1 -RTS 9 512 > 1.pnm

real    0m5.830s
user    0m5.779s
sys     0m0.038s

$ time ./ray +RTS -N2 -RTS 9 512 > 1.pnm

real    0m3.680s
user    0m6.914s
sys     0m0.057s

$ time ./ray +RTS -N3 -RTS 9 512 > 1.pnm

real    0m2.402s
user    0m6.509s
sys     0m0.053s

$ time ./ray +RTS -N4 -RTS 9 512 > 1.pnm

real    0m1.928s
user    0m6.609s
sys     0m0.083s
unC0Rr ★★★★★
()
Ответ на: комментарий от legolegs

>>В плюсах вообще нет ни одной хорошей идеи сверх того что есть в Си.

>Это ты про шаблоны,

Раздувает зависимости внутри проекта, нет интероперабельности с другими фичами языка, росло интуитивно и бессистемно от Array<T>. Итого - говно.

>пространства имён,

Чисто украшательная фигня.

>исключения

Реализация в g++ - говно.

>и перегрузку операторов (без которой длинная арифметика на жабе выглядит как мегагавно)?

Бесполезный сахар, скрывающий реализацию.

>>gc

>Обязательный не отключаемый учёт каждой ссылки - это достоинство?

Принципиальная невозможность его иметь без применения хаков идущих вразрез со стандартом - достоинство?

>>опенсорцные либы

>Даже гуя нормального нет, страх и тормоза.

В плюсах даже плохонького но стандартного нет.

>>А насчет лямбд-замыканий - мне на них пофиг по большому счету

>Как выяснилось, что они даже на си делаются (без гарбыдж каллектара, OMFG!!11) - так сразу пофиг.

Ламбды в С и С++ это cargo-cult programming в чистом виде. Но в Си хотя бы нет клинического идиотизма в виде указателей на методы и если нужен колбэк, то его можно легко организовать.

>>оператор new надо было делать перегружаемым не по типу а по контексту вызова.

>Что ты понимаешь под "контекстом вызова"? Вазу луны?

Обобщение mark/release из Паскаля.

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