LINUX.ORG.RU

В стандарт C предложено внести лямбды и defer из golang

 , ,


5

6

Привет, ЛОР!

Я тут тебе немного покушать принёс. Как ты, наверное знаешь, не за горами выход нового стандарта языка C – C23. Среди прочих вкусностей, таких как лямбды в стиле C++, в этот стандарт предложено добавить механизм defer, аналогичный существующему в языке Go.

Ссылка на предложение: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2895.htm

В случае, если этот стандарт будет принят, будет возможно написание вот такого кода:

p = malloc(N);
defer { free(p); }

Где аргументом оператора defer является анонимная функция. Так же возможны более сложные варианты использования:

enum { initial = 16, };
double buffer[initial] = { 0 };
...
size_t elements = 0;
double* q = buffer;
defer [orig = q, &q]{ if (orig != q) { free(q); }};
...
// increase elements somehow
...
// adjust the buffer
if (elements > initial) {
    double* pp = (q == buffer) ? malloc(sizeof(double[elements])) : realloc(q, sizeof(double[elements]));
    if (!pp) return EXIT_FAILURE;
    q = pp;
}
...

Учитывая всё это, скоро в C больше не будет нужно использовать goto вообще нигде, даже для очистки ресурсов при ошибке. Так заживём, ЛОР!

Ответ на: комментарий от BceM_IIpuBeT

Каэш! Резистор на спор я по пьяни в рот не пихал ещё. А ты?

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

от таких известных экспертов по языку C как Царь и Iron_Bug.

Iron_Bug свалила с ЛОРа.
@byko3y

У меня только один вопрос по теме треда: почему нужно было ждать 50 лет? Когда-то давно я писалЖ

C++, при всей его монструозности, дал ровно две полезные вещи:
- контролируемое высвобождение данных (но само определение точки высвобождения сделано отвратительно);
- использование обобщенных структур кодом. В си обычно либо обобщенные макросы используют код, либо обобщенные макросы пропускают через себя тип без изменения. Но макросы не могут стирать тип, абстрагируя его для использующего кода, не могут подстраивать свой тип под использующий код, что ограничивает возможности наращивания абстракций.

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

byko3y ★★★★
()

шлак, не взлетит и не примут к счастью

аффтору пропрозла язык С++ бы поучить

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

Если язык позволяет сделать zero runtime, значит это низкоуровневый язык.

Я бы добавил zero cost abstraction еще

Psilocybe ★★★★
()

Дивная тема, чувствую все рекорды побьет. Я за регулярный расстрел состоящих в комитетах клоунов. Своего рода самоочищение среды. Сдержаться и не создавать комитеты они все равно не смогут, а польза от этой меры несомненна. Вы не читали Сирила Н. Паркинсона?

anonymous
()

Круто ж.

ЗЫЖ цуко какой же ублюдочный UI у ЛОРа стал.

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

А в каком-нибудь компиляторе для web assembly она не будет работать, к примеру. И твой код получится непереносимым.

Больные ублюдки…. Может вам ещё сишных компиляторов для JVM отсыпать? :) :) :)

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

Больные ублюдки…. Может вам ещё сишных компиляторов для JVM отсыпать? :) :) :)

А почему бы кстати и нет? Не вижу ничего плохого в этом.

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

Не вижу ничего плохого в этом.

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

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

Ну плохого-то может и нет, а вот полнейшая бессмысленность имеется по полной программе.

В штанах у тебя полнейшая бессмысленность.

А вот компилировать C в байткод JVM может быть полезно как минимум чтобы не приходилось париться с JNI так сильно. И ещё сборкой нативных библиотек и жабакода в один bundle и последующим распространением. А то реально ад жеж какой-то иногда.

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

чтобы не приходилось париться с JNI так сильно.

Шта? а это то тут причем?

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

И чтоб сразу получить защиту от переполнения буфера. Единственное, что спасет отца^W си от них.

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

А вот компилировать C в байткод JVM может быть полезно как минимум чтобы не приходилось париться с JNI так сильно.

И какой же инструкцией JVM можно хотя бы запихать один байт в TX регистр реального последовательного порта?

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

