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 вообще нигде, даже для очистки ресурсов при ошибке. Так заживём, ЛОР!

Лучшее из того, что могу сказать на ЛОР …

Я, ВОЛКОМ бы   
       ВЫГРЫЗ АТЕИЗМ   

Неверам прощения 
       НЕТУ!

К любым ЧЕРТЯМ с  
       МАТЕРЯМИ КАТИСЬ   

Любое НЕВЕРИЕ к

    БОГУ!

Владимир

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

Си вообще минималистичный ЯП

Он таким и задуман был.
Ведь поначалу основная его задача была - разработка ЯП, который позволит легко переносить код на иные архитектуры CPU.

Минималистичный он также потому, что его создатели решили задачу создания ЯП, который хорошего пригоден для разработки АЛГОРИТМОВ.

То бишь ЯП не прибит гвоздями НИ К КАКОМУ «ГОРЮ ОТ УМА».

Десятилетия и ГИГАТОННЫ ХОРОШИХ проектов продемонстрировали правильность их подхода.

РЕСПЕКТ создателям этого ЯП! ...
anonymous
()
Ответ на: комментарий от anonymous

defer не для того чтобы был похож, а для решения реальной проблемы.

Представь себе функцию где goto для освобождения ресурсов в случае ошибки. И все работает, но потом приходит другой разработчик, добавляет еще что-то, и goto забывает. Вот у нас уже утечка. Чтобы такого не было, придумали defer, который нужно написать только один раз.

Вообще весь этот языкосрач от того, что многие игнорируют другого разработчика.

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

Вообще весь этот языкосрач от того, что многие игнорируют другого разработчика.

Не игнорируют хорошее, а СРАЧ в ЯП НЕ НУЖЕН …

В моем API используется дерево ресурсов и в частности программа знает в каком порядке и какие должны быть освобождены.
И БОЛЕЕ ТОГО использует их в работе …

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

Я ж тебе писал - не лезь туда где не разбираешься.

fernandos не технарь и в тех разделах ни в чем не разбирается. странно этого не знать.

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

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

а так, программирование на Си - это не про ЯП, это про предметную область. сами операторы языка изучить вообще не вопрос. их мало и там никакой развесистой клюквы нет, всё просто и прямолинейно. но чтобы на нём писать, надо знать, что именно писать: стандарты, протоколы, основные распространённые библиотеки в той области, под которую пишется софт.

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

Минималистичный он также потому, что его создатели решили задачу создания ЯП, который хорошего пригоден для разработки АЛГОРИТМОВ.

У нас есть Си и некоторые воспринимают его как некий упрощенный ЯП, который нужно развивать потому, что мол создатели НЕ ОСИЛИЛИ.

Это НЕ ПРАВДА!
Создатели Си сумели выделить из множества возможностей лишь те, которые
позволят вести разработку любой сложности АЛГОРИТМОВ.
Они полагали /и были ПРАВЫ/, что программисты произведут разработку API для разного рода предметных областей.
API много создано, но к сожаления НИ КТО пока не смог создать архитектуру, которая была бы core для остального предметного API.
Единственные поползновениями являются RTL, но это не архитектура для наборы разного API /хотя конечно и такой API нужен/.

ИМХО технологии программирования /в т.x. разработка компиляторов/ застыли на месте лет пятьдесят назад.
Да, создаются разные протоколы, алгоритмы для графики, мультимедии и …, но нет даже намека на архитектуру, которая позволила ести разработку не просто АЛГОРИТМОВ, а увязывала бы логику проекта в целом.

А это НЕОБХОДИМО! 

Ныне разрабатываю API, которое позволяет на основе метаданных в run-time без использования компиляторов создавать и работать с объектами любой сложности.
Ныне вот затачиваю API для создания и работы с объектными базами данных и ЯП, использующего метаданные.

ЭТУ СТУПЕНЬКУ ПЕРЕПРЫГНУТЬ НЕ ПОЛУЧИТСЯ НИ КАК!   
Работы еще МНОГО!

Далее разработка архитектуры и API для работы с ЗНАНИЯМИ …

Пост был для разработчиков!

