Обсуждение:C++

Материал из Lurkmore

• В разделе по OpenCL писать «nVidia запилила CUDA, а затем и OpenCL» некорректно, ящитаю. OpenCL вроде как Apple изначально запилила, а потом потом работы продолжила Khronos Compute Working Group, в которую не только nVidia входит.
• УБЕРИТЕ УЕБАНСКИЕ ХЭЛОВОРДЫ, БЛИА!) ++ конечно говно, но «хэловорды» ещё хуже. =) серьезный язык же, не?)

Пример с СОМовым хелловорлдом я бы выпилил — С+±специфичного там мало, это скорее MS-специфичное. C+±ный подобный вариант хелловорлда где-то видел, с темплейтами, smart-pointer'ами и всем прочим.

• Лучше сам найди и замени. У меня сейчас свободного времени не очень много, поэтому и статью сделал наскоро, чисто отвлечься.

Ересь ООП. фейспалм.жпг

MFC — это вообще пиздец. Настолько кривого пакета придумать сложно. Сам кодю на C#, а С++ и особенно MFC (Mother Fucking C) вспоминаю как кошмар. К примеру, последний код из примеров хелловорда — явно заточен под MFC.

Используй ATL/WTL, Люк.

Многие ассоциируют кодирование GUI на C++ с убогим MFC. Есть те же QT, gtk, С++ Builder на конец, etc. Так же многие сравнивают языки программирования(!) по сложности кодирования GUI в той или иной среде, например Delphi vs MFC. Прекращайте это быдлячество.

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

А реализовать строку — это такой особенный юмор?

Подключай STL-овский std::string. Довольно годная разработка, включение коей в Стандарт очень облегчило жизнь.

От автора о хелловорлдах

Хелловорлды взяты отсюда: [1]. Если Анонимус заменит их на более адекватные, не нарушая общей идеи, то я только ЗА.

В чём поинт наличия четырёх хелловорлдов?

В сложности изобретённых велосипедов, очевидно. А на самом деле, HelloWorld'ы надо писать на w:HQ9+.

w:HQ9+ — FFFFUUUUUUUUUU~ первый интерпретатор Delphi такое УГ, удолил. А всё-таки, почему бы не оставить только первый хелловорлд здесь ?

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

По-моему, вариант 4 не будет работать. int main() HelloWord { - что за??

Там стоит #define HelloWord, который заменяет HelloWord на пустую строку.

Никто не будет против, если я из хеллоувордов уберу всякие getch, system("pause") и тому подобные вещи? Они нужны лишь для того, чтобы при запуске в венде получающегося консольного приложения, выскакивающее окошко консоли с выводом программы не пропадало бы раньше времени, до того, как программист успел прочитать надпись "Hello, world". И использование такой паузы, какбэ не труЪ. Хотя с другой стороны, какбэ школьный мем, и может хуй с ним, пускай будет?

Реакции не было, видимо всем пох. Удалил. Правда оставил в примере #11, его единственным отличием от варианта #1 является как раз использование conio.h и _getch. Быть может вообще стоит экстерминировать этот вариант #11?

Ололо

Плюсовики возомнили себя пупом вселенной. Учните хаскельца!

• О да. «Умение героически преодолевать трудности, которые создает твой собственный инструмент» — это скорее про хацкель, чем про С++.

void main

Распространено заблуждение что «void main(){}» — коррекное объявление головной функции. На самом деле, оно некорректно. Путаницу вносит то, что:
1. int main() {} — корректно и вернёт 0.
2. main() {} — в Си до С99 корректно и вернёт 0.
Пожалуйста, не пишите void main в хелловорлдах.

Ok, признаю, был не прав. Суть в том, что если объвить int main, а в теле функции не указать return вообще, гарантировано возвращение нуля. Но, поскольку, возвращаемое значение не входит в сигнатуру функции, компилятор не должен различать эту ситуацию. Плюс святая уверенность в обратной совместимости с С. Каюсь.

«Суть в том, что если объвить int main, а в теле функции не указать return вообще, гарантировано возвращение нуля.» ЛОЛЩИТО? behavior is undefined (implementation-specific), бля!

Ещё один. Кури 3.6.1/5

 A return statement in main has the effect of leaving the main function
 (destroying  any  objects with automatic storage duration) and calling
 exit with the return value as the argument.  If  control  reaches  the
 end  of  main  without  encountering a return statement, the effect is
 that of executing
         return 0;

Это не единственное необычное свойство main, об остальных — в других параграфах 3.6.1

>behavior is undefined (implementation-specific), бля!

Кстати, «undefined behavior» и «unspecified behavior» — это две большие разницы. Смотреть 1.4/1.

Луговский

Может лучше создать раздел и скопировать туда больше утверждений с того треда?

Драма, рекомендую

Обсуждение шаблона:Языки программирования

Александреску

Надо добавить срач про «Современное проектирование».

Да-да, реквестирую то же самое. Я — увы, — не в теме всего этого «современного проектирования»: профессиональная деятельность моя, слава богу, не требует, а «для себя» мне это неинтересно, «для себя» мне хватает Common Lisp'а. А между прочим, складываются достаточно интересные срачи, когда «современные» программисты не представляют себе кода без нагромождения шаблонов, а более консервативных обвиняют в том, что те пишут не на C++, а на «C с классами.» Причём до меня доходили отголоски IRL срачей, когда консерваторов по результатам «ушли» с работы, за их консерватизм.

Недоумение

Я не понимаю шаблоны. Совсем не понимаю. Легче понять сложнейшие системы объектов, интерфейсов и прочей хуини. BPW-кун

И поэтому пласофагам похуй на характеристику «быдлокодерский», ня.

если ты такой то это неисправимо, да.

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

чуваки, ну в натуре жгете! Ёбанный насос, в самом деле очень круто и интересно! Всего вам всякого кошерного и насосного! Уть-уть!!!

тогда предлагаю вам упороться от невозбранно заимствованного с говнокода struct X{template<class T>X(T);X g(){X(this->*&X::g);}};

лол ведь, он нигде не используется, паскалестрекатель — вон из треда!

первый хелловорлд

В такой маленькой программе ошибку сделали. Вот мудаки. Правильно так:

#include <iostream>
int main()
{
  std::cout << "Hello, World" << std::endl;
}

Сброс stdout через endl совершенно излишен. Достаточно std::cout << «Hello, World\n»

—Мимо проходилНе ври endl может быть разное в разных ОС, в Mac OS, например это '\r'

Почему бы тогда не написать вот так?

#include <iostream>
using namespace std;
int main()
{
  cout << "Hello, World" << endl;
}

Быдло-язык?

Лол тому, кто утверждает быдлонутость языка из-за отсутствия сборки мусора. Если в ц++ будут свистоперделки ввиде сборки мусора, потоков (и прочего говна из boost) то это будет уже не ц++. С таким же успехом можно называть быдло-ц.

Может, выпилить ту секцию полностью?

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

LoL или не-LoL — совершенно не важно, поскольку троллить C++-быдлокодеров отсутствием сборки мусора, сам Б-г велел. У них есть всего два аргумента в пользу отсутствия сборки мусора: 1) сборка мусора замедляет работу программы; 2) со сборкой мусора любой дурак напишет, а вы попробуйте без неё. Очевидно, что второй пункт порождает массу лулзов, если его грамотно вскрыть, первый же раскрыть в полной мере чуть сложнее, для этого надо представлять себе особенности работы кучи при ручном управлении выделением/освобождением/указателями, так и особенности сборщика мусора, в том числе и разные стратегии сборки мусора. Но всё не так ужасно, поскольку, все эти особенности достаточно знать и понимать в объёме, превосходящем познания лишь типичного C++-кодера, который познав Александреску, решает что нынче он Программист, и больше ему ничего знать не требуется. Соответственно все его познания о сборке мусора сводятся к тому, что «сборка мусора, это когда delete писать не надо.»

