Добрый день...Полистав топики и форум заметил что большая масса людей подло кидает «Отца хорошого кода C++» и бегут туда где деньги. А от молодого поколение вобще почти не встретишь кто планирует свою судьбу с С++ связать...? теперь вопрос по сути не приведет это к смерти «ОТЦА». и кто какие перспективы видит в С++.
1. Embedded.
2. Qt.
3. GameDev.
от такі перспективи для плюсятников
dou.ua/...ic/7480/#318187
i.imgur.com/e5egMa1.png
і такі
twitter.com/...654331246747649
" :( вышло прям как с nokia qik — тоже весь московский офис из 30+ с++истов внезапно принял ислам"
Ну и что...
Ну да , разогнал гугль 80 сишников в Харькове, и какое отношение это имеет к «преспективам С++». Разогнал 80 , наймет 100, где нибудь в Киеве или Мумбае, а может и в том же Харькове.
Не понимаю, зачем смешивать внутренние разборки/поглощения/открытия/закрытия между кампаниями к преспективамя того , или иного ЯП.
Ну и что...а то шо як пише Я.Войтович:
По этим и по другим причинам рынок труда сокращает свою потребность в плюсовиках, это медицинский факт.
процессоры и всякое там низкоуровневое программирование каких-то дров тоже не нужно, ибо сложно всё, и постоянно становится ещё сложнее, поэтому, то же не вижу перспектив развития!!1
«Отца хорошого кода C++»
Чуть со стула не упал. Если бы упал, то от грохота бы упал Chrome с «опаньки»
Думаю 2 плюса перейшли в один ряд із С, Паскалем, Ліспом і т.п. тому вивести його можна тільки Ванішом)
Я б і сам з радістю вивчив його, але думаю на даному етапі всі його «вкусняшки» не потяну.
23 Роки? сеньйор? =D
Я ж не словничок збирався заповнювати)
Так что С++ юзали , юзают и юзать будут.
С++тільки там вдруг може бути якийсь велосиепед, наприклад не STL a EASTL
Так что С++ юзали , юзают и юзать будут.по селах теж ще на фірах із кінською тягою їздили, їздять, і будуть їздити
тільки там вдруг може бути якийсь велосиепед, наприклад не STL a EASTL
Ну так вся красота С++ и заключается в борьбе и понимании всяческих лисапедов, написаных задолго до вас/нас.
Где уж там писать на какой то Жаве или С#/.net с готовенькими фрэймоврками — скукотища...
лол, просто лол.
Давно написано-перенаписано, що або С або Жава/С#
вся красота С++ и заключается в борьбесадо-мазо,
понимании всяческих лисапедов, написаных задолго до вас/наскропто кодо цінителів
Жаве или С#/.net с готовенькими фрэймоврками — скукотищатак хтось може працює за гроші, а не за цікаві проекти
Судя по по конфе Going Native, которую организовала в начале февраля Microsoft и пригласила туда Страуструпа, Александреску и Саттера, слухи о смерти C++ очень сильно преувеличены :)
С++ будет жить. Я вот уже учу этот чудо язык. Потому что без него никак... Винапи еще никто не отменял. Как посмотрю, куда не полезь... Лезешь в Веб, там CSS, HTML, JavaScript + (C#,Java,PHP) ... Сейчас сижу над таской, где буду юзать винапи.
Винапи никто не отменял? Расскажите это джавистам. Передавать 100500 переменных в 1 метод чтобы создать файл — спасибо, не надо.
Далеко не всегда можно без них обойтись. Фреймворки не всемогущи, они покрывают только общеиспользуемые функции, тоесть те что постоянно нужны, но если вам нужно что-то экзотическое то велком.
а расскажите тогда что такое есть в винапи чего джава не покрывает?
(если джава может так, снимаю шляпу)
Дальше, попробуй сделать, чисто на джава, такую же штуку как:www.microsoft.com/...s.aspx?id=22917
На джава=) Без винапи). Если влом заходить по ссылке, то что она делает:При вводе текста в ЛЮБУЮ(даже чужого приложения) текстовую область открывает небольшое окошечко с выбором нужного иероглифа, прямо над текстовой областью.
Я бы мог бы перечислять что НЕ может джава. Но думаю Вы меня поняли. Я не поклонник С и С++, но они будут жить еще ОЧЕНЬ долго.
Так и запишем. Для извращенцев оставим винапи.
Недавний пример из жизни. Есть libVLC, которая используется для вывода видео, как ни странно. Надо контекстное меню сделать в винде, при этом сама либа не передаёт никакой информации о том, что был клик по окну с видео. Вариант только один (если не лезть в саму либу) — хук на мышь.
Можно еще найти окно с видео и сделать subclassing (подменить WNDPROC)
Спасибо, в курсе, выбрал то, где меньше кода :) Хотя subclassing по идее несколько более красивое и правильное решение.
Ну, я думаю, оба варианта имеют право на жизнь :) Но у low-level хуков есть недостатки, например timeout на выполнение HookProc, после которого они слетают
Вы говорите про десктопные апликации, но сейчас мир движется в сторону вэба, а там ваш винапи нафик не нужен.
Согласен, мир движется в сторону разработки мобайл приложений, планшетов, и облачного SaaS. Я поностью с этим согласен. Так же, я говорю о том, что десктоп приложения еще будут существовать лет 20. Так что по етому поводу волноватся не стоит. Я вот уже начинаю пересматривать свои взгляды на жизнь, и на сферу в которой хотелось бы работать. Может перейду вообще на HTML 5 + JavaScript.
HTML 5 + JavaScript рулит, вроде даже десктоп апликации на Windows 8 будут разрабатываться на этой связке. Но конечно для С++ и Дот.нет разработчиков еще долго работы будет хватать, даже на Дэлфи еще проэкты есть :).
NoSQL(mongoDB) + Node.js vs ASP .Net + MSSQL) Кто же выйдет победителем?
А какое имеет отношение винапи к С++? Если мне не изменяет склероз WinAPI на чистом C написан.
А если мне не изменяет память то в WinAPI около 10к функций(может чуть больше или меньше, я знаю примерное количество). И вы уверенны что все там написано на С?
Коментар порушує правила спільноти і видалений модераторами.
Уверен, что не только на С, не сомневаюсь что там полно ассемблерных вставок в местах, где скорость выполнения критична.
Но в любом случае, 10к функций, а классов сколько? Функции, это же все же фича не выходящая за границы чистого С.
Вы можете вспомнить хоть одну фичу WinAPI которая использует специфические особенности С++? ну там может какие-то абстрактные классы есть? Потоковые классы ввода/вывода юзаются, STL? Я, конечно, уже года три не юзал WinAPI, но что-то с ходу ничего такого припомнить не могу.
Буду рад, если просветите.
К сожалению, я в данном вопросе слаб, я их использовал, но привести конкретный пример, WinAPI фичи написанной на С++ или использующего абстрактные классы, не смогу.
STL используется, только очень скудно.
И то что винапи не куколка стиля С++0x, а монстроподобная смесь С и С++ так это уже другой вопрос.
C++ там только в COM. И то COM можно на С юзать ) А где там STL?
#endif /* __cplusplus */
вы же не будете спорить о том, что нахождение в границах __cplusplus не является плюсовым кодом?
А где там STL?
Насчет СТЛ — прикольно, не знал, что есть такое :)
В тыренные исходники win2k загляните. Ядро и библиотеки типа ntdll, kernel32, user32 — на чистом С. Но в shell32, comctl32 и т.п. используется C++.
к счастью я это уежище уже лет 8 не видел и надеюсь больше не увижу. Это надо быть тонким ценителем или просто не иметь выбора
Я тоже надеялся, когда шел работать C# WPF девелопером, но иза кривизны самого .Net и его «совместимости» с COM конролами, получаются вот такие вот вещи:
i.stack.imgur.com/tL0r7.png
фу блин жесть, хорошо у нас в java такой фигни нет
Листбокс — КОМ компонент?
Да. А теперь, представь что тебе нужно сделать, что бы MDI интерфейс правильно работал не прибегая к Винапи, причем от COM компонента уйти НЕЛЬЗЯ(в моем случае это не лист бокс). Эта вот «совместимость» будет перыкрывать ЛЮБОЙ WPF конрол который лежит в этом же окне(тоесть любая панель которой посчастливится наехать на этот лист бокс, будет перекрыта). В итоге, все панели с канвас айтемов нужно выносить в окна, но сдесь рождается одна проблемка. Окна сами по себе ездить за главным не будут, и вылазить за пределы окна смогут запросто. Сей факт идет в разрез с техническим заданием и нужно это как-то править.
А при создании СОМ компонента указывается HWND, куда его поместить? Помню, IShellView у меня нормально получалось с WPF завязать.
Винапи еще никто не отменял.
Разве винапи — это Си?
Да. Но уже давно начали появляться всякие ооп-расширения, типа ГДИ+
forum.sources.ru/...c=307437&st=105
С-код используется в основном для “серверов” под Linux. Тот же SQLite (в принципе, так себе... “серверок”, если это можно так назвать). Но, тем не менее, это С. Про остальные проекты, которые я здесь упоминал, повторно упоминать не будем. Там то же С. Т.е., отсюда простой вывод — для сервера под Linux необходим и достаточен язык С. Большего не нужно.
А вот клиентская часть это зачастую просто Java-приложение. Оно просто работает на любой из настольных платфром. Что на Linux, что на винде, что на маке. Причём, действительно — написано единажды, работает везде. Выгодно. Писать удобно. Но, вдобавок, надеюсь ты не будешь спорить с тем, что Java это не С++? :D :D :D Так что, как видишь, и здесь С++ мимо. Есть Java.
Отсюда, мы получаем два “основных” языка. Если угодно, “тренда”. Учитывая лавинообразное распространение (слава Богу, не в России, иначе такие мишары весь мозг наживую достанут) Linux, получаем потребность в С для “серверов”. Если не веришь что это быстро и просто, то глянь на xmlrpc-c. И на примеры в том числе. Кстати, там у тебя чёт про парсинг XML врукопашную было? Это фигня. Это не надо.
Второй “тренд” это именно Java. Нефиг один и тот же код по три раза пересобирать. Для пользовательских приложений это лишнее. Кстати, если будет желание, то можешь взять NetBeans, OpenOffice SDK и посмотреть как на Java под NetBeans пишутся вещи (там есть примеры) для “опенофиса”. Довольно наглядно. И “десктоп-приложение” и всякие расширения. Но это — если будет желание. Нет нужды в каких-то извратах. Офисное приложение (во всех смыслах этого слова) ваяется в два-три счёта. И поддержка баз данных и отчёты и формы. И, самое главное, кроссплатформенность. Этого не денешь ни куда.
Так что я в упор не вижу в С++ ни панацеи, ни “электронного микроскопа” тем более. Даже кувалды не вижу. На данный момент само время показывает его (С++) ненужность. Но что поделать — эволюции без ошибок не бывает.
Гы, то же самое рубисты говорят про Джаву :)
Т.е., отсюда простой вывод — для сервера под Linux необходим и достаточен язык С. Большего не нужно.
но ведь С++ это то же самое только быстрее(время разработки) удобнее типобезопаснее и иногда даже производительнее. при этом все возможности С сохранены.
Это Линусу Торвальдсу объясните. А то он не понимает.
ИМХО же
Если писать на С++ с сохранением всех возможностей С — то какой тогда смысл?
Типобезопастность же на С++ не бесплатна. Расплатой является потребность использовать как-то... «заумно» реализованную объектно-ориентированность.
А в последнем стандарте кажется еще и лямбды добавили?
Другой аргумент — смотрим на D и сравниваем с С++. Именно недостатки С++ и пытался убрать Брайт в своем языке. (впрочем как и создание Go — тоже попытка уйти от С++)
Не взлетят правда проекты в целом наверное. Но показательны в качества эталона — «что очень плохо получилось в С++».
Страуструпу же респект и уважуха. Очень сложную задачу он взялся решать, и раз С++ в 10ке основных ЯП — решил ее удовлетворительно.
Типобезопастность же на С++ не бесплатна.
в компайлтайме бесплатна
мне такие темы весьма доставляют))
О зарплатах — C++ идёт вверх и будет идти, потому что никто переписывать работающие программы на какую-то там #### (чтобы никого не обидеть) не будет — это раз.
О языках.Мечта изобрести простой, мощный и т.п. язык настолько давняя и породила настолько много различных ####s, в которые вбухали $##,###,###,###, что то, что C++ ещё после этого всего держится — говорит, что это хороший язык. Всё остальное — повод взять и попробовать сделать свой язык. Как минимум провести анализ и написать новую книжку-сравнение на уровне не только синтаксиса, но и паттернов разработки, стоимости поддержки и т.п. Это было бы интересное и поучительное исследование. Без этого вести спор сложно.
По поводу Линуса и его мнения. Господа. Он умеет писать на C. Если бы мы все так умели писать на C нам не нужен бы был C++. Но его мнение не всегда единственное — во многих вопросах он расходился, расходится и будет расходится с программистами/архитекторами не меньшей величины чем он сам. Просто он хорошо пишет на C. Наверняка есть вещи, которые другие делают лучше него. Это очевидно.
Я вообще не могу понять. Почему Lisp и C (старые языки) живут и к ним большое доверие, а всё что было после — как-то уже не очень. Что тут играет роль? Простота?
Для того, чтобы похоронить C++ надо изобрести что-то лучшее, чем C++.
И потом, ООП ещё никто не отменял.
Да, согласен, ООП vs performance — интересная тема, но в том то и прелесть, что всегда можно соединить С и С++ код. Это самое гениальное, что есть в C++.
Беда C++ на мой взгляд в том, что люди увлекаются сложностью. Или наоборот, те, кто ею увлекаются, берут C++. А на деле можно брать от C++ столько, сколько нужно. Пишите на C и компилируйте C++. Разве лишние возможности вас ограничивают?
потому что никто переписывать работающие программы на какую-то там #### (чтобы никого не обидеть) не будет — это раз.
Так и запишем, ц++ программисты нужны исключительно для разгребания кодопомоек
Я бы сказал, что C++ - это технологическая платформа, 20 лет предлагающая адекватные времени методы за счёт того, что сгружает многие функции на уровень библиотек. Хотел бы я посмотреть на программу на другом языке, в которой соседние файлы могут иметь такую большую разницу в возрасте.
С другой стороны, есть языки, нацеленные на долговременные проекты. C++ не является таким языком (недостаточно был стандартизирован изначально). Но, за счёт «всеядности» хорош сейчас, как и 20 лет назад.
Помойки не есть good, но никаких больших городов, даже с солидной историей, без помоек не бывает.
Не только. Некоторые кодопомойки весьма свежи. Android например.
Я не сильно в курсе но вроде там ц + джава в основном.
На Яве только верхний апп-слой, незначительная часть самого Андроида. Под ним 11 млн строк библиотек, в основном на C++, и 9 млн строк линукса, на C. (По данным на позапрошлую версию)
основном на C++С++ у вєдроїді обрізаний по самі яй
Вот как.
Я вообще не могу понять. Почему Lisp и C (старые языки) живут и к ним большое доверие, а всё что было после — как-то уже не очень. Что тут играет роль? Простота?
Есть мнение, что Common Lisp мощнее любого современного mainstream языка.
Язык без либ и пула разработчиков ниче не стоит. И если по первому пункту еще можно говорить, то по второму лисп пролетает.
Ну «ничего не стоит» это очень громко сказано, но в общем — правда.
В каком-то смысле да, если мерять мощность как количество работы полезной, которую можно запрограммировать в единицу времени то функциональные языки может быть уступают только логическим, но по последнему пункту не буду спорить из-за слабого знания Lisp.
paulgraham.com/avg.html Пол Грэм хорошо пишет
Тока програмулину которую он на лиспе написал и потом яхе продал почему то на джаве потом переписали.
Ну да, яхе гораздо проще и дешевле искать джаверов для поддержки/модернизации
В 98 году когда купили конторку Грехема думаю не легче было.
Спасибо. Не пожалел времени, прочитал всю статью.
Если интересно, напишу какие мысли в голове возникли (надеюсь, вы тоже не пожалеете времени прочесть многабукв :)
1. Первый язык — Lisp.
Давно придумали, посмотрите учебные программы Mit и Berkley.В последнее время я посылаю людей (инженеров смежных специальностей, которые после окончания института решили перейти в IT и претендуют на моё свободное время) читать SICP. Пока не могу сказать о чисто методологических результатах эксперимента — читать читают, лекции по дороге слушают, но примеры не делают (все хотят быстро и сразу программировать и получать $$$$, после чего мы имеем Как корректно объяснить человеку, что он вам не подходит). Но это социальная проблема, поехали дальше.
2. Lisp поможет вам делать лучшие стартапы.
Даже очень может быть. Но есть вероятность, что после подключения инвесторов вы будете переписывать. Недавно помогали с написанием автотестов одному стартапу. После того, как его проинвестировала (или купила, не помню) одна известная фирма, занимающаяся, в том числе, web search engines, они поменяли не только язык разработки (теперь там Python а не PHP) но и набор тестового инструментария (нет, им не лень переписывать работающие тесты).
Вообще, о стартапах. Многие мои коллеги (особенно те, которым сейчас по ~35) делают стартапы. Не исключено, что количество опытных кадров в стартапах больше чем в аутсорсе. Правильно, что люди начинают своё дело — это результат унылости многих местных компаний. Но не всегда правильно, что люди видят это только в плоскости стартапа = чего-то быстрого, на чём можно быстро заработать деньги и также быстро отдать свою долю инвестору. Прочитайте эту статью Джоуля (где-то она, вероятно, есть и на других языках). Сегодня она, я думаю, актуальна и для нас с вами.
Учтите, что бизнес работает на _средних_ идеях. Не на лучших, не на худших а именно _на средних_. Идеи, которые обгоняют время в стартап не пойдут. Автор говорит, что у вас будет технологическое преимущество. У вас оно будет, когда созреет рынок, а до тех пор вы должны назначить ему свидание в будущем и идти на встречу (вот так выделил своё ИМХО). Я делаю это с Prolog. Вы делайте это с Lisp и любым другим языком, который завтра будет новым Java или Python, а сегодня у него ещё только малая группа. Вспомните, сколько было поклонников у Python в нашей стане лет 10 назад. Уже тогда, многие знали, что это хороший язык.
A startup should give its competitors as little information as possible.
(цитата из статьи)
А преимущество долгоиграющей идеи — вы можете её спокойно обсуждать, ничего не опасаясь, ездить на конференции, создавать сообщества. Мне кажется, Lisp ещё недостаточно звучит на украинских конференциях, чтобы выстрелить как технология (не стартап), делающая деньги.
3.
if you bet on the wrong technology, your competitors will crush you
(цитата из статьи)
Я работал 5 лет в фирме, которая исповедует этот принцип по отношению к языку Ада. Безусловно, это стратегическая находка — программы надёжны как рельса, быстры почти как C (моё почти — это в адрес конкретного компилятора), на них работают сервиса активно гоняющие данные по 30000 соединений (информация
Обратная сторона медали — барьер выхода для сотрудника из компании очень высок. А это, разумеется, даёт много неочевидных возможностей менеджменту ... и я никогда не буду создавать компанию одной редкой технологии, потому что я испытал это на собственной шкуре.
4. Я Lisp не знаю, но, мне кажется, его недостаточная популярность объясняется ещё и тем, что у него много клонов. К примеру, представьте, что все бы поставщики Linux объединились и сделали один дистрибутив для десктопа ... у Windows пока есть преимущество (то же было и с Unix, кажется). Язык, который пропагандирует свободу никогда не будет очень распространённым.
5. Я использую Emacs. Он написан на Lisp. Мне этого достаточно, чтобы почувствовать, что Lisp гениален и даже очень практичен.
6. Согласен с главным — языки разнятся в мощности. C++ есть смысл использовать, когда решение на более мощных языках не подходит. Когда мне надо было написать SSH сервер под Windows я взял C++ (хотя, вероятно, Ада сообщество недоумевает по этому поводу и считает меня ренегатом).
Вообще, мы, программисты, должны знать много языков. Вопрос приверженности не должен иметь влияние на выбор языка для конкретной задачи — смотрите причины в пунктах выше. Мы должны хорошо знать алгоритмы, представлять внутренности ОС и СУБД, уметь считать O(.), строить диаграммы классов не хуже, чем в Java API ... и ещё мы должны знать много разных языков. ИМХО.
P.S. В Днепре, кстати, есть фирма (совсем не стартап), куда набирали Lisp-программистов. Но у меня ощущение, что переписывать на Java.
Цікаво, післяВообще, о стартапах. Многие мои коллеги (особенно те, которым сейчас по ~35) делают стартапы. Не исключено, что количество опытных кадров в стартапах больше чем в аутсорсе. Правильно, что люди начинают своё дело — это результат унылости многих местных компаний. Но не всегда правильно, что люди видят это только в плоскости стартапа = чего-то быстрого, на чём можно быстро заработать деньги и также быстро отдать свою долю инвестору. Прочитайте эту статью Джоуля (где-то она, вероятно, есть и на других языках). Сегодня она, я думаю, актуальна и для нас с вами.
Не пошкодував часу перечитати весь комент
Для цього існують Y Combinator та інвестори
С Лиспом та же ситуация, что была с Питоном несколько лет назад («Python paradox») — если человек на нем пишет, то точно не из коньюктурных соображений, а потому что ему это нравится => выше вероятность, что он хороший программист. Но когда проекты разрастаются, становится сложно искать новых разработчиков и находить замену ушедшим. Поэтому и переписывают на джаву, дотнет и прочий мейнстрим.
Нет, реальная причина не в недостатке программистов. Фирмы заинтересованы в высоком барьере выхода, а научить junior хоть на java, хоть на python — одна и та же работа. Для Senior тут вообще вопрос не стоит — за что платят, на том и пишут. Для удержания сотруников Python is good.
Проблемы 2, как мне кажется:2. Все хотят плыть в хвосте акулы. .NET двигает M$. Java двигала Sun, сейчас, может быть, на спад пошло, потому что, вероятно, не понятно, какие планы у Oracle. C++ двигается как-то сам за счёт программистов, но их много. А вот Python или Ada или Prolog — welcome guys, вы будете двигать его сами. То есть разработка на Аде — из 1 мегадоллара 300K может быть, в результате, неявно проинвестировано в поддержку и развитие самого языка. Накладные расходы, однако.
Но с Python, мне кажется, дело обстоит получше, чем с Адой. Смотрите динамику роста, наверное. А вообще, всё зависит от того, что вам надо и на сколько необходимо (и по каким соображениям) держаться mainstream.
Нет, не правильно. На обучение яве нужно в 5 раз больше сил чем на питон или руби.
Ничуть.
ява куда проще и питона и руби. До убогости.Сложны в освоении профессиональные, промышленные фреймворки на ней.
Рельсы вот тоже сплошная магия. Знания языка руби — необходимо, но недостаточно если решил влезть внутрь и понять как они, рельсы устроены.
Нет, не правильно. Популярность явы угасает, популярность питона растёт. И уж совсем трудно найти сегодня что-то мейнстримнее питона, ну может руби.
И уж совсем трудно найти сегодня что-то мейнстримнее питона, ну может руби.
Сказки какие, питону и руби до джавы еще как до луны: www.indeed.com/...,python,ruby&l=
ничуть.
Питону и Руби не удалось даже PHP существенно потеснить.Куда уж им до Java, ЯП с статической типизацией, куда более серьезной ВМ, и огромных количеством сложного но работающего кода.
Можно точно сказать:Будущее ЯП как платформы зависит от количества УЖЕ вложенных бизнесом в нее денег. По «капитализации» сложно найти нечто дороже чем Java.
Да, согласен, ООП vs performance — интересная тема, но в том то и прелесть, что всегда можно ...
В теории, коллега, к сожалению в теории. На практике же эти два плюса — два могильных креста. А жаль, в хороших руках плюсы — замечательный инструмент... :)
в хороших руках плюсы — замечательный инструмент.Народна мудрість каже, що в руках майстра і ххх — балалайка.
Итог: Си++ - инструмент весьма узкого применения.
Нужна производительность — пиши на Си.
С++ - он удобнее, безопаснее, часто быстрее, ибо больше возможностей для инлайна, да и возможностей в целом больше
С++ - он удобнее
Нет. При кажущейся няшечке в виде классов, плюсы всё равно раздувают нерелевантную сложность, в виде объектных моделей, архитектур и пр, что приводит к трате времени зря — не на задачу, а на архитектуру.
Ололо? О какой безопасности может идти речь в вермишели из нагромождения архитектуры с поинтер-арифметикой? Тут иной раз понять трудно что сам написал на STL, какая тут безопасность?безопаснее
Инлайн — это повышение производительности приложения на долю процента. А в это время, производительность скриптовых языков вбольше возможностей для инлайна
да и возможностей в целом больше
Если на выполнение задачи на Си++ у тебя ужодит в 2 раза больше времени чем на Руби, то возможностей у тебя в два раза МЕНЬШЕ.
это пока заказчик один, хороший менеджер ему впарит все что угодно и тот еще и счастлив останется.потому что главная ценность на сегодня — это скорость разработки, и может быть время разработчика.
а как только появляются пользователи, которые могут не купить из-за того что оно по ощущениям притормаживает все сразу меняется.
Какой сложности проекта — вот в чем вопрос.Нужна скорость разработки
Будем считать что эффективность работы конечного приложения нас не интересует.
Так вот чем проще проект, и чем меньше в нем задействовано людей — тем быстрее будет разработка на ЯП с динамической типизацией.Чем сложнее, и чем больше в нем задействовано людей — тем быстрее будет разработка на ЯП с статической типизацией.
Это проверено уже десятилетиями программирования как вида деятельности.Много надежд возлагается сейчас на ЯП с выводимыми типами, типа Haskell и Scala. Поживем увидим.
Но учитывать зависимость скорости разработки от инструмента нужно обязательно с таким параметром как — сложность проекта, программного продукта.
Чем меньше молодежи будет идти в C++, тем дороже будут "дедуганы"-сиплюсплюсники. Cпрос на С++ будет до тех пор, пока будут востребованы native-приложения (в смысле, код которых исполняется непосредственно cpu), a они в той или иной мере будут востребованы всегда.
Так таки так, еле є один ньюанс, тре хоч би якийсь хайтек щоб розвивався в цій країні.
дедуган плюсовик получает меньше чем 23 летний синьер со знанием джавы.
смотря где, смотря какой дедуган, смотря какой синьер.
хотя я вообще о тренде, а не об абсолютных цифрах.
А я видел живого КОБОЛ-программиста. И шо? Много людей побежали учить КОБОЛ? Это как-то повлияло на тот факт что КОБОЛ если не умер, то доживает свою старость в забвении?
Когда язык умирает, то не только становится меньше специалистов, меньше становится и задач: новых нет, а старые «консервируют».
Когда валовый объем задач по C++ начнет стремиться к таковому по Cobol, тогда и заговорим о смерти C++. Думаю, такие дискуссии крутились вокруг C лет *дцать назад, а он до сих пор живее всех живых.
так С были есть и будут, а от плюсы заменяют на всё что можно. Ибо если можно обойтись, к примеру, джавой, то зачем мучаться?
Потому что большинство того, что можно сделать на C, можно сделать на C++ и не мучаться.
При этом меньше мест где можна всунуть псевдо-джедайский код (код который понятен только истинному гугу, то есть автору, и то первое время)
С — не проще, он примитивнее.
Линус ответил бы тебе:вот это для меня загадка. мазохизм, не иначе.
*YOU* are full of bullshit.
Это был ответ Линуса человеку с фамилией Какурин. Доставило. :)
А у вас есть статистика? Поделитесь.Когда валовый объем задач по C++ начнет стремиться к таковому по Cobol, тогда и заговорим о смерти C++.
Если это просто домыслы, то вспомните про фин-сектор и штатовскую оборонку.
Думаю, такие дискуссии крутились вокруг C лет *дцать назад
Ну «лет *дцать назад» у меня были другие заботы :), так шо ссылочку мона. Я не слышал ни одной темы про смерть Ц, а вто про смерть ЦПП создают ну раз в год, точно.
Важный момент:Смерть — это не значит, что завтра все закончится. Обычно подразумевают «затухание», то есть нового практически нет, старое консервируют или «переписывают»; из предложений о работе в основном багофикс или докручивание мелочей.
банально:А у вас есть статистика? Поделитесь.
С++ - 8.063%, Cobol — 0.393%.
Если это просто домыслы, то вспомните про фин-сектор и штатовскую оборонку
Боюсь, такое в Украину не аутсорсят. Поэтому встретить тут кобольщика — это почти как динозавра или минимум мамонта.
Про темы о смерти С — слово «думаю» было указано именно с целью подчеркнуть свой домысел. Сейчас их нет, т.к. все давно поняли, что скорая смерть не предвидится.При появлении C++ такое вполне могло обсуждаться: «зачем писать на C, если есть C++, в котором можно почти всё то же, но без гемора». Как сейчас обсуждается «зачем C++, если в жаве можно почти всё то же, но без гемора».
Мир развивается по спирали ©.
Тиобэ отображает количество задач или просто анализирует количество поисковых запросов?
Фотошопы так же. Те ЦПП-задачи про которые я слышал в Украине — это как раз плачевные багофиксы и портирования (сюда же «написание мегавиджета в который отличается форматом поля»)Боюсь, такое в Украину не аутсорсят.
Первое — Киев; второе число — Украина. У ЦПП вычеркнул 2 вакансии потому что это С++ /Java, а скорее всего «просто вписали шо знали».
The ratings are based on the number of skilled engineers world-wide, courses and third party vendors.Тиобэ отображает количество задач или просто анализирует количество поисковых запросов?
Размыто, но рейтинг по количеству живых проектов мне не попадался.
Смерть C++, вроде как, обсуждается в глобальных масштабах. Местный кобольщик — это лирическое отступление.Фотошопы так же.
Да и по жаве, думаю, аутсорсят примерно то же.
Если мы уж говорим про Украинский рынок, то вот:чуть меняем запрос:
jooble.com.ua/...rogrammist-java (486/931)jooble.com.ua/...1-programmist-s (2/5-2)
Ситуация даже лучше, чем по рейтингу тиобе.
Вот где ниша ЦПП?
Никто не говорит, что нельзя. Но C++ позволяет с достаточным комфортом делать и то, и другое.
Умереть он в двух случаях:
1. То, что на нем делается, стало никому не нужным, что маловероятно (об этом было выше)
2. Появилась более удобная альтернатива (как умерли коболы, ады, фортраны, и прочее). Пока такого нет.
Появилась более удобная альтернатива
е критичные вещи писать на джаве ( или каком-то питоне/руби/джаваскрипте/и тд), а мега критичные вещи на Ц
битва цитатами.
Но C++ позволяет с достаточным комфортом делать и то, и другое.
Сколько веб-сайтов на ЦПП? Подозреваю около 0. Почему последний раз когда я ставил автокад он попросил дотНет-фреймворк? — это к вопросу о комфорте.
тут выше приводили мнение линуса о C++, так что не подстава :)
Почему последний раз когда я ставил автокад он попросил дотНет-фреймворк?
Вот скорая смерть дотНета меня не удивит. Вроде как был призван убить жаву, но «не шмогла».
Еще раз повторюсь, C++ - сегодня наиболее универсальный инструмент с поддержкой ООП и генерации native-кода. Прямого конкурента нет, кроме как «тута чуть-чуть на жаве, тута — на питоне, тута на си будет, и т.п.»
наиболее универсальный инструмент
Универсальный не значит лучший или даже эффективный.
Среди конкурентов, а их, по сути, и нет, — лучший и наиболее эффективный. Delphi — где-то лучше, где-то хуже, но уж точно мертвее и ограниченнее.
Подводя итог: на вопрос «умрет ли С++» мой ответ — нет, не в обозримом будущем.Все, иду спать. :)
а их, по сути, и нет,
C#, ObjC, Go, D, Ocaml.
C#,
не генерит нативный код. это жаве конкурент.
ObjC
добавляем. но вытеснил C++ он только с эппловских платформ.
Go, D, Ocaml
нууу... этим бы Кобол обойти когда-нибудь.
не генерит нативный код. это жаве конкурент.
jit компиллер вполне, коллекции примитивных типов, unmanaged mode которого нету в джаве вполне позволяет писать всякие высокопроизводительные штуки.
нууу... этим бы Кобол обойти когда-нибудь.
ну это процесс небыстрый, но есть преценденты www.janestreet.com/...ology/ocaml.php, опять же гугл вполне сможет го в массы продвинуть.
Вот скорая смерть дотНета меня не удивит. Вроде как был призван убить жаву, но «не шмогла».
В дотНете есть WPF, адекватного ответа которому в Java, насколько я понимаю, нет. Печальный пример тому — ArchiCAD, 3D визуализация в котором очень капризна и может дико глючить на одном и том же железе в зависимости от версии драйверов и прямоты поддержки OpenGL в оных (видел эти глюки собственными глазами, если что).
Другое дело, что Microsoft популяризацией Metro и WinRT своими же руками могут закопать дотНет на десктопе, и дать вторую жизнь C++ как средству разработки GUI приложений.
уже страшно что будет с WPF после того как они официально свернули развитие Silverlight и агитируют за HTML5
Сколько веб-сайтов на ЦПП? Подозреваю около 0
Как минимум один есть: www.webtoolkit.eu :) Да и думаю раз фреймворк есть то кто-то его все-же использует))
Ой, не удивлюсь если весь сайт на каком-то пхп, а на самом фреймворке, только примеры :)
.сколько веб-сайтов на С++?
А что С++ разрабатывался для рисования веб-сайтов? :)
Повторяю вопрос:
Вот где ниша ЦПП?
В идеале: Ниша в которой он доминирует над конкурентами.
Для разработки JNI-прокладок. :)
JNI-прокладок
В моем мире JNI — это Java Native Interface, при чем тут ЦПП?
Всё именно так. На голом Си JNI получается совсем корявым, так что Си++ там в самый раз. Вот она и ниша где Си++ доминирует над конкурентами.
Через некий PHP-to-CPP транслятор.
Если не ошибаюсь, то они сейчас забивают на транслятор в пользу ВМа.
Если кто-то знает статистику в строках кода, работающего в мире на том или ином языке — то, поделитесь. Кажется мне, C++ далеко не в конце списка. Серьёзные пакеты работы с графикой уж никак ни на C и ни на Java/.NET писаны, а это огромный рынок, и он полностью под C++.
Если кто-то знает статистику в строках кода, работающего в мире на том или ином языке — то, поделитесь.
Ну так поделитесь ... с цифирками и ссылкой.
Серьёзные пакеты работы с графикой уж никак ни на C и ни на Java/.NET писаны, а это огромный рынок, и он полностью под C++.
Насальніка, а GTK це не сірйозна?
Интересно, если у языка нет будущего и он никому сегодня не нужнен, то зачем в 2011 году приняли его новый стандарт?
никто не говорит что плюсы не нужны. Просто сфера их применения уменьшается.
Чтобы у языка появилось будущее, и чтобы он был всем нужен :)
Стандарт не определяет будущее языка и да, C++ ещё долго будет нужен.
Имхо, c++11 может немного подстегнуть спрос на C++. Кое-что из него помогает писать «меньше букоф» кода, и в целом делает язык удобнее. Долгожданный shared_ptr в стандарте — это вообще экстаз!!! :)
вы бы лучше вопрос про перспективы делфи задали :)
Ха. Вопрос конечно интересный.
Не буду говорить о том, что в Украине есть, хоть небольшое, но Ада сообщество и даже компании, пишущие на этом паскале-подобном языке. Подозреваю, что «студенты
Но вот любопытный факт. В разговорах со многими PHP программистами узнаёшь, что первым языком был Delphi. Почему они это иногда скрывают — не пойму. Очень хороший старт, между прочим, для PHP-ника (судя по наработкам).
ну, это была ирония с моей стороны.
небольшое отступление. у меня самый настоящий языковый расизм, когда речь идет про делфи-программистов. и это иррациональная неприязнь, не имеющая никакого смысла и объяснения.
у других вон подобное к шарповикам или джавистам относится, а у меня к делфи и его окрестностям.
сам я за Си и за плюсы
видя всю производственную кухню изнутри, (как говорил Эрик Картман) адски смешно читать про смерть этого языка или про то, как кто-то куда-то там уходит.
хотя, как говорится, скатертью по жопе :)
Поэтому мое мнение у Делфи еще немного осталось....
С Делфи одно время был бардак, но Embarcadero сейчас мало-мальски его разгребли. В последней версии добавили поддержку x64, и кросс-платформенную библиотеку для Win\MacOS\iOS. Так что по ряду параметров делфи ныне привлекательнее того же C#, и со счетов его списывать рано.
С++ будет жить столько же, сколько и C. C столько же, сколько же, сколько и современные нам ОС. *nix будет жить столько же, сколько и интернет, мобильные устройства и ещё чуть дольше.
То есть, наверное можно прогнозировать с точностью конца света ± некоторого количества веков хаоса.
(Не претендую на правдоподобность, но что вы можете сказать против?)
И тем не менее, сфера применения плюсов уменьшается, как показывает TIOBE. Большинство приложений под мобайл, это джава и обджектив С. А вот сам С стабилен :)
Да, согласен. В C++ изначально был заложен путь некоторой интеллектуальной бескомпромиссности, хватит ли времени и желания всё это изучать у студентов, когда вокруг так много всего вкусного.
Ну, если утвердится более простое и отвечающее времени расширение C, то, может быть, оно вытеснит C++.
Тут есть одна очень большая проблема — компиляторов C++ мало и написание новых — очень сложная, геморойная и нетривиальная задача. Что есть как-бы риск.
С С тут попроще.
Потому что большинство приложений под мобайл — это шлак основной ценностью которого является UI, то бишь поставил, удалил, забыл...
Ну тогда конец света наступит раньше, вероятно ...
а что все солидные проги написаны не на с++ ? :)
так и я о том же, что 90% серьезного/большого софта написано на с++
90% это явное преувеличение, с переходом всего и вся на веб и серверсайд доля ц++ нивелируется.
Не все можно написать на Java/PHP. Начиная с того, что сама Javа-машина написана на С++. Та и скоростью достигаемой компиляторами С++ далеко не каждый компилятор может похвастать.
ДЖВМ да, но ее разработка это далеко не 90% всего большого софта.
Ну, ДЖВМ — это далеко не единственная программа, написанная на С++. Более того, сегодня каждый новый процессор выходит в первую очередь с компилятором С/С++. Только потом там появляются Java и прочая невсегда востребованная хр*нь.
99% программ на PC, которыми я пользуюсь, написаны на С и C++. Начаиная с ОС, антивирусов, всякого рода тулзин по работе и заканчивая мультимедиа приложениями и игрушками.
Во первых Ц сюда не надо мешать, речь о ц++. Во вторых 90% сайтов на которые я захожу написаны не на ц++, а программами я почти и не пользуюсь.
С++ - не более чем расширение С, в 99% случаев обратно-совместимое с оным. Поэтому часто говорят С/С++.
Да, сайты написаны не на C/С++, но софт благодаря которому существуют технологии написания сайтов и вообще компьютерные сети, на 99% обязан С/С++. Начиная с драйверов, софта на сетевом адаптере, свичах, раутерах и заканчивая той же Java VM и браузерами.
С++ - не более чем расширение С, в 99% случаев обратно-совместимое с оным. Поэтому часто говорят С/С++.
Какая разница что там говорят, обсуждается будущее именно ц++, то что ц еще поживет у меня сомнений как бы нету.
на 99% обязан С/С++
Только ц++ в этих 99% занимает меньшую часть.
а скайп юзаете? Если вы на винде, то он на делфи
Теперь ясно, что он такой тормознутый :(Skype).
Я отнюдь не фанат Delphi, но хотелось бы увидеть какой-то пруф неэффективности компилятора или библиотек Delphi, вызывающий заметные невооруженным глазом тормоза в desktop-приложении.
Почему у меня не тормозит?
На маке?
На маке все вапше ок. Но он и под виндой не тормозит.
А линуксовая версия у них на чём? Интересна причина, по которой он периодически начинает жрать 100% CPU...
И жрет 40-100МБ памяти в IDLE режиме.
Я уже молчу, что сообщения могут сутки добираться до соседнего компьютера (хотя ЯП в этом мало виновен... возможно).
Линукс версия вообще жуть, регулярно зависает и перестает отправлять сообщения. Впрочем, она до сих пор в стадии «бета» :)
Криво написанное Delphi-приложение может, например, заметно тормозить из-за любви VCL пересоздавать оконные хендлы при изменении свойств компонентов. Но ключевая фраза здесь — «криво написанное».
Что по вашему личному мнению более перспективно — разработка на C/C++ для Linux или разработка на .NET/C# для Windows (не ВЕБ)?
оба бесперспективны, первое по причине очень маленького рынка, второе по причине рынка с маленькими зарплатами
В попсовый областях, типа веб/десктоп разработки, от с/спп постепено перешли на другие технологии, при этом программы стали немного медленей, стали требовать больше памяти, но визуально изменения скороти пользователи не видят, памяти и так хватате. А бонусом стала немногим более быстрая и дешешая разработка.
То есть, что вы предлагаете? Так как прочитав ваш пост я понял что сейчас важна не внутренность, а внешность — всем все равно на чем оно написано и сколько ресурсов кушает, главное, что красиво, значит разработка на С++ для Linux не перспективна (и не стоит тратить на ее освоение своего времени, а сфокусироваться на .NET/Java)?
Коментар порушує правила спільноти і видалений модераторами.
Десктоп має меншу затребуваність, проекти менш цікаві і з меншим рівнем компенсації, так що я б рекомендував саме веб.
Если смотреть по харьковским ярмаркам вакансий — то вакансий по C++ заметное количество. Я это точно знаю, так как специально подсчитывала — ведь в нашей компании C++ - это основной язык, который требуется более чем в 80% проектов. Вакансии по C++ у нас открыты постоянно и дальше видится, что их будет еще больше.
Действительно, вузы сейчас сокращают изучение С++ - ведь их пинают за отсталость и отсутствие новых технологий. Если раньше основы программирования и ООП были более менее на C++, то сейчас больше на C#. Это тоже вносит свой вклад в формирование мнения осмерти «ОТЦА».
После почти двух летнего перерыва (кодил больше на Java и немного на плюсах) вернулся полностью на C++ - причина тому Qt и моя тяга к железкам. Всё-таки прикольно написать прогу, потом собрать buildroot’ом систему и запустить на какой-нибудь ARMке. Области применения у языков достаточно разные, не думаю, что какой-то сильно потеряет популярность в будущем.
Я знаю, кому нужны С++ знайки. И очень их ищу.
А какие у вас печеньки и няшки?
я Вам напишу, что за компания, т.к. кондитеры из них не очень.
Ну и мне напишите пожалуста. Интересно
Якщо мені не зраджує пам’ять, тобі вони вже якось не сподобались.
Наскільки я при пам"яті, всього-навсьго, вони якось забувають давати фідбек після співбесіди.
Я тобі можу дати їх фідбек, хоч тут, хоч на мило.
Хоча ситуація в цій команді була досить патологічна: В кризу вони набрали п’ятеро термінаторів, а як криза зійшла — то ЦІЛИЙ РІК набирали трьох мідлів, бо кондора дуже жадібна, американська... ;)
Я так розумію, мінус три термінатора, один з них ти.
не-а =)
Общее впечатление: C++ - нафик никому не нужен. Одна джава, питон и руби.
А почему с+±ников стало меньше — так появились новые языки и произошло перераспределение — то, что раньше можно было написать только на с++ или паскале, теперь проще и быстрее писать на других языках. А с++ - остался там, где новые языки не справляются.
Так что смерть наступит очень нескоро. Навряд ли мы дождемся ее %) Наши потомки — да.
:)
Сорри, речь шла о lurkmore.ru/Луговский
(предположительно, скрывающийся под ником Xenocephal в треде по ссылке)
В следующей студии и винде можно будет делать проекты в связке XAML + C++. Что ИМХО несколько лучше чем MFC. Так что определенное развитие есть.
Но ща набегут мастера и расскажут что С++ - это вчерашний день и можно нынче ваять креативы на ПХП, Java и на Клетке.
Та можливість то буде тільки задоволення це сумнівне. Після C# і можливостей IDE інструментарій для С++ не тішить. Ну вийде
Не надо С++ хоронить, он развивается и не стоит на месте, он используется и в огромном колличестве пироектов. Да, до популярности тех же пхп/жава ему далеко ... но и завтра и после завтра С++ есть и будет есть и программеры будут на нем писать свои проги.
На мой памяти С++ еще с начала 2000х хоронят и что.. ? Никуда С++ не делся...
Дистанцируюсь от холиваров.
С плюс плюс не брошу,потому что он хороший
yeah!
сам конечно не долго с плюсами знаком...ну вот когда за # взялся понял что он действительно ярче, хотя не ярче а проще...на много)может это после ++)))))))))))
ВАм не показалось. Он дийсно прост и примитивен, как и весь высокий уровень, ибо затем и создавался, чтобы можно было дешевую тягловую силу пользовать, которая умеет шлепать формочки и гордицца количеством прочитанной доки по разным фреймворкам.
Нет лучше сидеть часами и фиксить бесконечные утечки памяти. Прост? Ну может быть. Примитивен? Посмеялся. Синтаксис должен простым и удобным насколько это возможно, но красноглазикам этого не понять.
В C++ не бывает утечек памяти (при грамотном проектировании — использовании shared_ptr’ов и RAII)
В C++ не бывает утечек памяти
В мемориз! Нееет, В СТАТУС!!!
Я не понимаю, чем вызвал вашу столь бурную реакцию. Есть что по делу сказать — говорите, а если нет — то кричать тут не надо, ваши эмоции мне не интересны.
при грамотном проектировании — использовании shared_ptr’ов и RAII
Если для всех new использовать shared_ptr (который САМ освободит занятую память), либо оборачивать выделение ресурсов в класс, в деструкторе которого этот ресурс освобождать, то утечкам взяться неоткуда.
(en.wikipedia.org/...#Smart_pointers )
А введен в стандарт вроде в C++11.
Но никто не запрещал использовать его без действующего стандарта. В крайнем случае, написать свою реализацию shared_ptr заняло бы полчаса времени.
Это ужасно. Я представляю, насколько все-таки тяжело формошлепам освобождать память вручную. Неудивителньо после этого, что оне достижением считаеют знакомство с очередным фреймворком посредством прочтения его доки.
Потому Ваша фраза больше напоминает другие эпические перлы как «Программы нужно писать правильно», «Правильная архитектура не требует изменений» и «Нынешнее поколение советских людей будет жить при коммунизме».
Даже в проекте ВООБЩЕ без использования указателей обнаруживаются утечки
А это как работает/реализуется/может выглядеть в принципе?
Очень просто. Некое большое нечто с непрозрачной спецификацией (если таковая есть вообще) что-то где-то буферизирует в каком то юзкейсе, а другое нечто это оттуда не выгребает. Юнит тесты не выявляют юзкейс. Прога завершается без утечек, валгринд доволен, багфиксер седеет.
да и если они были выделены динамически, в процессе их выделения/работы ведь указатели использовались. поэтому это уже не «проект без указателей».
так что при чем тут с++ и его проблема отсутствия GC, когда ваш пример может быть легко реализуем в языках с GC.
Да, но: Если есть указатели и нет GC — пространство поиска сильно расширяется, соответственно и затраты на него. А настоящая «сферичность» начинается тогда, когда утечки нет, а выделенная память медленно возрастает. :)
Есть мнение что всякие shared_ptr просаживают производительность больше чем например garbage collector в джаве. Может тогда уж лучше на джаве писать?
Понимаешь, есть такая простая вещь как детерминированность, вот код на С++ полностью прогнозируемый, а вот на джаве нет.
— в джаве можно привязать garbage collector к отдельному core проца и он не будет влиять на latency программы, с поправкой что ей будет хватать памяти.
— в многопоточных апликухах где эти проблемы возникают нету определенности когда вызовется деструктор
Это решается синхронизацией.
— в джаве можно привязать garbage collector к отдельному core проца и он не будет влиять на latency программы, с поправкой что ей будет хватать памяти.
Дело не в latency, а в том, что выполнение программы может быть остановлено из-за тех же проблем с синхронизацией между работающией программой и фоновым garbage collector’ом.
Это решается синхронизацией.
Как это решается?
Дело не в latency, а в том, что выполнение программы может быть остановлено из-за тех же проблем с синхронизацией между работающией программой и фоновым garbage collector’ом.
О каких проблемах синхронизации идет речь? Апликуха тихонько работает на своих корах а garbage collector на своих, никто никому не мешает, никакие программы не останавливаются.
Я так розумію, що якщо хід виконання програми може залежати від того чи знищився якийсь об'єкт чи ні. В плюсах виклик діліт синхронний і RAII рулить.
Я так розумію, що якщо хід виконання програми може залежати від того чи знищився якийсь об’єкт чи ні. В плюсах виклик діліт синхронний і RAII рулить.
Обсуждается джава, и в ней таких проблем нету.
вот и верь после етого людям
гм, а ось тут для таких чайників як я, написано, що GC в джава біжить в окремому треді
javarevisited.blogspot.com/...on-in-java.htmlвот и верь после етого людям
И что конкретно смущает?
проте програмувати деякі речі з GC набагато важче.
Почему тяжелее? Обоснуй? Почему тебе так важно знать когда прибьется обьект?
А привязка GC до іншого кора чим допомагає? Він тепер не витісняється і викликається з меншими лагами?
Тем что он не вытесняет программу и не создает для нее лагов.
А щодо другого. Дійсно приємно що GC не заважає програмі, але я говорив про протилежний випадок, коли програма a kind of "заважає" GC. Хоча знову ж таки згадується суслік.
Приємного дня!
Щодо першого, то я вже повністю висловився, можу хіба додати бородату фразу про сусліка тиеговидишьнетаонесть
Если правильно писать то никакого суслика нету. Идея — не привязывать какие то действия к деструктору, и тебе будет абсолютно фиолетово когда уничтожится обьект, уничтожится ли он вообще — может перезаюзаться например.
А щодо другого. Дійсно приємно що GC не заважає програмі, але я говорив про протилежний випадок, коли програма a kind of «заважає» GC. Хоча знову ж таки згадується суслік.
Програма не может сделать плохо ГК, потому что тогда ей не хватит памяти в какой то момент, она заблокируется и вызовется ГК.
Звісно, що можна написати так, щоб не привязувати якісь дії до деструктора - мільйони програм саме так і пишуться - але казати що це неправильний шлях... пахне сектою.
Это не секта, это подход к программированию в условиях ГК. Хочешь что то делать в деструкторе — готовся к граблям. Или какие другие предложения есть?
Ну перетерли ж уже. Выделять память на стеке не всегда удобно. Если не на стеке то либо ловить утечки, либо юзать всякие shared_ptr и получать проблемы с производительностью flyingfrogblog.blogspot.com/...lower-than.html
проте Майк звернув увагу на тонкі моменти, можливо він мав на увазі щось інше, але я згадав про свій дуже давній досвід боротьби з GC пов'язаний саме з його асинхронністю. І саме тому я і вступив в суперечку, ви ж заявляли про відсутність таких проблем у джаві взагалі, а тепер принаймі кажете, що їх немає, якщо правильно програмувати))) Прогрес наліцо, йопт.
ви ж заявляли про відсутність таких проблем у джаві взагалі
Где я такое заявил?
але я згадав про свій дуже давній досвід боротьби з GC пов’язаний саме з його асинхронністю.
Ты так и не удосужился обьяснить какие именно у тебя были проблемы связанные с асинхронностью ГК.
І саме тому я і вступив в суперечку, ви ж заявляли про відсутність таких проблем у джаві взагалі, а тепер принаймі кажете, що їх немає, якщо правильно програмувати))) Прогрес наліцо, йопт.
Помоему очевидно что на любом языке можно нагoвнокодить, ёпта.
а сборщик мусора в джаве на чем написан и как он узнает что ему освобождать? неужели умные указатели? не может быть...
Ознакомление с этим вопросом можно например начать с статьи в википедии en.wikipedia.org/...mputer_scienceа сборщик мусора в джаве на чем написан и как он узнает что ему освобождать? неужели умные указатели? не может быть...
Это очень не простой вопрос который охватывает много аспектов(менеджер памяти, многопоточность, время жизни обьекта, escape analysis, обработка графов обьектов), и есть альтернативные подходы выигрывающие в разных факторах.
Коментар порушує правила спільноти і видалений модераторами.
дадада, я знаю что там все очень сложно. я о сути говорю — везде подсчет ссылок, как shared_ptr может работать медленнее всей этой прелести?
Коментар порушує правила спільноти і видалений модераторами.
дадада, я знаю что там все очень сложно. я о сути говорю — везде подсчет ссылок, как shared_ptr может работать медленнее всей этой прелести? Возможно вы имеете ввиду, что получая контроль над памятью можно нагадить себе за шиворот
Ну я написал что есть множество аспектов этого вопроса кроме тупого подсчета ссылок, на которых джава выигрывает благодаря более правильным эвристикам. Как пример обработка больших графов обьектов.
посылаю лучи поноса кодеру движка этих комментариев.
к сожалению вынужден прервать нашу беседу
Возможно вы имеете ввиду, что получая контроль над памятью можно нагадить себе за шиворот
Ага. Можно отстрелить себе ноги, а можно построить самолет. Другое дело, что когда программеру не дают возможности отстрелить себе ноги, самолета также точно не выйдет.
это же хотел написать, но креативный движок комментариев не дал :)
чего-чего, какой подсчет сцылок? там более другая матчасть...
чего-чего, какой подсчет сцылок? там более другая матчасть...
А там это где?
В GС, конечно. Ну это зависит от терминологии и классификации, но счетчики ссылок обычно к GC не относят вообще.
PS. Не секрет, что у JVM вобщем-то самый хороший из бесплатно доступных GC.
А можно ссыль про самый «хороший»?..
Утверждение «не существует GC бесплатного, и лучшего, чем в JVM (возьмем Sun)» подтвердить ссылкой нельзя. Можно опровергнуть, приведя пример другого лучшего по производительности. Могу ошибаться, может и есть таковой, но всем GC, которые есть, скажем, в Common Lisp, далеко до JVM’овского.
Коментар порушує правила спільноти і видалений модераторами.
В C++ не бывает утечек памяти (при грамотном проектировании — использовании shared_ptr’ов и RAII)З.Ы. Я бы таким «грамотным проектировщикам» сразу бы отрубал и руки и пиписку, по, я надеюсь, понятным причинам.
Программа, написанная любителями смартпоинтеров, открывает документ, потом его закрывает. Объект документа НЕ УДАЛЯЕТСЯ, остаётся висеть в памяти. И вот в этом смартпоинтерном месиве (а это когда связи владения отследить практически невозможно) надо понять кто же его не отпускает...
вся та сама біда буває і без всяких смартпоінтерів, при чому не тільки коли “надо понять кто же его не отпускает” але також і коли треба зрозуміти хто ж його відпустив і потім заалокував на те саме місце інший об"єкт, і програма собі якимось чудом працювала години (дні) звертаючись до тої самої пам"яті з різних місць, поки нарешті та ділянка не покораптилася настільки, що нарешті вивалилося на segmentation fault, але від точки де вивалилося до точки де відбулося паскудство прослідкувати що відбувалося вже практично неможливо...
Угу. Лучше уж фиксить баги от того, что формочку нашлепал неверно или доку не дочитал. Да-да.
Да. Примитивен. На шарпе можно писать только одним способом, пользуясь лишь одной парадигмой. Спустицца на уровень пониже, когда в этом есть необходимость невозможно. И да, мы говорим не о синтаксисе, а о возможностях, которые в высоком уровне настолкьо ограничены, что даже примитивные формошлепы их осваивают.
А синтаксис шарпа такой же фиговый, как и синтаксис С++. Абсолютно нечитаемая хрень. К тому же, те же самые болезни, что и с ооп парадигмой (которая недооп), что в нем наличествует. Лень повторяцца, читайте в треде ниже мой спор с реалити хакером по читаемости и и с ним же и грезом по оопшности.
Напоминает спор автолюбителей по поводу того, что лучше — механика (с++) или автомат (языки-среды более высокого уровня, то же семейство дотнет). Только вот почему-то механика до сих пор жива, а автоматики в спорте вообще нет %) Я езжу на механике — мне она больше нравится %))
отсюда видно что вы ничерта не знаете С#(.NET), так как там хватает не тривиального. брюзжать слюной на «высокий уровень» (наверное имелась ввиду абстрагированость он железа и т.п.) это удел пещерных обезьян, которые способны только мыслить на уровне разбора байтов и неспособны мыслить на уровне решения проблем, взаимодействия и архитектуры.
C# проще, как и многие другие языки. Но когда на нем работаю (как и в Java) появляется дурацкое ощущение замкнутости и ограниченности :) Вроде и выполнить можно и там и там любую задачу, но мощь C++ меня покорила.
Есть такой закон Фреда Брукса (ни разу не закон, просто закономерность), который гласит, что программист выдает одинаковое кол-во кода вне зависимости от языка. Т.е., скажем программист выдает на гора 500 строк в день, можно посчитать эффективность ассемблерного и С#/Python/Ruby программистов. Поэтому все и бегут за эффективностью, чтобы заработать больше денег.
Например, на Python можно выдать много строк кода. А потом потрать много дней года, чтобы найти все эти чертовы ошибки. А если затыкать все юнит-тестами, так пусть лучше компилятор типы проверяет.
Если человек на Python ошибок наделает, то на C++ ошибок будет как минимум не меньше. На дебаг уйдет больше времени.
И что? ЭТо же не говорит о том, что пистон или С++ - негодные языки, да?
Смотря в чьих руках. Плохие программисты стабильно пишут плохой код и не важно на каком языке. Хорошие — хороший. При этом, абсолютно независимо от качества кода, будут хвалиться своим болотом.
Беру таймаут. Я потерялся в том ,о чем с вами спорил и не могу вспомнить. Вместо этого, я просто скажу вам, как аргумент к превозмоганию С++ над высокоуровневыми языками, что я только видел, как у красивой девушки на голове сидела шиншилла и гадила, тем самым выражая свое мнение об этом вашем высоком уровне.
З.Ы. Хоть это я это и вставил в метафорическом контексте, но оно вполне себе рельно только что имело место быть.
Коментар порушує правила спільноти і видалений модераторами.
«Какая характерная черта есть у всех багов в продакшне? Они прошли проверку типов И юнит-тесты.» ©
Угу. А потом к этому добавить неэфективность скорости выполнения кода на высоких языках и высокий порог вхождения на низкие языки и все встанет на свои места. Как грицца, формошлепу формошлепово.
Тогда нужно бежать на ассемблер, озолотимся!
вы поняли все наоборот
Да, признаю. Все равно утверждение сомнительное :)
вот теперь соглашусь
Как уже здесь много раз отмечалось: далеко не все можно сделать на С#/Python/Ruby, даже если написать в 10 раз больше строк кода или в 10 раз меньше. С другой стороны, это закон идеален для простых, рутиных и легко автоматизируемых задач, которые укладываются в строку кода нового языка.
Тю на вас. Его невозможно похоронить, ибо прост и жесток, аки рельса.
Да вы что? Синтаксис же похожий!!!111 one
Такая:
It was developed as an enhancement to the C language. Originally named “C with Classes”, the language was renamed C++ in 1983
И? Ц++ вполне может быть вытеснен более современными языками типа д,го,окамла как жава и .нет вытеснили уже из энтерпрайза, а вот ц так просто не вытолкнешь, потому что большинство ос, драйверов под них и все такое на с и слезать не собираются.
да, и с++ кода уже валом написано, до-фига нужно переделывать, чего никто делать не будет.
как и любой любой другой код, который разрабатывался годами, а то и десятилетиями.
mysql на си в основном. Остальные тоже перепишут если какой нибудь правильный язычек станет мэйнстримом. Или умрут как динозавры.
Вот именно, что может быть. И этому «может быть» скоро исполнится 40 лет.
Ц++ появился далеко не 40 лет назад, и применять масштабно его начали еще позже.
См. ссылки выше. Там все написано.
См. отличный сайт www.google.com — там все написано
А вот Ц++ есть.
Форт никому не известен? Веществами не поделитесь? Или он неизвестен конкретно господам, ваяющим формочки и УИ?
И что вам известно о форте? Сколько строк кода вы на нем написали ?
Конечно же ничего. Так, использовал в проектах чужие фортовые реализации, типа svd.
Другое дело, что я бы с удовольствием выслушал пояснения на тему того, какое отношение имеет написание кода к известности языка. Или информация секретна?
Язык известен, им пользуюцца, на него пишут либы в т.ч. и для нового железа (первое, что пришло в голову — CUDA).
Я под известностью подразумевал нечто большее чем «гдето слышал, прочел статью на википедии». На томже маргинальном лиспе вполне можно найти программистов, в том числе здесь на форумах, а вот на форте... врятли.
Известность — это, когда язык применяецца и применяецца часто. Не так ли? Так вот, он применяецца часто и много в определенных аппликациях. БОлее того, как я уже указал ранее, для него, в отличии от «маргинального лиспа» и т.п. выходят либы от прозводителей железа, что кагбэ показывает, что не то что не забыт, но активно используецца. Да далеко ходить не надо. Часть матлабовских функций написано на форте, часть на С, часть на С++. Балго ,в оном есть исходники, можете скачать и насладицца.
И да, неудивительно, что на форте у нас нед программеров. Фортовые задачи обычно на аутсорс не кидают, а внутренних проектов у нас, ориентированных на математическую составляющую нет, насколько мне известно, кроме парочки энергетических проектов от сименса, которые выполняюцца на стороне немцев.
Фортовые задачи обычно на аутсорс не кидают, а внутренних проектов у нас, ориентированных на математическую составляющую нет,
Ты похоже попутал фортран и форт.
Не просто попутал, а сократил, забыв, что есть еще и форт. Сорри, мой феил.
Но вот
forth.run
— это уже выше моей крыши. Завтра буду целый день хихикать. :)
Я — лох и в этом уже признался, не? И да, я их отличаю, но настолько привык сокращать фортран до форта, что тут попался.
Нет ничего удивительного что молодёжь о них может ничего и не знать.
Затем, что в моем случае это не простительно таки. А, если уж допустил ошибку, то надо ее признать и жить с ней дальше, не? Все-таки, доказывать до последнего свою правоту, даже, если не прав, таки несколько глупо, да?
SystemC — основа основ ESL, за которым будущее всех цифровых девайсов, является всего-лишь библиотекой С++. И именно С++, а не С, Python, PHP или Java. И на то есть все основания.
Стоющих альтернатив SystemC пока не знаю.
SystemC уже нное количество лет, что-то я не вижу ,чтобы на него переползали с верилога и вхдл и других хдлей разных вкусов, типа ахдл.
Кстате, поговаривают, что он синтезирует системы очень далекие от оптимальных, но сам не проверял, не знаю.
Ну, сравнивать SystemC и Verilog — это как сравнивать язык С и ассемблер.
Ну да. Но, позвольте, если вы уже делаете специализированный чип, гед все решаецца не за счет наращивания мегагерцев, а за счет параллелизма, то высокий уровень не применим. Я в этом контексте не особо понимаю профит от систем С. С тем же успехом можно было бы все и из матлаба генерить, ибо и там, и там теряецца основная и главная фишка, а именно — высокий параллелизм при низкой частоте, ибюо оптимизация ни к черту.
В то же время, С и АСМ сравнивать некорректно, тк. в основном С-копилятор выдась код не хуже, а зачастую и лучше челвоека, если не требуецца применение каких-то фич процессора, которые сам по себе компилятор вставлять не будет, либо будет вставлять криво.
Кристаллы сегодня очень большие, кодом на Verilog забить их крайне сложно. Нна языке С++ можно писать абстрагировавшись от многих аппаратных вещей. Можно просто описывать параллельно выполняющиеся алгоритмы/процессы/задачи/программы — их может быть и 100 и 1000, а тулза сделает автоматом из этого дела Verilog-код.
Одно из подобных существующих решений (направлений), где софтом можно решать апаратные вещи — процессоры XMOS. Здесь тулзы поддерживают С, С++, XC (расширение С++) и никаких верилогов.
Просто уточню. Какой именно код? Глюкавый верилог код, который более ,чем на 50 мгц и работать-то не сможет? Или таки что-то применимое в реальной жисти?
Кривые руки и Verilog-код на 50МГц не запустят, вот им С++ и призван помочь, т. к. далеко не все желающие сделать свой чип — ассы в этом непростом деле.
Это понятно, все, чем C++ хорош по сравнению с java/c#/python etc., есть и в C (но без гемора), а все чем он лучше С, есть в других языках.
Не знаю куда там все бегут, а я пока не интересной работы на С++ не видел. Все пока интересно и проекты, и задачи. И проблем с поиском работы не было.
P.S. это лично мое мнение.
Понимаешь, для тебя важна интересная работа, а кому — то просто нужно бабло. Вот и бегут за баблом
Так я и не говорю, что «Пишу на C++ за еду».
Эмм... Дял годных спецов в любой сфере вопросов с баблом не стоит, не?
и: просто бабло
Вот только время, пока станешь «годным спецом» различается. Зачем становится годным в С++, если деньги одинаковые
Не одинаковые, другое дело, что до С++ потолка расти несоизмеримо дольше, но сам потолок выше.
2) Что кушать в это время
У нас плюсы, это в основном игры за более, чем скромную зарплату.
Глобализация, фриланс, удаленка. ИТ-шники должны это понимать и уметь использовать. И тогда ответы на эти вопросы появяцца сами по себе. Ну да, если у нас сидеть в путсорсерах, то там цппшники получают меньше даже формошлепских яверов, шарперов и иже с ними.
То что доля спецов и работы для цепепе за последнее время весьма сократилась, и продолжает сокращаться вас не пугает ?
Вы таки хотите, чтобы вам ее показали? )
У меня есть уверенность, что раз уж разобрался с С++, то языки попроще освою без проблем.
Может быть и так, но какое отношение это имеет к интиресным проектам на ц++
Если вдруг пойдут не интересные проекты на цпп.
Языки наверняка, но к ним прилагаются еще фреймворки!
Ну все, фреймворк не осилю. Придется пропадать с с++
Да уж, прийдется г0внокодит за еду и создавать темы на доу «где берут джава джуниоров»
За ваши деньги я расскажу разработчикам то, что вы хотите. Только, укажите местонахождения скоплений разработчиков.
Тю. Рассказывать — не разрабатывать. Ваш К.О.
Тогда уменьшаем множество на «разработчикам супер-попупер графических движков».
Это Майнкрафт не тормозит? Лол.
Помоему великий исход с С++ уже закончился. Все кто остался не могут спрыгнуть по разным причинам: например требование к производительности, потреблению ресурсов и задержке.
И да и нет.
Вот лично я хотел бы спрыгнуть с этого паровоза, но пока ещё не выбрал место приземления. ;)
И, кстати, полное и абсолютное заблуждение думать что С++ это правильный выбор если речь идёт о о производительности-скорострельности-потреблении ресурсов. Есть немалый опыт наступания на эти грабли, но это длинная история.
Вот лично я хотел бы спрыгнуть с этого паровоза, но пока ещё не выбрал место приземления. ;)
Речь не о тебе и программистах а о бизнесах-работодателях.
И, кстати, полное и абсолютное заблуждение думать что С++ это правильный выбор если речь идёт о о производительности-скорострельности-потреблении ресурсов
Альтернативы?
Write in C-и-уууу!!!
Write in C,Write in C-и-уууу!!!
Петь надо, как лет ит би от битлов, а не читать репы тут разные.
Все таки есть мнение что ООП, шаблоны и стл не такая уж и плохая вещь и вполне добавляет удобства и ускоряет процесс разработки.
Угу. Но был ведь вопрос про быстрые альтернативы. Вот же они. А обернуть мона потом во что-нить повыше уровнем.
Ну для некоторых это не альтернатива по озвученнымм мной причинам.
Вот именно поэтому я и написал, что надо писать на С и оборачивать во что-нить высокоуровневое. Классический пример — С на уровне реализации, а на уровне оберток — Обжектив-С. А в итоге — весьма годный и быстрый тандем.
обджектив на серверсайде не силен, где ц++ все еще окопался. Большинство других оборачивалок не так что бы рулят.
Он не только окопался, но и будет там сидеть. Но альтернатива таки все же есть, хоть и призрачная. Я, кагбэ, вообще не серверы рассматриваю, а ЦОС и разное такое.
Популярная сегодня модель — низкий уровень на Си (и, возможно, Си++), верхний уровень на скриптовом языке.
Жаль, что вы не в Днепре. У нас намечаются неформальные тусовки по этой теме. C++ и производительность.
А анонс будет? В принципе, основные знания о том как похоронить производительность сводятся к тому что делать нельзя, в основном это OOP abuse, patterns abuse, OOP perfectionism, template abuse ... Как НУЖНО делать — информации я встречал мало, единственная светлая мысль это Data Driven Design, когда дизайн базируется не на иерархии классов, а на анализе потоков данных.
Лично мои последние заморочки в некоторых своих pet-проектах — оптимизация с учётом иерархии памяти, то, о чём прекрасно много лет назад расписал Крис Касперси и (надеюсь, независимо от первого) Ulrich Drepper («What every programmer should know about memory») (до последнего я, кстати, ещё не дошёл).
Но моё мнение не столько интересное. Я надеюсь пригласить людей, которые профессионально много лет занимаются high performance.
Правда, не думаю, что будет широкий анонс. Кому интересно — пишите. Но, я считаю, что в последнее время очень много всяких presentation, расчитанных на зал
Простите моё ИМХО, но судя по всему подобные вещи уходят в прошлое. Программисту на Python/Ruby/JavaScript/Lua/Lisp/Perl/PHP/ActionScript/Java/C# не нужно тратить _время_ на копания в лов-левел подробностях использования памяти, и от этого выигрывает время разработки, а так же размеры и сложность кода, стоимость сопровождения, а значит в конечном счёте успешность проекта. Вот такой вот грустный для C/C++ вывод.
Ну, во первых, в книге «Техника оптимизации программ — эффективное использование памяти» Касперски вам как-бы отвечает во введении (Pro et contra целесообразности оптимизации)
Во-вторых, все эти методы активно используются в той же gnu lib c, в механизмах операционной системы, в СУБД, в реализации языков, о которых вы упомянули.
И, наконец, есть задачи (кот. называются high performance) для которых мощности современных компьютеров не хватает и никогда не будет хватать — они работают на пределе возможностей (также используют свои СУБД, подсистемы на уровне операционки и библиотек).
Не стоит предъявлять требований гоночного автомобиля к автобусу. Это разные рынки. Но индустрию двигателестроения, заметьте, двигает первый.
В программировании всё точно так же. Вы используете инструменты, в которых некоторые принципы оптимизации с учётом иерархии памяти уже реализованы, не подозревая об этом.
>Не думаю что подрастающему поколению следует рекомендовать C++, есть куда более перспективные варианты:
Пральна, хай гoвнокодят за копейки.
Да и вообще говорят, что писать на С++ - это как подростковый секс: все об этом говорят, но не все этим занимаюцца :)
Ага, а некоторые занимаюцца, но не так, как надо, ибо нед партнера.
«на Страуструпа» можно вычеркнуть, от этого смысл не изменицца, не?
Ну, не совсем. По тому же источнику, платят чуть больше за более сложные технологии.
Какие именно?
И да, мы говорим о среднем по рынку или потолке?
признанно
Признанно кем? ООО «Формошлеп и Ко»?
Вообще-то, общеизвестный факт, что один из самых сложных языков.
общеизвестно что бэйсик тоже один из самых сложных, факт!!!!111
Дайте рейтинг языков пожалуйста, давно не смеялся над компутерным хумором.
Да, я знаю это прекрасное заблуждение человека, начинающего новую программу — «старая написана слишком сложно. Сейчас напишем новую».
C++ давно на сцене, программы подросли.А сложность — она не от языка а от задачи.
Другое дело, что есть сложность необоснованная. Вроде статической типизации в web проекте. Или заботе о распределении памяти, когда нет realtime требований.
Но есть сложные проекты, более того, доступная сложность проектов часто определяется инструментарием и методами разработки.
В области решений, с требованиями по времени, C++ лидирует. Возможно, его место в своё время, могла бы занять Ада, если бы Европа, а не Америка играла бы лидирующую роль на рынке.
А по поводу подрастающего поколения всё из вышеперечисленных не годиться, ИМХО. Ну, может быть Питон и то, только потому, что я его не знаю.
Выбор первого языка для обучения сегодня — тема, достойная отдельного топика. Berkley и MIT давно остановились на Lisp. Я изучал их методику, она, на мой взгляд, обоснована.
прекрасное заблуждение человека, начинающего новую программу — «старая написана слишком сложно. Сейчас напишем новую».В принципе, это здравая мысль, лежащая в основе рифекторинга: Я написал программу, она работает, а теперь я перепищу её проще и быстрее.
А сложность — она не от языка а от задачи.В идеальном мире. Во многих случаях львиная доля сложности проистекает от используемого инструментария — фреймворков, мидлвары, легаси кода...
В области решений, с требованиями по времени, C++ лидирует.Всё таки C а не C++. С++ легко раздувается «вспомогательным» кодом, который в итоге проглатывает производительность и ресурсы.
А по поводу подрастающего поколения всё из вышеперечисленных не годиться, ИМХО.Много лет назад подобный холиварчик был между сторонниками ЯВУ и машкода, итог — эффективность кода проиграла эффективности разработки. Сегодня всё повторяется: Никто не хочет платить программисту за написание контейнеров-итераторов и менеджмента памяти.
Возможно, его место в своё время, могла бы занять АдаАда ИМХО один из чудовищнейших языков программирования — непомерная сложность при отсутствии видимых преимуществ. C++ близок по сложности, но хоть был прогрессивен 20 лет назад :)
P.S. У С++ сейчас гораздо меньше шансов умереть чем когда-то у Objective-C. Благо второй заметили и использовали Apple, результат общеизвестен.
Коментар порушує правила спільноти і видалений модераторами.
Эх, хорошо что это отмирает под воздействием более современных и красивых языков.
зря ты так мне кажется....если он умрет то и с хорошим железом будет девайс тупить...в каменый век вернемся)))
Сегодня 4 ядра, завтра 256 ядер.
С++ уйдет, когда разница в производительности станет не существенной.
Но это точно не на повестке дня.
А вот давай посмотрим на такую область как NoSql, где производителность очень даже важна. Среди лидеров рынка — hbase, cassandra писаны на джаве, riak, couchdb — на эрланге, и только mongo на ц++. К чему бы это?
к тому что монго всех заборет! *trollface*
Ага, единственная из пятерки которая лочит всю таблицу на малейшее изменение. Читал в интернетах история как чуваки поднимали 16 монго на одном сервере что бы загрузить все 16 ядер сервака.
Почему нельзя минусовать?
И кстати, C++ обновился, теперь будут и лямбда-выражения, for-each аналог, поддержка потоков в стандартной библиотеке и много чего другого. Конечно этим мало кого сейчас удивишь, и возможно этот язык требует к себе больше внимания, но это только к лучшему!
И теперь ц++ гoвнокод будет падать в корку еще более изысканно.
С этого места пожалуйста по-подробнее. Каких именно? В чём красота? В чём современность?
Отмирает, в смысле что мало кто будет писать на С++ для души после того как попробует какой-то функциональный язык, для некоторый после С++ и питон кажется чем-то волшебным.
Угу. Особенно те, кто занимаецца специфическими числодробильнями, требующими высокого быстродействия. Ох уж они оттягиваюцца на высокоуровневых тормозах.
«специфическими числодробильнями» занимается совсем мало людей, а для души, и того меньше, с Си им и не нужно слазить, если им так уж важна производительность, а вот основная масса с плюсов надеюсь уйдёт.
Как раз, для души занимаецца куча народа числодробильнями. Другое дело, что вы этих проектов не видите в открытом доступе, ибо их редко выкладывают.
Более того, на том же С базируецца тот же обжектив, который от него не уйдет никогда, ибо являецца макронадстройкой над С.
З.Ы. Мечтайте- мечтайте. А лично я помечтаю о вымирании формошлепов. Мечтать-то не запретишь, да?
Отец будет жить в наших сердцах. Поэтому он не умрет :)
Куда все так бегут
бегут туда где деньги
Сам же и ответил.
почти не встретишь кто планирует свою судьбу с С++ связать
Я связываю свою судьбу с деньгами, дорогими машинами, красивыми женщинами. Работа как смысл жизни — кушайте это сами
Я связываю свою судьбу с деньгами, дорогими машинами, красивыми женщинами.
тогда тебе в манагеры
Кто б спорил — стремлюсь изо всех сил своей израненной отсутствием порше души
в UA?стремлюсь изо всех сил своей израненной отсутствием порше души
за поршем надо тащить попу в штаты
ну тяжело поспорить...ну ведь на С++ создаються проэкты серьезные а за все серьезное и серьезно платят, верней должны платить)
Платят не за сложность проекта, а за соотношение спроса и предложения. Будь ты хоть десять раз специалистом, если в твоем городе одна контора и десять человек желающих занять твоё место и могущих делать работу в принципе, пусть хуже, зарплата будет как у уборщицы
Ну так этож хорошая новость. Закапывайте уже его побыстрее.
Вообщем подводя итог — С++ был и будет, и люди со знанием языка будут требовать и дальше, но вакансий будет напорядок меньше, чем на дажа/пхп, воответственно и начинающему программеру будет очень сложно стартануть с С++.
И еще по поводу С++, требуются С++ under linux разработчики в Днепре, с опытом работы от 3х лет(1 год под линухом), кому интересно — пишите с личку.
Перешел на функциональщину, lisp и прочие clojur -ы. Теперь на С++ смотреть не могу. С еще нормально перевариваю...
C++ ныче удел геймдева и высокроизводительного ПО.Разработать ПО на jvm дешевле для всяких энтерпрайзов...
рынок, ничего не сделаешь...
?lisp и прочие clojur -ы.
Вон на цепепе есть, мало но есть.
рынок ИТ штука глобальная. В Киеве есть lisp еры, точно знаю. Я по фрилансу больше...
Сейчас грядет волна популярности C++ в рядах кодеров, ориентированных на Микрософт. Просто зайдите к ним на channel9.msdn.com и вы удивитесь, как много видеоматериалов посвящены C++, причем именно тому течению, которое принято называть Modern C++. Задача PR-машины компании проста: убедить разработчиков, что C++ в новой инкарнации — templates, STL, RAII — совершенно не страшнее того же C#.
Со временем эта волна дорастет и до Украины: через какие-нибудь год-два появятся заказы на разработку под WinRT. Так что тут полный порядок.
Кроме того, есть мобильный рынок — на том же Андроиде куча народу использует NDK — особенно, когда работают с графикой. В iOS C++ - такой же первостепенный язык, как и Objective C, а деньги iOS-разработчикам тоже платят хорошие.
Я вообще не вижу проблем. Вам кажется, что весь аутсорс переезжает на Java/.NET? Но ведь это ж аутсорс — там найти интересный проект гораздо сложнее. А если вы C+±девелопер, то в вашей работе гораздо больше разнообразия, а значит, вам легче найти что-то интересное.
Еще одно соображение: чем больше людей уходит из плюсов, тем меньше вас остается. При этом спрос на C++ будет еще долго оставаться высоким. Так что вы в выигрыше.
куча народу использует NDK
Не сгущайте краски: не куча, а кучка
Кроме того, есть мобильный рынок — на том же Андроиде куча народу использует NDK — особенно, когда работают с графикой.
Не сгущайте краски: не куча, а кучкатам приличная такая кучка, кстати.
графика, мультимедиа, звук и всё такое.
Так это все реализуется наджаве — инструментарий очень богатый. Зачем для работы с медиаплеером использовать NDK? Это если задачи — специфические, типа цифровая обработка сигналов, доступ в RIL или нужно максимально быстро что-либо обрабатывать — тогда да, а иначе — типовые решения.
сильно спорить не стану, поскольку не спец по NDK,Так это все реализуется наджаве — инструментарий очень богатый. Зачем для работы с медиаплеером использовать NDK?
Могу дать в студию примеры популярных фреймворков на гуглокоде, если интересно.
Могу дать в студию примеры популярных фреймворков на гуглокоде
Давай!
В світовому маштабі Windows XP ще досі до 40% ринку тримає. Хто з тверезомислячих людей буде писати масовий софт для платформи яка буде мати в кращому випадку
Я где-то писал, что нужно отказываться от старых api вроде COM и Win32 в пользу WinRT? Я просто сказал, что проекты будут появляться. И у меня есть определенное подозрение, что кодить на C++ под WinRT будет поприятнее, чем под win32. Хотя бы потому, что для Metro UI используется XAML, который и руками можно править, да и удобные инструменты для создания интерфейсов на нем есть.
Говоря о росте популярности, я в первую очередь напираю на появление нового стандарта и на рост популярности новых идиом. На C++ теперь писать можно почти также удобно и просто, как и на C#. Поэтому многие новые проекты могут выбрать C++ в качестве языка программирования.
WinRT может взлететь на планшетах, а планшеты в свою очередь тоже набирают популярность. На планшетах важна производительность, так что вполне вероятно, что появятся именно планшетные проекты под WinRT на C++/CX.
Скажете, зачем планшет на винде? А как насчет интеграции с Windows Domain, Active Directory и Exchange? Для многих организаций массовое развертывание таких устройств на порядок проще, чем планшетов на других платформах.
або .NET, а враховуючи що .NET реалізації є баги які висять с
1. Да, писать на C++11 не совсем легко, но все равно вполне преемлимо, явно проще, чем на тех плюсах, которым в наших университетах учат. C# - тоже язык не подарок, порог вхождения для него существенно выше, чем у той же Java или Ruby, JavaScript или даже Erlang.
2. XAML не означает, что для UI используется .NET — на выходе для C+±проекта все равно будем иметь нативный бинарник, быстрый и беспощадный.
3. Про то, куда целит планшеты Микрософт, я бы не торопился судить. Компания большая, и разные дивижены будут продвигать Win 8 разным клиентам. Простым пользователям будут показывать красивое Метро, а корпоративным — интеграцию с доменной политикой и прочие прибабахи, которые рядовой пользователь никогда не оценет, а для компании с 50 тысячами сотрудников, которая собирается закупить хотя бы пять тысяч планшетов, эти фичи могут оказаться определяющими. IT-отдел скажет, мол, хотим, чтобы пользователь входил на планшет под своим доменным паролем, который раз в месяц сбрасывается. Или еще что-то вроде этого. И купит компания планшеты на WinRT. А вам не все ли равно, под что писать — под Win 8 или под iPad?
5. HTML5 и HTML5 Metro отличаются, как JavaScript от Java — т.е. общего там совсем чуть-чуть. Куча стандартов из спецификаций W3C, ECMA, khronos и им подобным не поддерживаются, а их функционал заменен на проприетарные api. Так что просто так взять HTML5-приложение, тот же chrome.angrybirds.com и перенести его на WinRT не получится.
Если честно, мне кажется, что мы с вами в этом споре отошли от темы. Постер спрашивал, есть ли у C++ будущее, а в результате мне кажется, что вы пытаетесь доказать мне что будущее есть у .NET — но я ведь в этом тоже не сомневаюсь. Есть ли будущее у Метро? Надеюсь, да, но утверждать, что он захватит мир и лишит работы всех дотнетчиков, по-моему, излишне.
Сейчас грядет волна популярности C++ в рядах кодеров, ориентированных на Микрософт.цікаво, чому тоді у 2013 MS шле тести на С# ?
Сам фанат С++, но писать приходиться на С# так как плюсовых проектов почти нет. А в последнее время еще пошла тенденция плюсовиков переучивать на Obj-C, я это не сильно одобряю..
Согласен, между Обжективом и плюсами сходства нед, посему, годных плюсовиков переучивать — терять весь их годный опыт и знания.
Ц++ например в калифорнии и в прочих майкрософтах вполне денежное и стабильное направление, просто его на Украину аутсорсят мало.
А С++ не умрет. Ниша конечно сократится, но это естественно и оправдано.
Коментар порушує правила спільноти і видалений модераторами.
С++ плохо подходит для формошлепства. А деньги платят именно за него.
С++ замечательно подходит для формошлепства. Builder и QT тому подтверждение. С++ неаккуратности не прощает.
Так что поживёт ещё.
спасибо...это именно то что хотел услышать
+1 недавно читал книжку по java и поймал себя на мысли что не знающему что такое vtbl все это позднее связывание должно казаться разновидностью черной магии.
Порог вхождения в С++ выше то, и вообще костыли сплошные. С другое дело, более менее однороден и он больше для системного программирования подходит, кстати.
А чем это С больше подходит для системного программирования?
для написания драйверов ООП знать не нужно =)
А что, если знаешь ООП, то все? Драйвер уже никогда не написать?
Зря вы так. Загляни в ядро linux, много там с++? С++ тяготеет в сторону прикладного ПО. Мой основной тезис был в ответ на:
.Заходить в плюсы надо только при выраженной склонности к системному программированию
Есть системы типа Genera, в которой драйвера написаны на Lisp(чисто функциональный яп). Можно я думаю и на других языках заниматься системным программированием, но С — это де-факто стандарт в силу исторического развития.
А почему такая тенденция что все в пример linux ставят....? смотря по его рейтингу прироста юзеров, и он не растет(не смотря что стал коорпаративным)...а вот програмисты активно используют...в чем плюсы его?
Потому что у linux открытые исходники, и можно прийти и посмотреть как там все устроено. Вы знаете как сделан Windows или Mac? Только косвенно, где-то в блоге может написать кто-то. Linux же серверная платформа, среди юзеров она растет только у тех кто не хочет платить деньги или не приемлит пиратства.
Основное преимущество для программиста это сама среда.Для меня еще возможность не такскать
Эмм... Вообще-то, сырцы дарвина где-то валяюцца у эппла.
+200 млн юзеров за счет андроида за 3 года.
Зря вы так. Загляни в ядро linux, много там с++? С++ тяготеет в сторону прикладного ПО. Мой основной тезис был в ответ на:
Много драйверов под Windows сторонними производителями были написаны на C++. Да и Microsoft всячески поощряет разработку драйверов на C++.
И что? С++ - это сиравно грешно. Читаемость ниже плинтуса, сложность нереальная проста. Капееец.
С++ это не только STL и Boost, а ещё и ООП :)
Не. ООП — это смолтолк и обжектив-с. А все осталньое в плане ООП — это чудовищные суррогаты лошади и бронетранспортера. Включая яву и шарп, естессно.
Видимо, смолтолкеры и обжектив-Сишники смотрят на них как лошади на бронетранспортёр по каким-то субъективным причинам.Включая яву и шарп
Вполне себе объектно-ориентированные языки, очень юзабельные.
ООП — есть разное. Если не ошибаюсь, то в Обж-Ц более близкий к оригиналу вариант, в ЦПП и тд (джава/Ц№) неного переосмысленный вариант. (но это уже другая история)
Угу. Факт. Самый близкий к оригиналу концепции ООП — smalltalk. А обжектив кучу идей из иного натырил и продолжает тырить.
Вы тут друг друга пытаетесь убедить, что у каждого свое видение ООП?
Неа. ЗАчем убеждать? Есть определение от созадтеля. Есть определение от формошлепов. А дальше начинаецца срач.
о дальше начинается жизнь с ее серыми оттенками
Если это принять, то нет места дял конфликта. Определенно, не метод посетителей сего треда.
Там уже есть концепция метаклассов и прочего оборачивания в объект всего-всего и messaging? А как там с лейт биндинг и динамическими объектами? Какое же это ООП, если там этого нед? Или вы, как и большинство формош...гхм...юнош находитесь в заблуждении, что ООП — это полиморфизм, инкапсуляция и наследование?
Почитайте хоть, что такое ООП от его созадтеля, а не современные уродцы, которые даже не обладают полноценным полиморфизмом:полиморфизм, инкапсуляция и наследование
. И ненадо тут откапывать всякое.
Вы не правы. Сейчас именно фомрошлепы и прочие полуграмотные рассматривают ООП именно в этом свете, причем, даже не понимая сути того же полиморфизма, который киты, типа явы и шарпа, полноценно не могут обсепечить, т.к. нет у них messaging и метаклассов (а механизм рефлексии не дает всех тех свойств, что необходимы), который и есть базовая вещь для реализации полиморфизма (который почему-то низвели до использования известного интерфейса в известном объекте, котоырй в этом объекте точно есть). Хотя да, о чем это я? В современных ООП-неполноценных языках даже вызов метода не являецца объектом (что простительно для мультипарадигменного и старого С++, но совсем уж непростительно для новья, которое претендует на оопшность), а метакласс появился не с первых версий и крив.
Все, кто хоть чутку интересуецца вопросом логики и философии модели, которую пользуют, а не только шлепает формочки на языках с низким порогом входа без желания углубляцца в суть вещей, вполне себе также признают, что определение Кея превозмогает современное определение, ибо генерализует его.
Для вас это наверное неожиданность, но не-формошлепы (кстати есть четкое определение этому термину? чтобы можно было ткнуть пальцем в человека и сказать «во вот это формошлепъ! А вот этот не формошлепъ!») тоже в своей массе когда говорят ООП подразумевают це++, жабу, и ц#, но никак не смалтолк.
Формошлеп — товарищ, использующий язык без понимания его сути и структуры. Распространено среди высокоуровневиков, которые не интересуюцца ,как работает машина, что делает их вм, как использовать парадигму их языка, а используют карго-культ натыкивания паттернов к месту и не к месту, раскидываясь страшными словами, типа аджайл и скрум, и считающие, что они становяцца круче от того, что освоили интерфейс очередного фреймворка (всегда поражало, что внезапно читать доки — это настолько сложно, что пинус вырастает от ознакомления с очередным фреймворком). Изначально относилось к тем, кто в визуальном редакторе натыкивал формочки и требовал на форумах готовых компонент под любую самую элементарную задачу, являлось определением нежелания челвоека развивацца и было синонимом безграмотности.
Простите, но я не знаю ни одного челвоека, который был бы не формошлепом и не признавал или хотя бы не знал определения от Кея (причем, те кто знают, но не признают, также не считают полиморфизм, инкапсуляцию и наследование определяющими и единственными характеристиками ООП). Ибо любой челвоек, который хочет понять суть парадигмы, которой пользуецца, должен ее хорошо порыть, а иначе будет, как в тех случаях, когда на функциональных языках пишут в процедурной парадигме.
А мы говорим не о смолтолке, а о определении ООП, не так ли? ООП, кагбэ — это парадигма и к языку не привязана, если кто-то подразумевает под парадигмой фичи конкретного языка — то это его и его безграмотности сексуальные пробелмы, не?
З.Ы. Да-да. Я — графоман.
Ну вот смотрите в википедии написано что це++ ооепе (много где еще написанно). А вы коссвенно утверждаете что не оопе, и что все кто говорять что це++ оопе — формошлепчики. Ну ну.
>>Ну вот смотрите на заборе тоже написано (много где еще написано).
Очевидный фикс.
В современных ООП-неполноценных языках даже вызов метода не являецца объектом
Это обьясняется некоторыми требованиями к производительности этих языков: shootout.alioth.debian.org/...ng=vw&lang2=gpp
А если сделать пару финтов ушами, то почти не отстает от С++ по производительности. И да, у него сообщение — это тоже объект при этом.
www.mikeash.com/...operations.html
ТАк что производительность тут ни при чем, кагбэ.
Objective-C не сильно отстает от С++.
А если сделать пару финтов ушами, то почти не отстает от С++ по производительности. И да, у него сообщение — это тоже объект при этом.
www.mikeash.com/...operations.html
ТАк что производительность тут ни при чем, кагбэ.
Точто я вижу это что обэктивные сообщения занимают в больше чем в 5 раз больше чем виртуальный вызов в ц++, а в ц++ затем и темплейты придумали что бы избегать полиморфизма и сокращать накладные расходы на вызов к нулю потому что все будет инлайнится, и таким образом получим разницу в
Угу. Как я уже сказал, с парой финтов ушами работает почти также (пара финтов =
И да, мы так спорим с вами про быстродействие, но изначально я взъелся не на С++ в этом контексте.
Имп кеш тоже не бесплатный:а в остальное время — IMP-cached message send.
а в остальное время — IMP-cached message send.
Тут тоже можно инлайнить, но от этого теряем прелести messaging, хотя, в определенных местах это и разумно.
Так вот ,оверхед от имп кэш на самом мюллере описан так (замечу, что у эша сразу написано, что имп кэш быстрее вызова виртуальной функции С++):Obj-C method calls aren’t slow, but they are slower than plain C calls. Outside of inline code, the fastest invocations are the static C function (or any function that isn’t crossing shared library boundaries) and equally fast if not even a smidgen faster message implementations (IMP)s.
И собсно, то, что я и говорил, подтверждает и приведенный тобой источник, что вызовы методов ненамного медленнее С++, а если сделать пару финтов ушами, то почти такие же по скорости, а иногда и быстрее (то, о чем я не упоминал ,т.к. зачастую добивацца этого не имеет смысла).
objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метоад и не связан с IMP-cache никак.
Связан, когда проишодит посыл мессаджа, рантайм вначале смотрит в кеш не отрезолвлен ли адрес метода уже. Это и называется IMP кешем, и оно выделено крансым на листинге на который я ссылался.
То о чем ты говоришь это вызов метода в обход кеша, со всеми вытекающими последствиями(типа какой то хакер поменял класс в рантайме и вся программа посыпалась и неизвестно как ты это отловишь потому что имп поинтер уже ссылается не туда). Не говоря уже о том что вместо таких извратов может лучше писать сразу на ц++?
Тут тоже можно инлайнить, но от этого теряем прелести messaging, хотя, в определенных местах это и разумно.
Отлично, где можно найти библиотеку коллекций/алгоритмов которая бы это использовала(типа STL)? А иначе это все только на бумаге.
>Связан, когда проишодит посыл мессаджа, рантайм вначале смотрит в кеш не отрезолвлен ли адрес метода уже. Это и называется IMP кешем, и оно выделено крансым на листинге на который я ссылался.
Этот механизм являецца частью месседжинга и имп-кешем не называецца. Собсно, об этом я и говорил изначально, говоря, что «objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метода и не связан с IMP-cache никак.»
Внутреннее кеширование есть, но его проверить сложно, т.к. рантайм сам занимаецца резолвом и предсказать, когда лезет в кэш, а когда и без кэша хорошо живет невозможно, посему и замерить невозможно. Именно поэтому, имп — кеш — то, что сказал я, а внутреннее кэширование замеряют по станадртному месседжингу.
Вот имп-кеш по версии Эша:}
— (void)_stubMethod}
>Связан, когда проишодит посыл мессаджа, рантайм вначале смотрит в кеш не отрезолвлен ли адрес метода уже. Это и называется IMP кешем, и оно выделено крансым на листинге на который я ссылался.
Этот механизм являецца частью месседжинга и имп-кешем не называецца. Собсно, об этом я и говорил изначально, говоря, что «objc_msgsend — это то, что скрываецца под синтаксисом вызова любого метода и не связан с IMP-cache никак.»
Внутреннее кеширование есть, но его проверить сложно, т.к. рантайм сам занимаецца резолвом и предсказать, когда лезет в кэш, а когда и без кэша хорошо живет невозможно, посему и замерить невозможно. Именно поэтому, имп — кеш — то, что сказал я, а внутреннее кэширование замеряют по станадртному месседжингу.
Вот имп-кеш по версии Эша:}
— (void)_stubMethod {}
>То о чем ты говоришь это вызов метода в обход кеша, со всеми вытекающими последствиями(типа какой то хакер поменял класс в рантайме и вся программа посыпалась и неизвестно как ты это отловишь потому что имп поинтер уже ссылается не туда). Не говоря уже о том что вместо таких извратов может лучше писать сразу на ц++?
Первое, такой выход дает скорость быстрее виртуальных методов С++ по версии Эша.Третье, обычно, такой механизм наружу не выпячивают и предупреждают. Если же уж хакер был настолько идиoтом, что влез во внутреннюю структуру объекта и перегрузил приватную функцию, то кто ему доктор? Он и по смещению бед может натворить.
>Отлично, где можно найти библиотеку коллекций/алгоритмов которая бы это использовала(типа STL)? А иначе это все только на бумаге.
Я не хочу тебя огорчать, но, это только в С++ такая штука являецца костылем, типа СТЛ, который сбоку припеку и упоминаецца отдельно, что и неудивительно. Смотри в стандартную некстстеповую (все классы, начинающиеся с NS) и кор файндейшен (все функции и структуры, начинающиеся с CF) библиотеку. Там все это есть. И коллекции, и алгоритмы, которые используют и имп кэш, и инлайнинг, и черт знает что еще.
Этот механизм являецца частью месседжинга и имп-кешем не называецца
Я не хочу спорить на терминологические темы т.к. код это не ускоряет, хотя товарищи в приведенной мной статье называют кешем тоже что и я, и не называют кешем применение указателя на метод как делаешь это ты.
Третье, обычно, такой механизм наружу не выпячивают и предупреждают. Если же уж хакер был настолько идиoтом, что влез во внутреннюю структуру объекта и перегрузил приватную функцию, то кто ему доктор? Он и по смещению бед может натворить.
правильно, это то о чем я и говорю, что это не общеупотребимый подход, а хак с потенциальными последствиями, а программы которые используют рекомендуемые методы(мессанджинг который ты прославляешь в своих постах) тормозят в разы.
Я не хочу тебя огорчать, но, это только в С++ такая штука являецца костылем, типа СТЛ, который сбоку припеку и упоминаецца отдельно
Что значит сбоку? стл — часть стандарта!
Смотри в стандартную некстстеповую (все классы, начинающиеся с NS) и кор файндейшен (все функции и структуры, начинающиеся с CF) библиотеку. Там все это есть. И коллекции, и алгоритмы, которые используют и имп кэш, и инлайнинг, и черт знает что еще.
Ну давай посмотрим на конкретике, есть класс NSMutableDictionary, который типа хеш таблица, как мне сделать так что бы он использовал мой алгоритм вычисления хеша инлайня код, как это можно сделать в стл, что бы убрать оверхед на вызов функции хеширования?
>Я не хочу спорить на терминологические темы т.к. код это не ускоряет, хотя товарищи в приведенной мной статье называют кешем тоже что и я, и не называют кешем применение указателя на метод как делаешь это ты.
Они это называют кэшем. И эппл называет кешем:Но они не называют это IMP cache. Этот термин обозначает как раз то, что Эш подразумевает.
>правильно, это то о чем я и говорю, что это не общеупотребимый подход, а хак с потенциальными последствиями, а программы которые используют рекомендуемые методы(мессанджинг который ты прославляешь в своих постах) тормозят в разы.
Ты так и не понял одного, самым эппл делает то же самое в своих стандартных классах. И хаком не являецца. Просто, такие методы не выносят в публичные интерфейсы и все. Но ,если надо и в публичный, то просто при подмене надо еще класс предупреждать. Это уже костыль в какой-то мере. И таки все это остаецца месседжингом. Т.е., мы можем сделать чуть менее быстро, чем С++, при этом сохраняя динамику и имея чуточку больше возможностей. А можем и медленным способом, но без костылей.
>Что значит сбоку? стл — часть стандарта!
То ит значит. Изначально стандартом не была, а потом всунули еще один костыль.
>Ну давай посмотрим на конкретике, есть класс NSMutableDictionary, который типа хеш таблица, как мне сделать так что бы он использовал мой алгоритм вычисления хеша инлайня код, как это можно сделать в стл, что бы убрать оверхед на вызов функции хеширования?
Эмм... В зависимости от размера объектов и их коилчества, оно может действовать не только, как хэш таблица.
Первое, внутренняя реализация тебе, кагбэ, не нужна, стандартная библиотека в основном — это биндинги на кор-фаундейшен, который С шная хрень со вполне себе инлайнингом всюду, где необходимо. Все сделано за тебя.В третьих, если таки надо, то пишешь свою обертку над корфаундейшен.
Но они не называют это IMP cache. Этот термин обозначает как раз то, что Эш подразумевает.
Есть подозрение что эпл о существвании термина имп кеш вообще не подозревает.
Возражения:Т.е., мы можем сделать чуть менее быстро, чем С++, при этом сохраняя динамику и имея чуточку больше возможностей.
это не проблема навернуть обджектсишную или подобную динамику над ц++, типа как в гтк сделано
То ит значит. Изначально стандартом не была, а потом всунули еще один костыль.
Я не вижу связи в отсутствии стл-я в ранних версиях ц++ и классификацией его как костыля, если уж на то пошло то обджектив тоже не некстстеп разрабатывал, и классов с префиксами NS там явно изначально не было.
Второе, за счет того, что оно подменяет свою реализацию в зависимости от условий, ты этого сделать не сможешь, но оно тебе и не надо.
надо из-за вопросов производительности.
В третьих, если таки надо, то пишешь свою обертку над корфаундейшен.
Ну так а пример можно увидеть? А то пока что думается что такого сделать в принципе нельзя из-за отсутствия темплейтоподобных механизмов.
>Есть подозрение что эпл о существвании термина имп кеш вообще не подозревает.
Пральна. Хеш не эпплом введен. Кеширование — обще понятие, имп — специализация. Внезапно, да?
>имп кеш медленнее вызова статического метода ц++, а тут на форуме уже было обсуждение что переход от статического вызова к инлайнингу ускорял сортировку массива на
Ну а если ты хочешь инлайнить, то я тебе уже раньше писал, что это с тем же успехом делаецца и в обжективе.
>это не проблема навернуть обджектсишную или подобную динамику над ц++, типа как в гтк сделано
Согласен, т.к. обж-с — эт макронадстройка над С. Только вот гтк ,если мне память не изменяет на С, а не на С++, а сам С++ уступает С по скорости.
>Я не вижу связи в отсутствии стл-я в ранних версиях ц++ и классификацией его как костыля, если уж на то пошло то обджектив тоже не некстстеп разрабатывал, и классов с префиксами NS там явно изначально не было.
И что? НС — одна из библиотек. Есть еще опенстеп, гнустеп. Сам обжектив — эт совсем немного директив. И все. Все остальное реализовано в библиотеках, которые к стандарту не относяцца. А вот стл — впихнули монстрообразный костыль в стандарт и гордо теперь кукуют, хотя, это -далеко не единственный костыль. БУст еще в стандарт не впихнули? А то уже пора бы.
>надо из-за вопросов производительности.
Ок. Предположим, что ты таки относишься к той группе людей, которая достаточно сильна в математике, чтобы выбрать близкий к оптимуму алгоритм хеширования (лучший, чем уже имлементированные) и тебе оно таки надо.
>Ну так а пример можно увидеть? А то пока что думается что такого сделать в принципе нельзя из-за отсутствия темплейтоподобных механизмов.
Ты не понял, что я тебе написал. Ты пишешь свой хеш на основе corefoundation (или используешь другие в зависмости от того ,какой библиотекой базовых объектов пользуешься), пользуя gcc.gnu.org/.../libobjc/hash.c , www.opensource.apple.com/...me/hashtable2.m или что-то еще ( opensource.apple.com/.../CFDictionary.c , который легко допиливаецца под твои нужды), ибо невозбранно можно, т.к. просто еще одна сторонняя библиотека, как и библиотека метаобъекта. А дальше оттягиваешсья по полной, завернув то, что надо в обжектив, инлайня внутри все, что хочешь и выполняя любые другие угодные твоему сердцу извраты.
Но это мы берем случай, когда ты хочешь инлайнить сам вызов хеширующего метода, а иначе пользуешь: developer.apple.com/...5-CH2g-BBCIFDDF
Как я грил ,потери таки незначительны, особенно ,если учесть, что вызовы функций в большинстве алгоритмов не дают такого выиграша, т.к. логика сама и вычисления жрут поболе.
Итого, чистый профит.
З.Ы. Сорри, что долго отвечал, было время эротических приключений в мире разнообразного и такого агрессивного аутсорс по, щда и учеба доканывает нонеча, посему не мог ответить.
Пральна. Хеш не эпплом введен. Кеширование — обще понятие, имп — специализация. Внезапно, да?
А почему то о чем я пишу не является «имп кешем»? Если это не общепринятый термин откуда у тебя право решать где правильное использование термина а где нет?
а сам С++ уступает С по скорости.
Да ну? Пример с инлайн сортировкой показывает обратное в многих случаях.
Ты не понял, что я тебе написал. Ты пишешь свой хеш на основе corefoundation (или используешь другие в зависмости от того ,какой библиотекой базовых объектов пользуешься), пользуя
Это же лажа, на каждый чих нужно кучу каких то костылей делать. С таким подходом и питон будет high performance server side language, потому что все можно вытащить из другого места и обернуть в питоновую обертку?
А вот стл — впихнули монстрообразный костыль
Я так и не понял почему стл моструозен? Помоему вполне вменяемая библиотека коллекций. У обжектива такой нету — типозащищенной и производительной.
>А почему то о чем я пишу не является «имп кешем»?
МЫ начали обсуждать этот вопрос в рамках статьи эша, где четко оговорено, что он подразумевает под имп-хешем, нет? То, что ты начал путать эша имплементацию с мседжсендом, а теперь еще возмущаешься моей терминологией не меняет факта того, в каком разрезе было все изначально ,нет?
>Да ну? Пример с инлайн сортировкой показывает обратное в многих случаях.
Боже ж ты мой. В С тоже есть инлайн уже некоторое время как (С99). Но, самое главное, твои жалобы относяцца к тому, что на простейших задачах инлайн работает лучше, чем функция. Я даже не буду спорить, что, если в цикле вызывать функцию, которая выполняет одно действие (например, присваивание), то такая функция будет работать быстрее в инлайне. Однако ,в реальности, оверхедом на вызов при разумно подобранной архитектуре можно пренебречь (неразумная — это та, где одно действие тоже выносицца в функцию, а если уж очень хоцца, то его таки лучше заменить макросом по причинам, понятным нам обоим).
>Это же лажа, на каждый чих нужно кучу каких то костылей делать. С таким подходом и питон будет high performance server side language, потому что все можно вытащить из другого места и обернуть в питоновую обертку?
Нет. Лажа — это обосновывать потери в быстродействии через оверхед на расчете функции хеша, которая, кроме самых примитивных случаев, намного более вычислительно сложна. Методы коллбеков в CF есть дял пересчета, причем, сам вызов не сыграет существенной роли по причинам, указанным выше. И даЭ, что ты ожидал от кор-фаундешна? Это — чистый С, там наследование нет, кагбэ. Просто, этот С — toll-free bridged относительно Objective-C.
А теперь самое галвное, как я и грил ранее, обжектив-С почти не уступает С++, к чему мы и пришли, при этом имеет все те плюшки, которые С++ только сняцца в голубых мечтах.
Про хай пефоманс. Тут эрланг с явой и шарпом в таковые записывают. А ты сейчас со мной споришь по поводу скольки там? 30 циклов? Или 40? 0,9 наносекунд в общем (что, кстати, по эшу опять же, бьет С++ вызов виртуального метода). Причем, спорим мы об очень частном случае, когда надо заинлайнить хеш.
Это для языка со смоллтолковской динамикой (то, чего в С++ нет и не предвидицца, до сих пор вспоминаю, как выглядит в С++ паттерн делегат и удивляюсь) отличный показатель и имеет право иметь место быть на сервере, где с успехом и живет на отдельной узкой группе проектов.
>Я так и не понял почему стл моструозен? Помоему вполне вменяемая библиотека коллекций.
Моя икнула. У обжектива вообще нет библиотек. Обжектив — это язык. Синтаксис. Все. СТЛ монструозен и костыль, т.к. какую-то конкретную реализацию пхнули в стандарт ЯЗЫКА программирования. Выглядит убого. Впрочем, как и последние довески из 0х, когда начали уже совсем дичь пхать, добив по сложности и так непростой С++ до предела, но те хотя бы к языку относяцца.
Если же рассматривать СТЛ как просто библотеку, то да весьма милая, но неудобная, т.к. предполагаецца, что реализацию вообще-то надо от пользователя сокрывать, с чем СТЛ с успехом не справилась, ибо в общем случае все контейнеры сводяцца к мутабельным и немутабельным словарям и массивам.
>У обжектива такой нету — типозащищенной и производительной.
Типозащищенность — это что в твоем понимании? Уточняю заранее ,чтобы потом ты мне не начал доказывать, что на луне трава не растет.
Прозиводительность. Как мы уже обсудили выше, таки есть. Толкьо заинлайнить не выйдет, но это не критично на фоне сложности самих вычислений.
З.Ы. И да, ты вот все кричишь, что инлайн хорош, а ведь он иногда и просаживает производительность, нет?
МЫ начали обсуждать этот вопрос в рамках статьи эша, где четко оговорено, что он подразумевает под имп-хешем, нет? То, что ты начал путать эша имплементацию с мседжсендом, а теперь еще возмущаешься моей терминологией не меняет факта того, в каком разрезе было все изначально ,нет?
Ну придумал какой то чувак термин не имеющий смысла, чего я должен вестись?
Боже ж ты мой. В С тоже есть инлайн уже некоторое время как (С99).
Инлайнинг есть, темплейтов нету, что не позволяет написать библиотечный метод
Iaroslav Voitovych
Ювженко Денис
flyman
ScorpZ Lapshov
artificiatum
Igor Petruk
anonymous
anonymous
ScorpZ Lapshov
Dmytro Lapshyn
Leon KPI
Кацман
Leon KPI
Олександр Петров
Нестор Иванович
Bogdan Shyiak
Iaroslav Voitovych
Anton P
Sergei Lodyagin
Sergei Beloborodov
reality_hacker
Dmytro Lapshyn
Павел Яровой
Denis Muratov
св Антоний
Anton Gropyanov
Smarty Coder
Smarty Coder
dp wiz
Roman Bardachev
Ostap Vyshnya
Petro Sasnyk
Oleg Shparber
Tania Radchenko
Леголас Трандуилович
Volodymyr Sydorenko
Ivan M
Oleg Lugovskiy
Mikhail Boiko
Volodymyr Yelnikov
trimm
Valeriy Zamaraiev
Fedir Kovalenko
Doumember
Max Yehorov
Alexander Stoyakin
Max Yehorov
Владимир Кожаев
Andrey Balyn
Oleg Tyshchenko
Oleg Tyshchenko
Bohdan Rybak
Eugene Kyba
Kostiantyn Shchepanovskyi
Sergey Mylovanov
Владимир Кожаев
Sergey Bushnyak
Sergey Bushnyak
Андрей
Andrey Morskoy
reality_hacker
fizz buzz
Gremlin
tester
template<class t=""> void sort(T t[], int n)делающий инлайнинг для любого класса реализующего операцию сравнения. В С прийдется либо копипастить код сортировки каждый раз для нового класса, либо обходится без инлайнинга.
Однако ,в реальности, оверхедом на вызов при разумно подобранной архитектуре можно пренебречь
Ну где можно, а где нельзя.
Нет. Лажа — это обосновывать потери в быстродействии через оверхед на расчете функции хеша, которая, кроме самых примитивных случаев, намного более вычислительно сложна.
Ну Ок, хеш не сильно хороший пример, а вот сортировка отличный пример, и миллионы ц-шных програм тормозят уже сегодня из-за отсуствия темплейтов в ц.
Ерланг тормозной язык, его суют в хай лоад(не high performance) из-за реализованных идей с актерами и легкими потоками, позволяющих одновременно обрабатывать милионы конкурентных запросов, но одновременно не значит быстро.Про хай пефоманс. Тут эрланг с явой и шарпом в таковые записывают
Вот кстати в тему: www.rhussmann.com/...-c-and-results
Моя икнула. У обжектива вообще нет библиотек. Обжектив — это язык. Синтаксис. Все. СТЛ монструозен и костыль, т.к. какую-то конкретную реализацию пхнули в стандарт ЯЗЫКА программирования.
Понятно, обьяснений я не услышу.
т.к. предполагаецца, что реализацию вообще-то надо от пользователя сокрывать, с чем СТЛ с успехом не справилась, ибо в общем случае все контейнеры сводяцца к мутабельным и немутабельным словарям и массивам.
Я не осилил, можно конкретный пример?
ипозащищенность — это что в твоем понимании? Уточняю заранее ,чтобы потом ты мне не начал доказывать, что на луне трава не растет.
Это когда в контейнер
vector<car>ты не можешь засунуть обьект book, и это отловится на этапе компиляции.
З.Ы. И да, ты вот все кричишь, что инлайн хорош, а ведь он иногда и просаживает производительность, нет?
Это какие то фантасические случаи.
>Ну придумал какой то чувак термин не имеющий смысла, чего я должен вестись?
Того, что мы начали обсуждать это в контексте его статьи, после чего ты вдруг скатился до иной терминологии. Ну а теперь уже просто дергаешься, лишь бы не признавать очевидное, что имп-кеш работает быстро, в отличии от мсж_сенд.
>Инлайнинг есть, темплейтов нету, что не позволяет написать библиотечный методделающий инлайнинг для любого класса реализующего операцию сравнения. В С прийдется либо копипастить код сортировки каждый раз для нового класса, либо обходится без инлайнинга.
С тем, что темплейтов нед я и не спорю. В С — да. В обжективе — нет. Достаточно использовать месседж форвардинг. Ну и опять же, вспоминаем, что для большинства сортировок, кроме самых элементарных с самыми простыми объектами, вызовом функции можно пренебречь.
>Ну где можно, а где нельзя.
Пример, где нельзя в студию.
>Ну Ок, хеш не сильно хороший пример, а вот сортировка отличный пример, и миллионы ц-шных програм тормозят уже сегодня из-за отсуствия темплейтов в ц.
Угу. Особенно линукс тормозит, да? Да и не только он. Все тормозит, зато кресовые винды летают. Да? Сортировки, кроме самых простейших, где сравнение одного поля с одним числом, таки позволяют пренебречь такой деталью, как вызов метода.
>Вот кстати в тему: www.rhussmann.com/....-c-and-results
Ню-ню. Есть такой момент, он использовал высокий уровень с блоками, диспатч кью и подобным. Говорим о скорости, пишем оптимизированный код, нет? А то парадоксальная ситуация, что на крестах пишем с нуля и гордимся скоростью, ну а в обжективе внезапно сравниваем готовые библиотеки высокоуровневые и чмырим оный, хотя изначалньо разговор был тоже о том, чтобы писать оптимизированный код ,а не пользовать то, что дано из высокоуровневого, не?
>Понятно, обьяснений я не услышу.
Уже несколько раз давал. Перечитай в цикле до просветления, не?
>Я не осилил, можно конкретный пример?
Посмотри на количество контейнеров в СТЛ. Когда выбираешь, какой контейнер пользуешь, сам учитываешь особенности контейнера. В итоге, контейнеров куча, ты долежн понимать базисы их реализации дял выбора правильного. Перейти с одного вида контейнера одного типа на другой контейнер того же типа можно только вручную.
В итоге, реализация от пользователей не сокрыта.
Как надо, чтобы реализация была сокрыта — в зависимости от того, сколько данных в контейнере на данный момент, переключацца между конкретными реализациями самостоятельно без ведома пользователя. Тогда, получаем только два контейнера — ассоциативный (словарь) и последовательность (массив). Отдельный камень, иммутабельных контейнеров в СТЛ нет ведь?
>ты не можешь засунуть обьект book, и это отловится на этапе компиляции.
Тю. Делаецца и в обжективе, но более многословно (вариантов много, лично мне нрацца добавление протокола с указанием типов). Выбивает не ошибку на этапе компиляции, а ворнинг, если не шаманить с настройками компилятора.
>Это какие то фантасические случаи.
Злая реальность. Если найду этот код в анналах, обязательно покажу. С++ с инлайнингом просаживал производителньость в 2 раза. Человек писал сей код по математическим выкладкам и прототипу в матлаб. Вся математика была заинлайнена. Математика — здоровые функции инлайновые, которые вызывают здоровые функции инлайновые, которые... и т.п. Так что инлайнинг таки не всегда полезен.
Того, что мы начали обсуждать это в контексте его статьи, после чего ты вдруг скатился до иной терминологии.
Еще раз, а чего я должен употреблять достаточно странную терминологию какого то одного чувака, который уже наверное и сам про нее забыл?
Ну а теперь уже просто дергаешься, лишь бы не признавать очевидное, что имп-кеш работает быстро, в отличии от мсж_сенд.
Я спорю с тем что быстро — понятие относительное.
Достаточно использовать месседж форвардинг.
В пятый(кажется) раз — пример кода в студию.
Все тормозит, зато кресовые винды летают.
Откуда дровишки про винду на крестах?
Ну и опять же, вспоминаем, что для большинства сортировок, кроме самых элементарных с самыми простыми объектами, вызовом функции можно пренебречь.
В правильных алгоритмах все операции сравнения как раз простые, например в бд, очень не хочется обнаружить что програмулина тормозит на 30%(при этом наплодив кучу гавнокода с сайд эфектами который ты называешь оптимизациями) только потому что выбрал неправильный язык. Другой пример таже хештаблица — если произошла колизия хеша то нужно сравнить нового элемента со всеми элементами бакена что бы проверить его уникальность.
Когда выбираешь, какой контейнер пользуешь, сам учитываешь особенности контейнера. В итоге, контейнеров куча, ты долежн понимать базисы их реализации дял выбора правильного. Перейти с одного вида контейнера одного типа на другой контейнер того же типа можно только вручную.
Ну да, область стл да и ц++ - там где производительность важна, и люди обычно должны понимать как работает контейнер когда его юзают. Отсутствие runtime полиморфизма — плата за производительность раннего связывания.
Отдельный камень, иммутабельных контейнеров в СТЛ нет ведь?
Да, недостаток, но наверное не критичный.
Тю. Делаецца и в обжективе, но более многословно (вариантов много, лично мне нрацца добавление протокола с указанием типов). Выбивает не ошибку на этапе компиляции, а ворнинг, если не шаманить с настройками компилятора.
А пример кода посмотреть можно?
Математика — здоровые функции инлайновые, которые вызывают здоровые функции инлайновые, которые... и т.п.
Ну и у тебя есть соображения почему инлайнинг тормозил программу? Милион вызовов мелких функций был бы быстрее? Может проблема в чем то другом была?
Ню-ню. Есть такой момент, он использовал высокий уровень с блоками, диспатч кью и подобным. Говорим о скорости, пишем оптимизированный код, нет? А то парадоксальная ситуация, что на крестах пишем с нуля и гордимся скоростью, ну а в обжективе внезапно сравниваем готовые библиотеки высокоуровневые и чмырим оный, хотя изначалньо разговор был тоже о том, чтобы писать оптимизированный код ,а не пользовать то, что дано из высокоуровневого, не?
Ты все попутал, там нуб писал на эрланге используя высокоуровневый фреймворк без оптимизаций из коробки, а не оптимизированный ц++ код.
И ненадо тут откапывать всякое.OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things
перед тим, як г-но мамонта відправити в музей вивчаю його консинстенсію
Читаемость ниже плинтуса
У кого что получается.
ТРем не менее, читаемость слабая, не так ли? Особенно, при применении фич, доступных дял сего языка, типа шаблонов?
Не так ли, приведи пример ц++, и твоего любимого языка который бы демонстрировал разницу в читаемости.
Без проблем ,но завтра, если не против ты.
Буду писать дял сравнения с этим: www.developers.org.ua/...y-usage/#145006 , т.к. у меня до сих пор висняк и я не могу понять разницы. Точнее, возьму дял сравнения несколько методов, котоыре приведу ниже.
Хочу дял чистоты эксперимента уточнить, знаком ли ты с обжективом. Скажем, я с С++ на уровне шаблонов не знаком, т.к. уже вообще ничерта не помню. И после этого сравним читаемость. Скажем, я так и не смог понять некоторые тонкости в этом куске кода:}
template<>}
virtual void CreateAndSwap(void * pObject, int iMaxSize)}
Посмотрим, поймешь ли ты в моем это без знания языка. Гы?
Там у автора очень высокий полет мысли, возьми попроще пример.
Я не С++ник. Мне тяжко взять пример посему, прост, первое, что пришло на ум из непонятного. Если дашь что-нить подобное на шаблонах, то переведу на свой язык, если пояснишь, что сниппет делает. Скажем так, именно темплейты вызывают в читаемости для меня основные проблемы. Ну и вызов функций, как таковых, что тоже приведу в примере переделки.
И обьясни чего тут непонятного и как это можно улучшить с помощью продвинутых техник.
Я не знаю, почему ты говоришь о продвинутых техниках. Я речи о них не вел.
Первое, что бьет по глазам:BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, const IndexDetails& _id, const shared_ptr< FieldRangeVector > &_bounds, int _direction, bool useFRVSpec )
BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, const IndexDetails& _id, const BSONObj &startKey, const BSONObj &endKey, bool endKeyInclusive, int direction)
BtreeCursor* BtreeCursor::make(NamespaceDetails *_d, int _idxNo, const IndexDetails& _id, const BSONObj &startKey, const BSONObj &endKey, bool endKeyInclusive, int direction)
Читаемость уже ударена сильно, но это связано с самим синтаксисом. Во-первых, тут три функции с одинаковым именем, но разными параметрами. Во-вторых, читакемость бьет сам вызов, о чем ниже.
Посмотрим на вызов из самого кода:make( _d, _d->idxNo( (IndexDetails&) _id), _id, _bounds, _direction, useFRVSpec );
Все замечательно, только непонятно, что они жрут на входе у кого конкретно вызываецца этот метод, если не лезть в описание функции и включать подсказку. Самое главное, я далеко не сразу нашел, где этот метод и какой именно из нескольких одинаковых по имени методов вызываецца. Зато лаконично. Это я еще не прошелся по именованию переменных, в котором черт ногу сломит.
Сравним читаемость с Обжективом, который более многословен (не знаю, статичен ли мейк, считаем, что таки статичен):Многословен? Да. Читаем? Да. Именование оставил то же, что и в оригинале, хотя, такое именование в обжетиве недопустимо.
И да, в данном шаблоне нет рекурсивного подсчета и чего-то подобного, что меня заставляло вешацца всегда. Если в обещм, пример приведенный вами уже намного более читаем, но, все-таки, недостаточно из — за особенностей синтаксиса С++. Но ,в нем нет и специальной шаблонной магии ,если я правильно это понимаю.
Все замечательно, только непонятно, что они жрут на входе у кого конкретно вызываецца этот метод, если не лезть в описание функции и включать подсказку.
Опционально можешь называть методы по разному и добавлять коментарии о параметрах — дело вкуса.
Вычисления в шаблонах это пример чего-то там головного мозга, типа дали обезьяне гранату с большим количеством степеней свободы. Я так считаю.И да, в данном шаблоне нет рекурсивного подсчета и чего-то подобного, что меня заставляло вешацца всегда.
Если правильно писать на ц++, все более менее читаемо и понятно, не так лаконично как в питоне конечно , но это уже вопрос компромисов.
>Опционально можешь называть методы по разному и добавлять коментарии о параметрах — дело вкуса.
Эмм... Я, наверное, не правильно понял, но makeCursorWithNamespaceDetailsIndexDetailsNumberIndexDetailsInDirectionShouldUseFRVSpec( _d, _d->idxNo( (IndexDetails&) _id), _id, _bounds, _direction, useFRVSpec) читаемости коду не добавит. Это не только в С++ проблема, как по мне, т.к. после нотации, подобной той, что я привел, читать голые названия функций у которых еще и не интуитивные названия переменных ну очень тяжело. Очень уж болезненный синтаксис, хоть и лаконичный.
>Вычисления в шаблонах это пример чего-то там головного мозга, типа дали обезьяне гранату с большим количеством степеней свободы. Я так считаю.
Тогда этот вопрос снимаецца, т.к. именно чтение подобного кода у меня всегда вызывало вопросы и непонимание. Собсно, яркий тому пример — топ про оптимизацию в С++, где я не понял ничерта, а парсер, сожрав теги, еще и добавил сложностей в понимании.
makeCursorWithNamespaceDetailsIndexDetailsNumberIndexDetailsInDirectionShouldUseFRVSpec
Там вполне можно заюзать например makeByRangeAndFRVSpec(), не обязательно все одинаковые параметры тулить в имя метода.
Но тогда проблема читаемости остаецца. Откуда я знаю, что лежит в остальных параметрах, если не лезу в доку или хеадер?
Но тогда проблема читаемости остаецца. Откуда я знаю, что лежит в остальных параметрах, если не лезу в доку или хеадер?
Проблема нечитабельности там потому что товарищи локанично называли переменные(возможно потому что им эти сокращения о многом говорят), если переменные называть правильно то и читаемость будет правильной.
ДЫк в том-тьо и дело ,что читаемость, зависящая от именования переменных — это плохо. И именно об этом я и говорил. Скажем, если у нас подряд несколько вызовов одной и той же функции с разными входами, то с читаемостью вновь будут вопросы, т.к. с переменными прийдецца, ибо они же однотипные извращацца.
обджектив тут тоже не защищен:ДЫк в том-тьо и дело ,что читаемость, зависящая от именования переменных — это плохо.
Ну и ты похоже согласен что если на ц++ правильно писать то с читаемостью все Ок?
Согласен. Даже на лиспе, если писать правильно, с читаемостью нет проблем. Однако, для этого надо приложить разные усилия. Как по мне, читаемость С++ ниже плинтуса из — за вызова функций, что лечицца именованием к которому надо подходить очень придирчиво. Однако, подходят же редко настолько грамоно. Даже в таком большом проекте, как тот, ссылку на который ты дал. В итоге, в обжективе можно прочитать: [f createWithReference:b], где именование — важная составляющая, в то же время даже в годных проектах мы видим на С++ create(b)б где созадтелям все понятно, но мне, лично, без старателнього вчитывания, поверхностным осмотром не разобрацца.
Счас мы говорим о чем — о читаемости кода ? Читаемость кода, в первую очередь, завист от криворукости разработчика. Я видел код на С++, который выполнен в определенной стилистике, структурно разложен по классам и методам, основные функциональные блоки кода закоментированы — все прекрасно читается и через несколько минут понятно что ут и как работает и при это голова не болит, как от ящика мартини. С другой стороны я видел код на том же С++ написанный , который еще типа компилится и типа работает и выполняет то же , что и предидущий код,,, но там какие то ф-ции на тысячи строк кода ,с сотнями переменных, где все смешано в одну кучу.. — там черт ногу сломит.
Так что читаемость / нечитаемость кода — это в первую очередь заслуга конкретного разработчик, а уже во вторую — особеность того или иного языка.
ИМелаьс в виду читаемость самих конструкций. Особенные проблемы с шаблонами в темплейтах и стле. Ну сложно это читать, зачастую, неинтуитивно нифига.
Да и сами вызовы методов в С++ читаюцца плохо, приходицца лезть в справку, чтобы узнать, что же принимает функция.
:)
св Антоний
Найкращі коментарі пропустити