C2x

Совместимость это например когда я могу взять код на Си, и с минимальными правками (или вообще без них) скомпилировать этот код компилятором C++ и он будет корректно работать.

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

Зачем и где им конкурировать? Какие-то капиталистические предрассудки. Все хорошо на своем месте. Чудище обло поверх сишки уже есть.

Что есть совместимость? Возможность дёргать сишный апи?

Да. К примеру, взять QuickJS, там часть API сделано макросами. Да и просто хаков хватает. В итоге под тот же раст нужна ручная обертка (в добавок к генератору кода). И при каждом обновлении ее нужно чинить и добавлять новые фичи. И даже если за тебя это будут делать другие - это и неполное покрытие API (как в quickjs-rs), и новые баги, и необходимость ждать новых версий (если обертку не забросят, что часто бывает).

Из последних

А ещё можете назвать? Можно и не из последних.

Вполне себе профилируют, не надо.

Кто сказал java?

В случае с java мощное железо нужно и на стороне пользователя, что не всегда приемлемо

Разработчики должны страдать? Нет, спасибо.

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

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

PS: ну и C и C++ уже давно не полностью совместимы.

В итоге под тот же раст нужна ручная обертка

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

Я за сишкой особо не слежу. Меня больше интересуют «убийцы» C++. А к ним совсем другой набор требований.

Интересно услышать про «убийц» C++ и требования к ним.

Rust

/thread

Не нужна.

Серьезно? Т.е. bindgen может обработать такое, например?

 #define JS_MKVAL(tag, val) (JSValue){ (JSValueUnion){ .int32 = val }, tag } 

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

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

Ты хотел сказать, что использование сишного API на Rust это нечитабельный ужас. И так и есть.

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

Т.е. bindgen может обработать такое, например?

При чём тут bindgen? Это вообще сторонняя тулза. Речь про сам язык, ака extern "C" fn и memory layout.

Ну и напомню, что это некорректный код даже в C++, ибо designator initialization только с C++20.

Ты хотел сказать, что использование сишного API на Rust это нечитабельный ужас.

То есть раст виноват в том, что сишка - это окаменелый УГ?

При чём тут bindgen? Это вообще сторонняя тулза. Речь про сам язык, ака extern «C» fn и memory layout.

Так это ты про ABI, а не API. А API это в том числе и макросы, и типы, и сигнатуры функций (с возможной реализацией) в сишном хедере. Ничего этого Rust не умеет.

Ну и напомню, что это некорректный код даже в C++, ибо designator initialization только с C++20.

Но при этом поддержка в компиляторах уже есть.

То есть раст виноват в том, что сишка - это окаменелый УГ?

Нет, просто Rust не умеет в удобную работу с сишными библиотеками. Никто в этом не виноват и никому ничего не должен.

Ничего этого Rust не умеет.

А кто умеет? C++ не умеет. Кто ещё? D?

Но при этом поддержка в компиляторах уже есть.

Убогая. Пробовал уже.

Нет, просто Rust не умеет в удобную работу с сишными библиотеками.

В чём выражается удобство?

А кто умеет? C++ не умеет. Кто ещё? D?

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

Убогая. Пробовал уже.

Да, поэтому в хедере quickjs.h есть комментарий:

/* Note: c++ does not like nested designators */ 

В чём выражается удобство?

В том, чтоб сначала не выписывать API руками, а потом еще не выписывать еще один уровень абстракции, чтоб не писать что-то вроде:

std::ffi::CStr::from_bytes_with_nul("value\0".as_bytes()).unwrap().as_ptr()

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

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

При чём тут фанатизм? Можно копипасть сишный код в плюсовый проект без изменений? В большинстве случаев - нет. ЧТД

То есть если вы подключаете эту либу в C++, то в плюсовый контейнеры вы её оборачивать не будете? А будете передавать туда сюда сырые указатели? Ага, щас. Всякие gtkmm не от хорошей жизни.

Да, поэтому в хедере quickjs.h есть комментарий:

И Rust тут при том, что?..

При чём тут фанатизм? Можно копипасть сишный код в плюсовый проект без изменений? В большинстве случаев - нет. ЧТД

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

То есть если вы подключаете эту либу в C++, то в плюсовый контейнеры вы её оборачивать не будете? А будете передавать туда сюда сырые указатели? Ага, щас. Всякие gtkmm не от хорошей жизни.

Зависит от либы и ее применения. К примеру, в том же QuickJS есть сборка мусора, а указатель запрятан в структурку. Не надо руками возится со счетчиком и очисткой памяти. Получил на руки JSValue, отдал JSValue, никаких тебе free или incref, decref.

И Rust тут при том, что?..

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

находятся с ними в одной экосистеме, где Rust-у нет места

Правильно. Нефиг лезть в это болото.