Ксеноцефал

В связи с акцией по зачистке статей от мусора, из данной секции были выпилены примечания, полемизирующие с мнением этого персонажа. В результате, «охуенно ценное IMHO от быдлокодера» выглядит общим мнением. Это неправильно. Предлагаю либо выпилить ксеноцефальные излияния, либо добавить альтернативные мнения, излагавшиеся в примечаниях.

Оформил как цитату. Опровергнуть при большом желании можно непосредственно под.

Поскольку спорить в статьях нам строжайше запретили, выношу моё «охуенно ценное IMHO» на суд уважаемой публики на странице «Обсуждение» ;-) Синтаксис и структура написания программ на C++ действительно имеют достаточно «неудобных моментов», но, если быть честными, неменьше неудобств и «технических нелепостей» присутствует и в Жабе, и в Дельфи, и в любом другом языке общего назначения, который претендует на определённую универсальность. Что касается C++, то большинство кирпичных экскрементов вокруг него порождены простым нежеланием быдлокодеров нормально изучить этот язык. Кроме того, кодеры на других языках часто считают, что знание, например, Джавы или структурного C, автоматом делает их экспертами в Це-плюс-плюсе. Они не хотят понять, что C++ это не «навороченный ANSI C» и не «предыдущая версия Джавы», а другой язык со своей спецификой, своим инструментарием, своим синтаксисом и правилами компиляции и исполнения кода. Другая вестчъ, которую часто упускают из вида обличители Си-плюс-плюса, это тот факт, что задача определяет выбор инструмента, а не наоборот. По этому, как это делает Ксеноцефал, они часто пытаются представить знание C++ как нечто «необязательное» или «ненужное», и пустословят о «сложностях, которые создаёт твой собственный инструмент». Конечно, если ты ваяешь Web-странички с парой таблиц и кнопок, ничего универсальнее Javascript'a тебе не надо и С++, равно как Smalltalk, Fortran или LISP, тут совершенно ни при чём. Из моего личного опыта могу добавить, что, когда возникает необходимость, люди, нормально знающие C++, «пересаживаются» на любой другой язык с минимальными затратами времени — обычно хватает недели (а то и меньше) вдумчивого чтения какого-нибудь вменяемого руководства (типа книжки «Thinking in Java») и выполнения нескольких упражнений, что бы человек стал кодить на вполне достойном уровне, как по скорости написания, так и по качеству выдаваемого кода. А вот как раз адепты Жабоскриптов и ПыХПыхов испытывают жесточайшие сложности и могут гнать классику быдлокода в течении неограниченного времени. Возвращаясь к Ксеноцефалу, в «программистской професси-анальной» среде я неоднократно замечал, что когда человек имеет некую жёсткую формулу для определения программерской квалификации (типа «Знаешь только два языка? — Лох. Знаешь десять? — Суперэксперт.»), сам этот человек — весьма посредственный специалист. Искусство Программирования™, как и любая прикладная наука, состоит из двух разделов: теоретического и практического. К первому относятся базовые знания в теории алгоритмов, теории автоматов, математической лингвистике, реляционной алгебре, структурах данных, моделировании систем и т. д. — словом, всего того, что программеры (по идее) должны были изучить на соответствующем факультете в своём институте. Суммируя эти познания, их можно назвать «алгоритмическим мышлением» — способностью построить нужную модель и грамотно разработать алгоритмическое решение задачи, используя доступные теоретические наработки. Второй раздел, практический, предполагает знание уже конкретных языков программирования, аппаратных и програмных платформ, сред разработки и исполнения, нужного middleware-инструментария и т. п., а главное, умение использовать всё это на уровне, необходимом для правильной реализации нужных моделей и алгоритмов. Так вот, «хороший программист» это не тот, кто «обязан знать C», и не тот, кто «знает десять языков», а тот, кто обладает достаточными знанием и опытом в обоих разделах применительно к конкретной задаче. Имею наглость гарантировать, что можно запросто быть «аццки паршивым программистом», будучи полным гуру в одном отдельно взятом разделе. Если у человека хромает «алгоритмичекое мышление», он никогда не построит грамотное решение задачи, если хромают практические навыки — никогда не сможет это решение грамотно реализовать. А быть очень хорошим программистом вполне можно работая только на Вижуал Бейсике…

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