НЕ КОСТЕНЕЙТЕ В ДОГМАХ И ПОЙМИТЕ, ЧТО В ОБЛАСТИ РАЗРАБОТКИ НЕПОЧАТЫЙ КРАЙ РАБОТЫ!  
Те кто говорят "До нас все украли" - НАГЛО ВРУТ! ...

Владимир

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

Немного о ЛОР …

Люди ведь не роботы и поэтому ИМХО вполне допустимо /в разумных пределах конечно/ разговоры на любые темы.
Да не пошлая шутка ИМХО вполне допустима.
Конечно ПОЛИТИКУ И ИНОЙ СРАЧ разводить НЕ НУЖНО, а нормально пообщаться вполне допустимо.

Это же ФОРУМ!   
То бишь почти - БАЗАР!  

Владимир

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

API которое я разрабатываю, уже функциональнее плюсов …

ВЫ МОЖЕТЕ МНЕ ЗАДОНАТИТЬ ДЛЯ УСКОРЕНИЯ РАЗРАБОТКИ 

Владимир

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

В этом не очень много смысла. Проще AOT компилировать джаву, тогда будет бесплатный (по идее).
Лучше переписать GC в GHC на Haskell, чтобы одной зависимостью меньше. Это я так, к слову вспомнилось.

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

@unC0Rr, меня очень весело троллят уже года четыре.
Надеюсь вы поймете от какого Владимира пост …

anonymous
()
Ответ на: комментарий от anonymous
Дёня, а почём у тебя стоят стандарты'?'
Ден, напиши нам _Static_assert;
Ден, о привет сколько зим, сколько лет;
Ден, Ден, Ден, ДЁНЯ" '\0'

Дёня обожает родные <stddef.h>;
Ден, как перчатки меняет typedef;
Ден, расскажи, ну в чём брат секрет'؟'
На все семь бед, один NULL ответ!" '\0'

Ден, ну просто капитальный красавчик;
Ден тебе приготовит __builtin_ia32_paddw128;
Не какие-то сэндвичи/**/ланчи;
Настоящие стандарты .с default:" '\0'

Ммм, ну просто капитальный красавчик;
Взял и придумал весь этот #define __VEC_CLASS_FP_INFINITY_P (1<<5);
_Imaginary, _Thread_local, _Alignas;
И накопил СиBSD на КОМПИЛЯТОР;" '\0'

КОМПИЛЯТОР цвета Бардадыма, в нём едет важная void (*(*p(void))(long double complex))(void);
extern типа char *, едет знакомится с *(void *);
КОМПИЛЯТОР цвета Бардадыма, в нем КОМПИЛИРУЕТ важная персона;
NULL типа malloc(sizeof *p), едет с бутылкой Арарата, Камон LISP #define __ATTRS_o_ai __attribute__((__overloadable__, __always_inline__))!" '\0'
anonymous
()
Ответ на: комментарий от unC0Rr

Лучше как-нибудь встретимся с вами и поболтаем.

ЧТОБЫ БЕЗ ТРОЛЛИНГА ...

Владимир

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

И все работает, но потом приходит другой разработчик, добавляет еще что-то, и goto забывает.

Это не разработчик, а идиот. Зачем вам понадобилось допускать идиота к работающему коду, и почему куда-то делся предудущий, нормальный разработчик, который не забывал про goto?

Вот у нас уже утечка.

У вас HR головного мозга и неспособность удержать старого или нанять другого нормального программиста.

Чтобы такого не было, придумали defer, который нужно написать только один раз.

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

Желание «решать» ваши проблемы с некомпетентностью менеджмента и управления добавлением совершенно ненужных и неуместных костылей в язык программирования только доказывает некомпетентность вашего начальствования.

Ваши проблемы в принципе не решаются языком программирования. Никакие попытки бизнеса решить свои проблемы с жадностью путём снижением порога вхождения в ЯП за много лет ни к чему не привели. Дело в том, что если нанятая обезьянка «забывает про goto», то ничего кроме лютого говнокода она родить не сможет, какой язык ей не подсовывай. А программист который способен писать качественный код и про goto не забудет.

