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)

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

Для чего?

Ты серьезно?

Для подпорок под несопровождабельным говном из других велосипедов,

Точный диагноз с++! Поздравляю! В других средах народ умудряется таки вылезти и прошлого века.

Пример проекта с десятками фреймворков

Собственных модулей:

ls -la *.module | wc -l

27

Внешних зависимостей:

ls -l */lib/*.jar | wc -l

83

+ JRE + scalalib

Ы? В случае с с++ мне надо было бы сразу застрелится?

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

А я что говорю? Сплошные исторические причины, наследие и т.д.

с тобой спорить — как в бетонную стену головой биться. Сама суть программирования на C++, это создание СВОИХ типов. При чём тут дефолт? Какая разница, какой дефолт?

Хороший тон - это когда ты получил структурки не хрен знает откуда и можешь переписать все что хочешь?

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

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

да. Что касается копирования, то оно по своей сути может не иметь смысла. Вот ты можешь скопировать обычную бутылку с пивом? Нет, ТЫ можешь? Я вот не осилю. Проще и дешевле ящик пива купить, но это не копирование, а перенос. Операция копирования для большинства объектов IRL имеет очень мало смысла, а если и возможна, то сопряжена с практически непреодолимыми трудностями.

Вот в C++ и нужен механизм, который не даёт выполнять не имеющие смысла операции другим программистам. В сам ЯП ввести такой механизм невозможно, ибо ЯП должен быть универсальным, т.е. описывать как копируемые объекты, так и не копируемые.

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

Работу GC невозможно контролировать из кода, что и делает невозможной ручную оптимизацию.

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

но по сравнению с кастомным аллокатором сольет все равно.

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

Никакой умный GC не сможет предсказать этот сценарий без libastral.

Никакому GC это не надо. Он заточен чтобы работать со стопицотами объектами любого размера.

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

Просто наш r пытается использовать известные ему фичи там, где они неуместны

Положить объекты в вектор и отсортировать для того чтобы получить сортированный вектор - это неуместно?

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

Ты наверное не понимаешь что такое бедная система типов....

а ты понимаешь? Тогда рассказывай.

если бы оно было нормально написано оно бы решало проблемы программиста а не требовало чтобы оно было «нормально написано».

чудес не бывает. Говорю-же, если я начну портировать в обратном направлении, то вообще нерабочее говно получится. Что это доказывает? Ущербность целевого ЯП?

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

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

Компиляторы не умеют оптимизировать алгоритмы. Sad but true.

Да - кастомный аллокатор на каждый тип объекта - это сильно.

Не на каждый, а на тот, который часто создается.

Он заточен чтобы работать со стопицотами объектами любого размера.

Поэтому не может не сливать аллокатору, заточенному на один размер.

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

хороший тон — не бросать грабли на пороге.

С++ это такое минное поле граблей. А на нем писать - это не наступать на грабли. Классный инструмент!

Тогда программист, если использует копирование, которое (по твоему мнению, как автора этого типа) не нужно

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

Операция копирования для большинства объектов IRL имеет очень мало смысла

Мля - я три страницы назад об этом написал. Что в дизайне плюсов в качестве стратегии по умолчанию с передачей параметров реализованы конвенции которые в реальности имеют очень узкую сферу применения. Как например - передача всего по значению. А потом начали изобретать конструкторы копирования и прочую хрень для возможностей оптимизации процесса. Ты вообще подумай нафига тебе на сегодняшний день работа со всем что движется на таком уровне? Для _чего_? Дада знаем - по историческим причинам...

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

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

это ты ипонутый, если уверен, что можешь показать мне инструмент, а я не смогу показать тебе задачу, в котором ты с этим инструментом проблем не огребёшь. Даже в DOOM'е и то с одним оружием тяжко. С любым оружием, тем более  — с самым мощным. А в жизни ещё хуже.

и создают инструменты которыё этому способствуют, а не страдают херней.

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

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

Точный диагноз с++!

Штоааа? Доктор, ты бросай эти вещества. А то планировщик новый напишешь и Леннарт от обиды уйдет из большого секса.

Собственных модулей:

ls -la *.module | wc -l

27

Три хаха. Тут дело не в количестве фреймворков явно. А «количество модулей» - это не размер проекта. Если это не экстенсивный сбоку-костылизм, достаточно написать сам механизм модульности и заложить хорошую масштабируемость. У нас есть один ынтерпрайзный миддлварь для финансовых «МНОГО ДАННЫХ» :) У него в зависимости от флагов сборки легко может быть 100 транспортных модулей к разным IPC и MQ. Но они сравнительно тонкие (да и столько их сразу никому из клиентов не надо - подмножества только) :) И размер проекта от одного этого количества сторонних свистелок не становится большим :)

+ JRE + scalalib

ls -l */lib/*.jar | wc -l

83

Ы? В случае с с++ мне надо было бы сразу застрелится?

Зачем. С кулфейсом посчитать количество чего-нибудь со звездочкой :) Выйдет такая же «ОГОГО погода на марсе».

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

чудес не бывает.

Зато есть такая хрень как прогресс. Его цель - чтобы работа которая требовала много усилий вчера - завтра делалась проще. Для этого создаются инструменты которые облегчают работу. Если они облегчают ее хренов- значит это хреновые инструменты. Чем больше тренинга требуется для умения владеть инструментом - тем он хуже среди других инструментов делающих тоже самое. Знание потрохов С++ не увеличивает квалификацию человека как инженера - это не фундаментальные знания в области CS. Это узкий скил работы со странным инструментом только потому что инструмент так устроен. Чтобы уметь пользоваться исключениями в любом другом языке - нужно просот понимать что такое исключение. В С++ к этому еще прилагается мануал «что нужно знать конкретно в ++ чтобы исключения не отстрелили тебе ногу». И так по куче тем. Безотносительно конкретики - любой инструмент который обладает такими свойствами _хреновый_.

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

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

нет. Иногда надо увеличить скорость _освобождения_ памяти. Для этого GC и применяют — вместо освобождения, память НЕ освобождают. Т.е. перезагружают delete пустым кодом, который ничего не делает. Ну а GC запускают тогда, когда выделять уже неоткуда, ведь память не освобождается. Потому _выделение_ памяти не очень быстрое, иногда _очень_ не быстрое, за то освобождение _всегда_ бесконечно быстро. И да, очень часто IRL память выделяется LIFO, потому не только delete ничего не делает, но и сам GC (почти)ничего не делает, если у тебя (почти)LIFO. Случай частный, но на практике так чуть менее, чем всегда.

Однако в общем случае всё становится очень печально, и ведёт к проблемам с GC.

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

что можешь показать мне инструмент, а я не смогу показать тебе задачу,

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

Так что там у нас сейчас за серебряную пулю,

У нас как раз ничего. Это ж у любителей плюсов слепота какая-то на глазах и они не видят что рынок задач на плюсах за 10 лет схлопнулся.

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

Чем больше тренинга требуется для умения владеть инструментом - тем он хуже среди других инструментов делающих тоже самое.

Ололо. Хороший пистолет сам стреляет в ногу, дадад.

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

. С кулфейсом посчитать количество чего-нибудь со звездочкой :)

«бугага» - это все что ты имеешь сказать? Я тебе показал реальность. Сотни тыщь строк кода на с++ подобном языке. На С++ такое не напишешь никогда. Потому и не пишут.

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

Ее там оптимизирует GC, при чем делает это лучше чем аллокаторы.

повторяю: GC полезен только в _частном_ случае (почти)LIFO. В общем случае он сливает по полной. А универсальный аллокатор типа ::new работает всегда примерно одинаково. Потому-то его и ставят в дефолт. Или ты думаешь, что ты самый умный?

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

они не видят что рынок задач на плюсах за 10 лет схлопнулся.

Может ты им просто завидуешь? :) А то у некоторых веб-погромистов тут и рынок настольных приложений «схлопнулся кококо!!111»... 90 % рынка, дескать, браузерные игры... Ну, то что рынки бывают местечковые и немного более других масштабов (покрупнее аппстора «все по $6, говна много, но одинакового», например) - это за скобками.

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

Если писать под мак что-то новое, то интересно использовать тулкит твиттера (похож на UIKit из iOS), он использует полное аппаратное ускорение рисования, из-за чего возможны красивые анимации и ультраплавная прокрутка.

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

Ато O_o void qsort (void* base, size_t num, size_t size, int (*compar)(const void*,const void*)); Все ясно, void void-ом погоняет.

учи матчасть — в данном случае void* как раз и обозначает «что угодно», потому-что qsort с этим «что угодно» НИЧЕГО НЕ ДЕЛАЕТ. Оно только что и умеет это «что угодно» местами менять друг с другом. И именно потому ей нужен размер «что угодно», число этих «что угодно», и где они начинаются. Ещё ей нужно нечто, что будет эти «что угодно» сравнивать. Ибо она в них не разбирается, и разбираться не желает. Прямо как ты в C/C++.

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

Я тебе показал реальность.

Солипсизм теперь лечится же.

На С++ такое не напишешь никогда.

Потому и не пишут.

Конечно. Ненужно писать сотни тыщ какого-то кода ради собственно сотен тыщ кода (особенно без указания, чего он конкретно делает, может там авто-комментариев и скобочек больше или копипасты) :) ты даже список оч. нужных фич этих сотен кода никакой не привел - в выхлопе ls я и покруче могу циферку нарисовать. :)

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

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

именно этим GC и занимается. Предсказывает сценарий. И получается очень хорошо. Правда только в синтетических тестах аффтора этого GC.

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

Нетъ, на С лучше, иначе у меня под SH4 не соберется.

непортируемый говнокод можно и на C писать.

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

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

Это не я. Нахрена по твоему такие платформы как жаба и .NET вообще создаются?

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

Точный диагноз с++! Поздравляю!

может ты предварительно вылечишь ФП гойловного моска, прежде чем диагностикой заниматься?

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

В случае с с++ мне надо было бы сразу застрелится?

угу. Даже в сишечке лучше сразу повесится, ибо препроцессор из двух(sic!) строк gnu /bin/false делает Over9000 строчек, выдёргивая их откуда только можно и нельзя. А уж для C++ — проще сразу застрелиться.

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

Нахрена по твоему такие платформы как жаба и .NET вообще создаются?

покажи на твоих платформах аналог Photoshop, Chrome, Firefox, AutoCAD, MS Office, MySQL, Skyrim и т.п.

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

Работу GC невозможно контролировать из кода, что и делает невозможной ручную оптимизацию.

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

подмена понятий detected. Твой оппонент говорил про оптимизацию _алгоритма_ распределения памяти. На пальцах: это вроде замена пузырька на qsort. Компилятор тут не при чём.

Что поделать, что жизнь такая поганая штука? Что этот твой qsort практически всегда сливает пузырьку на синтетике вида 1,2,3,4,5... Так и обычный аллокатор сливает твоему GC на синтетике.

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

но по сравнению с кастомным аллокатором сольет все равно.

Да - кастомный аллокатор на каждый тип объекта - это сильно.

не. Слабовато. Обычная демагогия. Слово «все» ты сам придумал и вставил. И смеёшься ты над своей глупостью, а не над глупостью оппонента. Он глупостей не говорил, это ты додумал.

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

не забивали. Если ты такой умный, то попробуй НЕ забивать. Во многих случаях разницы не будет никакой. А в некоторых твой GC начнёт жутко сливать, и тормозить всю систему.

Никакому GC это не надо. Он заточен чтобы работать со стопицотами объектами любого размера.

такой большой, а в сказки веришь. Делить на ноль нельзя. Как нельзя сделать аллокатор идеальный для _любых_ размеров и сценариев. Этот твой «идеальный» будет сливать в 95% ситуаций.

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

Положить объекты в вектор и отсортировать для того чтобы получить сортированный вектор - это неуместно?

конечно. Это же не недоязычёк, в котором на всё про всё один контейнер, вроде php. Не, C++ на порядок сложнее, в нём есть сотни(если не тысячи) идиом и приёмов для создания разных коллекций.

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

Компиляторы не умеют оптимизировать алгоритмы. Sad but true.

немножко умеют. Хвостовую умеют, неизменную часть из цикла умеют... Но алгоритм аллокатора конечно не осилят. Чуть подпилят под CPU, а по сути так и оставят. Из говна конфетку не сделают, не тот случай. Вот бесконечный цикл могут, x-- - --x тоже могут в ноль прировнять. Но не аллокатор.

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

Для массовой утилизации быдлокодеров-формошлепщиков же. Для чего еще? :) Человеческие ресурсы - они как углерод. Алмазов мало, добывать («воспитывать») долго и дорого:) В основном уголь... Графит... Просто сажа («коптит небо»)... И прочие сорта «субстанции-нейм». Жрите что дают, гг ПМы с «Архитекторами Больших Проектов»(ТМ). «Других X у меня для вас нэт» (с) Сам знаешь кто.

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

Он про инструменты хорошо сказал... веско как бэ. Метафора только с оружием (да и с инструментами из ИРЛ) не работает почему-то :) Потому что «облегчает жизнь» хороший инструмент не всякому - а тому, кто уже что-то умеет и без «облегчающего»:) Потому что облегчение это сводится к автоматизации рутины (привет интеллисенцам и решарперам) - в руках нуба что-то выходящее за рамки схем «облегчения» становится в ряд «это невозможно сделать!» Аналогично с воплями про «тяжесть работы» или «защиту от дурака». От бензопил и экскаваторов почему-то не требуют думать за оператора, хотя они нехило облегчают жизнь тем, кто умеет обращаться с топором и лопатой... Однако нуб легко останется без ненужных конечностей или станет героем... Попутно сделав героями сотни окружающих :)

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

Я не буду с вами и вашими самодельными проблемами спорить. Честно, мне просто надоело. Тут уже хватает stevejobs, lovesan, r и прочих элитных ололо. УМВР. если у вас не работает с++, не пишите уже на нем. ну раз такой он страшный.

правда, надоели придирки вида «а если мы напишем на с++ говнокод, то почему с++ такой плохой»

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

С++ это такое минное поле граблей. А на нем писать - это не наступать на грабли. Классный инструмент!

совместная работа == всегда грабли. У всех свои тараканы. Да, можно как в питоне, ставить отступы как Гвидо заповедовал... Но это не очень удобно. Отступы-то хоть стандартизировать можно...

Вот такой пример: я пишу какой-то класс, а ты пишешь код, который использует мой класс. Наша программа падает. Ты пишешь мне, что-бы я исправил свой говнокод. Я пишу тебе, что «говнокодер == ты, ибо на 666й странице документации, в секции 13/76 в восьмом примечании, я ясно сказал, что в этом случае НЕЛЬЗЯ копировать объекты! RTFM, быдло!»

Ну и кому нужен этот скандал? А как решается эта проблема в твоём любимом язычке?

Тогда программист, если использует копирование, которое (по твоему мнению, как автора этого типа) не нужно

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

Да ты точно белены объелся! На просто «может», но и ОБЯЗАН предполагать. Например создатель микроскопа обязан предполагать, что его микроскоп будет служить для разглядывания мелких объектов, которые не видно невооружённым глазом. И никак НЕ для покраски забора. Потому он на забор просто забьёт. А тут случай ещё сильнее: _можно_ копировать, и можно _случайно_ скопировать. Это как в микроволновке, можно случайно свои руки поджарить. Потому микроволновку _специально_ усложняют, что-бы её было невозможно включить с руками внутри. Так и тут — программу невозможно собрать, если ты там применил копирование моего класса. Тебе компилятор скажет, что «копировать объекты этого класса нельзя». Почему? Потому-что нельзя. Почему можно скопировать file.txt, но нельзя скопировать /dev/sda ? (внутренности диска ты можешь конечно скопировать, но во первых НЕ командой копирования, а во вторых, второго диска у тебя от этого не получится, надо УЖЕ иметь второй диск, и тогда ты сможешь сделать этот второй диск неотличимой(почти) копией первого)

Мля - я три страницы назад об этом написал. Что в дизайне плюсов в качестве стратегии по умолчанию с передачей параметров реализованы конвенции которые в реальности имеют очень узкую сферу применения.

мля, я с этим и не спорю! Это не баг, а фича. Для говнокодеров можно было-бы сделать Страуструпу костыль, вообще НИКАК не определив дефолт. Ну что-бы тебе нужно было каждый раз ЯВНО описывать тоже копирование.

ВНЕЗАПНО: Гениальный Страуструп сделал намного ЛУЧШЕ: он встроил в C++ детектор говнокодеров. Я с одного взгляда на код говнокодера понимаю, что он говнокодер. Например, если не вижу в классе оператора=. (есть вероятность, что это не баг, а фича. Но там и кроме копирования ещё Over9000 детекторов быдлокода).

Как например - передача всего по значению. А потом начали изобретать конструкторы копирования и прочую хрень для возможностей оптимизации процесса. Ты вообще подумай нафига тебе на сегодняшний день работа со всем что движется на таком уровне? Для _чего_? Дада знаем - по историческим причинам...

а тут ты путаешь причину и следствие. Дефолт — это всего-ли костыль для имитации сишечки.

Что касается «передачи по значению», то она ВЕЗДЕ такая. В твоём хаскеле тоже. И в php. Другое дело, ЧТО это за значение? Это вовсе не обязательно должен быть сам объект, как в твоих недоязычках. Если тебе нужна лишняя сущность (типа «ссылка»), то сделай эту сущность, в чём проблема? Проблема видимо в том, что ты привык эту лишнюю сущность называть «ссылкой», а в C++ тоже есть ссылки, но это ДРУГАЯ СУЩНОСТЬ. На самом деле, «ссылка в C++» это такой указатель, с особыми свойствами, т.е. адрес в памяти. Дело осложняется ещё и тем, что указатели тоже никто не отменял. Т.е. получается аж три «ссылки». Но аналог ссылки из твоих бэйсиков только один, и его надо делать самому (или брать чужой), в самом языке его НЕТ по умолчанию.

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

да сложновато, но так ли оно надо. Я бы делал так:

{-# LANGUAGE TypeFamilies, MultiParamTypeClasses, FlexibleInstances #-}

import Data.Word

class Up a b where up :: a -> b

-- cheating
instance (Integral a, Integral b) => Up a b where up = fromIntegral 

type family  Sup a b :: *
type instance Sup Word8 Word16 = Word16
type instance Sup Word8 Word32 = Word32
-- 100500 штук, но семейство открытое, можно доопределять или генерить TH

liftS :: (Up a c) => a -> c
liftS = up

liftS2 :: (Up a c1, Up b c2) => (c1 -> c2 -> d) -> a -> b -> d
liftS2 f a b = f (up a) (up b)

проверка:

λ> :t liftS2 (+) (1::Word8) (2::Word16) :: Word32
liftS2 (+) (1::Word8) (2::Word16) :: Word32 :: Word32
λ> :t liftS2 (+) (1::Word8) (2::Word16) 
liftS2 (+) (1::Word8) (2::Word16) :: Integral d => d
λ> liftS2 (+) (1::Word8) (2::Word16) 
3
λ> let k = liftS2 (+) (1::Word8) (2::Word16) -- дефолтный тип
λ> :t k
k :: Integer

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

ты даже список оч. нужных фич этих сотен кода никакой не привел - в выхлопе ls я и покруче могу циферку нарисовать. :)

Ну раз ты предполагаешь что я соврал - дальнейший разговор бессмысленен. И да это система digital asset delivery, обслуживает кучи теле и радиостанций, состоит из тысяч нодов, ноды могут разными начиная от дескопных приложений и заканчивая кластерами транскодинга.

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

Не, C++ на порядок сложнее, в нём есть сотни

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

Это звездец какой-то «C++ хороший потому что там на порядок сложнее».

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

Для массовой утилизации быдлокодеров-формошлепщиков же.

facepalm.

Алмазов мало, добывать («воспитывать») долго и дорого:) В основном уголь...

Еще один. Наспьс себе уже в еду стекла - переваривать будет на порядки сложнее - будешь считать себя бриллиантом чистой воды.

Эта звездец.

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

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

повторяю: чудес не бывает. Вот тебе такой пример: сколько ресурсов надо, что-бы выкопать канаву? Предположим, что 100 лет назад, тебе эту канаву трое землекопов выкопают за 3 бутылки водки ($20 сегодня). ИЧСХ, сегодня, один экскаваторщик пригонит свой экскаватор, и выкопает ту же канаву за те же 3 бутылки водки / $20. Только он её выкопает за 5 минут, а не за 4 часа. Тебе от этого легче? Особенно учитывая то, что экскаватор с объекта ты не сдёрнешь в любой момент, и тебе всё равно придётся ждать. Те же 4 часа в среднем, ЧСХ.

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

Чем больше тренинга требуется для умения владеть инструментом - тем он хуже среди других инструментов делающих тоже самое.

По твоему экскаватор намного хуже простой совковой лопаты? Лопата она ведь тоже Тьюринг полная, ей можно любую яму выкопать.

Знание потрохов С++ не увеличивает квалификацию человека как инженера - это не фундаментальные знания в области CS. Это узкий скил работы со странным инструментом только потому что инструмент так устроен.

Ну ещё раз: C++ НИКАК НЕ УСТРОЕН. Это ты программист, ты его и устраивай. Или юзай какой-нить boost, в котором уже сделали «как надо». Если оно тебе надо, конечно.

Чтобы уметь пользоваться исключениями в любом другом языке - нужно просот понимать что такое исключение. В С++ к этому еще прилагается мануал «что нужно знать конкретно в ++ чтобы исключения не отстрелили тебе ногу». И так по куче тем. Безотносительно конкретики - любой инструмент который обладает такими свойствами _хреновый_.

м... Тут ты наверное прав. Есть некоторая разница между «знать» и «понимать». Любой школьник(выпускник) знает теорему Пифогора, но далеко не любой её понимает настолько, что-бы например её самостоятельно доказать. Да, для C++ необходимо _понимание_

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

Это ж у любителей плюсов слепота какая-то на глазах и они не видят что рынок задач на плюсах за 10 лет схлопнулся.

не схлопнулся. Да, стал меньше.

Намного меньше стал в относительных цифрах, потому-что сейчас многие тыщи строк говнокода пишут на всяких php и там C#, и даже на java тоже говнокодят в огромных количествах. (дело не в языках. Говнокодер будет писать говнокод и на C/C++, это ничего не меняет)

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

Но ещё полно C++, причём сейчас часто весьма годного.

А вот твоего хаскеля как не было, так и нет. Да и не будет ИМХО. И не мечтай. Учи php, если жить хочешь. Ну или иди в дворники... Всяко выгоднее хаскеля.

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

Сотни тыщь строк кода на с++ подобном языке. На С++ такое не напишешь никогда. Потому и не пишут.

ты не поверишь...

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

Он про инструменты хорошо сказал... веско как бэ. Метафора только с оружием (да и с инструментами из ИРЛ) не работает почему-то :)

ещё-бы она работала...

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

не могу не согласиться.

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

Я не буду с вами и вашими самодельными проблемами спорить. Честно, мне просто надоело. Тут уже хватает stevejobs, lovesan, r и прочих элитных ололо. УМВР. если у вас не работает с++, не пишите уже на нем. ну раз такой он страшный.

вы наверное неправильно поняли мои слова: речь там выше про ядро была, ядро как известно на C++ не пишут. Я и пытался объяснить — почему.

А лично мне C++ нравится. И да, ядра для OS я не пишу.

правда, надоели придирки вида «а если мы напишем на с++ говнокод, то почему с++ такой плохой»

мне тоже надоели...

Моя позиция в том, что C++ здорово облегчает жизнь. Лучше, чем любой другой ЯП. Вот только думать и/или копипастить C++ за тебя не будет. Даже и не попытается. Особенно думать. Да, это такая традиция ещё с сишечки — обратился к одиннадцатому эл-ту десяти эл-ного массива — компилятор не будет думать за тебя, а сделает ровно то, что ты и сказал. Скажешь «раздели на ноль», компилятор сделает код, который будет делить на ноль. Арифметику в школе должен был программист изучать, компилятор в школе не учился. У него свои тесты, которые он успешно прошёл.

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

Ты еще не предложил на работе у вас насыпать битого стекла и простреливать коридоры с нерегулярными интервалами? Так будет еще сложнее жить - сможешь себя считать еще круче. Это звездец какой-то «C++ хороший потому что там на порядок сложнее».

у меня для тебя плохие новости, ОЧЕНЬ ПЛОХИЕ:

ЯП это отражение реальной жизни, а реальная жизнь ещё сложнее, чем даже C++. Причём сложности либо надо как-то учитывать, либо сделать вдоль. Третьего не дано. Смирись.

Особенно сложно не просто что-то сделать, а ещё это что-то поддерживать. А ещё сложнее, если ты не один.

Даже если один, всё равно это полезно. Я сам как-то забил сделать деструктор виртуальным. И сам же потом удивлялся. Зачем мне это надо? С другой стороны, если-бы Страуструп сделал ВСЕГДА деструкторы виртуальными, это было-бы тоже плохо. Иногда надо НЕ виртуальные. Да. 1 из 1000. Да, дефолт 1 из 1000. Да, если в твоём коде деструктор не виртуальный, то ты — быдлокодер. Гарантия 99.9%. За то я знаю чего от тебя ждать, и чего ждать от твоего говнокода. В Java не так... Там хрен поймёшь, что от этого кода ждать, и насколько он годен.

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

Эта звездец.

Этот звездец целиком в твоей голове :) Агитируешь за членовредительство там, где ИРЛ херилось бы ТБ в угоду ложнопонятому «удобству». Зачем носить каски... Давайте отменим кирпичи и здания высотой больше двух этажей (один из которых - подвал) :) «Будем строить коттеджи соединенные подземными переходами» (с)

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

А зачем Sup не используется?

instance (Integral a, Integral b) => Up a b where up = fromIntegral

*Main> up (2^63 - 1 + 1 :: Integer) :: Int
-9223372036854775808

плохие инстансы затесались, то есть не вложения. Плавающие числа не работают, как и прочие вещи (... => Up a b не оставляет возможности настраивать инстансы). На самом деле (+) будет работать через Integer (или через то что в default у Num — -Wall скажет что «Defaulting the following constraint(s) to type `...'» и в core видно). Точный sup для последующего использования с (+) не выбирается.

Идея с liftS2:

-- http://en.wikipedia.org/wiki/Monomorphism, http://ncatlab.org/nlab/show/subobject
class a :>-> b where
  embed :: a -> b

instance Word8 :>-> Word16 where
  embed = fromIntegral

instance Word16 :>-> Word16 where
  embed = id

-- http://en.wikipedia.org/wiki/Join_and_meet, http://en.wikipedia.org/wiki/Pushout_(category_theory)
type family a :\/ b :: *
type instance Word8 :\/ Word16 = Word16

liftS2 :: (a :>-> c, b :>-> c, c ~ (a :\/ b)) -- O_o
       => (c -> c -> d) -> a -> b -> d
liftS2 f a b = f (embed a) (embed b)

так Word-ы, Int-ы и выбирается ровно sup, то есть Word16, на нём работает (+):

*Main> :t liftS2 (+) (1 :: Word8) (2 :: Word16) 
liftS2 (+) (1 :: Word8) (2 :: Word16) :: Word16

но так ли оно надо

Вообще да, но из всего этого я бы хотел стандартного класса (:>->) — с только тотальными инстансами, ценен не сам он, а эти инстансы, то есть единожды сделанные эффективные безопасные преобразования (= вложения) для чего угодно. Вот в C++ безопасные поднятия производятся вообще без кастов, отсюда необходимость городить там такие вещи.

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

Зачем носить каски...

А ты сам носишь ? такие клоуны как ты про правила ТБ (MISRA например) наверняка ничего и не слышали.

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