LINUX.ORG.RU

C2x

 , , , ,


1

8

Что нужно добавить в новый стандарт языка Си, чтобы он был удобным, дружественным и мог конкурировать с современным Go? И почему язык Си по сути не развивается? Все эти C17 ничего толкового не привнесли, никакой тебе нормальной и удобной многопоточности, ни удобных новых структур данных, во многом Си остался в 98 и ничего не поменялось в лучшую сторону. Да и на поприще стандартных библиотек Си все как-то уныло, в большинстве дистрибутивов пихают старушку Glibc от GNU, не пора бы её “переписать” заменой, выкинув или оптимизировав лишнее с оглядкой на musl и всякие dietc? И при этом всё под MIT лицензией? И всё это с учётом LLVM и ARM, мобилок и 64 ядер в каждый дом 🏠

★★★★★

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

Virtuos86 ★★★★★ ()
Ответ на: комментарий от LINUX-ORG-RU

Не будет, только профи регистранты могут внести свою значимую лепту. Школьников царков с позором выгнали

menangen ★★★★★ ()

Лучше скажи, где есть ресурс по ноде типа лора. Хочу либы, не хочу велосипедить, смотрю на то, что есть и опять хочу велосипедить.

crutch_master ★★★★★ ()

унылый бред унылого регистранта у которого какой-то Go конкурирует с С.

И при этом ему не хватает «удобных новых структур данных», потому что регистрант не знаком с понятием библиотек и что все существующие структуры данных которые реализованы на других языках уже реализованы на С…

И которому не хватает удобной многопоточности…

Ладно, сделаю одолжение и покажу одну библиотеку для удобной многопоточности:

https://kosmospredanie.gitlab.io/-/gpseq/-/jobs/414949128/artifacts/gtkdoc/html/index.html

https://gitlab.com/kosmospredanie/gpseq

https://gitlab.com/kosmospredanie/gpseq/-/wikis/home

fsb4000 ★★★★ ()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от menangen

gnome lib и есть хоть какое-то удобство в С.

А в стандарт ничего не завезут, вот можешь почитать первые две страницы отсюда:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2455.pdf

«The following documents have been applied to this draft» и пункты ниже.

атрибуты из С++, strdup из POSIX, u8 из С++, практически больше ничего и нет…

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

я про удобство в стандарте языка

А что это даст? Во всех компиляторах «удобства» не появятся, Microsoft не хочет, и не развивает свой компилятор, а в Clang наоборот есть поддержка расширений GNU.

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

Многие концепции легко можно было перенести из Go в Си, те же горутинки лёгкие, срезы, каналы… но, видимо, нет единства, да и многим похер, хавают что есть. Понятно, что есть либы и я видел их, но не пора ли всё это бросить в развитие языка и стандартной библиотеки? 2020 всё таки. Не 98

menangen ★★★★★ ()

А как знать, что брать в Си, что не брать в Си? Наверно, всё, что можно было вобрать за столько лет в Си, вобрал и продолжает вбирать C++.

gedisdone ★★★ ()

Что нужно добавить в новый стандарт языка Си, чтобы он был удобным, дружественным и мог конкурировать с современным Go?

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

У меня всё

SZT ★★★★ ()

никакой тебе нормальной и удобной многопоточности

Define, please. Потоки и атомики уже есть в стандарте. Корутины и прочие тредпулы?

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

TheKnight ★★★ ()

единственное что может вернуть Си на роль Первого во всём языка программирование - это чудесным образом сделать в нём раздельную компиляцию ( реально раздельную которая на порядки порядков уменьшит время полного билдинга-линковки)

а без этого - так и будет всё более и более усугубляться в роли ассемблера мобильного

qulinxao3 ()

Все попытки разукрасить C очень печальны. На С пишется мало нового софта, а если пишется, то одна из причин выбора C = переносимость, в том числе на старые и не-ширпотребные платформы/компиляторы.

Поэтому любое нарушение обратной совместимости означает, что новыми фичами примерно никто не будет пользоваться. Ровно тоже самое с дополнительными «стандартными» функциями. Т.е. все эти нововведения приводят только к росту ifdef/endif, либо вообще игнорируются.

Тем не менее, я бы сделал три вещи:

  1. Распространить действие __restrict с аргументов на все указатели.
  2. Стандартизировать и сделать обязательными все независимые от архитектуры builtin-ы GCC.
  3. Максимально зачистить все случаи UB и implementation defined, т.е. привести в соответствие с de-facto (хотя и так уже навели порядок).

Короче, __restrict и GCC как de-facto стандарт )

+Чуть забыл про __unaligned или __builtin_assume_unaligned().

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

никакой тебе нормальной и удобной многопоточности

