https://www.linux.org.ru/forum/development/15766724?cid=15767332

набросок сценария: kirk_johnson попадает в 1980-й год в тело ребенка сохранив все свои знания. И к началу 90-х выпускает компилятор раста и ОС kirkuх целиком на расте c системд и вейландом. Микрософт разоряется, а наш герой становится самым богатым и известным человеком на планете, изобретает социальные сети, смартфоны, финансирует полеты на Марс. А в 2020 предотвращает эпидемию коронавируса.

Здравствуйте, AlexRK, Вы писали:

ARK>Любое можно же сделать, нет?

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

Здравствуйте, Lexey, Вы писали:

L>Да уже давно придумана куча других аргументов. Например, убогая стандартная библиотека, отсутствие модулей (да, планируют завести, но еще хрен знает когда), отсутствие современных асинхронных примитивов (корутины в 20-м обещают, но только кастрированные), отсутствие рефлексии, ...
L>В этом плане язык лет на 10 отстал от того же C#.

Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования. Таким аргументом про стандартную библиотеку можно подловить разве что новичка. Для примера, можно взять Qt, вот и аналог .NET плюс рефлексия, плагины и прочее. Для любителей обобщённого программирования есть boost.

Я, кстати, тоже могу приводить такие смешные аргументы. В C++ есть множественное наследование, а в C# нет, только интерфейсы и это преимущество. Причём некоторые утверждают такое на полном серьёзе. То есть против C++ часто аргументы в стиле слишком много возможностей, нам столько не нужно.

Но как уже сказал, не нужно путать язык программирования и библиотеки программирования. То что добирается сторонними библиотеками лично я сразу отбрасываю как преимущество. И ещё раз повторю, ни один язык программирования не сравнится с C++ по функциональным возможностям сторонних библиотек.

Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.

Здравствуйте, L.K., Вы писали:

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

Крайне важный в контексте программирования факт!

Здравствуйте, velkin, Вы писали:

V>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера.

Ага, вот например: .net всё, C++ навсегда?

Автор: varenikAA
Дата: 11.06.20

Здравствуйте, vsb, Вы писали:

vsb>Думаю да, у Rust есть все шансы стать последним ЯП, сложно придумать что-то лучше.

Детский сад, штаны на лямках.

Здравствуйте, AlexRK, Вы писали:

ARK>Любое можно же сделать, нет?

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

Здравствуйте, velkin, Вы писали:

V>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.

Увы, нет.

V>Таким аргументом про стандартную библиотеку можно подловить разве что новичка. Для примера, можно взять Qt, вот и аналог .NET плюс рефлексия, плагины и прочее. Для любителей обобщённого программирования есть boost.

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

V>Я, кстати, тоже могу приводить такие смешные аргументы. В C++ есть множественное наследование, а в C# нет, только интерфейсы и это преимущество. Причём некоторые утверждают такое на полном серьёзе. То есть против C++ часто аргументы в стиле слишком много возможностей, нам столько не нужно.

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

V>Но как уже сказал, не нужно путать язык программирования и библиотеки программирования.

Голый язык без библиотек практически никому не нужен, так что, никакой путаницы тут нет.

V>То что добирается сторонними библиотеками лично я сразу отбрасываю как преимущество. И ещё раз повторю, ни один язык программирования не сравнится с C++ по функциональным возможностям сторонних библиотек.

Оно не добирается, вот в чем проблема.

V>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.

Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.

Здравствуйте, Lexey, Вы писали:

ARK>>Любое можно же сделать, нет?

L>Ну и как ты будешь тот же вектор на C делать (чтобы он автоматом память освобождал при выходе из скоупа)?

{
    struct myvector *v = NULL;
    ....
    v = myvector_allocate(...);
    if (v == NULL) {
        goto end;
    }
    ...
end:
    if (v != NULL) {
        myvector_deallocate(v);
    }
}

автоматизм достигается аккуратным программированием.

Здравствуйте, Lexey, Вы писали:

V>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.
L>Увы, нет.

И какой тогда язык программирования лидирует? Дело ведь не в том, что мне есть какое-то дело кто и на чём программирует. Просто все аргументы против я вижу как ложные. Например в C++ предыдущих стандартов не встроена работа с параллельными потоками исполнения, формально это правда, а по факту это ложь, так как эту проблему решает компилятор и сторонние библиотеки. Я могу сказать даже более, C++ стандарта ISO/IEC 14882:2003 более чем достаточно для самого изощрённого современного программирования.

Пока новички будут гоняться за "новейшими" разработками профи будут выбирать всё те же C/C++. Тот же аллокатор памяти в C++, его можно заменить. Лично я вообще не сторонник конкретных языков программирования, и считаю, что программа должна быть от них независима, и что процесс преобразования программы в код это кодирование и закодировать программу можно на многих языках. Если программист писал лажу на одном языке программирования, то другой не сделает его чудесным образом профессионалом.

