LINUX.ORG.RU

Производительность C++

 ,


7

13

Как насчёт производительности у C++ по сравнению с C? Мои предположения на текущий момент:

1) Код, не использующий возможности C++ (то есть по сути plain C), скомпилированный C++ компилятором будет иметь абсолютно ту же производительность, что и код на С.

2) Исключения и dynamic_cast медленные. Если нам важна производительность, лучше их не использовать.

3) Класс без виртуальных методов, должен быть по производительности эквивалентен сишной структуре и функциям, обрабатывающим её. Не считая копирования. Нужно везде, где можно использовать передачу по указателю или ссылке (собственно, если в Си делать memmove при передаче структуры в качестве аргумента, то это вызовет примерно такой же оверхед, как дефолтный конструктор копирования С++. Верно?).

4) Класс с виртуальными методами полностью аналогичен пункту 3, но при вызове виртуальных методов добавляется небольшой оверхед. Сишный эквивалент obj->vtable->func(obj, ...). Если сравнивать с plain C кодом, реализующим ООП в той же манере (каждая структура-объект имеет поле, указывающее на структуру, содержащую адреса функций работы с ней), то оверхеда по сравнению с plain C не должно быть.

5) При использовании атрибута класса final (если компилятор поддерживает соответствующий стандарт) даже при наличии виртуальных методов в нём, их вызов будет превращаться в прямые вызовы функций вместо обращения к vtable, если переменная имеет соответствующий тип, а не указатель/ссылка на его предка (который не final).

6) Шаблоны могут привести к разбуханию кода. Впрочем, #define-ы и inline-функции в C++ могут устроить то же самое. Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз. А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах? Будет ли реализация расшариваться между ними или у каждого своя?

7) Что насчёт inline-методов класса? (те, которые описываются прямо в момент определения самого класса, внутри блока class). Может ли их реализация расшариваться между модулями или в каждом будет своя копия (допустим, метод слишком длинный, чтобы инлайнится в момент вызова)?

Я не претендую на правоту, какие-то утверждения могут быть ложными. Хотел бы узнать, как обстоят дела на самом деле. А также какие подводные камни я ещё не знаю. Разумеется, речь идёт о последних версиях gcc/clang с включённой оптимизацией не ниже -O2.

★★★★★

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

про HipHop

Суть в том, что веб логика написана на пыхе.

Разница в стоимости устройства (для примера можно взять даже виртуалки у хостеров) может составлять 2-3 и более раз.

Примеры можно, когда джава на бэкенде выходит дороже крестов?

местами и с Java/Erlang конкурируют.

Ну вообще не думаю. Слишком разная стоимость разработки и т д.

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

Кто, зачем?

After the minimum viable product (MVP) release, there are plans to support garbage collection[5] which would make WebAssembly a compilation target for garbage collected programming languages like Java and C#.

Затем, что без поддержки языков со сборкой мусора оно в вебе просто не нужно будет никому и быстро загнется.

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

И Java, и .NET. И, естественно, никто, кроме тебя, этого не знал.

Теперь съезжаешь с темы :-) Признавать свою неправоту - это не просто :-) Особенно очень опытным :-)

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

Суть в том, что веб логика написана на пыхе.

Суть в том, что без C++ обслуживать тяжелый Web не получается. Или от меня требовалось показать сайты, где вообще все на C++?

Примеры можно, когда джава на бэкенде выходит дороже крестов?

При чем здесь бэкэнд?

Ну вообще не думаю. Слишком разная стоимость разработки и т д.

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

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

Ты какой-то реально угашенный.
https://en.wikipedia.org/wiki/Just-in-time_compilation
После прочтения поймешь к чему про V8 написали

Нет, не пойму :-) Вопрос tailgunner звучал: «какие компиляторы распространённых языков умеют генерировать нативный код?» :-) JavaScript - распространённый язык, а компилятор V8 умеет генерировать нативный код :-) Был, есть и будет JavaScript языком за номером один в вебе :-)

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

Или от меня требовалось показать сайты, где вообще все на C++?