И какой же инструкцией JVM можно хотя бы запихать один байт в TX регистр реального последовательного порта?

Прости, где в стандартной библиотеке C есть хоть что-то про последовательные порты? В C этого нет. Это функциональность конкретной комбинации ОС и железа.

Но если тебе очень хочется, можешь под лялехом /dev/ttyS0 открыть и пихать. В жабе это можно делать. Или, если тебе совсем всралось.

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

И как же сишные программы взаимодействуют с реальным миром? Неужто через libastral? Так ведь и libastral вместе со всем, что она там пользует, внезапно должна содержать некий код, чтобы таки запихивать байтики в астральную девайсину.

Но если тебе очень хочется, можешь под лялехом /dev/ttyS0 открыть и пихать. В жабе это можно делать.

Ты вообще хоть какое-то базовое представление о том, как работают компьютеры имеешь? Какая инструкция JVM позволяет вызвать прерывание на реальном процессоре, чтобы выполнить syscall’ы open, write и close (а, ну да, жаболюбы же close не делают, я забыл), которые необходимы для этого? А если никакого ядра вообще нет?

Или, если тебе совсем всралось.

Ты вообще, что-ли никакого понятия о том как компьютеры работают не имеешь? :) :) :) Занятный у тебя манямирок, да.

И вот такие мимокрокодилы рассказывают что там и как на сишечке должно писать. По стандартам. Ага.

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

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

Иначе говоря как целые числа будут разные а как указатели - одно и тоже.

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

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

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

Никто не утверждает, что обязательно нужно компилировать весь сишный код в JVM. Моё утверждение: возможность компилировать сишный код в JVM как минимум полезна в случаях, которые я перечислил. И никаких препятствий этому нет, потому что JVM – довольно простая стэк-машина.

Какая инструкция JVM позволяет вызвать прерывание на реальном процессоре, чтобы выполнить syscall’ы open, write и close (а, ну да, жаболюбы же close не делают, я забыл), которые необходимы для этого? А если никакого ядра вообще нет?

Ты ещё спроси, как на жабе TSR-программы писать.

open, write и close не являются необходимыми функциями для C. Это вообще части POSIX. В C есть fopen, fwrite и fclose, которые без проблем можно реализовать через функции из JVM. Как и всю остальную стандартную библиотеку C.

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

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

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

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

Сегментная реализация тут вообще не нужна. Тебе никто не мешает замапить один и тот же кусок физической памяти дважды в адресном пространстве на любом процессоре с MMU.

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

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

Никто не утверждает, что обязательно нужно компилировать весь сишный код в JVM. Моё утверждение: возможность компилировать сишный код в JVM как минимум полезна в случаях, которые я перечислил.

Т.е. пишем на С код, который компилируем в инструкции JVM, но при работе этого кода будет постоянно вызываться JNI, который с огромной вероятностью является тоже написанным на С кодом но скомпилированным в инструкции реального процессора. И нахера тут вообще JVM? Чтобы тормозило и память жрало, что-ли? :)

Мда. Вырезание гланд через жопу уже не выглядит достаточным примером идиотизма.

Ну и кто тут дебил?

Ты ещё спроси, как на жабе TSR-программы писать.

Т.е. в JVM приниципиально нет инструкций которые могли бы позволить сишной программе скомпилированной для JVM получать данные и выдавать результат. Для этого придётся вызывать написанные на С JNI. Так зачем тогда может понадобиться компилировать сишный код в JVM, чтобы он через эту совершенно ненужную прокладку в итоге всё равно вызывал другой сишный код, но скомпилированный для реального процессора?

Это какой-то полнейший трындец. Жаба ради жабы.

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

Т.е. пишем на С код, который компилируем в инструкции JVM, но при работе этого кода будет постоянно вызываться JNI, который с огромной вероятностью является тоже написанным на С кодом но скомпилированным в инструкции реального процессора.

Пишем код на C, который компилируется в байт-код и, при запуске программы, прогоняется через JIT в нативные инструкции.

Вся разница тут в методе распространения и когда итоговая компиляция в нативный код произойдёт.