Потому простой переход Rust не сделает из программиста профи. Нравится C#, ну так пожалуйста, я не против. Но вот так откровенно дурить головы людям, что C#, Rust или ещё что превосходят C/C++, да ещё и по библиотекам алгоритмов. Ну, ну. Особенно мне нравится бездоказательность этих утверждений.

Здравствуйте, Lexey, Вы писали:

V>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.
L>Увы, нет.

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

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


V>>Но мы опять ушли с темы. Люди обычно не пытаются доказать, что C# или какой-нибудь Rust круты. Они всё время начинают с того чтобы обругать лидера. Это позиция слабого, к тому же аргументы ложны по своей сути. Именно об том и был мой комментарий выше.
L>Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.


Любой язык нишевый. Нет ни одного языка, который претендовал был на лидерство в любой области. У каждого языка есть область, в которой его применение имеет смысл. Но при этом он может быть в ней лидером (как C/C++ в свой или Питон в своей или Жабка в своей), а может и не быть (например C# и Ruby не повезло иметь более сильных конкурентов в своей нише).

Rust полностью попадает в нишу C/C++ и соответственно в случае успеха будет пытаться подвинуть его с лидирующих позиций. Я лично не исключаю такое развитие событий и с удовольствием переведу все процессы на Rust в таком случае (лет через 5-10 это возможно начнёт иметь смысл). Если конечно с ним не случится тоже самое, что случилось с языком D (который при выходе был просто на порядки сильнее C++ того же времени по всем пунктам, а в данный момент уже стал уступать современному C++ по целому ряду актуальнейших для индустрии направлений).


P.S. Давно не был на этом форуме. Вот сейчас решил вечерком заглянуть, проведать как тут дела... А тут практически ничего не изменилось. )))

Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).

Здесь выбор отвечающих этому требованию языков небольшой: C++, Rust, Ada. Может быть, есть еще что-то?

Динамический диспатчинг, впрочем, также интересен на основе vtable. Кстати говоря, в Rust тоже это есть.

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, Lexey, Вы писали:

V>>>Если говорить о библиотеках алгоритмов, то C/C++ превосходят любой язык программирования.
L>>Увы, нет.

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективные (там где в C++ будет просто сравнение двух чисел, в языках без шаблонов будет вызов виртуальной функции (или его аналог) со всеми печальными последствиями).
В этой ветке как раз обсуждают аналог шаблонов на C# с переопределением операторов
http://rsdn.org/forum/dotnet/7749568.flat

Автор: varenikAA
Дата: 08.06.20

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

Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...). Иначе алгоритмы будут или не универсальные (только под один тип данных) или же крайне не эффективны

Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы. Тут по сети по десятки и сотни миллисекунд пакеты идут, а ты страдаешь из-за шаблонов. У нас не 1980 г. когда пытались все оптимизировать. Скоро в браузере будет все работать и требовать 128 ядер для чата, а ты все оптимизируешь универсальные алгоритмы.
Такая оптимизация — не более чем предпочтение определенного типа программистов, а не реальная необходимость. Не говоря уже о том, что способов оптимизировать каждую программу обычно много и без шаблонов.

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

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

L>>Какого лидера? C++ уже давно не лидер, а весьма нишевый язык.
_>Любой язык нишевый.
Такие тезисы нужно доказывать. А если это невозможно(так и есть), то не разбрасываться ими.
До Java, у С++ была гораздо более широкая область применения чем сейчас. И это разумно, т.к. никто не хочет возиться ни с delete, ни с weak_pointer<...>. Плюс инструменты для разработки на java проще, легче отлаживать.
Но вы будете до упора оптимизировать шаблоны С++, пока он не останется в нише языка для универсального сравнения интов и флоатов.

Здравствуйте, vsb, Вы писали:

vsb>

vsb>{
vsb>    struct myvector *v = NULL;
vsb>    ....
vsb>    v = myvector_allocate(...);
vsb>    if (v == NULL) {
vsb>        goto end;
vsb>    }
vsb>    ...
vsb>end:
vsb>    if (v != NULL) {
vsb>        myvector_deallocate(v);
vsb>    }
vsb>}
vsb>

Не решает озвученную задачу.

vsb>автоматизм достигается аккуратным программированием.

Не достигается.

Здравствуйте, velkin, Вы писали:

V>И какой тогда язык программирования лидирует?

Глобального лидера нет. В разных областях лидеры разные.

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

Подобные решения подходит далеко не всем.

V>Я могу сказать даже более, C++ стандарта ISO/IEC 14882:2003 более чем достаточно для самого изощрённого современного программирования.

А зачем тогда все то новое, что будет в 20-м и далее?

V>Пока новички будут гоняться за "новейшими" разработками профи будут выбирать всё те же C/C++.

Какие-такие "профи"? Профи стараются выбирать тот инструмент, на котором задача лучше решается. И для многих задач плюсы являются плохим выбором.

V>Тот же аллокатор памяти в C++, его можно заменить. Лично я вообще не сторонник конкретных языков программирования, и считаю, что программа должна быть от них независима, и что процесс преобразования программы в код это кодирование и закодировать программу можно на многих языках.

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

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