Логика. Не ``о, сайт использует imagemagick — сишка рулит в вебе", а веб. Понятно, что в вебе косвенно используется код хоть на окамле.

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

Логика.

То, что HTML используется на 100% сайтов означает, что остальные языки в вебе просто сосут?

Или наличие JavaScript на фронте означает, что Ruby в вебе нет?

Что вообще значит «в вебе»: фронт, энд, лоад-балансер, http-сервер?

Какой, блин, вопрос, такой и ответ.

Ну и, насколько могу судить, C в вебе несколько больше, чем C++.

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

Мало видели. С «жавистами» вообще бесполезно спорить.

У любителей JS своих проблем хватает, с их динамическим язычком.

Ну и вы забыли самых ушибленных - лисперов.

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

похоже, анониму следовало адресовать это вам, прошу проигнорировать его невоспитанность

Да нет же - тебе. Зачем ему писать мне то, что я, в отличии от тебя, понимаю?

это нереально.

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

В какой такой кеш и на каком таком «современном процессоре» поместится «старое ядро линукс», дум и ещё место останется?

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

Признавать свою неправоту - это не просто

Да. Ты так и не смог.

Хотя... может, ты и правда считаешь себя правым? Тогда тебе должно быть 15 лет.

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

Да. Ты так и не смог.

Неправота твоя в том, что на аргументированный ответ про компиляцию JavaScript в нативный код, ты взбрыкнулся с неуместной и несущественной поправочкой про JIT :-) Непонятно, на что именно ты этим поспешил возразить, но это никак не меняет того факта, что V8 компилирует JavaScript в нативный код :-) Прямо в работающем браузере :-) Лол :-)

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

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

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

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

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

на аргументированный ответ про компиляцию JavaScript в нативный код, ты взбрыкнулся

Ты реально угашенный. Речь идет о Web Assembly и нативной компиляции, и тут ты такой весь в белом «V8 компилирует в натив». Это фейспалм.

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

Он всего лишь намекает, что язык должен использоваться либо полностью, либо никак :-)

Но ведь это ерунда. Даже в С, при всей его простоте, не всегда прямо уж всё задействуется. И наоборот - если надо, то используются расширения языка. В CL не всегда используют, скажем, CLOS. В хаскеле целая куча вещей является «полустандартными» и прячется за ключами, но при этом нередко используется. С++ тут ничем не отличается и при отказе от отдельных частей всё равно могут быть полезны остальные.

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

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

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

А потом засахаризуем его try!, ?? или постфиксными ? и !. И получим те же исключения, вид сбоку.

Неа. Исключения не видны на границе функций, а Result - видны. Да и try! и аналоги надо явно каждый раз писать, а исключения пролетают через уровни никак не обозначая своё присутствие.

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

повёрнутого жабаскриптераповёрнутого жабаскриптера

Так даже тот уважает как минимум смоллток, еще какие-то там ТРУООПЯЗЫКИ!!! Лисперы ближе, да. Сишников упоротых не встречал, ибо те обычно как минимум на пистоне и го пишут тоже. Да и кресты — единственный язык, который пытался пролезть всюду в свое время, от веба до ядер, и который автор до сих пор позиционирует как серебряную пулю (да, как и грэхэм позиционирует борщелисп аки панацею).

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

Да и кресты — единственный язык, который пытался пролезть всюду в свое время, от веба до ядер

Саночники это пытались и с Java сделать. А мелкомягкие и с C#.

Да и вам бы с Oberon-щиками бы пообщаться. Вот там вааще жесть.

Ну и непонятно, если в теме про производительность C++ относительно C не защищать C++, то где тогда это следует делать? ;)

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

Царь, не тупи.

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

Тут уже ткнули пальцем в файл с расширением .c

5 файлов из 100 - отлично. Смотрим файл по ссылке:


struct alias_set_traits : default_hashmap_traits
{
  template<typename T>
  static bool
  is_empty (T &e)
  {
    return e.m_key == INT_MIN;
  }

  template<typename  T>
  static bool
  is_deleted (T &e)
  {
    return e.m_key == (INT_MIN + 1);
  }

