Модули в C

А вот почему бы не сделать C расширяемым?

Уже как минимум два раза сделали. Хотя ничего из этого не является расширением в математическом смысле

Покажи.

Кресты + раст. Даже #addon писать не надо - просто не используешь ненужное

Примерно такое организовать можно с C# и Rust,пишешь аддон на расте,а в сисярпе импортируешь

Вот говорят, что C устаревает с каждой минутой.

Никто разумный так не говорит.

А так же D, objc, ну и всякие местечковые изуверства, которые компилируются в С типа vala.

Вот говорят, что C устаревает с каждой минутой.

Только в мечтах веб-макак.

1) C++. Как бы там сиплюсплюсники того не хотели и как бы не старались, их язык все ещё Си.

2) Objective-C. Даже эта хреновина лучше, чем С++.

Чем это отличается от #include?

Это больше на namespac'ы C# похоже ведь, не?

В шарпе ты можешь хоть не подключая неймспейс system написать system.console.write(«оп пердолик»). Насколько я помню, конечно же.

Можно просто на Nim писать.

Допустим я шарю в C, Python и Cython. Можешь в трех строках «продать» мне Nim?

https://hookrace.net/blog/what-is-special-about-nim/ прочитал, показалось каким-то неособым и бредовым, особенно unified call syntax.

Верная мысль

Я иногда страдаю из-за отсутствия ООП в С, но это бывает так редко, что не стоит беспокойства.

Это уже сделали - называется C++. Но сишников с синдромом утёнка не переубедить.

Objective-C. Даже эта хреновина лучше, чем С++.

В каком месте?

особенно unified call syntax

Это обещают в и C++ добавить, если не уже.

Можешь в трех строках «продать» мне Nim?

До релиза 1.0 там продавать нечего.

Я иногда страдаю из-за отсутствия ООП в С

А из-за отсутствия дженериков не страдаешь?

Неа, мне такие вещи без надобности. Я бы вообще на fortran перешёл, но у него с поддержкой не так хорошо, как у C.

Поддержкой чего? Шаблоны вроде отдельная часть.

Недавно выяснил насколько в фортране, например, просто к динамическому массиву кусок другого массива прикрутить, и без всяких ".begin()" ".end()".

Я бы вообще на fortran перешёл

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

В целом коммьюнити у С несколько больше, легче находить ответы на вопросы. Мне в принципе всё равно было, с чего начинать, но мой научрук писал на С, у него были кое-какие наработки, поэтому мой выбор был предопределён.

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

же даже приличных многомерных массивов нет

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

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

См. мой последний ответ :)

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

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

Вычислительные задачи на Fortran писать, конечно, проще, однако C перспективнее, если смотреть в сторону переезда на OpenCL, CUDA, OpenMP, MPI и интеграции с другими модулями ПО (если всё ПО написано на C, то тащить компилятор Fortran как зависимость можеть быть излишним).

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

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

то ты начинаешь понимать, что что-то делаешь не так.

Кривую архитектуру можно запилить на любом ЯП.

Кривую архитектуру можно запилить на любом ЯП.

...но некоторые ЯП помогают в этом особенно активно.

автор которого продолжает писать используя C++98

Ну, а я писал на C89 с OpenMP пару лет назад и что? Единственное, что реально неудобно: в C89 нельзя передать переменную в размер массива — это лютая боль.

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

Вычислительные задачи на Fortran писать, конечно, проще, однако C перспективнее,

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

C перспективнее, если смотреть в сторону переезда на OpenCL, CUDA, OpenMP, MPI

Почему? Вот OpenMP и MPI у фортрана вроде всё в порядке было. Для OpenCL были какие-то библиотеки. Для CUDA, кажется, есть библиотеки только у компилятора PGI (которым владеет NVidia).

Fortran очень хорошо дружит с видеокартами

Насколько мне известно, только через лютые маргинальные костыли.

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

Я и не планирую, хотя для своего удовольствия я бы попробовал что-нибудь пописать на фортране.

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

Да, тот проект, что я видел, четыре человека уже пять лет пилят. Там тысяч 50 строк, куда уж там переписывать.

Вот OpenMP и MPI у фортрана вроде всё в порядке было.

Поскольку нативная поддержка со стороны вендоров (Intel MPI Library, mpich), либо со стороны стандарта (OpenMP).

Я его и не упрекаю в использовании C++98, так как проект действительно уже какой-то огромный: там только его конфигурация перед компиляцией минут 15 идёт. Поэтому что-то переделывать в этом плане, если вдруг захочется, придётся очень долго.

не знаю насколько маргинальные и лютые, но вроде не самый безызвестный наборчик : https://www.pgroup.com/products/

Ну как тебе сказать, разница между c98 и с17 мне кажется несколько большей, чем между с89 и с99.

в C89 нельзя передать переменную в размер массива

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

Ну тут за что купил, за то и продаю, сам понимаешь.

1000 бачей на рыло за Фортран? C/CUDA обходится в 0 бачей.

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

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

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

в C89 нельзя передать переменную в размер массива — это лютая боль.

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

typedef struct _object obj_s;

struct _object {
    int value;
    int (*destroy)(obj_s * this);
    int (*set_value)(obj_s * this, int v);
    int (*get_value)(obj_s * this);
};

int object_destroy(obj_s * this)
{
    if(!this) return -1;
    /* do something else here */
    free(this);
    return 0;
}

int object_set_value(obj_s * this, int v)
{
    if(!this) return -1;
    this->value = v;
    /* do something else here */
    return 0;
}

int object_get_value(obj_s * this)
{
    if(!this) retrun DEFAULT_VALUE;
    /* do something else here */
    return this->value;
}

struct _object * new_object()
{
    obj_s *obj;
    obj = calloc(1, sizof(obj_s));
    if(!obj) return NULL;
    obj->value = DEFAULT_VALUE;
    obj->destroy = object_destroy;
    obj->set_value = object_set_value;
    obj->get_value = object_get_value;
    return obj;
}

main()
{
    obj_s * obj = new_object();
    if(!obj) return 1;
    printf("default: %d\n", obj->get_value(obj) )
    obj->set_value(obj,123);
    printf("set: %d\n", obj->get_value(obj) );
    obj->destroy(obj);
    retrun 0;
}

Вот тебе ООП в C, не страдай больше. Можно даже методы перегружать на лету и всё такое. С перегрузкой арифметики конечно не выйдет, но оно и не так часто нужно.

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

В механизмах управления памятью. В c++ как сильно не используешь фичи языка, всё равно можно напороться на ссылку/указатель на удалённый объект.