Другой ему может просто не дать написать лажу. Может это и не сделает программиста более профессиональным, но улучшит качество конечно продукта.

V>Потому простой переход Rust не сделает из программиста профи. Нравится C#, ну так пожалуйста, я не против. Но вот так откровенно дурить головы людям, что C#, Rust или ещё что превосходят C/C++, да ещё и по библиотекам алгоритмов. Ну, ну. Особенно мне нравится бездоказательность этих утверждений.

Тут я прочитал невнимательно (упустил слово "алгоритмов"). Да, насчет алгоритмов можно согласиться, наверное.
За Rust топить не могу, ибо видел его только краем глаза. А вот C# в определенных областях плюсы превосходит.

Здравствуйте, alex_public, Вы писали:

_>Чтобы сравниться с библиотеками алгоритмов C++, в языке претенденте должен присутствовать какой-то аналог механизма шаблонов (синтаксические макросы? Ещё что-то подобное? Не знаю...).

Тут мой косяк. Прочитал фразу по диагонали.

_>Любой язык нишевый. Нет ни одного языка, который претендовал был на лидерство в любой области. У каждого языка есть область, в которой его применение имеет смысл. Но при этом он может быть в ней лидером (как C/C++ в свой или Питон в своей или Жабка в своей), а может и не быть (например C# и Ruby не повезло иметь более сильных конкурентов в своей нише).

Собственно, я и хотел сказать, что никакого единого лидера нет. В разных нишах лидеры разные.

_>Rust полностью попадает в нишу C/C++ и соответственно в случае успеха будет пытаться подвинуть его с лидирующих позиций. Я лично не исключаю такое развитие событий и с удовольствием переведу все процессы на Rust в таком случае (лет через 5-10 это возможно начнёт иметь смысл). Если конечно с ним не случится тоже самое, что случилось с языком D (который при выходе был просто на порядки сильнее C++ того же времени по всем пунктам, а в данный момент уже стал уступать современному C++ по целому ряду актуальнейших для индустрии направлений).

ИМХО, он попадает в одну из ниш C++, но не во все. В тот же embedded он вряд ли серьезно зайдет в ближайшем будущем.

_>P.S. Давно не был на этом форуме. Вот сейчас решил вечерком заглянуть, проведать как тут дела... А тут практически ничего не изменилось. )))

Стабильность, однако.

Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, AlexRK, Вы писали:
ARK>>Любое можно же сделать, нет?
L>Ну и как ты будешь тот же вектор на C делать (чтобы он автоматом память освобождал при выходе из скоупа)?

#include <stdio.h>
#include <stdlib.h>

#define SCOPE(TYPE, NAME, ...) \
  {                            \
    ctor_##TYPE(NAME);         \
    __VA_ARGS__                \
    dtor_##TYPE(NAME);         \
  }                            \
  (void)0

typedef struct {
  int n;
} MyClass;

void ctor_MyClass(MyClass** this) {
  *this = malloc(sizeof(MyClass));
  printf("MyClass::ctor, (this-> %p)\n", (void*)*this);
}

void dtor_MyClass(MyClass** this) {
  printf("MyClass::dtor, (this-> %p)\n", (void*)*this);
  free(*this);
}

int main(int argc, char* argv[]) {
  MyClass* my_class_obj;

  SCOPE(MyClass, &my_class_obj, 
    (*my_class_obj).n = 16;
    printf("(*my_class_obj).p = %d\n", (*my_class_obj).n);
  );

  return 0;
}

MyClass::ctor, (this-> 0x7f0260)
(*my_class_obj).p = 16
MyClass::dtor, (this-> 0x7f0260)

Насколько я знаю, некоторые JVM написаны на С/С++, а следовательно GC также написаны на нем. Так что ничего удивительного, что даже на C можно написать менеджеры памяти разной степени автоматизации.

Здравствуйте, prog123, Вы писали:

P> SCOPE(MyClass, &my_class_obj,
P> (*my_class_obj).n = 16;
P> printf("(*my_class_obj).p = %d\n", (*my_class_obj).n);
P> );

Это все замечательно, только вот, как насчет возможности делать return из произвольных мест кода, который в макрос засовывается?

P>Насколько я знаю, некоторые JVM написаны на С/С++, а следовательно GC также написаны на нем. Так что ничего удивительного, что даже на C можно написать менеджеры памяти разной степени автоматизации.

Эти менеджеры не доступны конечному пользователю в C/C++ (точнее, что-то доступно через тот же JNI, но это еще хуже, чем просто C).

Здравствуйте, lpd, Вы писали:

lpd>Можно подумать у программистов других проблем нет, чем возиться с шаблонами ради 2% скорости программы. Тут по сети по десятки и сотни миллисекунд пакеты идут, а ты страдаешь из-за шаблонов. У нас не 1980 г. когда пытались все оптимизировать.

Надеюсь, в аду есть специальные котлы...