  template<typename T> static void mark_empty (T &e) { e.m_key = INT_MIN; }

  template<typename T>
  static void
  mark_deleted (T &e)
  {
    e.m_key = INT_MIN + 1;
  }
};

На этом весь С++(5 строк кода) в файле на 3.5к строк заканчивается.

При этом смотрим чейнджлог: * alias.c (alias_set_traits): Delete.

Далее, смотрим - как вообще используется С++ в гцц - vec/hash_map/tree/heap. Остальное - крестовые кастыля для того, чтобы это работало - т.е. те же трейты к си из-за отсутствующего void *. При этом всё это не из stdlib. При этом всё это - враперы над си-кодом. На С++ там ровным счётом ничего не написано.

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

Далее, смотрим:

template<typename T, typename A>
struct GTY((user)) vec<T, A, vl_embed>
{
public:
  void qsort (int (*) (const void *, const void *));//!

При этом ты сам говорил, что std::sort - визитная карточка гнутого stl?

Далее, смотрим - видим знакомый нам С++:

   struct Y y2, *py;
   struct Z z2, *pz;
struct elt_loc_list *l = NULL;//С++ - такой С++

Т.е. даже если использование С++ и можно как-то притянуть за уши - оно там есть, но это даже на «частично написан» - не тянет не то что на «переписан».

в котором и наследование, и шаблоны.

Это не наследование - это «наследование». Это не шаблоны - это просто генерик-тайп.

У пацанов просто было много разных структур и им надоело рвать жопу - вот они и впилили туда шаблоны из-за неимения лучшего.

Посему доверять выхлопу cloc уже просто нельзя.

Про cloc никто уже не говорит.

В целом основная проблема даже не в этом - C++ в гцц совершенно другой С++ нежели тот, который проповедуешь ты, либо иной крестовик. Ты же, как и любой балабол, пытаешься подменить понятия и приписать гцц к С++, который твой С++ - это не так.

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

Зачем ты мне пишешь

Вот даже и не знаю, вы же больны.

При этом ты сам говорил, что std::sort - визитная карточка гнутого stl?

Пруф, плиз.

В целом основная проблема даже не в этом - C++ в гцц совершенно другой С++ нежели тот, который проповедуешь ты, либо иной крестовик.

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

Главное, что царь все тот же.

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

Ну, так собери его компилятором Си.

Ну дак собери гцц до С++ крестовым компелятором? Естественно он перекастылен на С/С++ и только по этой причине собирается.

Ты, как и все - дитя С/С++ - я уже это сотни раз объяснял. Гцц - это запоздалый приступ болезни нулевых, когда все массово повалили из си в С/С++. Это было связано с тем, что страуструп всем академическим кругам мозги своим С++ промыл и новых адептов клепали по С/С++ везде. Ну и отсутствие вменяемого си-конпелятора у хомячков.

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

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

С/С++ - это отдельный язык, который не есть современный С++ настолько же, насколько он не есть си.

При этом гцц - это даже не С/С++ - это просто пара возможностей из крестового комплеятора без крестового рантайма(что есть основа С++).

Вот этого ответа хватило бы.

Мне лень тебе даже отвечать, ибо будет либо игнор, либо замазывание следов трением комментов, либо кукареку.

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

Ну, так собери его компилятором Си.

Ну дак собери гцц до С++ крестовым компелятором?

Зачем мне это? Я не доказывал, что gcc всегда был Си++. Это ты несешь «кококо Си++ в gcc - это не ваш Си++».

С/С++ - это отдельный язык

Дай я догадаюсь - этот отдельный язык не является ни Си, ни Си++, но компилируется только компилятором Си++? Ты реально болен.

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

Даже в С, при всей его простоте, не всегда прямо уж всё задействуется.

Ты пытаешься подменить понятия, но у тебя ничего не выйдет :-) Речь не о том, чтобы каждый «Здравствуй, мир!» писать используя все возможности языка, а речь о том, что в цепепе для сигнализации об ошибках специально придумали механизм исключений :-) Потом написали тонны книг о том, как нужно программировать на цепепе :-) И тут выясняется, что без этого всего можно обойтись :-) Достаточно лишь взять какой-нибудь picojson со строкой с ошибкой вместо результата парсинга и воспользоваться каким-нибудь -fno-exceptions :-) Ну а что, цепепе - он такой :-)

