LINUX.ORG.RU

defer в C быть!

 ,


0

9

Привет, ЛОР!

Как я писал три года назад, в стандарт языка Си было предложено добавить выражение defer, выполняющее функцию или блок кода по выходу из области видимости, где оно было объявлено.

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

При этом, defer почти наверняка не будет добавлен в C++, так как его использование будет конфликтовать с другими частями этого языка.

Ссылка на пост в блоге автора: https://thephd.dev/c2y-the-defer-technical-specification-its-time-go-go-go

Спецификация: https://thephd.dev/_vendor/future_cxx/technical%20specification/C%20-%20defer/C%20-%20defer%20Technical%20Specification.pdf

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

У них в блоге написано, что оно включается только если в юзерагенте Mozilla.
И действительно, поменял UA на curl и всё заработало

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

Мне кажется ты не в ту ветку ответила.

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

Неужели там был дефолтно всунутый signed int вместо size_t? Если так то это баян из 80х 90х, в более позднее время только у совсем слабоумных такое происходит (да, среди авторов вмвара могут быть и такие, как и в любой коммерческой фирме).

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

Примеры замены кода на функции без включения неадекватных оптимизаций ты так и не привёл. Инициализация переменной это не то.

firkax ★★★★★
()
Ответ на: комментарий от gaylord
$ cat > test.c
#include <limits.h>
main() {
int i = INT_MAX;

if (++i < 0)
    puts("lol");
}
$ gcc -o test test.c
test.c:2:1: warning: return type defaults to ‘int’ [-Wimplicit-int]
    2 | main() {
      | ^~~~
test.c: In function ‘main’:
test.c:6:5: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration]
    6 |     puts("lol");
      |     ^~~~
$ ./test
lol
firkax ★★★★★
()
Ответ на: комментарий от gaylord

Властью данной мне Керниганом и Ритчи

ты майку сначала себе нормальную купи, ну что ты вырядился, как гитлер?

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

В зависимости от версии компилятора может выдать хоть вообще ничего. Куда уж более неявно-то.

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

Неужели там был дефолтно всунутый signed int вместо size_t? Если так то это баян из 80х 90х, в более позднее время только у совсем слабоумных такое происходит (да, среди авторов вмвара могут быть и такие, как и в любой коммерческой фирме).

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

  1. С помощью C слишком легко испортить память
  2. Люди не могут быть сконцентрированы на 100% 24/7/365
gaylord
()
Последнее исправление: gaylord (всего исправлений: 3)
Ответ на: комментарий от firkax

У тебя шланг вместо компилятора

Про баги в GCC мы в другом треде уже обсуждали. Шланг тут не хуже и не лучше.

-O2

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

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

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

Согласен, надо писать хороший компилятор поскорее.