Факты -> лулзы. Статья должна быть правдивой.

В писанине выше дофига хуиты. Писать не буду, ибо придирки. С главным посылом, что программирование — это профессия, и как профессию его и нужно оценивать, согласен. Но: а) цитата представлена как частное мнение, имеющее право быть. б) язык умирает. Кстати, никто не знает на каком языке написано больше кода — на фортране или це++? Также, называть знания computer science «алгоритмическим мышлением», да ещё и говоря при этом об ОО языке — очевидный признак быдлокодера.

Так уж и умирает? Быть может он таки просто занимает свою нишу: высокопроизводительные и сложные приложения. А не пытается быть языком для всего. Алсо, QT.

Не знаю что он там пытается, но факт в том, что это довольно дорогой и трудоёмкий язык (в промышленном смысле), поэтому там, где от него можно отказаться, от него отказываются. И таких ниш всё больше и больше. Сложные приложения — это которые? Если древние проекты, типа адинэс, неро и прочего, то это не ниша, а реликт. Такое с каждым умирающим языком было. Веришь-нет, некоторым приходится до сих пор с фортраном возиться и даже деньги зарабатывают на портировании фортранных прог в современные языки. Поменять язык гораздо сложнее, чем поменять архитектуру. Но даже на линуксе складывается тенденция писать пользовательский софт не на це++, а под моно, вещи вроде зул (правда не знаю на чём зулраннер написан). Под гном так и вообще давно уже для интерфейсов юзают питон (сука, язык скриптовый, а быстрее жабы!), а движок и либы на Це. Под qt в чистом виде сейчас либо сторонние проекты портируют (как опера), но чаще пишут всякую мелкую юзерофильщину. А действительно сложные приложения — это обычно такой конгломерат, что там часто похуй на чём отдельные компоненты написаны.

Хорошо-хорошо. Давайте называть знания «компьютер саенс» знаниями «компьютер саенс». Вы что хотели сказать-то? Знания «компьютер саенс» к объектно-ориентированным языкам никакого отношения не имеют? Или вы о чём? Никакой «рекламы» C++ в моем комментарии не содержится. Содержится оспаривание мнения Ксеноцефала. Я неправ? Объясните почему. И никаких придирок :) Да, и расскажите пожалуйста, в какой-такой профессиональной среде «некоторые возятся с Фортраном, портируя проги на другие языки»? И зачем конкретно? Математику теперь проще писать на Питоне, а не на специализированном для этого Фортране? Короче — типичный быдлокодерский понос: сказано немало, но ничего по существу, зато нам объяснили что всё надо писать «под моно и зул», а «в сложных приложениях похуй на чём написаны компоненты».

Ты сейчас похож на дефектного, которому причудилось в собеседнике собственное отражение, и который поэтому готов разразиться ненавистью. Те же необоснованные проекции, провоцирование флейма и обвинения, которые как минимум в той же степени можно применить и к тебе. Попробую по порядку, конструктивно: Знания computer science отношение к ООП имеют, «алгоритмическое мышление» в буквальном понимании этой фразы — нет. Только косвенное. Если ты хочешь весь computer science свести к «алгоритмическому мышлению» — тебе в зарю эпохи ЭВМ. Про рекламу це++ не понял зачем ты сказал, я про неё ничего не говорил. Насчёт оспаривания мнения — флаг в руки, но ты прав не более, чем Луговский. Про фортран: друг знакомого этим занимается, сам с ним не встречался. Цели сугубо специальные, как это часто бывает в программистской индустрии, и зависят от конкретного куска кода. + однокурснику бывшему для дипломной пришлось с фортраном связаться. Математику сейчас проще писать не на фортране или питоне, а в маткадах, если не встают технические ограничения. И нигде я тебя не учил как и что надо писать. Я такими глупостями не занимаюсь. Это твои проекции.

Хорошо, «алгоритмическое мышление» — неудачный термин, с его помощью я хотел обобщить требуемые теоретические знания, о чём недвусмысленно написал («Суммируя эти познания…»), не так ли? Термин неудачен, согласен, но ведь я развёрнуто объяснил, что имею в виду. И ежели я теперь так похож на «дефектного», то только потому, что ты, несмотря на понимание смысла моей писанины, решил повыёживаться и записать меня в быдлокодеры :) Не твои ли это проекции? :) Про Фортран: мой близкий друг, физик, очень много работает на Фортране (как, по его рассказам, и все его коллеги — тысячи их), на Фортране, а не в маткадах, потому что задачи объёмные, обсчитываются на больших машинах, а Фортран предоставляет и хорошее быстродействие и нужные возможности параллелизации их алгоритмов. И переписывать это на что либо другое никто не собирается — это просто ненужно. Да, про «рекламу C++» я сказал, потому что вторым твоим пунктом, после замечания о том, что Ксеноцефал имеет право на мнение, было «язык умирает». Я так же на эту тему ничего не говорил.

У меня несколько трепетное отношение к буквальному смыслу идентификаторов. Это профессиональное, как ты должен понимать. «Язык умирает» — это в защиту мнения ксеноцефала. Хотя я и не утверждаю, что он прав. Такие вот ВП.