В CL не всегда используют, скажем, CLOS.

Опять ты пытаешься замылить дискуссию о неидиомотичности :-) В CL никому и в голову не придёт отказываться от сигнального протокола в пользу возврата ошибки в виде строки :-) Такая пурга любому лисперу лишний раз продемонстрирует печальную для цепепе ситуацию :-)

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

Одно дело отказываться от «отдельных частей», а другое дело говнокодить в стиле «а не вернуть лишь мне ошибку в строке» :-)

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

Ну, то, что исключения в цепепе на фоне сигнального протокола в Лиспе - это серая серость и я сейчас могу доказать легко :-) Что же касается в Qt, то там ошибки в std::string таки не заворачиваются, несмотря на то, что исключений нет :-) Ты ж пойми, std::string - это есть строка, а std::runtime_error - это ошибка :-) Лол :-)

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

Вот даже и не знаю, вы же больны.

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

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

В целом твой удел в толпе хомячков пастить пасты из маздайских презентаций, а после кукарекать «я сам их придумал/везде читал и добился». Типичная тактика лс"а - пускать пыль в лицо лсной аудитории.

Пруф, плиз.
выигрывать за счет генерации кода, оптимального под конкретные структуры данных (Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort).

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

Слив засчитан. Когда ты тем копелятором, которым собирается гцц - соберёшь свой С++ код - тогда приходи.

Главное, что царь все тот же.

В целом потуга понятна - взывание к публике с криками «это же царь - это не я обосрался - это он идиот, ведь вы же сами знаете? да? да?».

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

Слив засчитан.

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

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

Зачем мне это? Я не доказывал, что gcc всегда был Си++. Это ты несешь «кококо Си++ в gcc - это не ваш Си++».

Ты слишком слаб, чтобы что-то там утверждать, либо кого-то ловить.

Давай я тебе объясню, ну чтоб ты понял. Вот смотри - ты утверждаешь, что из «гцц собирается С++ конпелятором» - это С++(Тут уже достаточно: «раз это С++ - собери его другим С++-конпелятором?» и ты уже проиграл, но я не буду этого делать).

Я же объясняю причину этого тем, что код гцц - это в основном код на си, который собирается g++ ТОЛЬКО ПОТОМУ, что бы подготовлен к его сборке.

И далее всё просто - т.к. код гцц никто не переписывал и он остался тем, которым бы - нам надо узнать - был ли он изначально С++, либо его им сделали.

Из этого выводится просто вопрос - собирается ли гцц g++ до того, как он на него перешел? Если нет - весь код гцц, который не С++ - это адаптированный до С/С++(сишного диалекта с++) код на си.

Дай я догадаюсь - этот отдельный язык не является ни Си, ни Си++, но компилируется только компилятором Си++?

Во-первых - гцц не компелируется ни С, ни С++ конпелятором, ибо это диалект, а не сам язык.

Во-вторых - гцц компилируется компелятором диалекта 98-х крестов, который не есть «современный С++», а так же без крестового рантайма.

Т.е. этот «конпелятор» не соберёт код на С++ от слова совсем.

Ты реально болен.

Да нет, просто ты слаб.

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

Вы говорите, что все форумные споры на публику. Ну пусть публика решает.

Вот мои слова:

выигрывать за счет генерации кода, оптимального под конкретные структуры данных (Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort).

Вот то, что вы пытаетесь мне приписать:

При этом ты сам говорил, что std::sort - визитная карточка гнутого stl?

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

Ну что тут можно сказать? Лечись.

И да, дальнейшая муть будет удаляться.

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

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

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

Так даже тот уважает как минимум смоллток, еще какие-то там ТРУООПЯЗЫКИ!!!

