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)
Ответ на: комментарий от KivApple

Учи конечные автоматы.

Проблема с пониманием таких примитивных вещей, как этот пример, - серьёзный «звоночек».

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

Пример хреновый, если переписать на goto, будет в 100 раз короче.

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

читаю и зло берёт насчёт спора про то, что лучше - Error или std::string. Оба варианта - шило. Ничего не нужно возвращать. Нужно передавать коллбэк, который будет вызываться с контекстом ошибки, а там уже тот, кто вызывает ваш парсинг разберётся, что ему с ошибкой делать. Накладных расходов, когда используются шаблоны - 0. Для сишечки будет один лишний дереференс адреса функции, которую нужно вызвать. Пример кода:

https://github.com/dzidzitop/libafc/blob/master/src/afc/json.hpp#L74

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

на сишечке будет также лишний аргумент функции (как и для шаблонов, но те скорее всего заинлайнятся). Но в любом случае это много лучше бесконечных проверок на эроры в формате free text.

а вообще «дорогие» эксепшены для этого придумали - эффективность кода должна повыситься, если явно эксепшен выкидывать на первом же факапе.

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

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

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

можешь представить обычный callback, который отвечает за обработку ошибок.

struct ErrorHandler
{
	void malformedJson(const char *pos) { throw parse_exception(); }
	void prematureEnd() { throw parse_exception(); }
}

можно протеговать функции как no_return для потенциально более компактного кода (без goto).

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

а что не так с goto? дедушка ленин наказал не пользоваться?

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

можешь представить обычный callback, который отвечает за обработку ошибок.

Представить-то я представил, то выглядит это нефига не удобно, особенно если не брать исключения. На примере parseObject: случается у нас malformedJson - вызывается колбек, там мы устанавливаем флаг и потом его проверяем. Это однозначно менее удобно чем использование какого-нибудь Result или исключений.

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

а что не так с goto?

А какая в коде от них польза? Избавление от ретурнов посреди функции? Сомнительный выигрыш.

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

а что не так с goto? дедушка ленин наказал не пользоваться?

Теоретики структурного программирования Эдсгер Дейкстра и Никлаус Вирт против goto.

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

читаю и зло берёт насчёт спора про то, что лучше - Error или std::string. Оба варианта - шило. Ничего не нужно возвращать. Нужно передавать коллбэк, который будет вызываться с контекстом ошибки, а там уже тот, кто вызывает ваш парсинг разберётся, что ему с ошибкой делать.

Ты. Это. Серьезно?

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

А какая в коде от них польза?

более компактный код на выходе для non-error веток выполнения. если бы там был только ретурн, то goto бы не было.

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

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

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

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

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

Кстати, этим тулкитом реализовал парсинг достаточно раскидистый json с массивами вложенных структур без единого new/malloc (среди прочего). он изначально на это затачивался, с сохранением возможности поддерживать код парсинга, а не на то, чтобы красивую диаграмму классов нарисовать. А если не думать про производительность, то любой вариант будет «достаточно хорош».

dzidzitop ★★
()

Пацаны! Тссс, только тихо... Они не знают, что есть «чистый Си», который решает проблему с производительностью ...

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

И, да. Кто насрал тебе на кукундер и потом сфотографировал? Мерзкий тяпок...

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

На конференции сказали пару слов про restrict. Уж очень он похож на костыль.

anonymous
()
14 августа 2017 г.
17 сентября 2017 г.
Ответ на: комментарий от Enthusiast

Чувак не понял C++ memory ordering и посчитал, что это ненужно. Ну чо, правильно. Настоящие паца^H^Hпрофи именно так и делают.

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

И ведущий разработчик «Тарантула» объяснил почему.

И вот эти 3 минуты невнятного бэканья и мэканья теперь называются «объяснил почему»? Okay.jpg

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

Мне любопытно другое: кто из ведущих разработчиков «Яндекса» так одержим «Крестами»?

практически все разработчики яндекса С++ программеры,https://www.youtube.com/channel/UCNuItlOR3qXZBtMRwb4GoBg/videos больше половины видео про С++ разработку в яндексе, несколько разработчиков присутствуют в группе по формированию предложений по улучшению С++ и так же бывают в комитете С++

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