>мой близкий друг, физик, очень много работает на Фортране (как, по его рассказам, и все его коллеги — тысячи их)
Это случайно не те же самые физики, которые придумали эпиграф к статье программист?

«высокопроизводительные и сложные приложения» — это тру игры (да-да, естественно те что с корованами). И С++ там все еще юзается неплохо.

Тот же Фортран, тащемта, нихуя не умиарет, ибо в своей отрасли он замечательно работает. Аналогично с Прологом. Так что заявление о смерти С++ — ересь. Дальше. Называть С++ ОО-языком и есть быдлокодерство, потому что язык, сука, мультипарадгменный. Лисп, между прочим, ООП тоже поддерживает, если кто не в курсе. — S a 21:25, 8 ноября 2009 (MSK)

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

> Называть С++ ОО-языком и есть быдлокодерство, потому что язык, сука, мультипарадгменный.

Угу, вот только упаси Б-же писать софтину в нескольких парадигмах одновременно. Либо ты используешь Це++ как ОО язык, либо как структурный (для этой цели обычно гораздо лучше подходит Це), либо удовлетворяешь свои изощрённые сексуальные фантазии. А на лисп в контексте треда всем похуй.

Навскидку внутренности Андроида на Сях и С++. Алсо, «похуй на чём отдельные компоненты написаны» — это признак того, что архитектура в Жопе, ибо связывать несколько языков — тот еще гемморой, на который идут ради того, чтобы разделить по полочкам задачи. То есть см. того же Андроида: ядро на сях, API и обвязка на цпп, юзерспейс на жабе. Систем быстра аки скаковая лошадь, а всякие свистелки и перделки ненапряжно пишутся на жабе, которую изучить объективно проще чем цпп — разделение труда и сказка.

Никто и не говорит про связывание (ты линкинг и биндинг имел ввиду ведь?) нескольких языков. IPC же

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

Есть, но это коммерческая тайна :) Внутренний проект. А вообще, на линуксе полно софтин, сделанных по схеме клиент-сервер (и не только) с помощью IPC. Даже муз проигрыватель такой есть :) Хотя не помню, какие конктретно механизмы там используются. Может те же сокеты и пайпы. А почему это важно?

Так и shared memory можно изпользовать в программах на разных языках.

Клиент-серверную хрень я и сам пишу, но там кроме сокетов, пайпов и fork-exec юзается чуть менее чем ничего ;). И да, как минимум Перловка, Пхп, Питон, Цпп и Ц в этом проекте есть, но все работает как распределенная система по сокетам, а сокетам до лампочки от чего к чему байты гонять. А вот чегонибудь монолитного я не припомню, так чтобы активно несколько языков, вот в чем соль.
И плееры тоже — сокеты. Причем максимум два языка — клиент и сервер.

>Другая вестчъ, которую часто упускают из вида обличители Си-плюс-плюса, это тот факт, что задача определяет выбор инструмента, а не наоборот.
напомню позицию ксеноцефала. задача диктует инструмент; не существует такой задачи, для решения которой c++ был бы хорошим инструментом.

Плюсану, например. Кстати, интересное сложилось на Лурке, а именно засилье ФЛП-фагов. Вот только мне кажется, что все это лисп- и хаскельфажетсво из того же разряда, что и ненависть к маздаю у людей, которые на деле в жизни не сидели за другой ОС. ФЯП — это ж типа модно, это ж типа круто выебнуться, рассказать про то, какой Хаскель крутой и обосрать C/C++/C#/Java. Но в реале большая часть этих холиворщиков оказывается унылыми цпп-быдлокодерами :) (живого хаскельщика вообще никогда не видел). Не говоря уж о том, что стремление применять ФЛП во всех отраслях программирования является весьма удивительным. Для каждой задачи свои инструменты, ня?

Ня. О живых Хаскельщиках ходят легенды. Якобы они где-то водятся…