Дык, в том и дело. Он отказывается понимать, скажем, полезность макросов в лиспе из-за того, что они «работают не в рантайме» или то, что иногда вполне стоит пожертвовать «тру ооп-шностью» ради производительности. Что это как не упёртый фанатизм? То, что он устремлён на «идею», а не конкретный язык сильно дело не меняет. Причём есть подозрения, что если бы его любимый Io был хоть немного популярнее, то на джаваскрипт и смоллток он меньше ссылался бы.

Сишников упоротых не встречал

Eddy_em?..

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

Ну а сейчас «время джаваскрипта». Тоже всюду лезет «потому что может».

и который автор до сих пор позиционирует как серебряную пулю

Мы об «автор языка»? Было бы странно, если бы он евангелизмом не занимался, но мне казалось, что он далёк от фанатизма и призывов писать всё на плюсах. Впрочем, последнее его творчество не читал.

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

Вот то, что вы пытаетесь мне приписать:

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

stl - это визитная карточка шаблонов - это факт. Далее:

Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort

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

Далее, страуструп, да и все после него - сравнивали гнутые sort. Гнутый sort является самым сильным std::sort() - поэтому я написал «гнутый».

Ты сам выделил пример std::sort как показательный. Показательный пример реализации обобщенных алгоритмов, которые есть stl.

Давай ещё раз. Ты сам выделил std::sort из stl ссылаясь на страуструпа. А раз ты выделил одного его - я его и назвал визитной карточной. Есть какие-то возражения?

AnonCxx
()
Ответ на: тред не читай от mix_mix

тред не читай

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

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

Повторю еще раз для больных и дебилов, причем полную версию: «Ибо есть факторы, которые могут склонять чашу весов в ту или иную сторону. Например, конструкторы/деструкторы могут добавлять оверхед по сравнению с C. А шаблоны, напротив, выигрывать за счет генерации кода, оптимального под конкретные структуры данных (Страуструп давно приводит пример, как шаблонный std::sort выигрывает у С-шного qsort). Даже исключения, в зависимости от того, как они используются, могут давать либо выигрыш, либо проигрыш.»

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

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

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

Почему ты не можешь вести себя нормально? Выкатывать мне что-то осмысленное - это так сложно?

Я же всё надеюсь, что ты можешь быть вменяемым - не обижай меня.

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

Ещё раз.

Еще раз: возможности C++ могут приводить как к выигрышам в производительности, так и к проигрышам. Страуступ приводил один из примеров, в котором выигрыш может получаться.

Ключевое слово «может».

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

Нет, ты. Про строку я ничего не говорил.

Конечно, ты просто выдрал фразу об отказе от использования исключений из контекста, оправдывающего такой отказ в угоду возврата std::string с текстом ошибки :-) Ну и начал рассказывать про то, что в Лиспе не всегда используется CLOS, а C не всегда используется полностью :-) Меня не проведёшь :-)

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

Еще раз: возможности C++ могут приводить как к выигрышам в производительности, так и к проигрышам.
Страуступ приводил один из примеров, в котором выигрыш может получаться.

А может и не получаться :-) Тут ведь как, либо пан, либо пропал :-) Лол :-)

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

Можете внятно рассказать, с чего ржоте?

Не могу :-) Тайлгунер забанил, комменты потёр :-)

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

Еще раз: возможности C++ могут приводить как к выигрышам в производительности, так и к проигрышам.

Я говорю не про это.

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

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

Ключевое слово «может».

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

Хотя конечно, пацаны которые пишут конпелятор реально знают профит шаблонов, но оставим это.

Из этого следует то, что писать на С++ пацаны даже не пытаются. Им те же шаблоны нужны только для того, чтобы они могли написать vec<type>, а писать тонну сишной лапши.

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

Если ты думаешь, что я против твоего любимого С++ - нет. Я пишу на С++ - только я не оголтелый фанатик. Я бы сам на нём писал всегда, если бы он мог не только в экстерн из си, а и в инлайн си.

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

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

Суть в том, что видя C++ вы усираетесь крича «это не тот C++».