:~/dev.new/fcc$ svn log | grep line | awk '{print $1" "$3" "$5" "$6}' |awk 'FNR%2' 
r1375 host10 2019-03-26 01:17:12
r1373 host10 2019-03-26 01:15:35
r1371 host10 2019-03-26 01:12:15
r1369 host10 2019-03-26 01:08:30
r1367 host10 2019-03-26 00:45:43
r1365 host10 2019-03-26 00:26:30
r1363 host10 2019-03-26 00:22:20
r1361 host10 2019-03-26 00:20:36
r1359 host10 2019-03-26 00:03:39
r1357 host10 2019-03-25 23:55:33
r1355 host10 2019-03-25 23:47:11
r1353 host10 2019-03-25 23:37:51
r1351 host10 2019-03-25 23:22:24
r1349 host10 2019-03-25 23:12:21
r1347 host10 2019-03-25 06:46:31
r1345 host10 2019-03-25 06:37:02
r1343 host10 2019-03-25 05:13:47
r1341 host10 2019-03-25 04:57:33
r1339 host10 2019-03-25 04:28:55
r1337 host10 2019-03-25 04:04:02
r1335 host10 2019-03-25 02:50:12
r1333 host10 2019-03-24 23:43:27
r1331 host10 2019-03-24 22:55:25
r1329 host10 2019-03-24 22:18:48
r1327 host10 2019-03-24 21:24:57
r1325 host10 2019-03-24 21:21:43
r1323 host10 2019-03-24 21:18:32
r1321 host10 2019-03-24 21:11:05
r1319 host10 2019-03-24 20:53:37
r1317 host10 2019-03-24 20:46:32
r1315 host10 2019-03-24 20:40:02
r1313 host10 2019-03-24 20:33:39
r1311 host10 2019-03-24 20:32:36
r1309 host10 2019-03-24 20:29:01
r1307 host10 2019-03-24 18:46:23
r1305 host10 2019-03-24 17:30:37
r1303 host10 2019-03-23 16:18:36
r1301 host10 2019-03-23 16:12:08
r1299 host10 2019-03-23 14:24:53
r1297 host10 2019-03-23 04:57:19
r1295 host10 2019-03-23 01:16:35
r1293 host10 2019-03-23 00:53:46
r1291 host10 2019-03-22 23:53:50
r1289 host10 2019-03-22 23:24:42
r1287 host10 2019-03-22 21:11:50
r1285 host10 2019-03-22 18:07:37
r1283 host10 2019-03-22 17:47:56
r1281 host10 2019-03-22 17:40:54
r1278 host10 2019-03-18 18:07:56
r1276 host10 2019-03-18 14:29:27
r1274 host10 2019-03-18 14:02:28
r1272 host10 2019-03-18 13:25:48
r1270 host10 2019-03-18 13:07:39
r1268 host10 2019-03-18 12:31:03
r1266 host10 2019-03-18 00:39:40
r1264 host10 2019-03-18 00:25:56
r1262 host10 2019-03-18 00:03:49
r1260 host10 2019-03-13 03:13:03
r1258 host10 2019-03-12 02:42:55
r1256 host10 2019-03-12 02:39:19
r1254 host10 2019-03-12 02:07:15
r1252 host10 2019-03-11 21:00:58
r1250 host10 2019-03-11 20:50:37
r1248 host10 2019-03-11 20:34:42
r1246 host10 2019-03-11 20:30:53
r1244 host10 2019-03-11 20:12:51
r1242 host10 2019-03-11 19:58:31
r1240 host10 2019-03-11 19:38:04
r1238 host10 2019-03-11 19:18:28
r1236 host10 2019-03-11 10:00:31
r1234 host10 2019-03-11 08:40:17
r1232 host10 2019-03-11 08:05:06
r1230 host10 2019-03-11 07:49:13
r1228 host10 2019-03-11 06:56:09
r1226 host10 2019-03-11 05:44:22
r1224 host10 2019-03-11 05:19:52
r1222 host10 2019-03-11 03:51:48
r1220 host10 2019-03-11 00:56:02
r1218 host10 2019-03-09 08:23:29
r1216 host10 2019-03-09 07:52:01
r1214 host10 2019-03-09 06:12:28
r1212 host10 2019-03-09 05:46:29
r1210 host10 2019-03-09 05:29:05
r1208 host10 2019-03-09 04:37:27
r1206 host10 2019-03-09 04:12:19
r1204 host10 2019-03-09 03:52:59
r1202 host10 2019-03-07 04:11:41
r1200 host10 2019-03-07 03:01:15
r1198 host10 2019-03-07 02:21:15
r1196 host10 2019-03-07 01:43:00
r1194 host10 2019-03-07 01:14:55
r1192 host10 2019-03-06 02:25:07
r1190 host10 2019-03-05 02:11:05
r1188 host10 2019-03-04 04:14:05
r1186 host10 2019-03-04 03:23:09
r1184 host10 2019-03-04 03:10:37
r1182 host10 2019-03-04 02:26:12
r1180 host10 2019-03-04 01:02:17
r1178 host10 2019-03-03 03:23:35
r1176 host10 2019-03-03 02:08:22
r1174 host10 2019-03-03 01:52:16
r1172 host10 2019-03-03 01:31:42
r1170 host10 2019-03-03 01:11:00
r1168 host10 2019-03-02 22:43:31
r1166 host10 2019-03-02 21:02:32
r1164 host10 2019-03-02 20:59:22
r1162 host10 2019-03-02 20:39:21
r1160 host10 2019-03-02 20:19:26
r1158 host10 2019-03-02 19:21:41
r1156 host10 2019-03-02 18:37:03
r1154 host10 2019-03-02 18:20:40
r1152 host10 2019-03-02 17:05:34
r1150 host10 2019-03-02 07:35:04
r1148 host10 2019-03-02 06:58:56
r1146 host10 2019-03-02 05:24:03
r1144 host10 2019-03-02 04:44:05
r1142 host10 2019-03-02 04:17:49
r1140 host10 2019-03-02 03:17:32
r1138 host10 2019-03-02 01:01:51
r1136 host10 2019-03-01 23:14:29
r1134 host10 2019-03-01 23:05:50
r1132 host10 2019-03-01 22:44:55
r1130 host10 2019-03-01 20:28:19
r1128 host10 2019-03-01 01:52:15
r1125 host10 2019-02-28 23:15:33
r1123 host10 2019-02-28 22:31:36
r1121 host10 2019-02-28 04:57:21
r1119 host10 2019-02-28 03:44:26
r1117 host10 2019-02-27 23:07:04
r1115 host10 2019-02-27 22:47:06
r1113 host10 2019-02-27 22:21:32
r1111 host10 2019-02-27 15:09:01
r1109 host10 2019-02-27 14:54:06
r1107 host10 2019-02-26 04:06:43
r1105 host10 2019-02-26 02:43:49
r1103 host10 2019-02-26 02:21:10
r1101 host10 2019-02-26 02:01:54
r1099 host10 2019-02-26 01:24:21
r1097 host10 2019-02-25 19:21:39
r1095 host10 2019-02-25 18:56:13
r1093 host10 2019-02-25 18:47:44
r1091 host10 2019-02-25 18:29:48
r1089 host10 2019-02-25 18:01:04
r1087 host10 2019-02-25 17:10:32
r1085 host10 2019-02-24 23:57:42
r1083 host10 2019-02-24 23:17:30
r1081 host10 2019-02-24 22:41:16
r1079 host10 2019-02-24 22:16:07
r1077 host10 2019-02-24 21:29:59
r1075 host10 2019-02-24 18:28:00
r1073 host10 2019-02-24 16:13:22
r1071 host10 2019-02-24 03:19:58
r1069 host10 2019-02-24 03:02:32
r1067 host10 2019-02-24 00:58:12
r1065 host10 2019-02-23 23:47:19
r1063 host10 2019-02-23 23:11:19
r1061 host10 2019-02-23 19:30:29
r1059 host10 2019-02-23 17:39:33
r1057 host10 2019-02-23 17:17:07
r1055 host10 2019-02-23 15:02:02
r1053 host10 2019-02-23 02:07:41
r1051 host10 2019-02-23 00:26:41
r1049 host10 2019-02-23 00:13:49
r1047 host10 2019-02-22 14:39:20
r1045 host10 2019-02-22 14:04:52
r1043 host10 2019-02-22 13:35:02
r1041 host10 2019-02-21 17:11:54
r1039 host10 2019-02-21 00:25:33
r1037 host10 2019-02-20 15:41:13
r1035 host10 2019-02-20 02:54:25
r1033 host10 2019-02-20 02:22:53
r1031 host10 2019-02-20 00:43:28
r1029 host10 2019-02-19 22:29:51
r1027 host10 2019-02-19 21:49:11
r1025 host10 2019-02-19 02:43:09
r1023 host10 2019-02-19 01:41:42
r1021 host10 2019-02-19 01:33:49
r1019 host10 2019-02-19 01:26:35
r1017 host10 2019-02-19 00:50:12
r1015 host10 2019-02-19 00:38:46
r1013 host10 2019-02-18 23:49:57
r1011 host10 2019-02-18 02:10:10
r1009 host10 2019-02-17 22:09:26
r1007 host10 2019-02-12 05:08:24
r1005 host10 2019-02-11 05:18:39
r1003 host10 2019-02-11 04:49:53
r1001 host10 2019-02-11 04:36:26
r999 host10 2019-02-11 02:23:26
r997 host10 2019-02-11 02:14:46
r995 host10 2019-02-11 02:10:47
r993 host10 2019-02-11 02:02:26
r991 host10 2019-02-11 00:55:47
r989 host10 2019-02-11 00:09:39
r987 host10 2019-02-10 21:12:33
r985 host10 2019-02-10 20:05:40
r983 host10 2019-02-10 06:50:22
r981 host10 2019-02-10 06:27:05
r979 host10 2019-02-10 06:20:02
r977 host10 2019-02-10 05:45:33
r975 host10 2019-02-10 04:59:17
r973 host10 2019-02-10 04:51:52
r971 host10 2019-02-10 04:35:08
r969 host10 2019-02-10 04:09:09
r967 host10 2019-02-10 02:54:54
r965 host10 2019-02-10 00:57:32
r963 host10 2019-02-09 23:10:09
r961 host10 2019-02-09 21:46:39
r959 host10 2019-02-09 21:12:46
r957 host10 2019-02-09 19:30:22
r955 host10 2019-02-09 19:24:05
r953 host10 2019-02-08 13:02:12
r951 host10 2019-02-08 11:13:12
r949 host10 2019-02-08 10:35:46
r947 host10 2019-02-08 10:31:43
r945 host10 2019-02-08 09:18:54
r943 host10 2019-02-08 07:06:56
r941 host10 2019-02-08 06:10:19
r939 host10 2019-02-08 06:00:47
r937 host10 2019-02-08 05:45:41
r935 host10 2019-02-08 04:48:19
r933 host10 2019-02-06 16:38:42
r931 host10 2019-02-05 16:17:39
r929 svn 2019-02-05 00:34:21
firkax ★★★★★
()
Ответ на: комментарий от firkax

