Если вы пишете на c++98/99, то какие ограничения не позволяют вам перейти на c++11/14/17?

И вывод... какой? Что тем, кто писал на C++98, вообще не следует эти возможности использовать?

Я бы сформулировал так: «Хочешь использовать C++11 — бери компилятор, поддерживающий C++11. Использовать промежуточные версии не стоит».

Я бы сформулировал так: «Хочешь использовать C++11 — бери компилятор, поддерживающий C++11. Использовать промежуточные версии не стоит».

Лучше быть богатым и здоровым, чем бедным и больным, конечно. Но иногда нужно делать выбор между «бедным и больным» и «бедным и здоровым».

Не вижу большого смысла в C++. Для быстрого и оптимизированного кода для высоких нагрузок есть C, для всего остального, C# гораздо лучше C++.

Не вижу! Поднимите мне веки!

/fixed

ну действительно, какой смысл в C++? В C# большинство идей реализовано гораздо лучше. А по скорости C уделывает обоих

ну действительно, какой смысл в C++?

Можно полюбопытствовать, какой у вас опыт в C++ и в чистом C?

В чистом C - несколько лет разработки высоконагруженных приложений, в C++ около года. Ну и на C# есть опыт.

Тогда понятно.

В чистом C - несколько лет разработки высоконагруженных приложений

Даже интересно - какие высоконагруженные приложения в наше время пишут на Си?

Анализ сетевого трафика и системы защиты датацентров

несколько лет разработки высоконагруженных приложений

Даже интересно - какие высоконагруженные приложения в наше время пишут на Си?

Анализ сетевого трафика и системы защиты датацентров

Неортодоксальное определение «высоконагруженных приложений».

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

Такие системы с успехом пишутся и на C++. Так что для использования C там есть всего два оправдания:

1. Код растет из бородатых 80-х годов.

2. Религиозный фанатизм.

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

Тогда 90% тех, кто пишет на Си, «разрабатывают высоконагруженные приложения», и термин становится бессмысленным.

Например, если мы хотим защитить приложения, хостящиеся в датацентре, от sql, xml, подделки кук, xss, ddos, то нагрузка на систему защиты будет очень хорошая.

C++ заметно медленнее, чем C, если это не просто «C с классами», а полноценное использование C++. И благодаря использованию C можно сэкономить ресурсы, ставя не несколько серверов для фильтрации, и раскидывая по ним трафик, а 1.

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

Например, если мы хотим защитить приложения, хостящиеся в датацентре, от sql, xml, подделки кук, xss, ddos, то нагрузка на систему защиты будет очень хорошая.

Повторюсь, такие системы успешно делают и на C++.

C++ заметно медленнее, чем C, если это не просто «C с классами», а полноценное использование C++.

Во-первых, хотелось бы понять, что такое «полноценное использование».

Во-вторых, «заметно» — это чем-то кроме авторитетного мнения подтверждается? Замерами, скажем.

Тогда 90% тех, кто пишет на Си, «разрабатывают высоконагруженные приложения», и термин становится бессмысленным.

Ну так да

Забавно. Оказывается, я большую часть жизни занимался «высоконагруженными приложениями».

Если вы пишете на c++98/99, то

ого, счастливчики.

Во-вторых, «заметно» — это чем-то кроме авторитетного мнения подтверждается? Замерами, скажем.

Да, реализации одного и того же алгоритма средствами C++ и C как правило имеют разницу в скорости от 1,5 и более раз. Замеры проводились, и мной в том числе.

Хотелось бы посмотреть на такой алгоритм и такую реализацию.

По поводу «полноценного использования» какие-нибудь пояснения можно получить?

Я бы тоже глянул на пример. Какие-то уж очень дикие цифры ты пишешь.

Ну, если std::string по значению возвращать и передавать, то можно еще и не то получить. Или если std::vector поэлементно заполнять через push_back без предварительных reserve.

Во-первых, хотелось бы понять, что такое «полноценное использование».

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

Ну прям стандартный набор заблуждений.

умные указатели,

Чем вы их заменяете в чистом C?

использование абстрактных классов для описания интерфейсов классов,

Что вместо абстрактных классов в чистом C?

лямбды.

А уж лямбды-то какой оверхед дают?

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

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

Ну например у меня когда-то была задача вычисления большого количества математики, raytracing в искривленном пространстве. Ну и будучи написанным на C и C++ у меня разница более чем в 2 раза была. Да, когда я писал на C++, я активно использовал абстрактные классы, перегрузку операторов и методов и прочие радости C++.

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

raytracing

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

Эээ... Зачем?

Ну и код вообще-то нужно смотреть.

Ну самое первое, пересечение абстрактной частицы с абстрактным объектом. И поиск пересечения с фактическим объектом наследуется от него.

Конечно, наверное этот код можно было хорошо оптимизировать, но скорее всего и получился бы «C с классами»

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

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

Эээ... Зачем?

Ну а какой же это C++ без абстрактных-то классов?

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

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

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

Если для написания высокопроизводительного кода надо понимать что делаешь, то это и значит, что язык - медленный.

Вот так как-то правильнее.

абстрактные классы - стандартнейшая вещь C++

Да?

Вы еще скажите, что абстрактные классы должны быть в любой C++ программе.

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

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

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

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

Ха-ха! Удачи в использовании strcpy/strcat/strlen для обработки строк!

Ну а какой же это C++ без абстрактных-то классов?

Вроде pimpl+virtual проигрывает абстрактному интерфейсу. Сам не мерял, правда. Какая-то заметка в блоге была.

это библиотечные функции, пусть и входящие в стандартную библиотеку.

А перегрузка операторов и абстрактные классы - объекты самого языка.

Стандартная библиотека — часть языка. Она потому и «стандартная».

Из кода ядра линукс ты не можешь использовать стандартную библиотеку. Например, если я правильно помню, в пространстве ядра нет malloc(). Но это же не значит, что ядро написано не на C?

Но это же не значит, что ядро написано не на C?

Ядро написано на подмножестве языка Си. Более того, оно как бы и не совсем на Си, так как активно используются расширения GCC и его особенности. Когда GCC ломает эти свои особенности, даже недокументированные, Линус очень громко ругается.

А перегрузка операторов и абстрактные классы - объекты самого языка.

Я начинаю понимать... и всё, что является «объектом языка», должно иметь одинаковую стоимость?

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

Ну самое первое, пересечение абстрактной частицы с абстрактным объектом. И поиск пересечения с фактическим объектом наследуется от него.

А чем пересечение абстрактной частицы с абстрактным объектом заменили в коде на C, и почему код на C, реализующий то же самое, был быстрее?

и всё, что является «объектом языка», должно иметь одинаковую стоимость?

В идеале - да

А в реальности это не так и надо знать, что сколько стоит. Пока же то, в чем ты винишь Си++ - это твое собственное невежество.

И кстати, в Си тоже не все все «объекты языка» имеют одинаковую стоимость.

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

фейспалм.жпг

И кстати, в Си тоже не все все «объекты языка» имеют одинаковую стоимость.

К сожалению

И кстати, в Си тоже не все все «объекты языка» имеют одинаковую стоимость.

Как будто есть языки, в которых всё имеет одинаковую стоимость.

И кстати, в Си тоже не все все «объекты языка» имеют одинаковую стоимость.

Как будто есть языки, в которых всё имеет одинаковую стоимость.

Может быть, есть. Но не вижу в своих словах ничего, что могло бы навести на такую мысль.