Правильно. Нефиг лезть в это болото.

Всяк кулик свое болото хвалит.

чел на форуме самые адекватные советы дает в своей области

Потому что для дружественного, нужно не только добавить, но и убрать. Хотя бы void *. А убрать нельзя, т.к. это будет не Си уже.

Если тебе нужен PL/I, ты знаешь где его взять.

Про ограниченные возможности?

Си довольно качественный

Это серьёзно? Про язык в котором даже строк и массивов нормальных нет? В котором довольно долго были функции, работающие со строками, которые ничего не знали об их реальной длине? Про язык в котором можно вывихнуть глаз при объявлении сложных типов?

Ну так про это и речь, что пора бы впендюрить в стандартную либу многое, что нужно. А стороки - с ними всегде проблемы, без icu всё-равно всё очень убого, запихнуть всё это в стандарт языка - и получим второй жирный Go, где исполняемый файл под 8 Мбайт

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

Про язык в котором даже строк и массивов нормальных нет?

массивов нормальных нет?

O-o?

строк

Любая строка это массив в любом языке, разве что внутря ещё аля структурка с счётчиком границ.

В котором довольно долго были функции, работающие со строками, которые ничего не знали об их реальной длине?

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

Про язык в котором можно вывихнуть глаз при объявлении сложных типов?

Ну, это ты наверное то ли короче начитался, то ли ютуберов насмотрелся.

Ну хорошо я могу понять, весё твоё сообщение можно свести к одной фразе «В этом вашем Си мало сахара!» Вот и всё что ты сказал. Но ты пойми, вот тебе нужны строки с автопределением границ, тебе нужна конкатенация без явной аллокации аля «одын «+» два» = «одын два» Это можно сделать! Более того это не так уж и тружно! Гоо реалзовывать скорее и добавлять в стандарт! …. Стоп! стоп стооооп кричат нам эмбеденщики. Не буду продолжать говорит какими они нас идейныхгенераторов поливали бы помоями за такие мимими нововведения. Но думаю намёк понят? Широкие возможности и универсльность языка Си существуют не потому что в нём есть что-то, а потому что в нём почти золотая середина которая с одной стороны не налагает никаких оверхедов особенности языка в виде исполнения чего либо чисто для внутренних нужд и с другой стороны даёт конструктор для реализации чего угодно с переносом того самого оверхеда в рантайм реализации того чего тебе надо.

Говорить Си что чё ты какой куцый всё равно что говорить Питону чё ты какой тормоз.

А толку впихивать ну вот вышел c11 добавили генерики это чуть иное ну да ладно, хорошо добавили треды мать их етить на уровне std либ. Кроме musl и тот через pthread кто зачесался? Вот и я про то. Добавлять то можно, но смысл если на добавления все тупо забивают, хочу делаю хочу нет.

Тут просто надо некий аля POSIX только для адаптации к более простому использованию. На самом деле кучу всего можно свести к простоте уровня питона даже. Например сеть в 99% случаев нужно data = https_get("https://blabla.com/json_data"); age = json_get_int(data,"people.masha.age"); printf("Машке %d лет подём знакомиться?",age); А как там внутри curl там, jansson там вообще по барабатну.

Должно быть USIX API набор апи целью которого является получения конечного результата в жертву и в игнорирование контроля. Тоесть если мне просто надо получить данные https от сервера мне просто нужно получить данные и всё нужен API вызов который мне из вернет и точка без погружения в сертификаты, размеры буферов и прочего. А какова его реализация глубоко плевать хоть там курл внутри, хоть это встройка какая. Главное что бы была процедура для вызова. И так со всем остальным. Но опять же тут шаг в сторону и оочень легко получить монста. А любой зачаток монструозности убьёт С прям вот сразу.

Кроме musl и тот через pthread кто зачесался?

Да вообще-то все. Например, во FreeBSD libc и в OpenIndiana libc добавили threads.h почти сразу. Хорошо что сейчас и в Glibc добавили…

И всё это с учётом LLVM и ARM, мобилок и 64 ядер в каждый дом 🏠

https://github.com/llvm/llvm-project/tree/master/libc

Я

Вот для интереса нашел даже коммит во FreeBSD: https://github.com/freebsd/freebsd/commit/6f5f2f5fd7ad53b95e3fef6977942edeb70fc1e4

27 Dec 2011

массивов нормальных нет?

O-o?

Нету, одни лишь указатели, но внутри структур и статические, внезапно, есть, и внутри структур они даже копируются. Можно объявить n-мерный массив, но нельзя нормально объявить функцию принимающую его, только через VLA.

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