Функциональщина она даёт неожиданные удобства и в самых неожиданных местах (неожиданных, если с C/C++/C#/Java переключаться на неё). Попытка вернуться обратно на C/C++/C#/Java вызывает баттхёрт, поскольку то, что в черновой задумке выглядело просто, вдруг оказывается нереализуемо средствами языка, и приходится возвращаться к этапу проектирования программы, привносить новые классы, или члены классов, или добавлять аргументов функциям, или ещё что-нибудь в этом роде (например из-за того, что нет макроязыка, или из-за того, что понятие функции слишком узко, или потому, что понятие типа слишком узко, или потому, что понятие метода слишком узко, или уёбищная трактовка ООП не даёт развернуться). Лисп/хаскель -- это два других подхода к написанию программ, альтернативных тому, что используется в C/C++/C#/Java. Когда мозг встаёт на рельсы лиспа, то всё остальное выглядит также, как выглядит ассемблер с точки зрения C++ программиста. С хаскеллом ситуация менее радикальна, и немного в другой плоскости, но всё равно достаточно ярка. Но на лиспе с хаскеллом сложно заработать денег, поэтому приходится писать на каком-то дерьме. Проходит время, мозг вновь перестраивается-приспосабливается к убожеству C/C++/C#/Java и баттхёрт уходит. Остаётся ощущение того, что функциональщина -- это сказка и рай для программиста.

Годная копипаста

When you see the code

    i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

Источник: http://www.joelonsoftware.com/articles/Wrong.html

Ну Джоэл Спольски в своём духе. Хотя реально тема непредсказуемости смысла операторов в статье не раскрыта (разве что в примере analog literals)

Речь не о пидаре и его статье. Сама копипаста вне контекста доставляет. А статья спорная, да. Точнее, если выжать оттуда воду, то останется 2-3 тезиса, которые можно легко опрокинуть или, по крайней мере, поставить под сомнение из значимость. Ну да опять же, не о том речь, а то щас разболтаюсь…

ололо #define i return; j

Ну да, но так никто не делает. Точнее так можно сделать только из сознательной злонамеренности. Хотя именами i и j сложные объекты тоже никто не называет.

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

#define i *((rand()%7&1)?&i:&j)

Пидор такой пидор. Если вы видите i.assign(j.multiply(5)); вы знаете еще меньше — модифицирует ли multiply j или нет, а из названия multiply это никак не вытекает. Да и ООП лучше не использовать совсем: чтобы узнать что делает SomeClass.Foo() нужно слазить в ее определение, а оттуда в другие классы, которые она вызывает. Даже в ассемблере символические ссылки лучше не использовать: если вы видите mov [z],1 то вы не знаете, где лежит z и какой у нее размер.

Вы все тупо не шарите в ООП!!! Весь смысл ООП состоит в том, что вам нафиг не сдалось что именно делает тот или иной оператор, тот или иной метод. Это проблемы тех, кто этот оператор/класс пишет и документиует. И вообще, жава рулит!

Очередной быдлобенчмарк или сосание хуёв по-быдлокодерски

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

Итак, начнём с формальностей:

По ссылке приводится исходный код программ, но не указывается вообще ничего о среде компиляции/исполнения и машине, на которой проводился тест. В таких тестах запросто могут иметь значение версии компиляторов, библиотек и ОС, а так же характеристики машины. Я запустил программу на С++ на старом Acer Aspire 5600 с 2ГБ памяти под ХРюшей и через несколько секунд активно заработал свап (Венда в своём стиле) — а это значит, что тест уже не особо чистый. О подобных деталях, некоторые из которых могут значительно влиять на результаты бенчмарка, аффтарь статьи не обмолвился ни словом, зато пускается в пространные рассуждения про OutofMemoryException на 1.4ГБ и прочую поебень.

Далее, вот вывод, который делает аффтор:

"Получается, что выделение/освобождение памяти GarbageCollector'ом (который двигает объекты в памяти, ведет себя непредсказуемо, да и вообще «дико тормозной») происходит почти в полтора раза быстрее, чем в native-коде!!! Мда-а-а, недаром говорят «доверяй, но проверяй -)))) Ну и кстати аналогичные результаты получаются, если изменять размер объектов, их число и количество итераций…»

У меня вопрос. Почему аццкий сотона аффтар, так убеждён, что в его тесте сравнивается именно время «выделения/освобождения памяти GarbageCollector'ом»? Делал ли он профайлинг программ? Не буду тянуть, вот чью скорость меряет этот супер-мега бенчмарк (в программе на C++):

 memset(data, 0, 1024 * 1024);

С этой инициализацией, на упомянутом старом лэптопе, прога выдает 76.8 секунд в среднем, а без неё… 1.04 секунды. То есть порядка 98,7% всего времени исполнения программы, тратится на инициализацию каждого создаваемого объекта, а вовсе не на администрацию памяти. Почему memset «от Ц-плюс-плюс» работает медленнее аналога «от Ц-шарп» — хуй проссышь, может функция Ц-шарп как-то круче, а может Ц-шарп вовсе не инициализирует весь массив сразу при создании объекта, а делает это по мере запросов на доступ к этому массиву, но в любом случае к администрации памяти (GC vs. new/delete) этот тест не имеет вообще никакого отношения, и выводы сделанные башковитым аффтаром — ложь, пиздежь и провокация, а также классика быдлокодерства.

1. memset — это просто C, 2. На оптимизацию жаб и решоток потрачены миллионы, а сколько потрачено на стандартую функцию? 3. зависит от компилятора, тру-компилеры вроде GCC ещё и похлеще результаты выдают.

4. Что ты хотел сказать-то?

5. Что ты хуйнёй страдаешь. 6. GarbageCollector удаляет память, а не вылизывает её. 7. Cистемы ты будешь писать расчитывая на GarbageCollector? 8. Там стопицот лиит-техник оптимизации.

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

«На оптимизацию жаб и решоток потрачены миллионы, а сколько потрачено на стандартую функцию» — блеа ты риально тупой. ты настолько безумно тупой что не понимаешь даже что делает memset. и никогда не поймёшь.

САСИ МОЙ ХУЙ УЁБИЩЕ АЗАЗ МАМКУ ЕБАЛ)00 АБАСЦАЛ УЁБОК)0

Самый элементарный vs Вариант 0

Да вы упоролись. «Самый элементарный» и будет «Вариант 0». А «cstdio, элементарный, C++» это какой-то пиздец.

Линус Торвальдс о плюсах

может стоит запилить в статью? http://article.gmane.org/gmane.comp.version-control.git/57918

Не стоит. Очередное нытьё от профессионального обличителя и ненавистника плюсов. В статье и так до хрена ненависти и говна.

Хороший костыль со статичными переменными-членами класса

http://weblogs.asp.net/whaggard/archive/2004/11/05/252685.aspx

Нытьё от неправославного дотнетоё-аря, с лвлзом в лулзе:

Also do any initialization if needed

, а лулзов кроме инициализации я не вижу.

Вообще стоит добавить раздел с костылями, доставшимися в наследство или вызванными этим наследством от Си.

что делать если нужна скорость + ООП ?

при всей критике языка другого быстрого по скорости выполнения языка с поддержкой ООП я не вижу

добавь в подраздел «boost», пож.

а зачем мне boost? если есть OpenCL и CUDA ^__^ (слышал о них?)

ООП не нужен.

Куда?

Из библиотек как бы понятно, что Boost и Qt имеют к плюсам непосредственное отношение.

Но CUDA тут причём?

написана под C++ потому что а не под LISP

Gamedev