Им те же шаблоны нужны только для того, чтобы они могли написать vec<type>, а писать тонну сишной лапши.

Боюсь вас разочаровать, но шаблоны в C++ добавлялись как раз для этого.

Я пишу на С++

Ой, да ладно.

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

По поводу «возможности C++ могут приводить как к выигрышам в производительности».

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

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

Но опять же - писать эффективный код на С++ та ещё пытка из-за того же void * и полурабочего каста.

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

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

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

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

И любой пацан, который тюнит С++ - раб интерфейса, который 99% времени запиливает интерфейс для своей куллвектора, интегрируя его в стл, а на сам тюнинг времени нет - так проекты на современном С++ и живут.

А так да, писать тот конпелятор на С++ удобней и проще. Но в шланге уже написали там, что был в 2раза быстрее гцц(на С++), а стал в 2раза медленнее при этом уровня оптимизации его не достиг даже частичности.

И щас у пацанов дилемма - либо лечит регрессию, либо забить. А там и -х10 не загорами.

Но проблема в том, что пацаны просто верят в то, что «раз шаблоны - значит быстро». Но при этом какое отношение это быстро имеет к ним - никто не знает.

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

Суть в том, что видя C++ вы усираетесь крича «это не тот C++».

Это не тот С++ - это объективный факт. Это рушит твою теорию, но это так. В гцц С++ 99% кода не на плюсах, а просто собирается g++. Собирается без rtti, без рантайма и 98-м конпелятором.

Т.е. это максимум какое-то подможество С++, как тот же С/С++ использующиеся в <1% кода.

Боюсь вас разочаровать, но шаблоны в C++ добавлялись как раз для этого.

Ну во-первых в гцц не так - лапши стало только больше - просто она ушла из интерфейса.

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

Тонна лапши там будет только для эмуляции генерик-интерфейса, который для вектора не нужен. Вторая половина тонны лапши связана с тем, что веткор появился после перехода на С++ и сломались все void *.

Я тебе уже объяснял зачем тип у твоего вектора - для вывода типа у алгоритма/пушбека. Для само вектора тип не нужен.

В гцц нет генерик-«алгоритмов», поэтому шаблонный вектор смысла не имеет - он там чисто для type-safe.

А так да - шаблоны добавлялись чисто для написания интерфейсов + пригодны для примитивного метапрограммирования для которого работает и макрос(макрос даже мощнее.).

А уж эти днище-интерфейсы на макросах. Попробуй мне сделать call(f, ... args) {f(args);}, где f - шаблонная функция.

Ой, да ладно.

Да ладно.

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

Да что тебе писать - ты яро верующий, при этом без понимания предмета.

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

Проблема в том, что крестовики очень любят сравнивать кресты с сишкой, при этом сишкой той, которую они могут родить. Я уже не помню кому я выкатывал printf aka стримы - вроде тебе.

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

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

Поэтому когда крестовик оправдывает убогость шаблонов каким-то заклинанием «кресты-зерокост» при этом оно зерокост только в его мечтах. Конпелятор шаблонной лапши работает на 3порядка медленней конпелятора не-шаблонной лапши - зерокост. Всё зерокост не даёт писать вменяемый код - зерокост. Зерокост нихрена не зерокост? Ну мы же в это верим.

В конечном итоге даже какое-то дерьмо типа руста на уровне идеи в 100 раз лучше крестов. Хотя естественно, что крестам конкурентов не и никогда не будет.

Вера есть, понимания нет. Агрессивность есть. Я это помню ещё с тех времён, когда я писал код первый. Пацан рассказывает какое stlзерокост, какие кресты зерокост и как они быстры. Потом батл - царь выкатывает код - пацанчик не выкатывает, а после выкатывает именно мой код дописав туда класс/шаблон чисто для того, чтобы он сишным конпелятором не собрался.

Отличная история. Доказывая потом, что это С++, а про stl и libstdc++ - она забыл, да и вообще царь дерьмо.

Вся суть крестовика - присвоить себе сишные заслуги. А т.к. в основном это сектант - ему ничего не докажешь.

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