Ну и кто тут дебил?

Всё ещё ты.

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

Потому что не понимаешь, как работает JVM, но при это несёшь редкостную ересь.

Так зачем тогда может понадобиться компилировать сишный код в JVM, чтобы он через эту совершенно ненужную прокладку в итоге всё равно вызывал другой сишный код, но скомпилированный для реального процессора?

Прочитай про JIT уже и прекрати пороть ересь.

Кстати, если тебе интересно, компилятор C->JVM уже есть.

https://github.com/bedatadriven/renjin/tree/master/tools/gcc-bridge

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

Сегментная реализация тут вообще не нужна. Тебе никто не мешает замапить один и тот же кусок физической памяти дважды в адресном пространстве на любом процессоре с MMU.

Про union слышал? Сишный union не вызывает откладывания кирпичей? Или это плохой, негодный стандарт, который позволяет иметь один и тот же кусок физической памяти в разных элементах, который из сишечки надо выкинуть как goto и заменить на какое-нибудь убожище типа defer?

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

Про union слышал? Сишный union не вызывает откладывания кирпичей? Или это плохой, негодный стандарт, который позволяет иметь один и тот же кусок физической памяти в разных элементах

Каким образом union позволяет иметь один и тот же кусок физической памяти в разных элементах? Элементах чего? Ей богу, ты, кажется, даже русский язык с трудом используешь.

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

Какая инструкция JVM позволяет вызвать прерывание на реальном процессоре, чтобы выполнить syscall’ы open, write и close

Показывай, как сделать syscall на чистой сишечке.

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

Пишем код на C, который компилируется в байт-код и, при запуске программы, прогоняется через JIT в нативные инструкции.

facepalm.jpg

Дебилизм ради дебилизма.

Прочитай про JIT уже и прекрати пороть ересь.

Ну так и какая инструкция JVM скомпилируется чудесным JIT’ом в то самое процессорное прерывание которое необходимо чтобы вызывать syscall и таки получить или выдать какие-либо данные?

Кстати, если тебе интересно, компилятор C->JVM уже есть.

Прекрасная демонстрация того, что программирование катится в сраное говно. Одни master/slave заменяют, другие компиляторы C для JVM пишут…

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

Дебилизм ради дебилизма.

Это твой девиз по жизни?

Ну так и какая инструкция JVM скомпилируется чудесным JIT’ом в то самое процессорное прерывание которое необходимо чтобы вызывать syscall и таки получить или выдать какие-либо данные?

Зачем тебе прерывания или syscall? Что ты так на них зациклился-то? Ты в детстве вместо красных и фошыстов играл в процессор, а при наступлении прерывания тебя за пипиську дёргали? С тех пор ты такой, да?

Для программирования на C ВНЕЗАПНО не нужны прерывания или сисколлы. Это детали реализации. Более того, можно например построить ОС с интерфейсом вообще без сисколлов как таковых. Без шуток. Ни одной инструкции syscall/sysenter или int 0x80 в коде не будет.

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

Внезапно:

char int_code[] = { байткод прерывания для нужной архитектуры };
((void(*)(void))int_code)();

Или это не чистая сишечка?

Но удобнее просто __asm__ использовать.

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

ВНЕЗАПНО твой код даже не запустится. А точнее, упадёт с сегфолтом. Потому что стэк во всех ОС сейчас не исполняемый. Неудачник лол!

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

Зачем тебе прерывания или syscall? Что ты так на них зациклился-то?

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

Для программирования на C ВНЕЗАПНО не нужны прерывания или сисколлы.

Да неужели. В сырцы *libc заглядывал? Или если часть программы спрятали в библиотечку, то это внезапно несчитово? :) :) :)

Более того, можно например построить ОС с интерфейсом вообще без сисколлов как таковых. Ни одной инструкции syscall/sysenter или int 0x80 в коде не будет.

Флаг в руки, барабан на шею. Составите достойную компанию заменятелям master/slave и писателям компиляторов С в инструкции JVM. Это может быть даже забавно, но в любом случае совершенно бесполезно.

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