В средне- и крупно-калиберном геймдеве остаётся (и, видимо, будет оставаться) основным орудием труда. Правда, окруженный ещё десятком соседей: питон, Lua, C#, Squirrel. В мелком вытеснен обжективом, экшенскриптами и шарпами.

Почитать-тред

Суп, луркеры. Можете посоветовать какой-нибудь хороший учебник по С/С++? На /s/ зобанили, гуглу не доверяю

Ну, для начала:

• Б. Керниган, Д. Ритчи — «Язык программирования Си»
• А. Ахо, Д. Хопкрофт, Д. Ульман — «Структуры данных и алгоритмы»

А затем… SQL, TCP/IP и жаба с решётками. Если хочешь когда-нибудь где-нибудь работать, конечно :-(

C++

Я смотрю, у автора статьи батхёрт нехилый + в некоторых местах абсолютная хуйня написана.

— C++ это язык, на котором люди могут управлять машиной - с ручным управлением ресурсами, детерминированным освобождением, минимальным оверхедом - машиной, которой она на самом деле является...
— Ты СОВЕРШЕННО не понимаешь в чем суть С++. С++ это не лисп «о, привет GC, зацени сколько объектов я навыделял в куче, гыгы». С++ это не псевдоинтеллектуальный онанизм Haskell. C++ это не Python, Java или С#. C++ это язык, на котором люди могут управлять машиной - с ручным управлением ресурсами, детерминированным освобождением, минимальным оверхедом - машиной, которой она на самом деле является.
Захватили по ссылке объект в стеке, а мы смеемся. ПМ вставил за текущую память, а мы смеемся.
Проект три раза упал в продакшене с segmentation fault, а мы смеемся и просим еще. Конструкторы копирования, конструкторы по умолчанию, конструкторы перемещения — мы смеемся. RAII, SFINAE, undefined behavior, template<template<template, Александреску, rule of three, auto_ptr — мы смеемся. Вызвали невиртуальный родительский деструктор на объекте дочернего класса — мы смеемся. Мы бездушно подпишемся под чем угодно, наши предпочтения не основаны на здравом смысле, ручное управление ресурсами — наша стихия, мы — истинное лицо программирования.

CUDA и OpenCL

Если не отключить режим SLI, то CUDA видит только одно устройство (карту). Стандартными библиотеками можно пользоваться, но количество элементов ограничено размером CUDA Array, которые в этих библиотеках используются. Классы прикрутили далеко не сразу, изначально это си-лайк язык (да таким и остался). Не каждую задачу можно сделать параллельной, тем более для SIMD архитектуры. Да и количество потоков, которые нужно создать, чтобы полностью загрузить графическое ядро для GT 580, например, более 16000. Тут проблемы с загрузкой одной карты наблюдаются, не то что нескольких. Что в результате? Для научных вычислений пригодилось, да еще как. Но там не ленятся написать это как следует, да и задачи подходящие есть. А вот для всего остального ценность пока (?) низковата. Многоядерники-то не все освоили, не то что аппаратно-зависимое программирование для GPU (с пятью-то видами памяти). А без учета архитектуры можно «наваять» такое чудо, которое будет работать медленнее ЦП.

STL и структуры данных

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

Поциент скорее мёртв, чем жив?

Начинают-ли на С++ новые проекты, или сейчас он используется только для введения новых костылей в старые? А то, на первый взгляд, везде: под виндой - шарпы, под линуксом - жаба и питон —Анонимус

Из меинстрима ушел. Применяется там, где эти ваши шарпы и джавы не пролезут, но такого мало. Если стоит выбор учить плюсы или жабу/шарп - учи жабу/шарп.

как оно там, в сумасшедшем доме?

GameDev на нём сидит, потому что другие языки уступают в скорости + графические библиотеки в основном написаны под C++

Да тут дело не столько в скорости и наследстве, сколько в УБЕР ВСЕОБЪЯДНОМ ООП, который хоть и даёт писать чёрти что, он отлично поддаётся расширению функционала.

На самом деле достаточно любопытный вопрос. Я бы сказал, что поциент скорее жив, чем мёртв. Во всяких там линуксах, например, если рассмотреть создание гуёвого приложения, то альтернатив связке c++/qt на сегодня уже практически и не осталось. Жабу линупсоиды не любят (особенно после анального огораживания ораклом), python для гуёвых приложений -- дерьмо (хорошо видно в тормозящей убунте). Gtk+ катится в сраное дерьмо, вследствие прогрессирующего долбоебизма разработчиков. Есть ещё библиотеки из enlightenment'а, но enlightenment никогда не отличался активностью разработки, и до сих пор является сомнительным выбором для нового проекта. Xlib и всякие там Motif, потеряли популярность лет двадцать назад, а сегодня всё идёт к тому, что Xorg и вовсе будет заменён на Wayland. То есть единственным адекватным выбором тулкита оказывается qt. А к кутям, наиболее естественным выбором языка оказывается C++. Конечно, можно использовать всё что угодно в качестве языка, лишь бы бинды к qt были. Можно FreePascal, можно Haskell, можно Common Lisp, но все эти языки не канают в качестве замены C++. Можно использовать python/ruby, но их интерпретируемая сущность постоянно порождает подвисания приложения на ровном месте, поэтому шли бы они нахуй. Есть попытка запилить очередной C с классами -- Vala, -- но если разработчики gtk+ не одумаются, то Vala сдохнет вместе с gtk+. Так что, преждевременно прогнозировать смерть C++, до тех пор, пока не появится очевидной замены C++ в такой проблеме, как создание гуя в линуксе.

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

Хотя, надо отметить, что на фоне падения популярности PC, быть может эта проблема исчезнет сама собой, вместе с PC. Поскольку на мобильных платформах, типа Android и FirefoxOS, существуют официальные языки для написания гуёв, соответственно, java и javascript. Но и тем не менее, я б не рискнул что-либо прогнозировать в отношении жизни и смерти C++.

Cо смертью винды мы все перейдём на OS X и Objective-C, ибо линуксу в жизни не захавать больше 1% рынка. А C++ проживёт ещё лет пять-семь от силы, не больше (производители железа тоже на месте не сидят, и все игрули тоже скоро будут на шарпе).

Статью писал ДОЛБОЕБ, который не осилил «С++ для чайников»

Ну и ЕБАНУТЫЕ ЖЕ ВЫ ВСЕ! Автор(со-авторы) кроме «hello word» писал(и), что-то серьезное?! В обсуждении аналогично.

• Код с внутренним состоянием и жутким ссылочным навесом над ним? С ошибками доступа к памяти и утечками оной? Однопоточный, заведённый под семафоры, "не тронь — не сломается", код? И там было наследование реализации, охренеть как соответствующее предметной области, а когда впёрлись в ромбовидное "наследование", то было уже поздно?.. Это было лет десять тому назад. Но мне до сих пор страшно.
  • Что за бред? Не знаете, что такое _beginthread/WinAPI CreateThread?! Не знаете, что кроме семафоров существуют критические секции?! Ошибки доступа к памяти/утечки от кривых рук. Если что-то не устраивает, можно вставлять ассемблерные вставки и не ныть.
  • Что за бред? Не знаете, что у вас нет языка программирования и вы используете процiдурное API, что ли? Не знаете, что глобальные переменные — единственный путь, что вам не выбраться из этого пиздеца, что ли? Ошибки доступа к памяти/утечки — да это вы и виновны в этом, и сам ты пидор и твоя мать шлюха покайся грешник, наше божество тут ни при чём. А если что-то не устраивает, можно принять поллитра на грудь, вылезти из-под железнодорожной платформы и положить голову на рельсы и не ныть. Инфа 100%, я узнавала. И нас в нашем болоте всё устраивает. Мы к этому говнищу так привыкли, что и не замечаем. А вот когда Мекрософт его СДЕЛОЕТ... ну чо, выпьем, причастимся? А то, смотри: с утра не выпил — день пропал...

сборка мусора vs скорость

а нахуя вообще эта сборка нужна, если она так замедляет? не лучше ли обойтись вообще без неё?

• вкури обработку исключений, Люк!
  • и...? (непонял связи)
    • внутри функции отвели память → вызвали ещё функцию, она сломалась → вылетели на три вызова выше → сборщик всё удалил. Но я согласен с другим анонимусом: если можешь обойтись без неё, то обходись.
      • заюзал scoped_ptr и при вылете память почистилась. а вот файлы закрывать, да и любой другой unmanaged code(шарповский термин, но в других языках с gc то же самое) сборка мусора не может, приходится заботиться об этом самому— Мимо проходил
• Лучше. Обходись. Тем более в C++, где сборка мусора если и есть, то костыльна по-определению.
  • А ещё лучше свалить на OS X и Objective-C. Тамошнее ARC - самая лучшая пародия на GC (это компиляторная фича).

Учебники

Я зашел, для того чтобы узнать какие книги рекомендуются по теме. По теме книги не рекомендуются. Отсюда я считаю, что статья полное говно. Нахуй она нужна? Удалите её нахуй, вы, тупые ленивые педерасты, которые даже не потрудились дать список годных учебников, удалите её нахуй. Сука конченые уебаны, это с кем я одним воздухом дышу, инкубатор вам на что? Там и наваливайте своё говнецо. Мне нахуй не интересно читать всю вашу хуйню, мне нужны учебники! Сука! Блять, убил время на вас, вы же проститутки, идите нахуй...

Ух, в обсуждении кое-что есть. Серавно пидарасы. Уберите нахуй статью, пусть будет тока обсуждение.

Совсем охуели уже.

В Педивикию пиздуй за «книгами», обалдуй, хуем ёбаный.

Сочным хуйцом

по губам тем, кто на этом говне начинает новые проекты. Я понимаю ещё срань мамонта поддерживать, но зачем для современного софта заранее рыть могилу сраными плюсами?! Уже есть D, Go, ещё куча всего. Но плюсы - это же неприкрытый пиздец.

• Да вроде в стандарте C++11 новые указатели появились, да и зависимость от пройденного пути даёт о себе знать. P.S. Я не пишу на плюсах.

а вот если захотелось тебе сделать какую-нибудь embedded вундервафлю, с ASIC-ом и Nordic чипом, что будешь использовать? Питон?

Какое embedded, если для ООП нет постановочных задач. Это как мозг человечий - люди никогда не смогут использовать больше 2% от возможностей. Ляпать мультипроцессорную распределенную систему только для того, чтобы секретутка пасьянс косынка за наносекунду раскрывала? AI станет плакать кремниево-германиево-селеновыми слезами от того насколько использовалась мощь хардваре. Хня эта ваша сиплюсплюс - проблема поиска подходящей насадки на отвертку. Мимо крокодил

• а какой ещё язык даёт столь же быстрый код? (из таких я только С без плюсов и Forth знаю)

«Быстрость» в данном случае связана с возможность размещения строк и структур на стеке, так что... любой процiдурный язык, даже Фортран-77. Копайте глубже.

Алсо, кому такая "скорость" ахуительная нужна-то в 2015, блять, году, когда чуть ли не у каждой ебучей дворовой бабки с лавки дома стоит пека с проессором старше последнего поколения i3 и gddr3 оперативка "для скайпека". Кароч, если не понели мой рейдж - в чём разница между 0,1с и 0,01с? Пешите себе рукаме на питонах и радуйтесь.

игры!

финпрограммы для автоматического быстрого трейдинга (успеть продать или купить на бирже на 0.00001 секунд быстрее конкурента)

всякие прикладные программы для железа

И да, ТС малой хуесос ниасиливший ничо труднее С#.

УБИВАТЬ

Шёл я недавно по улице и вдруг почувствовал неприятную ВОНЬ, о да это была не просто вонь это была ВОНИЩА, мои глаза слезились мне хотелось блевать. Я смотрел повсюду и не мог найти источник этой мерзкой вони и как вы думаете, что это было?! В 20 метрах от меня стояло СУЩЕСТВО держащее МК-61 в руках, оно что-то бормотало себе под нос, но помню как сейчас, что я потерял контроль над собой, я был словно БЕРСЕРК, я хотел спасти эту планету и сделать мир лучше и я сделал… По воле счастливого случая под ногами валялся огромный топор я схватил его и начал кромсать эту тварь, она визжала как свинья и среди этих визгов можно было чётко слышать: «СЕГФОЛТ, СЕГФОООООЛТ, СЕГФОЛТ». И вот последний удар топором и я почувствовал, что небо стало светлее, что люди стали добрее, а самое главное ВОНЬ ИСЧЕЗЛА, а труп этого животного растворился словно пепел от сигареты. И вот только недавно я понял, что существо которое я повидал, это был байтоёб, этих тварей очень много и они среди нас…

Чё сказать-то хотел, родный? — Срикет

AFAIK, копипаста с нульчана.

не понимаю

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

всё понимаю

ты, наверное, читал рассказ про Рипа Ван-Винкеля. Напомню, на всякий случай, он заблудился в лесу, потом играл в кегли с Генри Гудзоном, ну или приснилось что играл. Проснулся он в лесу - смотрит - "хуе-мое!" - а у него борода отросла. Оказалось, что проспал 100 лет и как-то отстал от жизни. Ну а как нагонять? Никакой актуальный ко времени своего пробуждения язык (вроде того же эмелеговна) он не осилил и пришлось ему собственноручно повторить всю историю языкостроения. Начал он с говняшной, потому что до того как в лесу заплутал он, видимо, писал на сишке прошивки для фонографов и телеграфов. Прошло лет десять, он здорово продвинулся и переизобрел ЦЕПЕПЕ, но шутку про инкремент ему переизобрести не удалось, потому он назвал язык D. Тут мы вводим в повествование нового героя - румынского фокусника и рукоблуда. Всю жизнь он оттачивал мастерство лепки троллейбусов из хлеба, удаления гланд через жопу и построения изб из одних гвоздей - без единого бревна. Больше всего потенциала он видел в ЦЕПЕПЕ, но тот сыграл с ним злую шутку. Иллюзионист проштудировал стандарт и быстро напридумывал всяких диковин, но далее выяснилось, что компиляторов ЦЕПЕПЕ поддерживающих стандарт, тоесть компилирующих именно ЦЕПЕПЕ не существует! Впрочем, один компилятор ЦЕПЕПЕ ему таки найти удалось, но никто кроме него и автора компилятора о нем не знал. Впрочем, это позволило фокуснику написать статьи, тексты, посты, книги и широко прославиться в узких кругах. Но писателства ему для полного счатья не хватало. Так бы фокусник и закончил свои дни в печали, но однажды, проходя по своей дремучей трансильвании с осиновым колом в руках, набрел на землянку отшельника. Заросший курлибрейсами старикан с дикими глазами, не замечая ничего вокруг, вытачивал нечто, как две капли воды, похожее на ЦЕПЕПЕ. Великий румынский писатель с опаской огладелся по стронам. Ни представителей мегакорпораций, ни хищных мозолеедов, ни сплоченных рядов комитетских пидарасов, которые могли бы помешать писателю инженерить что-то кроме человеческих душ, не было видно. "Удача!" - Подумал наш новый герой - "теперь я могу не просто придумывать анальные трюки для существующего языка, но приложить свою ловкую руку к созданию языка, который идеально для анальных трюков приспособлен!". Фокусник осторожно окликнул отшельника - тот посмотрел на первого, за много лет, увиденного человека со страхом и недоверием. Румынский фокусник показал фокус "отрывание пальца". "Пиздато!" - оценил отшельник. Автор текстров и постов хищно улыбнулся: "Хочешь, и тебя научу?". "А то!" - ответил отшельник. И все заверте

Objective C

Это динамический пиздец, еще хуже C++. Яблокорпорация сочинила свой, доселе никому не нужный диалект Си-пиздеца, наделила его динамизмом - и теперь радуйтесь, жрите, быдлокодеры. Пишушие на нем петушки ненамного лучше PHP-етушков, хуярящих гостевухи за дошираки, только думающие, что они пишут на "Ниибацо илитном языке". И ведь хомячки хавают и просят еще...

Он же не для написания алгоритмов, а для формочек в мак-стиле, причём в стиле старой макоси — той, что была в восьмидесятые. Не пиши на нём вычисления, там даже факториал разворачивается в поток бреда на 2 страницы, но посмотри, как у него поля ввода привязываются к объектам и сравни его с M$ Access к примеру. Сравнение будет в пользу Objective-C.

А я не буду заниматься хуйней и сравнивать "лучший язык программирования для продуктов Apple" (и в самом деле, альтернатив просто нет - да здравствует анальное рабство) с эрзац-языком, предназначенным для того, чтобы по-быстрому склепать отчет. Сравнивать надо по принципу схожих задач. Objectiv C сейчас для Яблоубожества - мейнстрим для написания гуев. А у тех же Мелкомягких мейнстримовой технологией является... .NET. И здесь даже сравнивать нечего, это динамическое убожество до C# даже не собирается пилить ни в каком направлении. Apple просто считают, что хомяки и так все схавают - и правда, они жрут. Хули, сотни баксов за макхуйню выложил - деваться-то некуда.