Зашёл - увидел опять экспертов, ну ничего.

Чувак не понял C++ memory ordering и посчитал, что это ненужно.

Не верно. Дело в том, что понявшие «C++ memory ordering» - зовут мамку и пишут хелворды за партой.

Давай я тебе объясню в чём проблема. Есть реальный мир, есть свойства реального мира. Они прозрачны и ясны для людей в теме, ведь они, как и весь реальный мир, целиком и полностью логичны.

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

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

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

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

Из понимания выводятся правила, выводятся свойства. Из обобщённых правил не выводится ничего.

anonymous
()

Простой пример.

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

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

И вот эти 3 минуты невнятного бэканья и мэканья теперь называются «объяснил почему»? Okay.jpg

Я смотрю на то, что человек создал, а не как рассказал об этом. Докладчик создал и развивает работоспособную базу данных, выбрав языки Си и Луа. А что кроме книжек создал Страуструп?

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

Я смотрю на то, что человек создал, а не как рассказал об этом.

Это прекрасно. Просто прекрасно.

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

Объяснение-то где?

А что кроме книжек создал Страуструп?

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

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

eao197 ★★★★★
()

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

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

Теперь по заданным вопросам:

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

В основном да. Единственно, в си++ объектник может стать на несколько байт больше при одинаковом коде, но это совершенно несущественно. Например, попробуй скомпилировать си и си++ вариант «Hello, World». У меня при компиляции такого кода:

#include <stdio.h>

int main()
{
 printf("Hello, World!\n");
 return 0;
}

с оптимизацией -O2:

$ gcc -o test_hello_c -Wall -O2 test_hello_c.c
$ g++ -o test_hello_cpp -Wall -O2 test_hello_cpp.cpp
$ ls -l test_hello_c*
-rwxr-xr-x 1 6696 сен 18 18:35 test_hello_c
-rw-r--r-- 1   74 сен 18 18:34 test_hello_c.c
-rwxr-xr-x 1 6944 сен 18 18:35 test_hello_cpp
-rw-r--r-- 1   74 сен 18 18:34 test_hello_cpp.cpp

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

Касательно dynamic_cast не скажу, хотя очевидно, что оно должно быть медленнее статического приведения, исключения же могут быть реализованы по-разному:

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

б. Понемногу платят все. В этом случае исключение занимает не так много процессорного времени, но занимает его всегда, независимо, выбрасывается оно или нет. Такой подход, как я слышал, реализован в MS Visual C++.

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

П. п. 3 и 4 - очевидно да, ведь чудес не бывает.

По п. 5. точно не знаю.

6) Шаблоны могут привести к разбуханию кода.

Могут, как и макросы с инлайнами.

А если шаблон используется с одинаковыми параметрами в нескольких объектных файлах?

Если он не является инлайном и определён в одном заголовке, то для одинаковых параметров будет сгенерирована одна функция/класс.

7) Что насчёт inline-методов класса?

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

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

глупо определять как инлайн длинные функции в десятки строк

Если функция в хедере - не глупо, а единственно верно.

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

глупо определять как инлайн длинные функции в десятки строк

Если функция в хедере - не глупо, а единственно верно.

А зачем реализовывать тело такой функции в хедере? Чем не устраивают cpp/cxx-модули?

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

но отладка усложнится

Почему? Дебагер прыгает на нужную строку. Ему фиолетово кто там от кого наследуется.

появиться неожиданные побочные эффекты

Раскройте мысль.

имеет смысл использовать чистый си

Чистый С вообще нет смысла использовать за пределами 8-и битных контроллеров и криптографии (и то там simd и asm).

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

фейл, про медленные ексепшены, отладку итд

А можно поконкретнее?

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

но отладка усложнится

Почему? Дебагер прыгает на нужную строку. Ему фиолетово кто там от кого наследуется.

