Почитал про нововведения 3.10. "Да это же какой-то С++20хх получается", было первым, что пришло в голову. По этой же дороге ранее пошёл и Java, когда стали хаотично выпускать версую за версией. И скаждой версией фунционал всё страннее и страннее в том смысле, что непонятно, просило ли функционал много разработчиков или это было полтора землепока. И вот, как минимум, у этих в этих трёх языках — C++, Java и Python — я заметил одну общую тенденцию. Состоит она в том, что сначало в языки добавляют то, чего прям очень не хватало и чего все так долго ждали: Java 1.5 -> Java 8, Python 2.7 -> Python 3.6, C++98 -> C++14. А потом словно ломается стоп-кран и локомотива — добавления преобредают лавинный эффект, и уже не совсем понятно, успевает ли кто-то осилить весь этот багаж? Я вот не уверен. Если верить инсайдерам, то Фейсбук ещё в 2017-ом плотно сидел на С++11, дописывая недостающие (и часто тривиальные) части из 14 и 17 собственоручно.
А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
Здравствуйте, cppguard, Вы писали:
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
За питоном не слежу, но C++14 и старше считаю на 80% интересным только теоретически. Наверное, дело в том, что разработчики языков программирования — это специфичные программисты, и у них свои представления о полезных фичах. В реальных проектах эти нововведения не нужны. Я вообще считаю язык третьестепенным по важности, далеко за архитектурой программы и знанием как устроена ОС.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, cppguard, Вы писали:
C>Почитал про нововведения 3.10.
Ну вообще-то Python 3.10 — это просто праздник какой-то! Сопоставление с образцом, PEP 634 — это то, чего сильно не хватало. Но это вроде единственное серьезное прям изменение, разве нет? Остальное про typing в основном, но это же очень хорошо.
C>Если верить инсайдерам, то Фейсбук ещё в 2017-ом плотно сидел на С++11, дописывая недостающие (и часто тривиальные) части из 14 и 17 собственоручно.
Это не удивительно. Если кодовая база большая и старая, то может быть дешевле написать недостающее на старом стандарте, чем пересобрать на новом. Но это скорее о говорить о том, на сколько "качественная" кодовая база в компании и на сколько "трепетно" там относятся к предупреждениям компилятора.
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
А что такое "стабильная ветка" на примере C++? Мы всё что можно сразу на C++17 пишем сейчас, сильно комфортнее писать по сравнению с 11 стандартом, да и удобнее 14, что уж. Я вообще за то, что бы использовать последнюю стабильную версию языка и платформы.
Здравствуйте, kaa.python, Вы писали:
KP>Ну вообще-то Python 3.10 — это просто праздник какой-то! Сопоставление с образцом, PEP 634 — это то, чего сильно не хватало. Но это вроде единственное серьезное прям изменение, разве нет? Остальное про typing в основном, но это же очень хорошо.
А зачем это в Python? Pattern matching есть в Haskell, если он так нужен. Типобезопасность это тоже не то, для чего был создан Питон. Это же скриптовый язык, то есть для описание легковесной логики. Вот я и говорю, что всё идёт к С++. Я-то понимаю, что так делают, потому что Питон нынче во все щели пихают, и когда кодовая база переваливает за 10 000 строк, то волей-неволей задумаешься про типобезопасность.
KP>Это не удивительно. Если кодовая база большая и старая, то может быть дешевле написать недостающее на старом стандарте, чем пересобрать на новом. Но это скорее о говорить о том, на сколько "качественная" кодовая база в компании и на сколько "трепетно" там относятся к предупреждениям компилятора.
Слабый аргумент, потому что обратная совместимость всегда была коньком С++, поэтому большая кодовая база никак не может влиять на это решение. А вот то, что в 17 (или в 20) выкинули то, что ещё в 11 добавили вполне могло бы быть причиной — решили подождать, пока API настоится.
Здравствуйте, cppguard, Вы писали:
C>А зачем это в Python? Pattern matching есть в Haskell, если он так нужен.
Затем что это удобно, и можно использовать Python, а не тащить Haskell.
C> Типобезопасность это тоже не то, для чего был создан Питон. Это же скриптовый язык, то есть для описание легковесной логики. Вот я и говорю, что всё идёт к С++. Я-то понимаю, что так делают, потому что Питон нынче во все щели пихают, и когда кодовая база переваливает за 10 000 строк, то волей-неволей задумаешься про типобезопасность.
Типобезопасность нужна для проекта любого размера, если планируется его развитие и поддержка. Без этого через какое-то время ты просто не поймешь о чем вообще твой код.
C>Слабый аргумент, потому что обратная совместимость всегда была коньком С++, поэтому большая кодовая база никак не может влиять на это решение. А вот то, что в 17 (или в 20) выкинули то, что ещё в 11 добавили вполне могло бы быть причиной — решили подождать, пока API настоится.
Это реальный аргумент от человека, который как-то 3 месяца переводил кодовую базу с C++03 на C++11, а не игнорировали б разработчики предупреждения компилятора, проблем бы не было. И API был давно настоян на тот момент, просто проблемы в кодовой базе всегда лезут при обновлении компилятора. И, к примеру, если сделать миграцию с C++11 на C++14 просто, то на C++17 уже сложнее, а на C++20 и того хуже. Так что, надо либо обновлять компилятор периодически (что правильный подход, новые фичи ускоряют разработку), или сидеть на C++11 до конца просто делая обратную разработку и усугубляя проблему. Потом, когда проблема станет не решаемой через обновление компилятора всегда можно будет сказать что C++ — говно и переписать на Rust, ну или что там будет модным в тот момент
Здравствуйте, cppguard, Вы писали:
C>А вы лично очень ждёте новинок в своем языке или предпочитаете сидеть на стабильной ветке?
Лично для меня STL в C++ это не часть языка. И это не я придумал, это начиная со Страуструпа чуть ли не в каждой серьёзной книге написано. Дескать вы можете создавать свои пользовательские функции и типы как это сделали в STL. В итоге берём STL и Boost, исключаем их фишки из языка C++ и что остаётся. Остаётся синтаксических сахар, который накрутили поверх C++03 и всякая мелочь, которую большинство бы и не заметило, если бы её не было.
На основе данных cppreference проводил сравнения, отличия C, C++ и их диалектов, где за основу был взят C++03, более низшие версии ISO/IEC 14882 не считаю за нечто отдельное, всё это указано как C++.
ключевое слово
диалект C++
asm
C, C++
auto
C, C++
break
C, C++
case
C, C++
char
C, C++
const
C, C++
continue
C, C++
default
C, C++
do
C, C++
double
C, C++
else
C, C++
enum
C, C++
extern
C, C++
float
C, C++
for
C, C++
goto
C, C++
if
C, C++
int
C, C++
long
C, C++
register
C, C++
return
C, C++
short
C, C++
signed
C, C++
sizeof
C, C++
static
C, C++
struct
C, C++
switch
C, C++
typedef
C, C++
union
C, C++
unsigned
C, C++
void
C, C++
volatile
C, C++
while
C, C++
inline
C99, C++
and
C++
and_eq
C++
bitand
C++
bitor
C++
bool
C++
catch
C++
class
C++
compl
C++
const_cast
C++
delete
C++
dynamic_cast
C++
explicit
C++
export
C++
false
C++
friend
C++
mutable
C++
namespace
C++
new
C++
not
C++
not_eq
C++
operator
C++
or
C++
or_eq
C++
private
C++
protected
C++
public
C++
reinterpret_cast
C++
static_cast
C++
template
C++
this
C++
throw
C++
true
C++
try
C++
typeid
C++
typename
C++
using
C++
virtual
C++
wchar_t
C++
xor
C++
xor_eq
C++
alignas
C++11
alignof
C++11
char16_t
C++11
char32_t
C++11
constexpr
C++11
decltype
C++11
final
C++11
noexcept
C++11
nullptr
C++11
override
C++11
static_assert
C++11
thread_local
C++11
char8_t
C++20
co_await
C++20
co_return
C++20
co_yield
C++20
concept
C++20
consteval
C++20
constinit
C++20
import
C++20
module
C++20
requires
C++20
_Bool
C99, не C++
_Complex
C99, не C++
_Imaginary
C99, не C++
restrict
C99, не C++
_Alignas
C11, не C++
_Alignof
C11, не C++
_Atomic
C11, не C++
_Generic
C11, не C++
_Noreturn
C11, не C++
_Static_assert
C11, не C++
_Thread_local
C11, не C++
fortran
C, не C++
reflexpr
ТС рефлексии
atomic_cancel
ТС TM
atomic_commit
ТС TM
atomic_noexcept
ТС TM
synchronized
ТС TM
transaction_safe
ТС TM
transaction_safe_dynamic
ТС TM
1) "C, C++" значит есть и в C, и в C++.
2) "C++" значит есть только в C++.
Ну и что там появилось в C++11. Причём в основном только в нём и появилось, а потом это ещё исправляли. Так что некоторые версии, которых нет в списке это ещё и версии исправлений.
Ещё есть библиотеки вроде Qt. И даже другие библиотеки часто представляют свой собственный недостающий базовый функционал, такой как умные указатели и тому подобное. Потому эта тема от различий в языках программирования плавно переходит в различия между библиотеками алгоритмов. А библиотеки алгоритмов находятся в вечном изменении, за ними бесполезно гнаться. Хочешь привязать язык программирования к этому процессу, ну всё, получил сегментацию среди языков программирования.
Здравствуйте, velkin, Вы писали:
V>В итоге берём STL и Boost, исключаем их фишки из языка C++ и что остаётся. Остаётся синтаксических сахар, который накрутили поверх C++03 и всякая мелочь, которую большинство бы и не заметило, если бы её не было.
То есть тебе действительно нужны final и прочие? Да, это абсолютная сахарная дурь, хотя когда этого не было я задумывался, почему в других языках это есть, а здесь нет. Вот когда это ввели, я наконец понял, почему этого не было.
Или работа с многопотоком, а он может быть на CPU, на GPU, иметь различные реализации. Или какие-нибудь выражения, о да, без этого же не обойтись, кто-то скажет, что это ещё и удобно.
Хотя это беспредметный спор, нравится, используйте, не нравится, не используйте. Я заранее знаю все аргументы. Будет что-то такого обсуждения, а вот здесь есть вот это дальше многоэтажная конструкция.
А в ответ, а раньше можно было бы сделать так и не мучаться, другая конструкция. Нет, это же ты мучаешься, вот тебе, дальше офигительно закрученная конструкция в новом стандарте.
Потом приходят люди со стороны и говорят, ваш C++ говно и переусложнён. Потом приходят другие люди со стороны и говорят, у вас даже в последнем стандарте нет вот этой фичи, не то, что в нашем языке xxx, потому C++ говно.
Здравствуйте, velkin, Вы писали:
S>>auto, enum class, variadic templates, lambdas, override/final, noexcept, alignas/alignof, inline namespace, initializer_list, [[nodiscard]]/[[deprecated]]/[[noreturn]]/[[no_unique_address]], constexpr/consteval/constinit, decltype, static_assert, thread_local, if constexpr, structured binding, fold expressions, CTAD, coroutines, concepts, modules, spaceship operator.
S>>Мелкая фигня, сахарок сплошной.
V>То есть тебе действительно нужны final
final, может быть и нет, а вот override -- это, по сути, must have. Так что да, нужен.
V>А в ответ, а раньше можно было бы сделать так и не мучаться, другая конструкция. Нет, это же ты мучаешься, вот тебе, дальше офигительно закрученная конструкция в новом стандарте.
auto (особенно для вывода типов возвращаемых функцией значений), [nodiscard]], variadic templates, decltype, consexpr/consteval/constinit, if constexpr, structured binding, fold expressions, concepts, modules. Как минимум это то, что раньше сделать было нельзя. Как-то объехать на костылях в единичных случаях можно, но вот получить аналог этого -- нет. Да и слабать на коленке собственный вариант alignas/alignof в C++98 могли не только лишь все.
V>Потом приходят люди со стороны и говорят, ваш C++ говно и переусложнён. Потом приходят другие люди со стороны и говорят, у вас даже в последнем стандарте нет вот этой фичи, не то, что в нашем языке xxx, потому C++ говно.
Это никак не является доказательством того, что в C++ после C++03 добавляли лишь подсахаренные мелочи.
Вот простые вопросы:
1) Можно ли написать программы на C++03 с использованием сторонних библиотек, которые сейчас пишут на C++11 и выше?
2) Эффективнее ли программы по производительности на C++11 и выше нежели на C++03?
Ещё сторонние вопросы:
1) Где в C++ нормальная рефлексия, свойства, события?
2) И в целом где граница между языком и архитектурой приложений?
А между тем модификаторы доступа такие как public, protected, private, да и многое другое это тоже не более чем синтаксический сахар. То есть я как бы себе возражаю, постойте ка, синтаксический сахар был и до С++11, но что-то ты на него не жалуешься, а вот здесь появилась какая-то действительно полезная конструкция.
Я потому и говорю:
1) Для одних C++03 уже слишком сильно переусложнён.
2) Для других самый последний стандарт всё ещё недостаточен.
Давайте продолжим серию вопросов:
1) Перейдя на C++11 или выше стали ли программисты продуктивнее, то есть создают ли они программы быстрее?
2) Перейдя на C++11 или выше стали ли программисты совершать меньше ошибок?
Можно ли сказать, что до C++11 или выше они были распоследним дном, а с его приходом сразу стали мегапрофи и программы полетели как из пулемёта.
Потому я и написал выше, нравится, используйте, но лично у меня сомнения по поводу вышеперечисленных вопросов. А в чём я уверен, так это в том, что C++11 и выше ломает совместимость. Следовательно будут нанимать людей, которые станут переписывать то, что могли бы не переписывать.
Ну так не только другим языкам создавать рабочие места. Раз уж мы говорим про Python, то не только им баловаться с хозяинами и рабами.
В Python термины master и slave, обозначающие соответственно «господин» и «раб», будут заменены более политкорректными аналогами. После долгих споров решение было принято лично создателем языка Гвидо ван Россумом.
И потом целые отделы переписывают старый код на новый.
А вот интервью Страуструпа, где он говорит, что принадлежащие конкретным компаниям языки тем и отличаются от C++, что постоянно меняются в угоду кому-либо. В моём понимании самой компании, моде, заказчикам, температуре на поверхности Солнца. И что дескать C++ он не такой, не, не такой.
Ваша мысль понятна. Но я специально указываю вам на серьезнейшую ошибку, которая лежит в основе ваших рассуждение: далеко не все, что было добавлено в C++ после 98-го стандарта, является мелким синтаксическим сахаром. Там есть целый ряд принципиально важных вещей, открывающих принципиально новые возможности перед программистами.
А дальше вы уж сами решайте, стоит ли вам пересматривать выстроенные вами логические цепочки, которые базируются на ошибочных предпосылках, или нет.
ЗЫ. Еще одна дыра в ваших рассуждениях: замените C++03 на ассемблер и C++11 на чистый Си. Или C++03 замените на чистый Си, а C++11 на C++ времен 1985-го года. Получите тот же самый результат на счет синтаксического сахара, продуктивности программиста, скорости работы кода и пр.
Здравствуйте, so5team, Вы писали:
S>ЗЫ. Еще одна дыра в ваших рассуждениях: замените C++03 на ассемблер и C++11 на чистый Си. Или C++03 замените на чистый Си, а C++11 на C++ времен 1985-го года. Получите тот же самый результат на счет синтаксического сахара, продуктивности программиста, скорости работы кода и пр.
Фактически на Си полно успешных проектов, для примера топовая встраиваемая база данных SQLite, топовый веб-сервер Nginx и так далее. Если посмотреть на мою табличку, то внезапно логический тип bool и логические литералы true и false это синтаксический сахар C++, в Си обходились без них.
Вот только C++11 не несёт в себе никаких революционных идей по сравнению с C++03. А вот сопоставление Си с ассемблером и вовсе некорректно. Я думал над этими аргументами ещё когда писал прошлое сообщение. Подсказываю, так можно сравнивать не только ассемблер с Си, но и вообще любой язык программирования.
Но я то жду не этого, я жду заверений, что с C++11 и выше по сравнению с C++03:
1) Мы стали совершать меньше ошибок.
2) Мы стали писать программы быстрее.
3) Архитектура наших программ теперь менее запутана.
4) Наши программы стали работать быстрее.
И всё в таком роде. Но на практике кто осмелиться выйти и сказать, что всё это произошло. Между ассемблером и Си разница есть, это хотя бы процедурная и функциональная парадигма. Есть разница между Си и C++03, это объектно-ориентированная и обобщённая парадигма.
Но между C++03 и всеми последующими изменениями языка C++ особых достижений нет. Так, небольшие детали, которые по большей части можно нагородить изменив библиотеки алгоритмов.
Спорить бесполезно, всё равно вменяемых аргументов против C++03 не будет. Будет сегментация языка за пару встроенных плюшек, которые фактически не делают ни программистов, ни программы лучше.
И раз уж мы затронули тему других языков в прямом сравнении с C++, то от них ещё можно много чего добавить. Я даже могу предположить почему в C++ хоть и испортили совместимость, но добавили так мало, видимо боятся, что сольют язык, причём не старый, а новый.
D у нас уже был, что там дальше. А при серьёзных изменениях людей долго дурачить названиями не получится, что типа это у нас не новый язык, а C++100500. Или мы честно говорим, ну её совместимость, мы как все и уже явно разделяемся на адептов разных версий. Сейчас уже есть разделение, но оно ещё не такое явное.
Здравствуйте, velkin, Вы писали:
V>Вот только C++11 не несёт в себе никаких революционных идей по сравнению с C++03.
А должен?
Те же variadic templates -- это лишь шаг в эволюции обобщенного программирования. Но шаг существенный. Который ничем больше не заменишь.
Аналогично про автоматический вывод типов, концепты и модули.
V>Но я то жду не этого, я жду заверений, что с C++11 и выше по сравнению с C++03: V>1) Мы стали совершать меньше ошибок.
Да.
V>2) Мы стали писать программы быстрее.
Да.
V>3) Архитектура наших программ теперь менее запутана.
Да.
V>4) Наши программы стали работать быстрее.
Не так. Для достижения хорошей скорости теперь нужно приседать гораздо меньше.
И еще:
5) Наш код стал надежнее.
V>Но между C++03 и всеми последующими изменениями языка C++ особых достижений нет.
На кону мочало, начинаем все сначала. Раз уж вы в этом убеждены, то приведите, пожалуйста, аналог вот этого кода на C++03:
template<typename A, typename B>
auto add(A && a, B && b) { return a + b; }
Или сделайте на C++03 тип, который будет только Moveable, но не Copyable.
Здравствуйте, velkin, Вы писали:
V>Но я то жду не этого, я жду заверений, что с C++11 и выше по сравнению с C++03: V>1) Мы стали совершать меньше ошибок. V>2) Мы стали писать программы быстрее. V>3) Архитектура наших программ теперь менее запутана. V>4) Наши программы стали работать быстрее.
по факту всё — да и даже больше: ты тут хочешь ускользнуть от stl, но мы все её используем, а библиотека становится богаче и быстрее. Например small string optimization автоматически ускорило программы безо всякого участия программистов. Как следствие — практически перестали писаться свои велосипедные строки, что раньше было массовым явлением. Как следствие, программы стали меньше и надёжней. Ну или заменить в std::vector push_back на emplace_back — работать будет быстрее, кода станет меньше.
Далее ты не учитываешь прогресс в компиляторах, которые учатся новым оптимизациям, а также вылавливать новые ошибки (если не игнорировать warnings конечно).
Сейчас ты можешь не писать длиннющие списки инициализации в конструкторах, а инициализировать члены класса сразу при объявлении — программа становится компактней и снижается число ошибок. Сейчас можно из функции возвращать тяжёлые классы по значению, зная, что они переместятся, а не скопируются — программы становятся короче и понятнее. Ну и т.д., примеров масса.
Я пишу довольно прикладной код, безо всякого метапрограммирования. И у меня при рефакторинге старых кусков кода объёмы реально сокращаются, я специально обратил на это внимание. Приятно. И ещё заметно, что можно писать в стиле близком к Питону. А это уже дорогого стоит.
Здравствуйте, Nuzhny, Вы писали:
N>Я пишу довольно прикладной код, безо всякого метапрограммирования. И у меня при рефакторинге старых кусков кода объёмы реально сокращаются, я специально обратил на это внимание. Приятно. И ещё заметно, что можно писать в стиле близком к Питону. А это уже дорогого стоит.
Еще, кстати, ranges делают код реально сильно проще читаемым и компактным. Правда довольно тяжело писать из за диких отчетов компилятора об ошибках в шаблонах.
Здравствуйте, velkin, Вы писали:
V>Фактически на Си полно успешных проектов, для примера топовая встраиваемая база данных SQLite, топовый веб-сервер Nginx и так далее. Если посмотреть на мою табличку, то внезапно логический тип bool и логические литералы true и false это синтаксический сахар C++, в Си обходились без них.
"Синтаксический сахар" в виде bool (_Bool), например, полезен тем, что ты чётко показываешь, что диапазон значений типа — 2 значения (0/1, false/true) и что они вообще не обязательно int. Когда компиляторы начинают уметь смотреть на эти вещи (а два основных локомотива давно умеют), это помогает поиску ошибок. Например, ты такому скрытому bool в виде int присвоил 256, компилятору было пофиг. Что оно будет — true или false? В некоторых ABI от bool валиден только младший байт (при передаче через регистр старшие разряды могут иметь произвольный мусор), там будет false. А вот при присвоении bool компилятор может спросить, а как это ты ему невесть что присваиваешь? — и спрашивает в реале.
По аналогичным причинам в следующем C собираются ввести nullptr. Проблемы с "здесь 0, здесь (void*)0, а здесь рыбу завернули" наконец всех достали настолько, что меняют даже такое консервативное место.
Конечно, в новых языках за счёт явных определений через множество значений, в виде optional и т.п. это делается более явно. Но в пределах средств C можно получить улучшения.
V>Вот только C++11 не несёт в себе никаких революционных идей по сравнению с C++03.
Что-то откровенно кривое несёшь. Одни только лямбды чего стоят — как средство ограничения контекста, так и — самое ценное — замыкания. До этого создать полноценное замыкание стандартными средствами было просто невозможно — использовался поликостылизм разных окрасок.
Родная поддержка многонитевости и спецификация межзадачного взаимодействия по памяти — до этого что-то за пределами pthread_mutex_lock было просто стрёмно использовать.
Логическое замыкание существовавшего до полной системы за счёт move-семантики — несёт — в результате экономия по ресурсам, местами колоссальная, и упрощение мест, где копирование логически некорректно.
override как средство защиты от ошибок (особенно в местах со сложной перегрузкой функций).
Это только то, с чем я сам плотно работал при моих достаточно специфичных областях (хотя у кого они не специфичны).
V> А вот сопоставление Си с ассемблером и вовсе некорректно. Я думал над этими аргументами ещё когда писал прошлое сообщение. Подсказываю, так можно сравнивать не только ассемблер с Си, но и вообще любой язык программирования.
Категорическое "нет". "Любой язык" никогда не был заточен на то, чтобы максимально близко отображать то универсальное подмножество концепций, которые используются в программировании на ассемблере. И я не про ++ --, которые на самом деле не из PDP-11, а то, что ограничения по сравнению с тем, что можно делать на ассемблере, принципиально минимизированы и сведены по сути только к ограничению управлением потоком выполнения — нет переходов не в начало функции, управления адресами возврата в стеке и т.п. — но это и на ассемблере используют в редчайших случаях.
V>Но я то жду не этого, я жду заверений, что с C++11 и выше по сравнению с C++03:
Уже расписали в подробностях, не буду повторяться. Но — таки да, у нас в одном из ключевых компонентов только года два как разрешили C++11, и переписка на него в основном даёт упрощение, ускорение и сокращение костылей.
V>И всё в таком роде. Но на практике кто осмелиться выйти и сказать, что всё это произошло.
Если потерянные слова это "мало кто", то два у тебя уже есть, и я присоединяюсь: да, произошло, что бы там себе ни думал.
V> Между ассемблером и Си разница есть, это хотя бы процедурная и функциональная парадигма. Есть разница между Си и C++03, это объектно-ориентированная и обобщённая парадигма.
Тогда надо было C++98 упоминать. C++03 это только мелкие правки к нему.
И если твои рассказы про парадигмы приводят к кривым выводам, то, наверно, в них что-то не так? Например, не все парадигмы учёл?
Замыкания тебе не являются реализацией парадигмы? А move-семантика?
И про "процедурную парадигму" ассемблер->C ты неправ, она появилась (в реализации! в теории была раньше) тогда, когда появились первые команды типа "перейти к подпрограмме" в компьютерах 50-х. Ассемблерный код пишется с ней в >99% случаев, и это неспроста. Функциональная же парадигма в полный рост и сейчас в C++ нереализуема, это надо в ФЯ идти.
V>Но между C++03 и всеми последующими изменениями языка C++ особых достижений нет. Так, небольшие детали, которые по большей части можно нагородить изменив библиотеки алгоритмов.
Нет.
V>Спорить бесполезно, всё равно вменяемых аргументов против C++03 не будет. Будет сегментация языка за пару встроенных плюшек, которые фактически не делают ни программистов, ни программы лучше.
Делают. Существенно.
V>И раз уж мы затронули тему других языков в прямом сравнении с C++, то от них ещё можно много чего добавить. Я даже могу предположить почему в C++ хоть и испортили совместимость, но добавили так мало, видимо боятся, что сольют язык, причём не старый, а новый.
Выбрали, да, разумный баланс по их мнению. Это что, заведомо плохо?
(Ну я, конечно, предпочёл бы, чтобы как минимум синтаксис типизации был весь переделан на нормальный. Но это точно не примут.)
V>D у нас уже был, что там дальше. А при серьёзных изменениях людей долго дурачить названиями не получится, что типа это у нас не новый язык, а C++100500. Или мы честно говорим, ну её совместимость, мы как все и уже явно разделяемся на адептов разных версий. Сейчас уже есть разделение, но оно ещё не такое явное.
Принципиального разделения нет, но есть безумная инерция.
Здравствуйте, so5team, Вы писали:
S>final, может быть и нет, а вот override -- это, по сути, must have. Так что да, нужен.
Вроде как final может влиять на скорость доступа к виртуальным функциям. Вполне полезная штука.
Здравствуйте, Skorodum, Вы писали:
S>>final, может быть и нет, а вот override -- это, по сути, must have. Так что да, нужен. S>Вроде как final может влиять на скорость доступа к виртуальным функциям.
Да.
S>Вполне полезная штука.
Более чем. Но требует внимательного к себе отношения. Т.е. тут думать нужно, а польза не всегда заметна. Тогда как с override все куда более однозначнее. Посему, override -- это must have, а final -- ну хорошо, что есть.