За десятилетия попыток удешевить программизм посредством понижения уровня вхождения в язык, не появилось ни одного качественного программного продукта написанного на этих языках лицами с пониженной способностью входить. Вообще ни одного. Взять ту же жабу - практически весь прикладной софт написанный на ней является лютейшим шлаком, которым невозможно пользоваться. А чтобы создать на жабке хоть что-то работающее, всем без исключения достигшим какого-то успеха конторам пришлось в итоге нанимать адекватных жабакодеров (которые и про goto в сишечке не забудут) за невменяемые деньги. И то, в большом количестве случаев получились совершенно невменяемые, хотя и как-то работающие продукты типа SAP.

Так что снижение порога вхождения ЯП вообще никак не решает вопрос с качеством программного продукта. Совсем. И никакие defer в сишечке никак не решат ваши проблемы с некомпетентностью менеджмента.

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

@Stanson, программисты это такой народ, это такой народ …
Иногда на форуме все же по делу говорю, а часто для фана потому, что на форуме столько ЧУШИ, что НИ В КАКИЕ ВОРОТА …

Вообщем где-то так

Когда мы были молодыми и ЧУШЬ ПРЕКРАСНУЮ НЕСЛИ ...

Владимир

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

А сколько вам лет, Володя?

В 1812 было восемнадцать годков помню …

А потом огородами, огородами и к Кутузову ...

Владимир

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

сколько вам лет, Володя?

Я так понимаю, что нравлюсь вам … Что ж, мой возраст НЕ ПОМЕХА …

СТАРЫЙ КОНЬ БОРОЗДЫ НЕ ИСПОРТИТ

Владимир

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

Владимир, весело троллите …

Уже привык ...
anonymous
()
Ответ на: комментарий от hateyoufeel

Тут проблема в том, что C гораздо сложнее чем кажется. Дьявол, как всегда, кроется в мелочах. Там анон выше про «pointer provenance» написал. Что это такое? В стандарте не очень описано.

Что реально бесит, так это то, что в пропозалах про pointer provenance не пытаются завезти классификацию значений указателей аля C++ (pointer to an object и pointer past the end of an object), так что разница между указателем за последним элементом массива и указателем на объект с тем же типом, который там оказался до сих пор размыта.

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

В этом не очень много смысла. Проще AOT компилировать джаву, тогда будет бесплатный (по идее).

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

Лучше переписать GC в GHC на Haskell, чтобы одной зависимостью меньше. Это я так, к слову вспомнилось.

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

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

В Обероне компилятор определяет разыменовывание автоматически в большинстве случаев та что писать «^» не надо.

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

Желание «решать» ваши проблемы с некомпетентностью менеджмента и управления добавлением совершенно ненужных и неуместных костылей в язык программирования только доказывает некомпетентность вашего начальствования.

Хорошо сказано

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

Допустим. Но разве защита от идиота в языке будет лишней?

Она будет бесполезной. Создайте …. которым сможет пользоваться даже идиот и только идиоты будут этим пользоваться. Для языков программирования тоже верно. При этом, результат этого пользования будет тоже идиотским. Потому что идиот он не только забывает о важных вещах, он ещё и напрочь не понимает что он делает. С той же жабой - можно не заботится о освобождении ресурсов, но дай жабу идиоту - он станет на каждый чих объект создавать, причём в цикле, или ещё какие глупости делать. А то и вообще нужный алгоритм неправильно реализует. Он же идиот. В результате всё равно получится хоть и запускающееся, но совершенно бесполезное говно. ИМХО намного лучше, если программа падает, нежели молча выдаёт неверный результат. По очень простой причине - «небезопасный» язык априори требует наличия мозгов у программиста. И если у оного хватит мозгов написать на нём непадающий и нетекущий код, то с большой вероятностью и правильную и эффективную реализацию алгоритма он тоже осилит. Да и про юзабельность тоже скорее всего подумает.

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

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

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

Создайте …. которым сможет пользоваться даже идиот и только идиоты будут этим пользоваться.

Да, но defer это не тот случай. Он делает язык не тупее, а более утонченным.

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

Он делает язык не тупее, а более утонченным.

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

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

Это костыль в связи с отсутствующем RAII. Как например сделать, чтобы defer не вызывался в случае успешного выполнения функции?

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

Если уж решат, что Си нужно расширять, то должны быть приведены код, который четко демонстрирует преимущество и код на Си, эквивалентный добавляемой фичи.

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