Дебагеру-то фиолетово, но программист, отлаживающий код, вместо описанных им структур увидит кучу непонятных (в т. ч. приватных и незадокументированных) полей и виртуальных функций. Аналогично с шаблонами. Кроме того, последовательность выполнения кода будет другой (сначала выполнятся все конструкторы, потом код, потом деструкторы). В си же без объектов как написано, так и выполняется, всё прозрачно.

появиться неожиданные побочные эффекты

Раскройте мысль.

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

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

Возвращаясь к утечкам памяти: если в обычной процедурной программе достаточно убедиться, что free вызывается столько же раз, сколько malloc, то в ооп-программе плохо спроектированный класс, который сам выделяет и высвобождает память, может наделать куда больше проблем.

В конечном итоге всё снова сводится к неочевидности, из-за которой программист должен что-то предполагать, и иногда его предположения могут не соответствовать действительности. А в процедурной программе предположений минимум: что и в каком порядке написано, то и выполняется именно в таком порядке.

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

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

Чистый С вообще нет смысла использовать за пределами 8-и битных контроллеров и криптографии (и то там simd и asm).

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

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

Синдром утёнка в каждой фразе.

Ну хорошо, множество GNU-разработчиков, разработчиков ядра Линукс, просто сильных разработчиков из очень неслабых фирм, занимающихся ВПК или компьютерной безопасностью - все поголовно утятята, и только вы - д'Артаньян. Пусть будет так. :-)

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

Ну хорошо, множество GNU-разработчиков, разработчиков ядра Линукс

Да за них уже выбор был сделан лет 25-30-35-... назад. Теперь нужно колоться, но жрать. Хотя, например, разработчики GCC таки сделали над собой усилие, когда осознали, что clang развивается динамичнее.

занимающихся ВПК

Там может быть совсем смешно местами: самодельные процы, под которые какую-нибудь древнюю версию какого-нибудь простого C-шного компилятора портировали, а надежды на то, что туда же портируют gcc или llvm нет никакой.

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

Ну хорошо, множество GNU-разработчиков, разработчиков ядра Линукс

Да за них уже выбор был сделан лет 25-30-35-... назад.

Ну, Страуструп представил первую версию Си++ в 83-ем, т. е. 34 года назад, а си с классами (предтеча си++) появился вообще в 80-ом, т. е. 37 лет назад. Что им мешало уже тогда сделать «правильный» выбор?

занимающихся ВПК

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

Может быть и такое. Но я говорил про вполне нормальную фирму, проектировавшую софт под Unix для PC. Правда, давно это было. Сейчас они помимо Unix'а ещё и маздай поддерживают, а помимо писишек - ещё и мобильные платформы. И на чём проектируют сейчас под новые для них платформы, - не знаю.

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

Ну, Страуструп представил первую версию Си++ в 83-ем, т. е. 34 года назад, а си с классами (предтеча си++) появился вообще в 80-ом, т. е. 37 лет назад. Что им мешало уже тогда сделать «правильный» выбор?

Матчасть подучите. Название C++ появилось в 1983-ем. Для языка, который находился в разработке и которым пользовались несколько знакомых самого Страуструпа. Официальный релиз состоялся в 1985-ом. При этом тогда C++ мало кто считал языком, пригодным для системного программирования. Особенно с учетом того, что до начала 90-х C++ компилировался через Cfront, т.е. через генерацию чистого C, поэтому какие-то оптимизации, которые сейчас делают родные С++компиляторы, там были невозможны.

GNU Project начался в 1983-ем. Без наработок из GNU не было бы и Linux-а в 1991-ом. Unix-ы, из которых все это выросло, появились задолго до GNU Project-а.

Так что не удивительно, что все, что уходит корнями в древние ядра Unix-ов и иже с ними, привязано к C.

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

Название C++ появилось в 1983-ем.

Вот и я о том же: название появилось в 83-м, а сам язык - уже в 80-м.

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

Ну, это мягко говоря - преувеличение. Сообщество вокруг «си с классами» сложилось ещё до 83, иначе не появилось бы си++.

Официальный релиз состоялся в 1985-ом.

В 85-м вышла первая коммерческая версия. И что? Коммерческой версии gcc нет до сих пор. Из этого следует, что gcc никто не использует?