ВНЕЗАПНО твой код даже не запустится. А точнее, упадёт с сегфолтом. Потому что стэк во всех ОС сейчас не исполняемый. Неудачник лол!

Ты и правда полагаешь, что переменные в сишечке заводятся исключительно на стеке? :)

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

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

Да вообще, дофига сишного кода работает без ввода/вывода. Кодеки, парсеры и прочая шняга. И такого дофига.

Но я всё ещё не понимаю, откуда ты взял, что ввода-вывода в сишном коде на JVM не будет.

Да неужели. В сырцы *libc заглядывал? Или если часть программы спрятали в библиотечку, то это внезапно несчитово? :) :) :)

Ага. Потому что никто не мешает реализовать отдельную libc на основе JVM. Я прозреваю, что те чуваки по ссылке во многом так и поступили.

Флаг в руки, барабан на шею. Составите достойную компанию заменятелям master/slave и писателям компиляторов С в инструкции JVM.

У тебя master/slave такую большую травму вызвал? Тащемта, многие функции в твоём лялексе именно так и работают. Без сисколлов.

Например, для получения текущего времени сисколл не нужен. Как это реализовано, я оставлю тебе на подумать.

Ты и правда полагаешь, что переменные в сишечке заводятся исключительно на стеке? :)

Куча тоже без X мапится, если мы про malloc. Можно руками через mmap() замапить страницу с Executable, но это уже не чистый C.

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

Да вообще, дофига сишного кода работает без ввода/вывода. Кодеки, парсеры и прочая шняга. И такого дофига.

О как. Ну ладно, я уже ничему не удивляюсь. Глубина компетенции любителя стандартов, конечно, поражает.

Потому что никто не мешает реализовать отдельную libc на основе JVM.

Мешает полное отсутствие в JVM каких-либо инструкций для работы с реальными ресурсами.

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

Мешает полное отсутствие в JVM каких-либо инструкций для работы с реальными ресурсами.

Ты прямо сейчас это пишешь на сайт, который работает на JVM. Как-то же ты байтики получаешь, правда?

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

Ты прямо сейчас это пишешь на сайт, который работает на JVM. Как-то же ты байтики получаешь, правда?

Внезапно, через всякие JNI написанные на сишечке, которая в отличии от работает на реальном железе.

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

Внезапно, через всякие JNI написанные на сишечке

Или нет.

которая в отличии от работает на реальном железе.

Интересно, на каком железе работает JVM? На астральном?

Ты уже придумал, как можно текущее время без системного вызова получить?

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

Или нет.

Бгг.

Интересно, на каком железе работает JVM? На астральном?

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

Ты уже придумал, как можно текущее время без системного вызова получить?

Ты и правда не в курсе? Его тебе ядрышко заранее кладёт в нужное место, чтобы ты его мог читать. Вот только всякие файлики, сетевые интерфейсы и всё такое заранее туда не положишь. :)

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

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

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

Но это вызовет целый каскад сисколов. Нужно сразу из розетки выдергивать!

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

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

Кому ненужных? Если тебе не нужно, тебя же никто не принуждает пользоваться этим. Но многим это заходит и они даже бабло лопатой гребут.

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

За какое ранее? И почему нельзя? Кто мешает программе записать имя файла в одну ячейку памяти и получить доступ к замапленной тушке файла в другом месте? Или это фантастика для тебя?

Я понимаю, что такой подход ничем не лучше сисколлов, особенно учитывая, что сейчас даже память в fd можно обернуть через mem_fd(). Тем не менее, работать такое будет.

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

Кто мешает программе записать имя файла в одну ячейку памяти и получить доступ к замапленной тушке файла в другом месте?

А что, open/mmap не так работает?

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

У меня вопрос к уважаемым программистам. Почему, если в язык добавляют фичу, которая кому-то почему-то напоминает C++, то кто-то почему-то считает, что из языка «делают C++»? Все языки должны быть уникальными сферическими конями в вакууме?

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

RAII. всё необходимое есть там.

Оставьте магию С++ себе.

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

Anyway, до навозного С++ ей ещё далеко.

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

hateyoufeel ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.