Но революций делать не буду.
Нужно все тщательно ОБКАТАТЬ! …

Владимир

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

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

Проверкой внутри defer, ес-но.

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

Забыть goto это не идиотизм, а рассеянность. И умный человек может быть скрупулезным или рассеянным и глупый тоже. Вот что глупому человеку дается сложнее, так это абстракции. Абстракции нужны не ради абстракций, а чтобы решать проблемы. Компьютеры как раз об этом, абстракции позволяют решать проблему один раз в общем случае, а не каждый раз в каждом частном. Вот defer позволяет делать тоже что и goto, но писать это в функции нужно только один раз. Переменные в коде позволяют работать с разными данными много раз, написав код один раз.

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

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

Да, это костыль. Лучше взять c++ и не мучиться. Там есть решение чтобы defer не вызывался в случае успешного выполнения функции, но оно тоже костыльно.

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

ИМХО «вредность goto» - надуманная проблема.
Ныне goto имеется в Си и C++ и как бы все ok!
Что касаемо РУКОЖОПОВ, то от них ни один ЯП не спасет …

Владимир

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

Отец программирования Эдсгер Дейкстра плохого не скажет. «GOTO is considered harmful». В морг, значит в морг.

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

Отец программирования Эдсгер Дейкстра плохого не скажет. «GOTO is considered harmful». В морг, значит в морг.

Здесь важен контекст сказанного /в те года этот вопрос был особо актуален/.
Команды переходов во всех CPU имеются и они ЖИВЕЕ ВСЕХ ЖИВЫХ …

Владимир

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

Команды процессора предназначены в первую очередь для компилятора. Подход CISC и написание больших программ на ассемблере вручную давно устарел.

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

Команды процессора предназначены в первую очередь для компилятора.

Нынешние компиляторы к сожалению далеко не ПАНАЦЕЯ.

Даже switch в котором можно было бы использовать разные типы данных нет.

Автоматные таблицы кстати с использованием вычислимого goto очень просты в разработке и код понятен.

Согласен с тем, что в многих АЛГОРИТМАХ можно goto не использовать, но он бывает и полезен …

Владимир

anonymous
()
Ответ на: комментарий от anonymous
Considered harmful (с англ. — «считается вредным», «опасным») — 
фразема, широко используемая в заголовках критических эссе по 
информатике и смежных дисциплинах; существует как минимум 65 таких 
работ[1]).  
Вошла в оборот благодаря заметке «Go To Statement Considered Harmful»  
(с англ. — «О вреде оператора goto») Эдсгера Дейкстры[2]
[3], опубликованной в мартовском выпуске журнала Communications 
ofthe ACM 1968 года, в ней автор критиковал чрезмерное использование  
оператора goto в языках программирования той эпохи и 
пропагандировал вместо него структурное программирование[4]. 
Оригинальным заголовком письма, посланного в журнал, было «A Case 
Against the Goto Statement» (с англ. — «Дело в отношении оператора 
goto»), но редактор Никлаус Вирт изменил заголовок на «Go To 
Statement Considered Harmful»[5]. Дональд Кнут в отношении нового 
заголовка письма саркастически сказал, что «доктор Гото[en] [Goto] 
с улыбкой пожаловался, что им всегда пренебрегают»[6].

В те времена структурное программирование лишь зарождалось и о нем многие программисты не знали.
Как результат они часто использовали goto.

Ныне этой проблемы нет …

Владимир

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

Я не писал о вредности goto.

Извините! …

У меня иногда посты бывают не относящиеся непосредственно к предыдущему посту, а обсуждение темы в целом.
Поэтому иногда озаглавливаю посты …

Владимир

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

Я не писал о вредности goto.

Экий вы ВРЕДИНА … Пойдемте лучше погуляем, погоды нынче замечательные.

Владимир

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

поздновато надеяться что «само пройдет» когда пузо на нос лезет.

Это не про жир, это про беременность. Намек на то что процесс достиг стадии когда ожидать его самопроизвольного и БЕЗ ПОСЛЕДСТВИЙ завершения - наивно.

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

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

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

«небезопасный» язык априори требует наличия мозгов у программиста

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

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

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

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