При этом тогда C++ мало кто считал языком, пригодным для системного программирования.

А большинство unix-утилит и не являются системными. Это не ядро.

Особенно с учетом того, что до начала 90-х C++ компилировался через Cfront, т.е. через генерацию чистого C, поэтому какие-то оптимизации, которые сейчас делают родные С++компиляторы, там были невозможны.

И что? А Qt до сих пор компилируется moc'ом в си++. И кому это мешает?

GNU Project начался в 1983-ем.

Одновременно с си++. И при этом только начался, в то время как си++ развивался к тому времени уже 3 года.

Без наработок из GNU не было бы и Linux-а в 1991-ом

А к 91-ому уже 2 года как существовала 2-ая версия си++. И что мешало Торвальдсу использовать этот язык в ядре, тем паче, что си и си++ модули легко линкуются вместе, и из си++ легко вызываются функции си, надо только в заголовке соответствующие ифдефы включить и использовать extern «C».

Unix-ы, из которых все это выросло, появились задолго до GNU Project-а

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

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

Сообщество вокруг «си с классами» сложилось ещё до 83, иначе не появилось бы си++.

Величину этого сообщества можете назвать?

В 85-м вышла первая коммерческая версия. И что?

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

А большинство unix-утилит и не являются системными. Это не ядро.

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

И что? А Qt до сих пор компилируется moc'ом в си++. И кому это мешает?

И кто-то использует Qt для реал-тайма или хардкорной системщины?

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

В 1985-ом ничего этого не было.

Одновременно с си++. И при этом только начался, в то время как си++ развивался к тому времени уже 3 года.

Мне кажется, что вы живете в какой-то стране розовых пони. Ну посмотрите на современный Rust. Когда он начал развиваться? Насколько Rust первых версий отличался от того Rust-а, который зарелизили в 2015-ом? Как далеко и широко проник Rust за это время?

И это сейчас, с нынешним-то Интернетом.

А к 91-ому уже 2 года как существовала 2-ая версия си++. И что мешало Торвальдсу использовать этот язык в ядре

В виде книги она существовала. Первый компилятор, который стал поддерживать C++ образца 1989-го появился или в 1992-ом или в 1993-ем. И только для одной или двух платформ.

Уровни поддержки C++ в компиляторах начала 1990-х, особенно для x86, — это вообще пестня. Так что ничего не удивительного, что тогда Торвальдс не стал связываться с тогдашним C++.

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

Давайте вы не будете выдавать свои бредовые утверждения за мою логику. На Fortran-е ядра для Unix-ов не писали. И системные утилиты для Unix-ов не писали. А на C писали. Поэтому у Линуса выбор был совсем невелик. А у тех, кто занимается развитием BSD-ядер, так вообще не было.

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

Главной причиной использования чистого си вместо крестов в большинстве случаев, на мой взгляд, является совсем не разница в производительности и даже не разбухание объектного си++-кода, а простота отладки.

Всё проще. Есть Си с его соглашением о вызове cdecl и отделением котлет от мух (данных от функций). И это легко воспроизводимо в других языках программирования. Много ли ты знаешь ЯП не умеющих работать с Си-шными библиотеками? А что-то лучше Brainfuck?

А С++ в другие ЯП целиком не транслировать (если только не тащить еще и компилятор). Даже SWIG тут не большой помощник.

Что есть лучше чем cdecl? Ну возможно CLI из .Net. «Но это совсем другая история...»©

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

А что кроме книжек создал Страуструп?

Модель памяти для C++ разрабатывал, кстати, не Страуструп, который в этой области может быть даже не силён. Это делали такие люди, как https://isocpp.org/wiki/faq/wg21#hans-boehm, https://isocpp.org/wiki/faq/wg21#clark-nelson, https://isocpp.org/wiki/faq/wg21#herb-sutter, https://isocpp.org/wiki/faq/wg21#michael-wong

rupert ★★★★★
()

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

Не совсем. У полей могут быть недефолтные конструкторы.

Вопрос: будет ли использование шаблона с одинаковыми параметрами создавать 2 копии реализации или же всё-таки компилятор догадается сделать её лишь один раз

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

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