В том и дело, что Ричи выдумал какие-то дурацкие null terminated строки, и во многие строковые функции размер вообще никак не передаётся. Чуть позже выдумали функции с передачей размера буфера, но это всё равно говно. Кодеры постоянно путаются, большинство багов и уязвимостей в сишных прогах как раз связаны со строками.

Про язык в котором можно вывихнуть глаз при объявлении сложных типов?

Ну, это ты наверное то ли короче начитался, то ли ютуберов насмотрелся.

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

Попробуй объявить нечто типа массивов коллбеков на сях и, например, на плюсах, почувствуй разницу.

тебе нужны строки с автопределением границ

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

Это можно сделать! Более того это не так уж и тружно! Гоо реалзовывать скорее и добавлять в стандарт! …. Стоп! стоп стооооп кричат нам эмбеденщики. Не буду продолжать говорит какими они нас идейныхгенераторов поливали бы помоями за такие мимими нововведения. Но думаю намёк понят? Широкие возможности и универсльность языка Си существуют не потому что в нём есть что-то, а потому что в нём почти золотая середина которая с одной стороны не налагает никаких оверхедов особенности языка в виде исполнения чего либо чисто для внутренних нужд и с другой стороны даёт конструктор для реализации чего угодно с переносом того самого оверхеда в рантайм реализации того чего тебе надо.

У меня где-то был лист астбеста, могу подарить, на стул положишь.

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

Какие возможности даёт си, кроме низкоуровневого доступа к памяти?

Вброс унылый, поэтому ответы будут унылыми:

C17

Нет такого. C18 вообще новых фич не содержит.

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

Он уже прекрасен как есть.

не пора бы её “переписать”

Переписывай.

Убивший дракона сам становится драконом. Вот и все требования.

У меня где-то был лист астбеста, могу подарить, на стул положишь.

Эка ты злюка =) Но ладно. Я понимаю что хочется синтаксического сахара который ну наверное поможет избежать кучи проблем и не принесёт никаких издержек. Но этого не делают. Годами не далают и не просто так. Если уже есть С++ то зачем из С делать ещё один С++? Си просто не усложняют вот и всё. В некотором смысле его просто оставляют таким какой он есть просто потому что другой си не нужен, если его не хватает всегда есть замена более высокоуровневая. Если его мало бёрём С++ если его мало (типизация) берём питон и так далее. Но причём тут Си?

Попробуй объявить нечто типа массивов коллбеков на сях и, например, на плюсах, почувствуй разницу.

Объявление инициализация и использование. Три строчки. Чё тут сложного? А как это должно выглядеть в норме тогда?

#include <stdio.h>

int add(int a,int b)
{
    return a+b;
}

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

    int (*callback_array[100])(int a,int b) = {NULL};

    for (int i = 0; i++ < 100;callback_array[i]=add);

    for (int i = 0; i++ < 100; printf("%d\n",callback_array[i](i,i-1)));

    return 0;
}

В том и дело, что Ричи выдумал какие-то дурацкие null terminated строки, и во многие строковые функции размер вообще никак не передаётся.

Ну блин эт когда было то. Ты так говоришь будто на его месте ты бы придумал иное решение. Это вообще не строки это просто поток байт и концом его является метка ‘\0’. Ну ладно, допустим в те года были бы прям строки строчные, прямо тип данных отдельный. А толку бы с него было сейчас? Это тогда символ == байт и все довольны. Сейчас то уже не так. Короче если их привносить строки эти то только сейчас, но никак не тогда в те года.

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

А причём тут «мне». Это универсальный язык, в нём нет слова «мне», его минимализм и обусловлен тем что выкидывать из него по сути нечего, а вот привносить опасно ибо это сломает многое и всем. Теже строки, давай мы их сделаем человечными типа string srt = "привет " + "мир"; str = str + str; И ничего не падает, и всё хорошо. Но это сломает жизнь тем кто занимается встройкой, микроконтроллерами и прочим. Там где пока что С прочно сидит ибо идеален. Конкатенация по человечески == аллокация неявная, она нахер не нужна тем кто выбирает Си для той или иной задачи именно потому что там всё надо делать явно. Нельзя добавить в Си удобства не убив его суть. Ну может и можно, но чёт не.

Я тоже хочу Си который будет без UB с сахаром скрывающим чисто языковые особенности и не вносящим издержки производительнсти, строки за которыми не надо следить, а просто использовать их. И всё остальное. Но блин боюсь это будет уже не Си от слова совсем. И свои задачи решать будет от слова никак. Я имею в виду низкоуровневые.

Какие возможности даёт си

Позволяет писать программы для ЭВМ :D

Это всё равно что бы я спросил - «Какие возможности даёт любой язык кроме абстракции?»

Какие возможности даёт С++? А python? У каждого языка свои плюсы и минусы. Ну вот невозможно сделать С таким же однозначным как python, а python таким же быстрым как С.