Согласен, надо писать хороший компилятор поскорее.

А чо ж сишники-то не написали? Кто-то им мешает?

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

Так я же лог приложил. Правда он неоконченный.

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

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

А, не, там 2019 год. О! Он его написал, но не выложит, потому что не признает гитхаб! Или нет нормального компилятора, чтобы скомпилировать.

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

Не, не написал, двух месяцев не хватило а потом стало лень :(

Вот всё думаю продолжить.

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

То есть нормальный компилятор си так никто и не написал? Ну и зачем нам такое убожество?

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

если бы Си был топором

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

топор опасная штука
не пользуйся топором

olelookoe ★★★
()

«Не жалею, не зову, не плачу, Все пройдет, как с белых яблонь дым. Увяданья золотом охваченный, Я не буду больше молодым.»

anonymous
()
- нож это опасная штука?  
- видали и кой-чего поопасней!
- а если борщ?
- пфффф
- а если при этом джигу танцевать? а если в гамаке? стоя?
- ты больной?  
- вот! и мне приходится жить с этой опасной штуковиной на одной планете! комитеты! люди! кто-нибудь! спасити-памагити! ножи проникают на кухни и набрасываются на меня практически сами!
...
olelookoe ★★★
()
Ответ на: комментарий от olelookoe

Похоже на то, как красноглазый ООП-нутый C++-плюшник танцует с топором.
Вот до чего жизнь довела.

anonymous
()

карочи, уважаемые адепты, профаны, маглы и волшебники
вот и выросло поколение, как говорицца
к чему это я? ах, да
спешу напомнить, что в сях отродясь есть чудо чудное и диво дивное
for (initialization; condition; update)
при помощи которого можно пилить удивительное, а не только то, что вам там в учебниках рассказывали
на фоне чего весь этот ваш defer бледнеет и курит в сторонке

эх, маладёшь…

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

Все претензии к C++ аналогично можно отнести к любой профессиии.

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

Если бы он тебе for(i=0; i<10; i++) x[i] = 0; заменил на memset то да, он превратил твой цикл в вызов функции. А тут никаких алгоритмов не было в оригинале, было объявление переменной со статическим инициализатором.

Распишитесь, получите

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

То, что оптимизатор - с этим я не спорю.

На самом деле я не вижу в C много семантически неявного поведения. Т.е. если сравнивать с C++, то код вида void f() { my_object myobj; } может включать в себя два вызова функций (конструктор и деструктор), которых в явном виде нет в коде. А в функции вида my_object f() { my_object m = g(); return m += h(), m; } вообще бог знает сколько этих неявных вызовов будет, вплоть до перегруженного оператора «запятая».

Конечно, можно сказать, что знающий язык C++ априори будет видеть все эти неявные вызовы «между букв». Но под неявным кодом я понимаю именно ситуацию, когда на первый взгляд кажется, будто вызова нет, а на самом деле он есть. Потому он и неявный.

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

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

Т.е. если сравнивать с C++, то код вида void f() { my_object myobj; } может включать в себя два вызова функций (конструктор и деструктор), которых в явном виде нет в коде.

Но они есть. Ты читаешь этот код как будто он на Си, но это ведь не Си. Просто привыкни, что в C++ создание любого объекта приводит к вызову пачки функций.

А в Rust, кстати, не приводит. Rust очевиднее C++?

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

В стандартном Си, да. Но тут вступает в силу тот факт, что все обмазываются расширениями в той или иной мере. В реальном коде бывает дохрена __attribute__ типа constructor, cleanup (по сути, defer) и так далее. Хочешь unique_ptr на Сишечке с расширениями? Их у нас есть.

Практически все проекты сложнее Hello World так или иначе это всё используют, просто потому что удобно.

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

Но они есть. Ты читаешь этот код как будто он на Си, но это ведь не Си. Просто привыкни, что в C++ создание любого объекта приводит к вызову пачки функций.

Повторюсь, что с таким подходом сама формулировка «неявное поведение» не имеет смысла. Любой язык имеет детерминированную семантическую модель. Всегда можно сказать: «выучи язык и ничего неявного не будет». Короче просто отмахнуться от проблемы легко. Но проблема не исчезнет.

А в Rust, кстати, не приводит. Rust очевиднее C++?

Не знаю. Я его плохо знаю. Вроде бы действительно Rust в этом отношении намного лучше C++. Но уверенно утверждать не буду.

В стандартном Си, да. Но тут вступает в силу тот факт, что все обмазываются расширениями в той или иной мере. В реальном коде бывает дохрена attribute типа constructor, cleanup (по сути, defer) и так далее. Хочешь unique_ptr на Сишечке с расширениями? Их у нас есть.

«Все» это слишком смелый квантификатор. Я не обмазываюсь. Если я пишу не стандартный С, это значит, что я не придумал, как это сделать на стандартном C. Сходу вспомню только атрибуты для помещения данных в разные секции, которые потом компоновщик будет собирать определённым образом. Да и те атрибуты на 90% обусловлены «фреймворком», для себя я такое использовал только чтобы объявлять глобальные неинициализируемые объекты. Но это явная недоработка языка. Вообще не понимаю, кому в голову пришло, что глобальные переменные без инициализатора должны инициализироваться нулями. Это полностью противоречит подходу и философии C.

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

Повторюсь, что с таким подходом сама формулировка «неявное поведение» не имеет смысла. Любой язык имеет детерминированную семантическую модель.

В том-то и проблема, что в Си это поведение обозначено стандартом, в котором написано: «тут может произойти что угодно, включая ничего». Смотри про вставку memset() выше, это вполне себе неявное поведение и это допускается стандартом.

«Все» это слишком смелый квантификатор. Я не обмазываюсь. Если я пишу не стандартный С, это значит, что я не придумал, как это сделать на стандартном C.

Окей, напишу так: 95% проектов сложнее Hello World используют нестандартные расширения в той или иной форме. Начиная от -fwrapv или -fno-strict-aliasing, потому что эта вот срань всех достала, и заканчивая cleanup для удобства.

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

Можно на C++ писать код подобный Си.
В чём профит? Используем C++ как Си, но с возможностью при желании использовать API и синтаксис C++.

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

Можно на C++ писать код подобный Си.

Настоящий программист на Си может писать на Си на любом языке!

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

Настоящий программист на Си может писать на Си на любом языке!

В отличие от Фортрана, это не работает. В ЯП нужна поддержка указателей, void*, кастов между любыми типами без ограничений, юнионов и прочей содомии.

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

В ЯП нужна поддержка указателей, void*, кастов между любыми типами без ограничений, юнионов и прочей содомии.

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

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

печалька в том что в сяшке нечего осиливать

т.е язык прост как палено (есть очевидные трэйдоффы в кривизне синтаксиса ну и с изоляцией(инкапсуляцией) сырцов вполне кривое решение инклюдниками приводящие к экспоненте во времени компиляции)

но если чел не может раскурить Си - но хочет в айти - ну теперь для него есть в айти куча проффесий

факт в том что человек не могущий осилить Си просто не программист

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

для реального программирования есть python/языки над llvm и прочие жабы

крч Сяшка это латынь

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

достаточно индекса (вычисляемого селектора)

что бы при достаточном размере программы получить свой забагованный вариант LISP bCpl

[upd]лол кек Сss выгугливается по «вычисляемый селектор» <- подтверждение тьюринг полноты

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

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

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

Да, умение ползать с топором в ноге бесценно. Японцы вон медиатор в форме топора используют столетиями, чтобы играть на струнных инструментах. От головы помогает говорят гарантированно. В общем то да, язык хорошо. Вот только нужны всякие познания. Ну типа как заставить драйвер Creative AE работать в режиме Direct Mode выключив DSP. Драйвер и так грузится на избранных дистрибутивах, а тут целую функцию надо реализовать. Интересно как бы он в Go это делал.

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

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

Что сложного в том, чтобы разработать подсистему управления динамическими переменными и объектами в run-time, а не в compil-time?

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

Знаете скупой платит дважды, а ленивый делает работу трижды.

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

«Суровые годы уходят Борьбы за улучшение Си! За ними другие приходят Они будут тоже трудны…»

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

запили предложение(rfc?) и (возможно)proof of concept

чуйка подсказыет обнаружется что run-time слишком разнообразный что бы всех устроило предложенное решение (но вдруг устроит) -

ps:

ну и ващет Cи с рантаймом(большим чем в стандарте) это С++ <-- такая история - да и имя намекает

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

Это очевидный вопрос же …

У меня это давно реализовано.

Поэтому всё разрабатываемое API можно использовать в любом ЯП.

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

ну и ващет Cи с рантаймом(большим чем в стандарте) это С++ <– такая история - да и имя намекает

Потому Керниган и Ритчи Си не стали переусложнять синтаксис Си.

Разрабатываем системные библиотеки и код становится много проще и лаконичней.

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

оно просто и очевидно когда специализированно

при универсализации(тем более криворукими) всяко вылезут фичебаги

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

Безусловно, но ведь им говорят «положи», а они вечно «кладут» …

anonymous
()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)