Есть архитектуры, на которых многопоточности нет, а Си – есть. Для них тоже можно что-то придумать, например, треды в пользовательском пространстве, но в целом это довольно-таки жырно.

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

Octagon ()
Последнее исправление: Octagon (всего исправлений: 1)

И почему язык Си по сути не развивается?

Потому-что для тех, кому не хватает С, давно сделали С++, бери нужное помножество фич и пиши в стиле С, но с плюшками.

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

На С пишется мало нового софта,

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

Serral ()

Си и Go это языки для решения разных задач. Не совсем понятно, зачем делать 2й Go, когда уже один есть. А почему не тянут в него всё подряд, ну может было понятно, что получится второй С++.

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

Нет смысла делать из Си что-то другое, скорее надо дождаться когда появится конкурент. Пока что исходя из целей полноценно хочет заменить Си, наверное, только Zig, во всяком случае из известных мне.

andalevor ★★ ()

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

AKonia ()

Ну хз, рефлексию и асинхронщину добавить может надо? Не уверен, что это что-то даст

mittorn ★★★★★ ()
Ответ на: комментарий от I-Love-Microsoft

Vala это вроде некоторая мимикрия на шарп от гномишников, разве нет ?

AKonia ()

А ты можешь посодействовать? Тогда стандартизовать тулчейн, по типу того, как это пытаются сделать Go, Java или Rust. Т.е. одна команда с подкомандами, чтобы не засирать глобальное пространство имён. Ну и переносимая система сборки и разрешения зависимостей (тут можно натаскать всего из Ant+Ivy/Maven/Gradle/Cargo/Cabal/CMake/Meson/тысячи их, опыта накоплено огромная куча) с хорошо определенными консольным интерфейсом и API, тут нет смысла жить в прошлом веке.

Result-Code ()

Так Го убогинький язык, у него же вроде нету в стандарте примитивщины типа: map recude fold и т.п. Или уже завезли?

И как я понимаю нужно добавить в Си сборку мусора?

По мне так нормальный язык это язык с REPL, вот если бы СИ добавили REPL было бы замечательно.

Int0l ★★ ()
Последнее исправление: Int0l (всего исправлений: 3)

Си остался в 98 и ничего не поменялось в лучшую сторону

Ещё как поменялось, alignas/alignof добавили

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

Распространить действие __restrict с аргументов на все указатели

Оно ж вроде так и есть

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

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

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

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

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

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

За демонстрацию своей аватарки геям всяким

menangen ★★★★★ ()

Что нужно добавить в новый стандарт языка Си, чтобы он был удобным, дружественным и мог конкурировать с современным Go?

[fat]уже добавили, C++ называется[/fat]

annulen ★★★★★ ()
Последнее исправление: annulen (всего исправлений: 1)
Ответ на: комментарий от annulen

Искусство в том, чтобы добавить и не тормознуть компилятор, как это продолжает происходить с C++. Что и является критерием для разработки Go.

Профилировать компиляцию одного исходника - это же надо до такого докатиться.

gag ★★★★★ ()

Было бы неплохо добавить гошный defer, а лучше деструкторы.

Короче в сишке не хватает raii. В го нечто подобное можно скостылять с дефер. В сишке даже этого нет.

Так же нужно потырить передачу параметров по ссылкам и констекспр/констевал из плюсов. Ну и лямбды тоже можно.

В общем пишите на плюсах.

Да и на поприще стандартных библиотек Си все как-то уныло, в большинстве дистрибутивов пихают старушку Glibc от GNU, не пора бы её “переписать” заменой, выкинув или оптимизировав лишнее с оглядкой на musl и всякие dietc?

И чего ты этим добъёшся? Ты реально думаешь, что glibc хоть в чём-то, кроме размера уступает musl? А в чём сакраментальный смысл ужимать размер libc на десктопах в ущерб функциональности и производительности?

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

А раст вместо си тебе не нравится? Может лучше раст + многопоточность го?

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

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

Во всём остальном, кроме размера glibc, как и ожидалось, лучше.

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

Подозреваю, что она не совсем корректно разбирает utf8 на октеты, или как там их.

На code points? Это трудно сделать некорректно, так как принцип простой, а кое-где забить на разницу между байтом и code point’ом так, чтобы этого не заметили, не выйдет (в отличие от UTF16 vs UCS2, чем грешит, например, Qt)

annulen ★★★★★ ()

Ничего не нужно добавлять, всё и так хорошо

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

Подобных форков полно. Из последних Zig и Odin.

Насколько мне известно, более-менее нормальную обратную совместимость с Си сохраняют только C++ и Objective-C (ну и еще можно вспомнить смесь этих двух - Objective-C++). У Zig и Odin такой совместимости нет

SZT ★★★★ ()
Последнее исправление: SZT (всего исправлений: 1)
Ограничение на отправку комментариев: только для зарегистрированных пользователей