Ты мне говоришь вот мол в си это не то и то не это. Ну блин по другому никак. Что тут поделать. Я понимаю негодование, но не понимаю какие притензии к языку? Если он для строк не норм, ну всегда можно взять язык где для строк всё норм и всё. Проблемы нет. Ну а если приходится писать на микроконтроллере и там доступен только си, а в си нет нормальных строк… ну блин сорян чё :D

Что нужно добавить в новый стандарт языка Си

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

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

Потому что это язык, который был создан на коленке, без архитектуры, прототипирования, и даже без банального понимания создателями принципов построения ЯП и компиляторов. Причем, тяжкий груз наследия он получил с самого начала. пройдя цепочку BCPL->B->C, и должен был бы отправиться на помойку уже в момент своего выпуска. Но в то время программирование было некоммерческой и малоконкурентной средой, доминируемой государством, по этой причине выбор языка Си был сделан по соображениям «остальное ещё хуже».

Все эти C17 ничего толкового не привнесли, никакой тебе нормальной и удобной многопоточности, ни удобных новых структур данных, во многом Си остался в 98 и ничего не поменялось в лучшую сторону

Работает принцип «мы не можем признать ошибки предыдущих комитетов, потому что тогда и наша работа встанет под сомнение». Чтобы стать удобным языком, Си нужно:
- автоматический контроль времени жизни объектов;
- удобная обработка ошибок (без goto и сложных аргументов-ссылок);
- удобные средства работы с локальными данными. Лямбды просятся очевидным вариантом, но они сами вносят свои проблемы в виде неясности областей видимости захваченных переменных и высвобождения захваченных объектов;
- быстрые и безопасные строки.

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

Придумай, как выполнить эти условия, плюс выкинь из языка мусор веков - вуаля, ты получил конкурент Go и C++. Да-да, такой язык сделает ненужным в том числе кресты.

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

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

не пора бы её “переписать” заменой

Переписать - можно. Заставить индустрию хотя бы попытаться посмотреть на эту технологию/решение менее чем через 10 лет - практически нереально, инертность коммерческого IT очень высока.

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

Если использовать современное железо, ничего профилировать не придется

С++ является абсолютным рекордсменом по медленности трансляции - это факт, с которым приходится мириться, который приходится обходить. Он приводит, например, к тому, что ты не можешь работать с крестовым проектом на ноутбуке без интернета. Индустрия отвечается просто: ну и ладно, докинем еще 50 ядер в билд-сервер, и будем работать как раньше.

функции, работающие со строками, которые ничего не знали об их реальной длине

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

Да, и дальше что? В Си функциям длину не сообщают, в остальных языках - сообщают. Си является одним из немногих языков, в котором принято при работе с массивом не хранить и не передавать длину массива.

Про язык в котором можно вывихнуть глаз при объявлении сложных типов?

Ну, это ты наверное то ли короче начитался, то ли ютуберов насмотрелся

typedef void (*functions[256])(void) typename

typedef void (*function)(int (*arr)[256]) typename

Удачи разбирать эту клинопись.

В том и дело, что Ричи выдумал какие-то дурацкие null terminated строки, и во многие строковые функции размер вообще никак не передаётся

Вся печаль ситуации заключается в том, что Ричи ничего не выдумал. Он тупо взял ассемблерные строки, которые уже использовались в старом коде. Его не терзали сомнения, он не взвешивал альтернативы, просто «херак-херак» - и в продакшен. А что ему было терять? Юникс уже стоял на 10 компьютерах, и ожидалась установка на большее число машин, понимаешь?

:D Ой да ну вас. Вот пристали.

Удачи разбирать эту клинопись.

Дай чудаку зубочистку он себе глаз отковыряет. Лучше бы показал «как надо». А как не надо в квадрате я и сам знаю =)

Переписать - можно.

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

С учётом того что языки клепают кому не лень по 100500 новых на дню.

Дай чудаку зубочистку он себе глаз отковыряет. Лучше бы показал «как надо». А как не надо в квадрате я и сам знаю

Ну это всегда пожалста:

typename: array[256] of procedure();

typename: procedure(a: array[256] of ^int);

Но это немножко другой язык, у которого был этап проектирования при разработке синтаксиса: https://www.freepascal.org/docs-html/ref/refse16.html

напишем очередного убийцу си для интерпрайза и срубим бабалааа залочив на себя как вендоров

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

С учётом того что языки клепают кому не лень по 100500 новых на дню

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

Я имею в виду низкоуровневые.

Что такое есть в Си и отсутствует во всех остальных языках, что позволяет решать с помощью Си низкоуровневые задачи?

Что такое есть в Си и отсутствует во всех остальных языках, что позволяет решать с помощью Си низкоуровневые задачи?

ровно один слой абстракции над железом.