forum.opennet.ru - "Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью" (120)

"Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Проект TrapC развивает Си-подобный язык, безопасно работающий с памятью"	+/–
Сообщение от opennews (??), 12-Ноя-24, 22:51
Стартап Trasec развивает язык программирования TrapC, представляющий собой диалект языка Си, обеспечивающий безопасную работу с памятью. Для блокирования ошибок при работе с памятью, таких как выход за границы выделенного буфера, в TrapC применяется фундаментально иной способ работы с указателями и специальный механизм обработки ошибок. Заявлено, что особенности работы с указателями по возможности не будут нарушать привычный уклад и будут реализовываться на этапе компиляции. Исходный код компилятора для TrapC планируют открыть в 2025 году... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=62224
Ответить \| Правка \| Cообщить модератору

Оглавление

Спросил автора Fil-C об отличиях проектов, вот его ответы https x com solardiz, solardiz (ok), 02:14 , 13-Ноя-24, (53) +10

А можете еще спросить 1 Не хочет ли он нормальные типы с конкретными битностя, Аноним (-), 08:16 , 13-Ноя-24, (81) +3

Тогда уж для всех платформ унифицировать примитивные типы по длине А не как в с, Жироватт (ok), 09:06 , 13-Ноя-24, (92) +1

Ну так uint8_t из C99 и аналогичных плюсов - везде и должен быть 8 битов ак, Аноним (-), 10:16 , 13-Ноя-24, (107)

А, понял Ты про статическую проверку выборки индекса поля в enum е Ну, попутал, Жироватт (ok), 11:02 , 13-Ноя-24, (116) +1

Это как в том анекдоте - и упаси тебя перепутать хиппи с толкиенистом В случа, Аноним (121), 11:41 , 13-Ноя-24, (121)

Утро, кофе еще не до конца пошло по венам, разнося живительные молекулы по орган, Жироватт (ok), 14:57 , 13-Ноя-24, (132) +2

У вас какие то придирки причём к основам Сей трешу вроже bool my_var2 255 , Аноним (195), 02:31 , 18-Ноя-24, (195)

Вроде с типом enum в C23 решили вопрос, можно задавать его базовый тип enum E1 , Совершенно другой аноним (?), 09:34 , 13-Ноя-24, (100) +1

Это уже чуть лучше чем было - но я таки про - несколько другое См выше , Аноним (-), 10:21 , 13-Ноя-24, (108) +2

Да, согласен с Вами этого сильно не хватает В C попытались решить эту проблем, Совершенно другой аноним (?), 17:17 , 13-Ноя-24, (142)

Ну я и не понимаю - в чем прикол сделать перечисляемый тип, но вообще совсем ник, Аноним (-), 07:52 , 14-Ноя-24, (169) +1

enum это способ задать константу 100 без выделения памяти , Аноним (175), 13:57 , 14-Ноя-24, (175)

Так ее можно и define задать например И даже в случае const - ниоткуда не след, Аноним (176), 16:40 , 14-Ноя-24, (176)

Это он сейчас может, а когда C разрабатывался, const переменная означала статиче, Аноним (-), 21:52 , 14-Ноя-24, (181)

Это опять же нигде жестко не требуется в стандарте, насколько я понимаю И если к, Аноним (-), 18:26 , 15-Ноя-24, (186)

Та эта довольно просто Если ты задумаешься как можно сделать не 90 фичи, а 100, Аноним (-), 22:03 , 14-Ноя-24, (182)

Но это не значит что не нужно делать ничего Это как с дорогой - сделали ровный , Аноним (-), 01:38 , 15-Ноя-24, (183)

И это глупо Ибо на разные enum можно даже разные typedef навесить - но даже это, Аноним (-), 18:36 , 15-Ноя-24, (187)

затем, что виртовские языки не защищают от идиота чтобы защитить от идиота 82, arisu (ok), 23:49 , 15-Ноя-24, (192)

И тут какая то ахинея особой разницы между ними нет же в мышлении как скажем с, Аноним (195), 02:56 , 18-Ноя-24, (196)

Самое главное непонятно - в чем именно заключается фундаментально иной способ р, nc (ok), 23:01 , 12-Ноя-24, (2) +1

Скрыто модератором, помпезный (?), 07:37 , 13-Ноя-24, (77) +3

Скрыто модератором, Аноним (84), 08:50 , 13-Ноя-24, (84)

Скрыто модератором, помпезный (?), 09:14 , 13-Ноя-24, (96) +2

Скрыто модератором, Аноним (-), 08:57 , 13-Ноя-24, (85)

Скрыто модератором, помпезный (?), 09:16 , 13-Ноя-24, (98) +1

Скрыто модератором, Аноним (-), 10:24 , 13-Ноя-24, (109) –2

Скрыто модератором, помпезный (?), 10:35 , 13-Ноя-24, (114) +2

Скрыто модератором, Аноним (-), 11:52 , 13-Ноя-24, (122) –1

На моей памяти это уже не первая попытка исправить, 171 оберткой 187 , чужой,, Аноним Анонимович Анонимов (?), 23:07 , 12-Ноя-24, (4) +10

Зная говноделов в комитете, этот стандарт будут внедрять ещё один десяток лет, а, Bottle (?), 06:09 , 13-Ноя-24, (70) +9
Вроде всего третья попытка A, B и вот теперь C , Аноним (133), 15:09 , 13-Ноя-24, (133) +1

И каким образом Линейными типами Ну я бы посмотрел, как они в С их добавят ГЦ, Аноним (6), 23:12 , 12-Ноя-24, (6) +2

В свифте сделали же автоматическое управление памятью без гц И никаких боровов , Аноним (20), 23:57 , 12-Ноя-24, (20) –1

Сделали, ага Просто поменяли терминологию и громко, во всех форумах и теле-инс, Аноним (30), 00:29 , 13-Ноя-24, (30) +1

Ну так в C тоже есть shared_ptr который делает то же самое И никто не говорит, Аноним (49), 01:48 , 13-Ноя-24, (49) +2

Как же вы, неучи-фанаты-ябла с альтернативной терминологией, надоели https cpl, Аноним (30), 22:21 , 13-Ноя-24, (161)

Как выше указали, ARC это подобие shared_ptr от Apple, в целом никакой магии Ст, Пользователь (?), 07:59 , 13-Ноя-24, (79) +1
Зашибись, а оверхед и непредсказуемость они под ковер как сныкали , Аноним (-), 08:59 , 13-Ноя-24, (88)

Оверхед - никак у них там компилятор вставляет Inc_Ref X Dec_Ref X , а вот с , Аноним (30), 22:26 , 13-Ноя-24, (162)

Ага, с утечками памяти при циклических ссылках, Аноним (156), 21:11 , 13-Ноя-24, (156)

Ну и зачем это Уже пилят Safe C https safecpp org , ijuij (?), 23:19 , 12-Ноя-24, (9)

code initializer_list T dyn a data noexcept safeusing F4 void a, b wher, Аноним (66), 04:48 , 13-Ноя-24, (66) +13

Они, кажется, всерьез решили зарубиться с хрустиками на тему кто получит почетны, Аноним (-), 09:01 , 13-Ноя-24, (89) +10

Горшочек не вари, я еще доки по Carbon и Circle до конца не дочитал а тут еще и , nc (ok), 12:16 , 17-Ноя-24, (194)

Rust на минималках , Аноним (13), 23:27 , 12-Ноя-24, (13) –4

Совместимый по памяти и рантайму без этих всяких жужжаний про safe не safe, Аноним (133), 15:10 , 13-Ноя-24, (134) –1

Answers the call from NSA, white house, fbi Яснопонятно Это кого надо иници, Аноним (32), 00:32 , 13-Ноя-24, (32) +6

А, знач - хорошие сапоги, надо брать , нах. (?), 01:13 , 13-Ноя-24, (48) –2

Сапоги от NSA - лучше сапоги PS А от отечественного тащ майора ещё лучше , Аноним (84), 08:58 , 13-Ноя-24, (87)

DARPA , VladSh (?), 15:13 , 13-Ноя-24, (135)

Будет смешно, если из-за академичности и известности автора все эти zig и им под, Аноним (36), 00:38 , 13-Ноя-24, (36) –1

Aкадемка обычно к успеху обычно не приходит Из более-менее используемого ocaml , Вы забыли заполнить поле Name (?), 00:41 , 13-Ноя-24, (37) +4

И все как на подбор кривые как турецкий ятаган , HyC (?), 03:16 , 13-Ноя-24, (60) +2

Чтож поделать Взлетает почему-то именно такое , Вы забыли заполнить поле Name (?), 04:53 , 13-Ноя-24, (67)

Потому что делать что-то практическое на академхрености получается где-то в инте, Аноним (-), 09:04 , 13-Ноя-24, (91)
Во-первых, миллионы мух А во-вторых, уж очень велик соблазн взять что-то из пар, Анониссимус (?), 09:13 , 13-Ноя-24, (95) –1

В языке сейчас важно сообщество и экосистема, не считая корневой идеи где он мож, Вася Пупкин (?), 01:51 , 13-Ноя-24, (51)

Самое важое в любом языке -- это количество библиотек, которые можно использоват, Анониссимус (?), 09:16 , 13-Ноя-24, (97)

Ну если предположить, что Си не из академки, то впоследствии стал использоваться, Аноним (73), 07:17 , 13-Ноя-24, (73)

Удобно перехватил , Жироватт (ok), 08:26 , 13-Ноя-24, (82)
Т е C взял академический отпуск от академиков , Аноним (124), 12:20 , 13-Ноя-24, (124)

Известности ноль И уже есть Carbon , Аноним (118), 11:15 , 13-Ноя-24, (118)

Carbon нихрена не собрать не затаoив половину Google к себе на домашний серверны, Аноним (133), 15:13 , 13-Ноя-24, (136)

Релиз в 27-м году Осталось только подождать, затяните пояса , Аноним (143), 17:30 , 13-Ноя-24, (143)

а вообще по теме мне кто то может пояснить что за вечная проблема с памятью в , htmldevelob (?), 01:51 , 13-Ноя-24, (52) +1

Просто прочитайте, что такое переполнение буфера, висячие указатели, переполнени, Йцукенг (?), 03:00 , 13-Ноя-24, (58) +4

Вы давно не программировали Я пользуюсь g Он многие из таких ошибок отслежив, Аноним (78), 07:39 , 13-Ноя-24, (78) –4

Скрыто модератором, Аноним (156), 21:16 , 13-Ноя-24, (158)

Основная проблема с памятью, что тебе надо дёрнуть free delete на кусок памяти т, Аноним (-), 11:20 , 13-Ноя-24, (119) +5
Никакой проблемы насамом деле нет Сын учится в вышке, учат кондовый С на указат, Анониматор (?), 08:02 , 14-Ноя-24, (171)

Никакой проблемы при написании лаб на Си на самом деле нетПоправил , freecoder (ok), 11:20 , 17-Ноя-24, (193) +1

что за , Аноним (61), 03:17 , 13-Ноя-24, (61) –1

Карабас-Барабас - профессор кукольных наук Всё нормально , Аноним (78), 07:23 , 13-Ноя-24, (75) +1
Помнишь такого вот кривого доцента с кафедры АСУП, САПР или ВТ Который в жизни , Жироватт (ok), 08:29 , 13-Ноя-24, (83) +2

Типа, как Зуев, который один год писал синтаксическое AST-дерево для несостоявше, eugene_martein (ok), 09:36 , 13-Ноя-24, (101)

Таких у нас вагон и полная тележка сверху Не пониманию я этого наяривания на ак, Жироватт (ok), 10:57 , 13-Ноя-24, (115)

Она нужна тем кто хочет быть услышен , а за других говорят их дела Говорят, м, Аноним (138), 15:49 , 13-Ноя-24, (138)

Вообще интересно, но пока ещё сыро и не опенсорс , Аноним (69), 05:33 , 13-Ноя-24, (69) +1

Пока сыро - это всё состояние опенсорса, так что вполне подходит, КО (?), 08:11 , 13-Ноя-24, (80) +1

Неочевидно GCC - опенсорс, но не сыро , Аноним (78), 09:59 , 13-Ноя-24, (105)

Как говорится, ничто не вечно, ничто не закончено и ничто не совершенно , Аноним (140), 16:11 , 13-Ноя-24, (140)

А я бы стал утверждать, что программа достигает совершенства к концу развити, Аноним (145), 17:37 , 13-Ноя-24, (145)

NC достиг совершенства в VC - к сожалению, Волков не дал исходников не то что, arisu (ok), 23:25 , 13-Ноя-24, (164)

NC достиг совершенства в MC - Cтаричок до сих пор живее всех живых с далекой с, Incorporated (?), 08:05 , 14-Ноя-24, (172)

а MC не надо сопровождать никуда последнее хорошее, что с ним случилось 8212 , arisu (ok), 08:35 , 14-Ноя-24, (173)

Ой не верится, что это возможно Например Чтобы это работало бы, компилятор долже, Аноним (-), 09:32 , 13-Ноя-24, (99) +4
Я когда был маленький, мне казалось что мир информационных технологий огромен К, Данные в так называемом поле Name (?), 09:39 , 13-Ноя-24, (102) +2

Увидел иронию в словах бывший профессор Но с другой стороны, когда в новом се, Аноним55 (?), 10:26 , 13-Ноя-24, (111)

В смысле - что По сторонам посмотри, прфоессор Увидишь куда идут ломовые выпла, Аноним (-), 07:55 , 14-Ноя-24, (170) +1

Можно подробнее , Аноним (156), 21:13 , 13-Ноя-24, (157)

А зачем тогда вообще Си Открою секрет Си изобрели, чтобы на ассемблере не писа, Аноним (103), 09:53 , 13-Ноя-24, (103) +2

Your computer is not a fast PDP-11, Аноним (141), 16:28 , 13-Ноя-24, (141) –1

А гораздо, гораздо хуже На 11й можно не то что на ассемблере, а прямо в машинны, нах. (?), 20:28 , 13-Ноя-24, (155)

Глядя на примеры использования кажется, что их писал человек, который не понимае, Додо (ok), 10:13 , 13-Ноя-24, (106)

По мне sizeof buff удобнее константы Хотя вероятно машинный код будет идентичны, Ivan_83 (ok), 02:31 , 14-Ноя-24, (168)

sizeof buff лучше приучиться просто не юзать - грабельная конструкция, и если т, Аноним (-), 18:42 , 15-Ноя-24, (188)

Мой пофигизм обычно кончается после того как PoC начал работать И на самом дел, Ivan_83 (ok), 23:37 , 15-Ноя-24, (190)

ой вэй , arisu (ok), 23:40 , 15-Ноя-24, (191)

Ну и зря , YetAnotherOnanym (ok), 10:25 , 13-Ноя-24, (110) –1

Нет памяти - нет проблем, LinupsCrashGitz (ok), 11:23 , 15-Ноя-24, (184) +1

Это все пустое Еще пара лет и нейронки смогут сделать простой и более безопасны, X86 (ok), 11:26 , 13-Ноя-24, (120) –3

Да, такие бинари, что всякие NSA курят в сторонке , Аноним (124), 12:36 , 13-Ноя-24, (126)
Скрыто модератором, Аноним (131), 13:23 , 13-Ноя-24, (131)

Скрыто модератором, Аноним (-), 12:25 , 13-Ноя-24, (125) –1
Проект конечно странный Какие цели он проследует не понятно По итогу это новый, Алексей (??), 12:40 , 13-Ноя-24, (127) +1

Зиг улучшил так улучшил, даже многострочные комменты вырезали, Аноним (129), 13:03 , 13-Ноя-24, (129) +2
Цель понятная и они не не скрывают - найти инвесторов Спрос есть Будет и предл, anonimous (?), 17:54 , 13-Ноя-24, (146)

Стыдно признаваться будет, что используешь язык с таким названием, Аноним (129), 13:02 , 13-Ноя-24, (128)

Вы свои проблемы из Java не тащите Всем давно известно корреляция обратная , Аноним (133), 15:16 , 13-Ноя-24, (137)

Кстати, интересная видеопрезентация, посмотрите кто не смотрел , Аноним (147), 18:00 , 13-Ноя-24, (147) +4
Есть безопасный диалект чистого Си, называется Cyclone Последний стабильный рел, Аноним (-), 18:22 , 13-Ноя-24, (151) –1
Можно расходится, чуда не будет, Аноним (156), 21:18 , 13-Ноя-24, (159) +1
Сколько уже языков изобретено, например тот же ATS Осталось дело за малым - убе, Аноним (156), 21:19 , 13-Ноя-24, (160)
Чем его РуСи Терехова не устроил , Аноним (163), 22:55 , 13-Ноя-24, (163)
Не понял шутку, типа еще на этапе компиляции виднее когда объект не будет нужен , _kp (ok), 23:42 , 13-Ноя-24, (166) +1

Ну так ты сам пиши на плюсах Зачем других агитируешь-то , Аноним (-), 17:57 , 14-Ноя-24, (178) +1

Уже минус производительности Дебажные сборки С такое же делают, и кажется флаг д, Ivan_83 (ok), 02:28 , 14-Ноя-24, (167) +1

А посмотри как боров-чекер например работает Некоторые плюсеры смогли посмотрев, Аноним (-), 18:46 , 15-Ноя-24, (189)

Сообщения [Сортировка по времени | RSS]

53. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +10 +/–

Сообщение от solardiz (ok), 13-Ноя-24, 02:14

Спросил автора Fil-C об отличиях проектов, вот его ответы:
https://x.com/solardiz/status/1856433226849628551
Filip Jerzy Pizło @filpizlo
The presentation is light on hardcore details and only has super simple examples, while Fil-C can run real big stuff (CPython, OpenSSH, etc). So, it’s not clear how it compares. Worth noting Fil-C is freely available today rather than sometime in the future!
The article says it’s a fork of the language and for example doesn’t allow unions at all. So, I think the biggest difference is that TrapC really is a different language. Fil-C, on the other hand, is just C (and unions are allowed, and they’re made safe).

Ответить | Правка | Наверх | Cообщить модератору

81. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +3 +/–

Сообщение от Аноним (-), 13-Ноя-24, 08:16

> Спросил автора Fil-C об отличиях проектов, вот его ответы:
А можете еще спросить...
1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию, в том числе в препроцессоре, для избежания UB/vuln/кучи багов от "не того размера" int который себе представлял програмер? В хрусте очень правильно это сделали, имхо. И в C99 тоже, но пороху нормально сделать не хватило. И препроцессор например - грабель кусок. А 1, 1U, 1UL, и 1ULL это 4 довольно разные вещи.
2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам.
3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен - мало того что хрен знает какого он типа, так еще если тип переменной enum, реально на вход функции можно любую труху давать - и как бы все ок.
4) Покажите ему MISRA C и Embedded C Coding standard. Может часть из этого стоило бы взять в оборот?

Ответить | Правка | Наверх | Cообщить модератору

92. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 09:06

> 1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию,
Тогда уж для всех платформ унифицировать примитивные типы по длине. А не как в стандарте и реализациях: для 32х бит int у нас 4 байта, для 64х бит int может быть как скрытой макрозаменой для int64 (8 байт), так и для int32 (4 байта), так и для int16 (2 байта), так и отдельным типом, который при флаге "--собирай-х64" неявно подставляется в таблицу символов и по нему уже выделяет память.
> 2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам.
+1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы для тех же координат.
> 3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен
А разве энум не специально создавался, как котёл с единым адресом для разных программно, но единых с точки зрения логики предметной области, данных? Примерно как
Бул? А зачем тащить в С бул, если уже написано куча BOOL-макросов и пользовательских структур?

Ответить | Правка | Наверх | Cообщить модератору

107. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 13-Ноя-24, 10:16

> Тогда уж для всех платформ унифицировать примитивные типы по длине.
Ну так uint8_t из (>= C99) и аналогичных плюсов - везде и должен быть 8 битов ака 1 байт. И uint64_t - именно 64 бита а не что-то еще.
И это было бы прекрасно. Но тут на сцену выходит препроцессор. В котором тоже есть математика. И даже можно им делать вычисления. А теперь попробуйте угадать какие там разрядности и что оно РЕАЛЬНО будет делать.
Это же касается инициализаторов переменных. Особенно опосля препроцессора.
А с enum вообще мрак. Какой у него формально тип - да Ктулху бы его знает! Более того - никаких проверок что на вход функции хотевшей enum дали ессно нет.
Пример:

typedef my_t enum {
    VAL1 = 1,
    VAL2 = 2;
} my_t;
void something(my_t input) {
...
}
something(VAL1); // valid
something(VAL2); // valid
something(10); // WTF but who cares?!
> А не как в стандарте и реализациях: для 32х бит int у нас
> 4 байта, для 64х бит int может быть как скрытой макрозаменой
> для int64 (8 байт)
Ну так я про то и говорю. Вон то ведет к множеству залетов при портировани кода. Поэтому те кому важна стабильность, качество и безопасность, предсказуемые доступы и проч, скажем фирмвары мк и проч - юзают типы конкретного размера. Но вооооон то добро в препроцессоре и рядом - активно мешается на этом пути. Да, представляете конструкции типа (1 << 30), (1 << 61) и проч - выглядит вроде безобидно, но является куском грабель. С топоорм на ручке.
> +1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что
> иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы
> для тех же координат.
Компилер сам может прекрасно оптимизнуть такие вещи. А дереференс левых bounds это такая очень характерная трабла сей. Я тут как-то рефакторил старый код, который при определенном input радостно уходил в минуса по индексу и радостно телепал там хзчто в оперативе. При том это remotely triggerable было. Круто, да?
> А разве энум не специально создавался, как котёл с единым адресом для
> разных программно, но единых с точки зрения логики предметной области, данных?
Выше характерный пример enum. Где он как бы есть, но реально - толку с него фиг. кто такой something(10) этом выражении? Была бы чуть менее тупая система типов - и компилер бы ЭТО поймал. Спросив что есть something(10) когда в том enum никогда не было задано число 10 и это явно невалидный вызов. Ибо callee имеет все основания ожидать только значения из того enum'а, согласно такой декларации, но сие никак не форсится. И это глупо - все инфо для этого в декларации есть. Если нечто рантайм-вычисляемо и в компиле не удается просчитать, сделать квалификатор типа constexpr'а, которым можно затребовать компилтайм просчет и фэйл если это не удалось.
> Бул? А зачем тащить в С бул, если уже написано куча BOOL-макросов
> и пользовательских структур?
В сях и так есть bool. Хотя в C23 его выпилили в пользу bit-exact, так что пристегните ремни. Зачем нужно?

uint8_t my_var = 255 + 1;
bool my_var2 = 255 + 1;
if (my_var) ..  // Вероятно програмер хотел сюда.
else ...        // А вы точно ожидали оказаться ТУТ булевской логикой?
if (my_var2) .. // А вот тут все нормально
else ...

(и все назначения крупнее 1 насколько я помню обрубаются до 1)

Ответить | Правка | Наверх | Cообщить модератору

116. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 11:02

А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну, попутал с union, бывает, давно не работал. Ну тогда да.

Ответить | Правка | Наверх | Cообщить модератору

121. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (121), 13-Ноя-24, 11:41

> А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну,
> попутал с union, бывает, давно не работал. Ну тогда да.
Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом". В случае сишника - ну я б еще понял struct и union перепутать (весьма чревато, как в анекдоте), но вот с enum - как?!

Ответить | Правка | Наверх | Cообщить модератору

132. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 14:57

> Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом".
Утро, кофе еще не до конца пошло по венам, разнося живительные молекулы по организму

Ответить | Правка | Наверх | Cообщить модератору

195. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (195), 18-Ноя-24, 02:31

У вас какие то придирки причём к основам Сей...
трешу вроже "bool my_var2 = 255 + 1;" - мето на помойке и язык тут не причём,
- пишите с    "bool my_var2 = (255 + 1)!=0;" и сразу видно что делает код.
"enum" это константы для типа int, их (пусть не такой как вам бы хотелось)смысл - быть заменой #define'ам которые типчино именуются заглавными что не всегда наглядно хоть и терпимо, но как и те - знанения должны суммироваться для применения в качестве битмасок.
Если этого не будет это уже будет не Си.
Впрочем, раз выкинуты free в subj'е - всёравно лже-Си....

Ответить | Правка | К родителю #107 | Наверх | Cообщить модератору

100. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 09:34

Вроде с типом enum в C23 решили вопрос, можно задавать его базовый тип:
enum E1 : short { m11, m12 };
или Вы про другое?

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

108. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Аноним (-), 13-Ноя-24, 10:21

> Вроде с типом enum в C23 решили вопрос, можно задавать его базовый
> тип:
> enum E1 : short { m11, m12 };
Это уже чуть лучше  чем было - но...
> или Вы про другое?
... я таки про - несколько другое. См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет.
При том в сорце ЕСТЬ все аннотации намерений. И _можно_ определить в компилтайме что something(10) это нечто совершенно левое. Но нет. В лучшем случае это отловит какой-нибудь сильно отдельный статический анализатор.

Ответить | Правка | Наверх | Cообщить модератору

142. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 17:17

> См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет.
Да, согласен с Вами этого сильно не хватает. В C++ попытались решить эту проблему введя enum class, но в C, пока, на эту тему подвижек нет.

Ответить | Правка | Наверх | Cообщить модератору

169. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (-), 14-Ноя-24, 07:52

> Да, согласен с Вами этого сильно не хватает. В C++ попытались решить
> эту проблему введя enum class, но в C, пока, на эту
> тему подвижек нет.
Ну я и не понимаю - в чем прикол сделать перечисляемый тип, но вообще совсем никаких проверок не сделать, никак и нигде как mandatory в стандарте? Ведь 90% фичи - как бы есть. Но без остальных 10% толку то с нее такой? Гряблями по морде получить лишний раз? :)

Ответить | Правка | Наверх | Cообщить модератору

175. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (175), 14-Ноя-24, 13:57

enum это способ задать константу 100% без выделения памяти.

Ответить | Правка | Наверх | Cообщить модератору

176. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (176), 14-Ноя-24, 16:40

> enum это способ задать константу 100% без выделения памяти.
Так ее можно и #define задать например. И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO вообще может иметь очень сильно свое мнение на этот счет. Сделав с кодом такое что вам и не снилось.

Ответить | Правка | Наверх | Cообщить модератору

181. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 14-Ноя-24, 21:52

> И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO
Это он сейчас может, а когда C разрабатывался, const переменная означала статически выделенную память под эту переменную. Плюс const это всё же иное. Например, const обладает адресом. Const переменная рассматривается компилятором как lvalue, он может запрещать присвоение такому lvalue, но ты сам посмотри, он генерирует ошибки с другим текстом. Плюс эти запреты не столь строгие, и их можно обойти при желании.
> Так ее можно и #define задать например.
Можно, но enum во-первых убедиться, что у тебя нет дублирующихся констант, во-вторых он позволяет не указывать значения, если они у тебя последовательно идут или если тебе глубоко плевать, что это за значения, лишь бы они были разные.

Ответить | Правка | Наверх | Cообщить модератору

186. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 15-Ноя-24, 18:26

> Это он сейчас может, а когда C разрабатывался, const переменная означала статически
> выделенную память под эту переменную.
Это опять же нигде жестко не требуется в стандарте, насколько я понимаю.
И если константа где-то хоть как-то реально в коде юзается, де факто где-то в коде будет как минимум что-то типа mov r5, #CONST или что там у кого. И это где-то ессно хранится. Исключение разве что всякие unused (на которые нынче вообще warning модно давать) и compile-time штуки, типа условной компиляции.
А реально LTO может вспомнить что 2 кило назад, он уже вон то сделал, в условном r5 до сих пор это - так что можно реюзануть. Сделав для вгрузки константы - ровно ничего. Так в коде и данных может оказаться меньше чем де факто задекларено. Если абстракции удержатся.
> Плюс const это всё же иное.
> Например, const обладает адресом.
Теоретически - да. Практически - зависит от того смотрит ли на этот адрес хоть кто-то. Потому что если не смотрит, LTO может вообще лихо вообще скажем всю таблицу векторов прерываний выпилить. В софте usage не видно же?! А то что железо ее там вызывало... откуда ему знать? И такое может потребоваться явно костылять.
> генерирует ошибки с другим текстом. Плюс эти запреты не столь строгие,
> и их можно обойти при желании.
Через указатели можно попробовать. Но что будет в результате большой вопрос. Если это МК и оно чисто технически в флеше лежит, ибо RODATA - ну вы поняли. Не, такое вы не обойдете.
>> Так ее можно и #define задать например.
> Можно, но enum во-первых убедиться, что у тебя нет дублирующихся констант,
С #define нынче есть варнинги на redefined если оно надо.
> во-вторых он позволяет не указывать значения, если они у тебя последовательно идут
> или если тебе глубоко плевать, что это за значения, лишь бы
> они были разные.
Это все прекрасно, но весьма тупое использование перечисляемого типа. Когда все аннотации намерений есть - можно было бы и регламентировать что something(10) из того примера - левак и фу таким быть. На уровне стандарта. Потому что указан тип операнда my_t который enum, и он не содержит 10, вот хоть как.

Ответить | Правка | Наверх | Cообщить модератору

182. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 14-Ноя-24, 22:03

Та эта довольно просто. Если ты задумаешься как можно сделать не 90% фичи, а 100% фичи, то ты увидишь, что оставшиеся 10% сложнее первых 90%. Можно отгрызть 5% добавив статических проверок значений, которые кладутся в переменные типа enum, но это сработает только для случаев, когда статически известно, что кладётся недопустимое значение. А в случаях когда это неизвестно, что делать? Добавлять рантайм проверки? Допустим, но и что делать, если рантайм проверка провалилась? И одоление этих остающихся 5% потребует принятия спорных решений, например паник в рантайме, если в enum кладётся недопустимое значение. Или, например, добавление к каждому enum'у специального значения DefaultValue (или может его лучше назвать InvalidValue?) которое будет класться в enum вместо любого недопустимого значения. Придётся какие-то костыли изобретать.
> Ну и я и не понимаю - в чем прикол сделать перечисляемый тип
Я в школе не понимал в чём прикол enumeration в паскале. В C ты просто даёшь названия интересующим тебя int'ам, и потом работаешь с ними как с int'ами. Это делает код читаемее не создавая ненужных сложностей. В паскале же какие-то кошмарные сложности преобразовать значение enumeration в integer и обратно. Ну и я не понимал зачем такие enumeration нужны, когда проще насоздавать констант.

Ответить | Правка | К родителю #169 | Наверх | Cообщить модератору

183. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 15-Ноя-24, 01:38

> Та эта довольно просто. Если ты задумаешься как можно сделать не 90% фичи, а 100% фичи, то ты увидишь, что оставшиеся 10% сложнее первых 90%.
> Можно отгрызть 5% добавив статических проверок значений, ...
Но это не значит что не нужно делать ничего)
Это как с дорогой - сделали ровный асфальт -10% аварий, поставили освещение еще -10%.
Добавили разделительный отбойник - ну так вообще -20%.
> Придётся какие-то костыли изобретать.
Неа, они уже изобретены. Типа UB и прочих приколов.
> В C ты просто даёшь названия интересующим тебя int'ам, и потом работаешь с ними как с int'ами. Это делает код читаемее не создавая ненужных сложностей.
А потом кто-то создает enum Warm и второй enum Soft.
И.. легко и непринужденно сравнивает "теплое с мягким".
А языку вообще пофиг что там - это же все инты.
> В паскале же какие-то кошмарные сложности преобразовать значение enumeration в integer и обратно. Ну и я не понимал зачем такие enumeration нужны, когда проще насоздавать констант.
Потому что идея был возможно неплохой, а реализация - не самой удачной.
В новых языках это уже исправили - тут тебе и проверки "типа" енама, и patternMatching, и прочие  блага цивилизации.

Ответить | Правка | Наверх | Cообщить модератору

187. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 15-Ноя-24, 18:36

> А потом кто-то создает enum Warm и второй enum Soft.
> И.. легко и непринужденно сравнивает "теплое с мягким".
> А языку вообще пофиг что там - это же все инты.
И это глупо. Ибо на разные enum можно даже разные typedef навесить - но даже это не особо поможет.
При желании конечно частично лечится. Скажем юзанием struct'ов. Вот тут уже typedef будет работать так как ожидается, и зарубит подсовывания Warm в функцию хотевшую тип Soft. Но для вот именно того это уже нехилая сова на глобус - и нет гарантий отсутствия явно левых значений на входе и отлова этого в компилтайм, даже там где точно можно было.
> Потому что идея был возможно неплохой, а реализация - не самой удачной.
Паскаль вообще довольно активно делает мозг при попытке на нем что-то практическое програмить. Одна из причин по которой его не любят.
Ну может кроме дельфи. Но вся его занудность не помогает ему в результате от "unhandled exception" и каких там еще прелестей - при том в рантайме. И это как бы фэйл, так делать мозг, чтобы потом в рантайме все равно фигню творить. А зачем тогда все эти мучения были?

Ответить | Правка | Наверх | Cообщить модератору

192. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от arisu (ok), 15-Ноя-24, 23:49

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

Ответить | Правка | Наверх | Cообщить модератору

196. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от Аноним (195), 18-Ноя-24, 02:56

И тут какая то ахинея: особой разницы между ними нет же в мышлении (как скажем с Java),
фишка что Си, что Pascal,
-  в "всё ради скорости, кто натупил - сам виноват, а не синтаксис! мы вас предупредили,
лентяи [внимательно] читать документацию..."

Ответить | Правка | Наверх | Cообщить модератору

2. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от nc (ok), 12-Ноя-24, 23:01

Самое главное непонятно - в чем именно заключается "фундаментально иной способ работы с указателями и специальный механизм обработки ошибок". Жирные указатели как в Cyclone?

Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором +3 +/–

Сообщение от помпезный (?), 13-Ноя-24, 07:37

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

Ответить | Правка | Наверх | Cообщить модератору

84. Скрыто модератором +/–

Сообщение от Аноним (84), 13-Ноя-24, 08:50

"Ворованные санитайзеры" - что за санитайзеры такие? Где почитать? Поисковик вразумительного не даёт.

Ответить | Правка | Наверх | Cообщить модератору

96. Скрыто модератором +2 +/–

Сообщение от помпезный (?), 13-Ноя-24, 09:14

Можешь загуглить по -fsanitize флажку компилятора.

Ответить | Правка | Наверх | Cообщить модератору

85. Скрыто модератором +/–

Сообщение от Аноним (-), 13-Ноя-24, 08:57

> Ворованные санитайзеры, судя по всему. Как и всё остальное - уже имеется в гцц.
Как украсть санитайзер? И зачем все это делать? :)

Ответить | Правка | К родителю #77 | Наверх | Cообщить модератору

98. Скрыто модератором +1 +/–

Сообщение от помпезный (?), 13-Ноя-24, 09:16

Также, как и компилятор. Можешь посмотреть как раст ворует ллвм. Хотя судя по твоим вопросам ты как раз агитатор подобного "подхода".

Ответить | Правка | Наверх | Cообщить модератору

109. Скрыто модератором –2 +/–

Сообщение от Аноним (-), 13-Ноя-24, 10:24

> Также, как и компилятор. Можешь посмотреть как раст ворует ллвм.
У него что, borrow checker - кредит вам не отдал? Экий он злодей! А так - я почему-то думал что либа кодогенерации нужна - чтоб ей пользоваться. Что хруст и делает :)
А вон там gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое. И решили позаимствовать (borrow) из хруста вот прям next gen их боррова-чекера, который на хрусте же и написан. Это ведет к довольно забавным проблемам бутстрапа такого компилера, ибо надо собрать код на хрусте при том что хруста еще нет, но это решаемо.

Ответить | Правка | Наверх | Cообщить модератору

114. Скрыто модератором +2 +/–

Сообщение от помпезный (?), 13-Ноя-24, 10:35

> А так - я почему-то думал что либа кодогенерации нужна - чтоб ей пользоваться. Что хруст и делает
Агитатор путается в показаниях. Выше он спрашивал "зачем все это делать?", а теперь он оказывается уже знал зачем.
> gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое
Сообщил что можно своровать ещё и гцц. Молодец.

Ответить | Правка | Наверх | Cообщить модератору

122. Скрыто модератором –1 +/–

Сообщение от Аноним (-), 13-Ноя-24, 11:52

> Агитатор путается в показаниях. Выше он спрашивал "зачем все это делать?", а
> теперь он оказывается уже знал зачем.
А за что я агитирую? Если за хруста - то я им пользоваться если и начну то не раньше чем его в gcc запилят в потребном виде (такой проект есть и довольно активно развивается).
>> gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое
> Сообщил что можно своровать ещё и гцц. Молодец.
Gccrc - это, так то, фронтэнд Rust для GCC. И его базовую часть уже в последний gcc даже вроде комитнули. Но у них был затык в том что borrow checker - довольно сложная штука и прогать его весьма канительно. С ним есть проблемы даже у хрустиков, о чем написано https://rust-lang.github.io/rfcs/2094-nll.html ибо их боров который здесь и сейчас порой рубит лишку и заставляет вбивать весьма забавные костыли чтобы вообще компилилось.
В силу сложности действа авторы gccrs и приняли решение - утащить next-gen версию боров-чекера (она пишется на хрусте) к себе. Но т.к. это часть фронтэнда компилера, который они и делают - вопрос а как тогда GCCом самого себя собирать, если хруста еще нет, но надо уже собрать код на хрусте как часть фронтэнда - становится довольно интересным вопросом. Хоть и решаемым многофазным бутстрапом. Первая версия билдится без борова, билдит себе борова, и ребилдят всю тушку уже с боровом.
И да, я уже несколько запутался кто у кого и что украл в результате в этой схеме? :)

Ответить | Правка | Наверх | Cообщить модератору

4. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +10 +/–

Сообщение от Аноним Анонимович Анонимов (?), 12-Ноя-24, 23:07

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

Ответить | Правка | Наверх | Cообщить модератору

70. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +9 +/–

Сообщение от Bottle (?), 13-Ноя-24, 06:09

Зная говноделов в комитете, этот стандарт будут внедрять ещё один десяток лет, а софт нужно писать уже сейчас.
К тому же, обязательно напишут про implementation-defined behaviour. Т.е. стандарт опять окажется нерабочим дерьмом из разряда "А вот тут как хотите так и делайте. Кроссплатформенная арифметика? Нет, не слышали".

Ответить | Правка | Наверх | Cообщить модератору

133. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (133), 13-Ноя-24, 15:09

Вроде всего третья попытка A, B+ и вот теперь C++

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Аноним (6), 12-Ноя-24, 23:12

> Вместо malloc в TrapC используется похожий на C++ вызов new. Вызовы free и delete отсутствуют, так как за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти.
И каким образом? Линейными типами? Ну я бы посмотрел, как они в С их добавят. ГЦ? Даже произносить смешно. Автофри, а-ля как в Vlang? Ну так он и работает только для примитивных случаев. Что-то сложнее уже сделать не получится (я пытался), разве что уговаривать компилятор, что ты мамой клянёшься, что освободишь память в конце. Ну, то есть, как ансейф в расте. Собственно, вопрос: а зачем тогда, а главное, на кой?

Ответить | Правка | Наверх | Cообщить модератору

20. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (20), 12-Ноя-24, 23:57

В свифте сделали же автоматическое управление памятью без гц. И никаких боровов чекать не надо.

Ответить | Правка | Наверх | Cообщить модератору

30. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (30), 13-Ноя-24, 00:29

> В свифте сделали же автоматическое управление памятью без гц.
Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках) объявили "ARC - это не GC, вот!"
правда, на реальность это как-то не повлияло ...
https://docs.swift.org/swift-book/documentation/the-swift-pr.../
> How ARC Works
> Every time you create a new instance of a class, ARC allocates a chunk of memory to store information about that instance. This memory holds information about the type of the instance, together with the values of any stored properties associated with that instance.
> ...
> To make sure that instances don’t disappear while they’re still needed, ARC tracks how many properties, constants, and variables are currently referring to each class instance.
https://www.cs.cornell.edu/courses/cs6120/2019fa/blog/unifie.../
> Tracing and reference counting are normally viewed as the two main, completely different approaches to garbage collection.
>

Ответить | Правка | Наверх | Cообщить модератору

49. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Аноним (49), 13-Ноя-24, 01:48

Ну так в C++ тоже есть shared_ptr который делает то же самое. И никто не говорит что это GC. В р@сте тот же самый подход есть, аналог плюсовых shared_ptr и unique_ptr.

Ответить | Правка | Наверх | Cообщить модератору

161. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (30), 13-Ноя-24, 22:21

> Ну так в C++ тоже есть shared_ptr который делает то же самое.
> И никто не говорит что это GC.
Как же вы, неучи-фанаты-ябла с альтернативной терминологией, надоели:
https://cplusplus.com/reference/memory/shared_ptr/
> Manages the storage of a pointer, providing a limited garbage-collection facility, possibly sharing that management with other objects.
>

Ответить | Правка | Наверх | Cообщить модератору

79. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Пользователь (?), 13-Ноя-24, 07:59

Как выше указали, ARC это подобие shared_ptr от Apple, в целом никакой магии.
Стоит отметить что в Swift активно агитируют использовать структуры везде где только можно

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

88. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 13-Ноя-24, 08:59

>> В свифте сделали же автоматическое управление памятью без гц.
> Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках)
> объявили "ARC - это не GC, вот!"
Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :)

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

162. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (30), 13-Ноя-24, 22:26

> Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :)
Оверхед - никак (у них там компилятор вставляет Inc_Ref(X)/Dec_Ref(X)), а вот с предсказуемостью у RC-сборщиков как раз все в полном порядке - вполне пригодны для RT-задач.

Ответить | Правка | Наверх | Cообщить модератору

156. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (156), 13-Ноя-24, 21:11

Ага, с утечками памяти при циклических ссылках

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

9. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от ijuij (?), 12-Ноя-24, 23:19

Ну и зачем это? Уже пилят Safe C++: https://safecpp.org/

Ответить | Правка | Наверх | Cообщить модератору

66. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +13 +/–

Сообщение от Аноним (66), 13-Ноя-24, 04:48

initializer_list([T; dyn]^/a data) noexcept safe
using F4 = void/(a, b where a : b, b : a)(int^/a, int^/b) safe;
struct Pair/(T0.0.0, T1.0.0)<string_view/T0.0.0, string_view/T1.0.0>
П/ож/алуйст/а, не н/ад^о^

Ответить | Правка | Наверх | Cообщить модератору

89. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +10 +/–

Сообщение от Аноним (-), 13-Ноя-24, 09:01

>
initializer_list([T; dyn]^/a data) noexcept safe
> using F4 = void/(a, b where a : b, b : a)(int^/a,
> int^/b) safe;
> struct Pair/(T0.0.0, T1.0.0)<string_view/T0.0.0, string_view/T1.0.0>

> П/ож/алуйст/а, не н/ад^о^
Они, кажется, всерьез решили зарубиться с хрустиками на тему кто получит почетный титул брейнфак-2.0 :)

Ответить | Правка | Наверх | Cообщить модератору

194. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от nc (ok), 17-Ноя-24, 12:16

Горшочек не вари, я еще доки по Carbon и Circle до конца не дочитал а тут еще и это

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

13. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –4 +/–

Сообщение от Аноним (13), 12-Ноя-24, 23:27

Rust на минималках.

Ответить | Правка | Наверх | Cообщить модератору

134. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (133), 13-Ноя-24, 15:10

Совместимый по памяти и рантайму без этих всяких жужжаний про safe не safe

Ответить | Правка | Наверх | Cообщить модератору

32. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +6 +/–

Сообщение от Аноним (32), 13-Ноя-24, 00:32

"Answers the call from NSA, white house, fbi..."
Яснопонятно. Это кого надо инициатива, дед тут как Линус с Столманом - для ширмы

Ответить | Правка | Наверх | Cообщить модератору

48. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –2 +/–

Сообщение от нах. (?), 13-Ноя-24, 01:13

А, знач - хорошие сапоги, надо брать!

Ответить | Правка | Наверх | Cообщить модератору

87. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (84), 13-Ноя-24, 08:58

Сапоги от NSA - лучше сапоги!
PS А от отечественного тащ майора ещё лучше.

Ответить | Правка | Наверх | Cообщить модератору

135. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от VladSh (?), 13-Ноя-24, 15:13

> // darpa_tractor.c
DARPA...

Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

36. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (36), 13-Ноя-24, 00:38

Будет смешно, если из-за академичности и известности автора все эти zig и им подобные выставят на мороз и будут забыты.

Ответить | Правка | Наверх | Cообщить модератору

37. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +4 +/–

Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 00:41

> академичности
Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.
>  и известности
Настолько известный, что пришлось писать кто он и чем занимался.

Ответить | Правка | Наверх | Cообщить модератору

60. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от HyC (?), 13-Ноя-24, 03:16

> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.
И все как на подбор кривые как турецкий ятаган.

Ответить | Правка | Наверх | Cообщить модератору

67. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 04:53

>> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу.
> И все как на подбор кривые как турецкий ятаган.
Чтож поделать. Взлетает почему-то именно такое.

Ответить | Правка | Наверх | Cообщить модератору

91. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 13-Ноя-24, 09:04

> Чтож поделать. Взлетает почему-то именно такое.
Потому что делать что-то практическое на академхрености получается где-то в интервале от неудобно до жутко назойливо.

Ответить | Правка | Наверх | Cообщить модератору

95. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Анониссимус (?), 13-Ноя-24, 09:13

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

Ответить | Правка | К родителю #67 | Наверх | Cообщить модератору

51. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Вася Пупкин (?), 13-Ноя-24, 01:51

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

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

97. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Анониссимус (?), 13-Ноя-24, 09:16

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

Ответить | Правка | Наверх | Cообщить модератору

73. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (73), 13-Ноя-24, 07:17

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

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

82. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 08:26

Удобно перехватил.

Ответить | Правка | Наверх | Cообщить модератору

124. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (124), 13-Ноя-24, 12:20

>Так что можно считать, что Си - академка.
Т.е. C взял академический отпуск... от академиков.

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

118. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (118), 13-Ноя-24, 11:15

Известности ноль. И уже есть Carbon.

Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

136. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (133), 13-Ноя-24, 15:13

Carbon нихрена не собрать не затаoив половину Google к себе на домашний серверный шкаф из 40 серверов с дисковым массивом - шутка про Java и Gradle артефакты доставаемые гигабайтами какое-то невероятное зависимое говны.
Пока они не освоят хотя бы CMake не о чем говорить

Ответить | Правка | Наверх | Cообщить модератору

143. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (143), 13-Ноя-24, 17:30

Релиз в 27-м году. Осталось только подождать, затяните пояса.

Ответить | Правка | Наверх | Cообщить модератору

52. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от htmldevelob (?), 13-Ноя-24, 01:51

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

Ответить | Правка | Наверх | Cообщить модератору

58. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +4 +/–

Сообщение от Йцукенг (?), 13-Ноя-24, 03:00

Просто прочитайте, что такое переполнение буфера, висячие указатели, переполнение стека.
Программы на Си, на Си++ и, тем более, на ассемблерных языках имеют такие проблемы. Для борьбы с ними программист, который пишет на этих языках, должен вручную прописывать в коде дополнительные проверки и очень хорошо понимать, как его программа будет работать с памятью. И он должен нигде не ошибиться. Это трудно.
В других языках такие проверки и работу с памятью обеспечивают компиляторы. Но тогда, обычно, эти языки ограничивают программиста в работе на низком уровне и плохо подходят для написания системных программ, в которых нужно работать напрямую с ячейками памяти.
Про безопасные ассемлерные языки: В начале 2000-х был создан язык Сиклон (Cyclone), в котором часть проблем языка Си была устранена. Некоторые из авторов Сиклона участвовали также в работе над типизированным ассемблером TAL — Typed Assembly Language. Информация в сети есть.

Ответить | Правка | Наверх | Cообщить модератору

78. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –4 +/–

Сообщение от Аноним (78), 13-Ноя-24, 07:39

> В других языках такие проверки и работу с памятью обеспечивают компиляторы.
Вы давно не программировали? Я пользуюсь g++. Он многие из таких ошибок отслеживает.
>  Но тогда, обычно, эти языки ограничивают программиста в работе на низком уровне и плохо подходят для написания системных программ, в которых нужно работать напрямую с ячейками памяти.
Это верно.

Ответить | Правка | Наверх | Cообщить модератору

158. Скрыто модератором +/–

Сообщение от Аноним (156), 13-Ноя-24, 21:16

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

Ответить | Правка | Наверх | Cообщить модератору

119. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +5 +/–

Сообщение от Аноним (-), 13-Ноя-24, 11:20

Основная проблема с памятью, что тебе надо дёрнуть free/delete на кусок памяти тогда и только тогда, когда этот кусок памяти перестаёт быть доступным для программы. Но языки программирования предлагают массу способов осложнить доказательство того, что кусок памяти перестаёт быть доступным. Указатель может где-нибудь сохраниться, в какой-нибудь структуре, допустим в каком-нибудь ивенте, который в какой-то очереди дожидается, когда он будет обработан. Динамические подходы к управлению памятью почти решают эту проблему, но даже они не идеальны, потому что программа может "забыть" обнулить какой-нибудь указатель, и динамические подходы к сборке мусора будут рассматривать это как наличие способа для программы поработать с данным куском памяти. Кроме того, не все сборщики мусора precise, часто производительности ради они действуют в разной степени консервативно и вычищают не весь мусор, только то, про что легко доказать, что это мусор. Счётчики ссылок же дополнительно создают проблем с циклическими ссылками. Впрочем, в языках со сборкой мусора, утечки памяти всё же редкость, потому что требуется довольно специальные условия, чтобы такое произошло. А use-after-free виртуально не существуют в них, потому что для этого нужен бажный сборщик мусора.
Есть простые способы эти проблемы одолевать статически, но эти простые способы ограничивают программиста. Например, можно делать free на кусок памяти всегда в той же функции, в которой этот кусок был выделен при помощи malloc. В таком случае проблема редуцируется к тому, чтобы не забывать на каждый malloc иметь free, и... ну прям скажем, даже это для программистов часто оказывается проблемой, но всё же это может сильно упростить жизнь. Точнее оно упрощает управление кучей, но усложняет жизнь другими способами, потому что например такой подход (если его применять строго) запрещает паттерн конструктора, который многократно дёргает malloc, и собирает какой-то сложный объект, допустим, берёт массив строк и делает red-black tree из строк: для такого дерева вызовы free для отдельных нодов дерева будут находится в других функциях, не в конструкторе.
Поэтому следующий напрашивающийся ход, начать усложнять простые способы, чтобы они всё же в меньшей степени ограничивали бы программиста. Например, мы можем создать класс функций-конструкторов, и класс функций деструкторов, и вместо того, чтобы отслеживать чтобы на каждый malloc был бы free, следить за тем, чтобы на каждый конструктор был бы деструктор. Таким образом мы можем обойти одну конкретную сложность с одним конкретным паттерном. Но паттернов больше, и если мы начнём со всеми паттернами так обходится, то мы получим что-нибудь типа раста, который начинает говорить об овнершипе и борровинге, присыпая это unsafe, потому что модель управления памятью в расте, вообще-то не позволяет реализовать даже такую простую штуку как динамический массив, приходится unsafe задействовать. Поэтому раст довольно сложно даётся C/C++ программистам, им приходится ломать привычки и отказываться от некоторых паттернов, которыми они пользуются не задумываясь.
> в си и си++ и наверно в ассемблере нету такой проблемы ?
В ассемблере нет, но если ассемблер применять так, как это принято нынче. То есть исключительно для того, чтобы оптимизировать "узкие" циклы. Если в цикле есть malloc/free, то это уже не узкий цикл, это уже гарантированно тормозной цикл, и переписывать его на ассемблере бессмысленно. Но зато, в ассемблере, могут возникать гораздо более забавные проблемы, когда ты в цикле делаешь push/pop, чтобы временно освободить регистр от значения, и в процессе рефакторинга кода нечаянно получаешь ситуацию с pop без соответствующего push, или наоборот, push без pop. Спектр возможных последствий такого неограничен, хотя в современных системах с memory management'ом, как правило всё завершается унылым сегфолтом. В DOS'е и win9x было гораздо интереснее по таким граблям ходить. Никогда не угадаешь, что получится.
Впрочем, я подозреваю, что современный ассемблер и push/pop не использует, они были полезны в древности, когда 360k памяти хватало для всех, и пара однобайтовых инструкций, позволяющая временно освободить дефицитный регистр для чего-то, была очень полезна.

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

171. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Анониматор (?), 14-Ноя-24, 08:02

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

Ответить | Правка | К родителю #52 | Наверх | Cообщить модератору

193. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от freecoder (ok), 17-Ноя-24, 11:20

*Никакой проблемы при написании лаб на Си на самом деле нет
Поправил.

Ответить | Правка | Наверх | Cообщить модератору

61. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (61), 13-Ноя-24, 03:17

> бывший профессор компьютерных наук
что за ...?

Ответить | Правка | Наверх | Cообщить модератору

75. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (78), 13-Ноя-24, 07:23

Карабас-Барабас - профессор кукольных наук. Всё нормально.

Ответить | Правка | Наверх | Cообщить модератору

83. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 08:29

Помнишь такого вот кривого доцента с кафедры АСУП, САПР или ВТ? Который в жизни не написал ничего реально применимого, но очень гордящегося своим алгоритмом подсчёта синуса от количества усов на морде среднестатистического кота? Такое же, только англоязычное.

Ответить | Правка | К родителю #61 | Наверх | Cообщить модератору

101. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от eugene_martein (ok), 13-Ноя-24, 09:36

Типа, как Зуев, который один год писал синтаксическое AST-дерево для несостоявшегося отечественного компилятора C++ в 90-ых, но получил такую психотравму, что по сей день орёт, что отечественный компилятор есть.

Ответить | Правка | Наверх | Cообщить модератору

115. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Жироватт (ok), 13-Ноя-24, 10:57

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

Ответить | Правка | Наверх | Cообщить модератору

138. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (138), 13-Ноя-24, 15:49

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

> Хотя зубров, вроде Кнута, стоит исключить
Говорят, математика это язык природы, просто словарь этого языка переполнен "словами паразитами" ввиде имен всяких "профессоров".

Ответить | Правка | Наверх | Cообщить модератору

69. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (69), 13-Ноя-24, 05:33

Вообще интересно, но пока ещё сыро и не опенсорс.

Ответить | Правка | Наверх | Cообщить модератору

80. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от КО (?), 13-Ноя-24, 08:11

Пока сыро - это всё состояние опенсорса, так что вполне подходит

Ответить | Правка | Наверх | Cообщить модератору

105. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (78), 13-Ноя-24, 09:59

> Пока сыро - это всё состояние опенсорса, так что вполне подходит
Неочевидно. GCC - опенсорс, но не сыро.

Ответить | Правка | Наверх | Cообщить модератору

140. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (140), 13-Ноя-24, 16:11

Как говорится, ничто не вечно, ничто не закончено и ничто не совершенно.

Ответить | Правка | К родителю #69 | Наверх | Cообщить модератору

145. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (145), 13-Ноя-24, 17:37

А я бы стал утверждать, что программа достигает совершенства к ... концу развития. После чего выбрасывается, и всё начинается сначала. Потребуются примеры? Ну, NC и NU под MS-DOS, да и сама MS-DOS.

Ответить | Правка | Наверх | Cообщить модератору

164. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от arisu (ok), 13-Ноя-24, 23:25

NC достиг совершенства в VC. ;-)
к сожалению, Волков не дал исходников. не то чтобы груда асм-кода была сейчас сильно нужна, но чисто для исторического интересу было бы неплохо.

Ответить | Правка | Наверх | Cообщить модератору

172. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от Incorporated (?), 14-Ноя-24, 08:05

NC достиг совершенства в MC. ;-)
Cтаричок до сих пор живее всех живых с далекой середины 90-x!
И продолжает активно сопровождаться, в отличии от того же FAR
есть еще TC - но это оффтопик
Так что даже в деле классических файловых менеджеров семейства NC движуха идет и они показали свою востребованность сообществом

Ответить | Правка | Наверх | Cообщить модератору

173. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от arisu (ok), 14-Ноя-24, 08:35

а MC не надо сопровождать никуда. последнее хорошее, что с ним случилось — это mc^2. который, естественно, в апстрим не взяли, и продолжают там заниматься ерундой. я этот самый mc^2 спокойно использую, и за восемь лет отсутствия очень необходимых сопровождений и обновлений весьма доволен.
была ещё, кстати, очень крутая штука — x northen captain. уже иксовая, но ещё приличная. жаль, что померла. я как-то думал её оживить, но традиционно заленился.

Ответить | Правка | Наверх | Cообщить модератору

99. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +4 +/–

Сообщение от Аноним (-), 13-Ноя-24, 09:32

> Заявлено, что особенности работы с указателями по возможности не будут нарушать привычный уклад и будут реализовываться силами компилятора.
Ой не верится, что это возможно.
Например:
> Вызовы free и delete отсутствуют, а за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти.
Чтобы это работало бы, компилятор должен знать про каждый выходящий из области видимости указатель, держит ли код овнершип на этот указатель, или получил его в результате борроуинга. В некоторых случаях это понятно: если код сделал malloc, и не передавал указатель никуда, то код владеет указателем. Но если код передавал указатель? Может он передал овнершип? Может указатель где-то сохранён? Или если код получил указатель через аргументы функции, ему его дали попользоваться, или отдали навсегда?
Чтобы одолеть это, придётся как минимум размечать все указатели во всех заголовках функций, указывая какие из указателей передаются с овнершипом в нагрузку, а какие только на попользоваться.
> Все создаваемые переменные и буферы явно инициализируются или заполняются нулями компилятором.
Rust тоже думал, что это ок. Что типа можно на кривой козе объехать накладные расходы на инициализацию памяти в тех случаях, когда она не нужна. Сейчас же в расте есть MaybeUninit, на те случаи, когда забить на накладные расходы нельзя и кривая коза не сработала. И прям скажем, MaybeUninit не для слабонервных.
И я отмечу, расту пришлось выкручиваться так, несмотря на то, что он value-oriented язык, он может "создать переменную" не выделяя/инициализируя память под неё, потому что память увязана со значениями, а не с переменными, и может передаваться из одной переменной в другую при присваивании. Здесь же, судя по лексике, язык остаётся variable-oriented, память ассоциируется с переменными, а это значит, что если я написал `int x;`, то семантически была выделена память плюс ещё и проинициализирована.
Но у раста, при этом, для пердеоления этих проблем есть параметрическая система типов, трейты и макросы, и он в целом справляется. Этот же стартап заявляет, что он решит все проблемы каким-то загадочным, магическим образом, не перелопачивая язык серьёзно до несовместимости... Выглядит как разводка инвесторов на деньги.

Ответить | Правка | Наверх | Cообщить модератору

102. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Данные в так называемом поле Name (?), 13-Ноя-24, 09:39

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

Ответить | Правка | Наверх | Cообщить модератору

111. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним55 (?), 13-Ноя-24, 10:26

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

Ответить | Правка | Наверх | Cообщить модератору

170. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (-), 14-Ноя-24, 07:55

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

Ответить | Правка | Наверх | Cообщить модератору

157. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (156), 13-Ноя-24, 21:13

>Смотрю как Oracle пыхтит пытаясь жабу тащить и как ему не хватает силёнок, чего уж говорить об энтузиастах?
Можно подробнее?

Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

103. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Аноним (103), 13-Ноя-24, 09:53

А зачем тогда вообще Си? Открою секрет. Си изобрели, чтобы на ассемблере не писать. Еще тогда если вы хотели не скорости и компактности, а надежности и безопасности - могли писать на басике или паскале.

Ответить | Правка | Наверх | Cообщить модератору

141. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (141), 13-Ноя-24, 16:28

> Си изобрели, чтобы на ассемблере не писать
Your computer is not a fast PDP-11

Ответить | Правка | Наверх | Cообщить модератору

155. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от нах. (?), 13-Ноя-24, 20:28

>> Си изобрели, чтобы на ассемблере не писать
> Your computer is not a fast PDP-11
А гораздо, гораздо хуже. На 11й можно не то что на ассемблере, а прямо в машинных кодах писать (и да, они специально сделаны удобочитаемыми)
На современной интеловской архитектуре - это рожать ежа против шерсти. Получится мало того что с нечеловеческими усилиями, так запросто еще и медленнее чем у компилятора (потому что тот умеет в execution reordering а ты парные команды подбирал-подбирал, а потом при отладке пришлось вставить еще одну и все пошло по п-де).

Ответить | Правка | Наверх | Cообщить модератору

106. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Додо (ok), 13-Ноя-24, 10:13

Глядя на примеры использования кажется, что их писал человек, который не понимает принципы работы с памятью вообще - но вместо того, чтобы учиться, он надеется на "безопасный" компилятор. На крайняк можно использовать любой статический анализатор - он подсветит нужные места и даст советы по исправлению.
// darpa_tractor.c
   int main(int argc,char* argv[])
   {
           const size_t buff_size = 8; // Зададим размер буфера тут, чисто чтобы не пользоваться sizeof(buff) везде.
           char buff[buff_size];
           int success = 0;
           strncpy(buff, argv[1], buff_size); // Тут используем strncpy вместо strcpy.
           // Тут проверим последний элемент буфера.
           // Если при вызове strncpy исходная строка поместилась в буфер целиком,
           // то буфер будет заполнен нулями до конца. Если нет - то последний элемент будет не 0.
           // А вообще тут strcmp никогда не вернёт 0, потому что размер сравниваемой строки
           // больше размера буфера (если учитывать нулевой байт на конце).
           if(buff[buff_size - 1] == 0 && !strcmp(buff,"s3cr8tpw"))
           {
                success = 1;
           }
           if(success) // TrapC blocked strcpy overwrite, success good
           {
                printf("Welcome!\n");
           }
           return !success;
   }
   // trapc_ptr.c
   int main()
   {
           const char* ptr = "Hello World";
           // Тут просто меняем while на for (хотя лучше завести отдельную переменную для итерирования).
           for(; *ptr; ptr++)
           {
                printf("%c",*ptr);
           }
           return 0;
   }
   // trapc_array.c
   int score[10];
   for (int i = 0; ; i++) {
        printf("%d", i);
        if (i == INT_MAX) break; // Переписываем цикл, вынося условие сюда.
   }

Ответить | Правка | Наверх | Cообщить модератору

168. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Ivan_83 (ok), 14-Ноя-24, 02:31

> const size_t buff_size = 8; // Зададим размер буфера тут, чисто чтобы не пользоваться sizeof(buff) везде.
По мне sizeof(buff) удобнее константы.
Хотя вероятно машинный код будет идентичный.

> strncpy(buff, argv[1], buff_size);
А кто будет проверять что argc >= 1?)

Ответить | Правка | Наверх | Cообщить модератору

188. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 15-Ноя-24, 18:42

> По мне sizeof(buff) удобнее константы.
> Хотя вероятно машинный код будет идентичный.
sizeof(buff) лучше приучиться просто не юзать - грабельная конструкция, и если там не char был, на этом можно налететь при случае. Даже если вот конкретно тут оно и катит.
>> strncpy(buff, argv[1], buff_size);
> А кто будет проверять что argc >= 1?)
Да, дорогой Додо, если вам такой втык делает Ivan_83 известный своим пофигизмом на все, вы таки - конкретно облажались.

Ответить | Правка | Наверх | Cообщить модератору

190. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Ivan_83 (ok), 15-Ноя-24, 23:37

Мой пофигизм обычно кончается после того как PoC начал работать :)
И на самом деле в моём коде скорее наоборот избыточно много проверок входных аргументов.
В этом плане я не согласен с теми же гномерами которые предпочитают падать по раньше на ошибках.

Насчёт sizeof() - с ней всё нормально пока в объявлении переменной не добавят * или не уберут.
Я в целом считаю что это не проблема, потому что заменяя тип переменной пограмит должен убедится что оно не только собирается но и что переменная везде корректно используется.
И на самом деле я просто не люблю объявлять константы в функциях, у меня как правильно и без этого там куча переменных.

Ответить | Правка | Наверх | Cообщить модератору

191. "Проект TrapC развивает Си-подобный язык, безопасно..." +/–

Сообщение от arisu (ok), 15-Ноя-24, 23:40

> И на самом деле я просто не люблю объявлять константы в функциях,
> у меня как правильно и без этого там куча переменных.
ой вэй!

Ответить | Правка | Наверх | Cообщить модератору

110. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от YetAnotherOnanym (ok), 13-Ноя-24, 10:25

> Вызовы free и delete отсутствуют
Ну и зря.

Ответить | Правка | Наверх | Cообщить модератору

184. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от LinupsCrashGitz (ok), 15-Ноя-24, 11:23

Нет памяти - нет проблем

Ответить | Правка | Наверх | Cообщить модератору

120. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –3 +/–

Сообщение от X86 (ok), 13-Ноя-24, 11:26

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

Ответить | Правка | Наверх | Cообщить модератору

126. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (124), 13-Ноя-24, 12:36

>Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать)
Да, такие бинари, что всякие NSA курят в сторонке.

Ответить | Правка | Наверх | Cообщить модератору

131. Скрыто модератором +/–

Сообщение от Аноним (131), 13-Ноя-24, 13:23

> Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать)
- Джинн, сделай мне ЗБС!
- (дымяшаяся воронка на этом месте)
- Во, теперь - ЗБС!

Ответить | Правка | К родителю #120 | Наверх | Cообщить модератору

125. Скрыто модератором –1 +/–

Сообщение от Аноним (-), 13-Ноя-24, 12:25

Хм.. в последнее время что плюсовики, что сишники стали проявлять подозрительную активность.
Начали рассказывать про важность безопасности, на которую успешно забивали десятки лет.
Возможно что-то случилось?
ИМХО не взлетит по нескольким причинам:
1. ЧСВ большинства СИшников не позволит признать, что они пишут овнокод
2. Дидам придется учится, а они это не любят
3. Эту лабуду будут пытаться вносить в стандарт и я на 99% уверен, что не внесут. А стандарт это один из золотых идолов любителей дыряшки "язык без стандарта - отстой" каким бы отстойным не был сам ʼстандартʼ.
4. Даже если оно попадет в стандарт, то это займет лет 5-6 заседаний комитета и еще столько же пока появится в компиляторах

Ответить | Правка | Наверх | Cообщить модератору

127. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Алексей (??), 13-Ноя-24, 12:40

Проект конечно странный. Какие цели он проследует не понятно. По итогу это новый язык программирования с максимально похожим синтаксисом к C. И созданием данного языка они якобы решают проблему с памятью. Но в таком случае почему бы не пойти дальше улучшить в C еще что нибудь (и получить новый Zig, GO, V lang и тд и тп)?! Ведь по сути я не смогу взять TrapC и скомпилировать (без пердолинга) на нем кучу кода C получив при этом безопасные программы (а вот Fil-C вполне себе позволить это сделать хоть и в ущерб скорости)! Отсюда возникает вопрос: какая аудитория будет пользовался данным языком?! Трушные C/C++?! Так они не боятся утечек памяти и переполнения буфера и не будут переходить на TrapC. Всякие кому нравится C подобный синтаксис?! Так есть же 100500 C подобных языков без проблем с памятью (всякие Zig, Swift и тд и тп). Получается что они создают язык для себя чисто по фану. Ну, может конечно еще кто обзарится! Можно только пожелать им удачи в их трудном но интересном занятии.

Ответить | Правка | Наверх | Cообщить модератору

129. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +2 +/–

Сообщение от Аноним (129), 13-Ноя-24, 13:03

Зиг улучшил так улучшил, даже многострочные комменты вырезали

Ответить | Правка | Наверх | Cообщить модератору

146. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от anonimous (?), 13-Ноя-24, 17:54

Цель понятная и они не не скрывают - найти инвесторов. Спрос есть? Будет и предложение!

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

128. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (129), 13-Ноя-24, 13:02

Стыдно признаваться будет, что используешь язык с таким названием

Ответить | Правка | Наверх | Cообщить модератору

137. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (133), 13-Ноя-24, 15:16

Вы свои проблемы из Java не тащите.
Всем давно известно корреляция обратная.

Ответить | Правка | Наверх | Cообщить модератору

147. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +4 +/–

Сообщение от Аноним (147), 13-Ноя-24, 18:00

Кстати, интересная видеопрезентация, посмотрите кто не смотрел.

Ответить | Правка | Наверх | Cообщить модератору

151. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." –1 +/–

Сообщение от Аноним (-), 13-Ноя-24, 18:22

Есть безопасный диалект чистого Си, называется Cyclone. Последний стабильный релиз вышел в 2006 году. Диалект разрабатывали в стенах AT&T labs.
Разработчики TrapC велосипедят? Если уж на то пошло, взяли бы готовые наработки "Циклона".

Ответить | Правка | Наверх | Cообщить модератору

159. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (156), 13-Ноя-24, 21:18

>Как именно достигается подобная защита не поясняется.
Можно расходится, чуда не будет

Ответить | Правка | Наверх | Cообщить модератору

160. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (156), 13-Ноя-24, 21:19

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

Ответить | Правка | Наверх | Cообщить модератору

163. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (163), 13-Ноя-24, 22:55

Чем его РуСи Терехова не устроил?

Ответить | Правка | Наверх | Cообщить модератору

166. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от _kp (ok), 13-Ноя-24, 23:42

>>Вместо malloc .. new.. за освобождение памяти отвечает компилятор
Не понял шутку, типа еще на этапе компиляции виднее когда объект не будет нужен.
Тут, или не будет работать, или не освобождается память.
Более иого,даже со сборщиком мусора, ну не верится что оно будет предвидеть возникающие события, при которых надо освободить объект ;)
В остальном все хорошо.
Да, понятно, что рантайм должен быть напичкан проверками, ибо на этапе компиляции все не проверить.
Но ведь и не обязательно всё писать на этом.
И изюминка на торте...
А зачем Си, почему не С++?
Что то низкоуровневое или высокопроизводительное все равно писать на обычных C и С++, а для более высокоуровнего кода С++ удобней.

Ответить | Правка | Наверх | Cообщить модератору

178. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Аноним (-), 14-Ноя-24, 17:57

>А зачем Си, почему не С++?
Ну так ты сам пиши на плюсах! Зачем других агитируешь-то?

Ответить | Правка | Наверх | Cообщить модератору

167. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +1 +/–

Сообщение от Ivan_83 (ok), 14-Ноя-24, 02:28

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

> Вызовы free и delete отсутствуют, а за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти.
И откуда компелятору знать нужна мне эта память или уже нет?
Типа ссылки по указателям посчитать? - так а мне потом бегать всё занулять чтобы он память освободил?

Странное в общем оно.

Ответить | Правка | Наверх | Cообщить модератору

189. "Проект TrapC развивает Си-подобный язык, безопасно работающи..." +/–

Сообщение от Аноним (-), 15-Ноя-24, 18:46

> И откуда компелятору знать нужна мне эта память или уже нет?
А посмотри как боров-чекер например работает. Некоторые плюсеры смогли посмотрев на это все и довольно сравнимую логику и на плюсах местами захреначить.
> Странное в общем оно.
В этом мире есть много странного. Это не значит что оно непременно плохое.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

53. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+10 +/–
Сообщение от solardiz (ok), 13-Ноя-24, 02:14
Спросил автора Fil-C об отличиях проектов, вот его ответы: https://x.com/solardiz/status/1856433226849628551 Filip Jerzy Pizło @filpizlo The presentation is light on hardcore details and only has super simple examples, while Fil-C can run real big stuff (CPython, OpenSSH, etc). So, it’s not clear how it compares. Worth noting Fil-C is freely available today rather than sometime in the future! The article says it’s a fork of the language and for example doesn’t allow unions at all. So, I think the biggest difference is that TrapC really is a different language. Fil-C, on the other hand, is just C (and unions are allowed, and they’re made safe).
Ответить \| Правка \| Наверх \| Cообщить модератору


	81. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+3 +/–
	Сообщение от Аноним (-), 13-Ноя-24, 08:16
	> Спросил автора Fil-C об отличиях проектов, вот его ответы: А можете еще спросить... 1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию, в том числе в препроцессоре, для избежания UB/vuln/кучи багов от "не того размера" int который себе представлял програмер? В хрусте очень правильно это сделали, имхо. И в C99 тоже, но пороху нормально сделать не хватило. И препроцессор например - грабель кусок. А 1, 1U, 1UL, и 1ULL это 4 довольно разные вещи. 2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам. 3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен - мало того что хрен знает какого он типа, так еще если тип переменной enum, реально на вход функции можно любую труху давать - и как бы все ок. 4) Покажите ему MISRA C и Embedded C Coding standard. Может часть из этого стоило бы взять в оборот?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	92. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+1 +/–
	Сообщение от Жироватт (ok), 13-Ноя-24, 09:06
	> 1) Не хочет ли он нормальные типы с конкретными битностями по умолчанию, Тогда уж для всех платформ унифицировать примитивные типы по длине. А не как в стандарте и реализациях: для 32х бит int у нас 4 байта, для 64х бит int может быть как скрытой макрозаменой для int64 (8 байт), так и для int32 (4 байта), так и для int16 (2 байта), так и отдельным типом, который при флаге "--собирай-х64" неявно подставляется в таблицу символов и по нему уже выделяет память. > 2) Может, запретить к хренам signed как индекс массивов? Отрицательные индексы - ведут чаще всего к залетам. +1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы для тех же координат. > 3) Как насчет ЭНФОРСА (желательно компилтайм) значений в enum и bool? Сейчас enum совершенно бесполезен А разве энум не специально создавался, как котёл с единым адресом для разных программно, но единых с точки зрения логики предметной области, данных? Примерно как Бул? А зачем тащить в С бул, если уже написано куча BOOL-макросов и пользовательских структур?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	107. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 13-Ноя-24, 10:16
	> Тогда уж для всех платформ унифицировать примитивные типы по длине. Ну так uint8_t из (>= C99) и аналогичных плюсов - везде и должен быть 8 битов ака 1 байт. И uint64_t - именно 64 бита а не что-то еще. И это было бы прекрасно. Но тут на сцену выходит препроцессор. В котором тоже есть математика. И даже можно им делать вычисления. А теперь попробуйте угадать какие там разрядности и что оно РЕАЛЬНО будет делать. Это же касается инициализаторов переменных. Особенно опосля препроцессора. А с enum вообще мрак. Какой у него формально тип - да Ктулху бы его знает! Более того - никаких проверок что на вход функции хотевшей enum дали ессно нет. Пример: typedef my_t enum { VAL1 = 1, VAL2 = 2; } my_t; void something(my_t input) { ... } something(VAL1); // valid something(VAL2); // valid something(10); // WTF but who cares?! > А не как в стандарте и реализациях: для 32х бит int у нас > 4 байта, для 64х бит int может быть как скрытой макрозаменой > для int64 (8 байт) Ну так я про то и говорю. Вон то ведет к множеству залетов при портировани кода. Поэтому те кому важна стабильность, качество и безопасность, предсказуемые доступы и проч, скажем фирмвары мк и проч - юзают типы конкретного размера. Но вооооон то добро в препроцессоре и рядом - активно мешается на этом пути. Да, представляете конструкции типа (1 << 30), (1 << 61) и проч - выглядит вроде безобидно, но является куском грабель. С топоорм на ручке. > +1 шаг - отмаппить реальный диапазон массива на "безопасный" [0; N], что > иногда неприемлемо с точки зрения оптимизации и понимания кода. Хотя бы > для тех же координат. Компилер сам может прекрасно оптимизнуть такие вещи. А дереференс левых bounds это такая очень характерная трабла сей. Я тут как-то рефакторил старый код, который при определенном input радостно уходил в минуса по индексу и радостно телепал там хзчто в оперативе. При том это remotely triggerable было. Круто, да? > А разве энум не специально создавался, как котёл с единым адресом для > разных программно, но единых с точки зрения логики предметной области, данных? Выше характерный пример enum. Где он как бы есть, но реально - толку с него фиг. кто такой something(10) этом выражении? Была бы чуть менее тупая система типов - и компилер бы ЭТО поймал. Спросив что есть something(10) когда в том enum никогда не было задано число 10 и это явно невалидный вызов. Ибо callee имеет все основания ожидать только значения из того enum'а, согласно такой декларации, но сие никак не форсится. И это глупо - все инфо для этого в декларации есть. Если нечто рантайм-вычисляемо и в компиле не удается просчитать, сделать квалификатор типа constexpr'а, которым можно затребовать компилтайм просчет и фэйл если это не удалось. > Бул? А зачем тащить в С бул, если уже написано куча BOOL-макросов > и пользовательских структур? В сях и так есть bool. Хотя в C23 его выпилили в пользу bit-exact, так что пристегните ремни. Зачем нужно? uint8_t my_var = 255 + 1; bool my_var2 = 255 + 1; if (my_var) .. // Вероятно програмер хотел сюда. else ... // А вы точно ожидали оказаться ТУТ булевской логикой? if (my_var2) .. // А вот тут все нормально else ... (и все назначения крупнее 1 насколько я помню обрубаются до 1)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	116. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+1 +/–
	Сообщение от Жироватт (ok), 13-Ноя-24, 11:02
	А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну, попутал с union, бывает, давно не работал. Ну тогда да.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	121. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (121), 13-Ноя-24, 11:41
	> А, понял. Ты про статическую проверку выборки индекса поля в enum'е. Ну, > попутал с union, бывает, давно не работал. Ну тогда да. Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом". В случае сишника - ну я б еще понял struct и union перепутать (весьма чревато, как в анекдоте), но вот с enum - как?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	132. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+2 +/–
	Сообщение от Жироватт (ok), 13-Ноя-24, 14:57
	> Это как в том анекдоте - "и упаси тебя перепутать хиппи с толкиенистом". Утро, кофе еще не до конца пошло по венам, разнося живительные молекулы по организму
	Ответить \| Правка \| Наверх \| Cообщить модератору


	195. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (195), 18-Ноя-24, 02:31
	У вас какие то придирки причём к основам Сей... трешу вроже "bool my_var2 = 255 + 1;" - мето на помойке и язык тут не причём, - пишите с "bool my_var2 = (255 + 1)!=0;" и сразу видно что делает код. "enum" это константы для типа int, их (пусть не такой как вам бы хотелось)смысл - быть заменой #define'ам которые типчино именуются заглавными что не всегда наглядно хоть и терпимо, но как и те - знанения должны суммироваться для применения в качестве битмасок. Если этого не будет это уже будет не Си. Впрочем, раз выкинуты free в subj'е - всёравно лже-Си....
	Ответить \| Правка \| К родителю #107 \| Наверх \| Cообщить модератору


	100. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+1 +/–
	Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 09:34
	Вроде с типом enum в C23 решили вопрос, можно задавать его базовый тип: enum E1 : short { m11, m12 }; или Вы про другое?
	Ответить \| Правка \| К родителю #81 \| Наверх \| Cообщить модератору


	108. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+2 +/–
	Сообщение от Аноним (-), 13-Ноя-24, 10:21
	> Вроде с типом enum в C23 решили вопрос, можно задавать его базовый > тип: > enum E1 : short { m11, m12 }; Это уже чуть лучше чем было - но... > или Вы про другое? ... я таки про - несколько другое. См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет. При том в сорце ЕСТЬ все аннотации намерений. И _можно_ определить в компилтайме что something(10) это нечто совершенно левое. Но нет. В лучшем случае это отловит какой-нибудь сильно отдельный статический анализатор.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	142. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Совершенно другой аноним (?), 13-Ноя-24, 17:17
	> См выше пример с функцией получающей на вход enum, но реально можно вызвать something(10) коего в enum нет. Да, согласен с Вами этого сильно не хватает. В C++ попытались решить эту проблему введя enum class, но в C, пока, на эту тему подвижек нет.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	169. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+1 +/–
	Сообщение от Аноним (-), 14-Ноя-24, 07:52
	> Да, согласен с Вами этого сильно не хватает. В C++ попытались решить > эту проблему введя enum class, но в C, пока, на эту > тему подвижек нет. Ну я и не понимаю - в чем прикол сделать перечисляемый тип, но вообще совсем никаких проверок не сделать, никак и нигде как mandatory в стандарте? Ведь 90% фичи - как бы есть. Но без остальных 10% толку то с нее такой? Гряблями по морде получить лишний раз? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	175. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (175), 14-Ноя-24, 13:57
	enum это способ задать константу 100% без выделения памяти.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	176. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (176), 14-Ноя-24, 16:40
	> enum это способ задать константу 100% без выделения памяти. Так ее можно и #define задать например. И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO вообще может иметь очень сильно свое мнение на этот счет. Сделав с кодом такое что вам и не снилось.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	181. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 14-Ноя-24, 21:52
	> И даже в случае const - ниоткуда не следует что новая декларация ведет к новой аллокации. Какой-нибудь LTO Это он сейчас может, а когда C разрабатывался, const переменная означала статически выделенную память под эту переменную. Плюс const это всё же иное. Например, const обладает адресом. Const переменная рассматривается компилятором как lvalue, он может запрещать присвоение такому lvalue, но ты сам посмотри, он генерирует ошибки с другим текстом. Плюс эти запреты не столь строгие, и их можно обойти при желании. > Так ее можно и #define задать например. Можно, но enum во-первых убедиться, что у тебя нет дублирующихся констант, во-вторых он позволяет не указывать значения, если они у тебя последовательно идут или если тебе глубоко плевать, что это за значения, лишь бы они были разные.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	186. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 15-Ноя-24, 18:26
	> Это он сейчас может, а когда C разрабатывался, const переменная означала статически > выделенную память под эту переменную. Это опять же нигде жестко не требуется в стандарте, насколько я понимаю. И если константа где-то хоть как-то реально в коде юзается, де факто где-то в коде будет как минимум что-то типа mov r5, #CONST или что там у кого. И это где-то ессно хранится. Исключение разве что всякие unused (на которые нынче вообще warning модно давать) и compile-time штуки, типа условной компиляции. А реально LTO может вспомнить что 2 кило назад, он уже вон то сделал, в условном r5 до сих пор это - так что можно реюзануть. Сделав для вгрузки константы - ровно ничего. Так в коде и данных может оказаться меньше чем де факто задекларено. Если абстракции удержатся. > Плюс const это всё же иное. > Например, const обладает адресом. Теоретически - да. Практически - зависит от того смотрит ли на этот адрес хоть кто-то. Потому что если не смотрит, LTO может вообще лихо вообще скажем всю таблицу векторов прерываний выпилить. В софте usage не видно же?! А то что железо ее там вызывало... откуда ему знать? И такое может потребоваться явно костылять. > генерирует ошибки с другим текстом. Плюс эти запреты не столь строгие, > и их можно обойти при желании. Через указатели можно попробовать. Но что будет в результате большой вопрос. Если это МК и оно чисто технически в флеше лежит, ибо RODATA - ну вы поняли. Не, такое вы не обойдете. >> Так ее можно и #define задать например. > Можно, но enum во-первых убедиться, что у тебя нет дублирующихся констант, С #define нынче есть варнинги на redefined если оно надо. > во-вторых он позволяет не указывать значения, если они у тебя последовательно идут > или если тебе глубоко плевать, что это за значения, лишь бы > они были разные. Это все прекрасно, но весьма тупое использование перечисляемого типа. Когда все аннотации намерений есть - можно было бы и регламентировать что something(10) из того примера - левак и фу таким быть. На уровне стандарта. Потому что указан тип операнда my_t который enum, и он не содержит 10, вот хоть как.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	182. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 14-Ноя-24, 22:03
	Та эта довольно просто. Если ты задумаешься как можно сделать не 90% фичи, а 100% фичи, то ты увидишь, что оставшиеся 10% сложнее первых 90%. Можно отгрызть 5% добавив статических проверок значений, которые кладутся в переменные типа enum, но это сработает только для случаев, когда статически известно, что кладётся недопустимое значение. А в случаях когда это неизвестно, что делать? Добавлять рантайм проверки? Допустим, но и что делать, если рантайм проверка провалилась? И одоление этих остающихся 5% потребует принятия спорных решений, например паник в рантайме, если в enum кладётся недопустимое значение. Или, например, добавление к каждому enum'у специального значения DefaultValue (или может его лучше назвать InvalidValue?) которое будет класться в enum вместо любого недопустимого значения. Придётся какие-то костыли изобретать. > Ну и я и не понимаю - в чем прикол сделать перечисляемый тип Я в школе не понимал в чём прикол enumeration в паскале. В C ты просто даёшь названия интересующим тебя int'ам, и потом работаешь с ними как с int'ами. Это делает код читаемее не создавая ненужных сложностей. В паскале же какие-то кошмарные сложности преобразовать значение enumeration в integer и обратно. Ну и я не понимал зачем такие enumeration нужны, когда проще насоздавать констант.
	Ответить \| Правка \| К родителю #169 \| Наверх \| Cообщить модератору


	183. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 15-Ноя-24, 01:38
	> Та эта довольно просто. Если ты задумаешься как можно сделать не 90% фичи, а 100% фичи, то ты увидишь, что оставшиеся 10% сложнее первых 90%. > Можно отгрызть 5% добавив статических проверок значений, ... Но это не значит что не нужно делать ничего) Это как с дорогой - сделали ровный асфальт -10% аварий, поставили освещение еще -10%. Добавили разделительный отбойник - ну так вообще -20%. > Придётся какие-то костыли изобретать. Неа, они уже изобретены. Типа UB и прочих приколов. > В C ты просто даёшь названия интересующим тебя int'ам, и потом работаешь с ними как с int'ами. Это делает код читаемее не создавая ненужных сложностей. А потом кто-то создает enum Warm и второй enum Soft. И.. легко и непринужденно сравнивает "теплое с мягким". А языку вообще пофиг что там - это же все инты. > В паскале же какие-то кошмарные сложности преобразовать значение enumeration в integer и обратно. Ну и я не понимал зачем такие enumeration нужны, когда проще насоздавать констант. Потому что идея был возможно неплохой, а реализация - не самой удачной. В новых языках это уже исправили - тут тебе и проверки "типа" енама, и patternMatching, и прочие блага цивилизации.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	187. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+/–
	Сообщение от Аноним (-), 15-Ноя-24, 18:36
	> А потом кто-то создает enum Warm и второй enum Soft. > И.. легко и непринужденно сравнивает "теплое с мягким". > А языку вообще пофиг что там - это же все инты. И это глупо. Ибо на разные enum можно даже разные typedef навесить - но даже это не особо поможет. При желании конечно частично лечится. Скажем юзанием struct'ов. Вот тут уже typedef будет работать так как ожидается, и зарубит подсовывания Warm в функцию хотевшую тип Soft. Но для вот именно того это уже нехилая сова на глобус - и нет гарантий отсутствия явно левых значений на входе и отлова этого в компилтайм, даже там где точно можно было. > Потому что идея был возможно неплохой, а реализация - не самой удачной. Паскаль вообще довольно активно делает мозг при попытке на нем что-то практическое програмить. Одна из причин по которой его не любят. Ну может кроме дельфи. Но вся его занудность не помогает ему в результате от "unhandled exception" и каких там еще прелестей - при том в рантайме. И это как бы фэйл, так делать мозг, чтобы потом в рантайме все равно фигню творить. А зачем тогда все эти мучения были?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	192. "Проект TrapC развивает Си-подобный язык, безопасно..."	+/–
	Сообщение от arisu (ok), 15-Ноя-24, 23:49
	затем, что виртовские языки не защищают от идиота. чтобы защитить от идиота — надо идиота просто не допускать к программированию. а виртовские языки защищают не-идиота от случайных, непреднамеренных ошибок. один из видов защиты — трапнуться в рантайме, если обнаружено что-то не то. да и с мозгом паскаль ничего такого не делает. просто предполагает программиста, а не кодира. кодиры, конечно, стонут и убегают.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	196. "Проект TrapC развивает Си-подобный язык, безопасно..."	+/–
	Сообщение от Аноним (195), 18-Ноя-24, 02:56
	И тут какая то ахинея: особой разницы между ними нет же в мышлении (как скажем с Java), фишка что Си, что Pascal, - в "всё ради скорости, кто натупил - сам виноват, а не синтаксис! мы вас предупредили, лентяи [внимательно] читать документацию..."
	Ответить \| Правка \| Наверх \| Cообщить модератору

2. "Проект TrapC развивает Си-подобный язык, безопасно работающи..."	+1 +/–
Сообщение от nc (ok), 12-Ноя-24, 23:01
Самое главное непонятно - в чем именно заключается "фундаментально иной способ работы с указателями и специальный механизм обработки ошибок". Жирные указатели как в Cyclone?
Ответить \| Правка \| Наверх \| Cообщить модератору


	77. Скрыто модератором	+3 +/–
	Сообщение от помпезный (?), 13-Ноя-24, 07:37
	Ворованные санитайзеры, судя по всему. Как и всё остальное - уже имеется в гцц.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. Скрыто модератором	+/–
	Сообщение от Аноним (84), 13-Ноя-24, 08:50
	"Ворованные санитайзеры" - что за санитайзеры такие? Где почитать? Поисковик вразумительного не даёт.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	96. Скрыто модератором	+2 +/–
	Сообщение от помпезный (?), 13-Ноя-24, 09:14
	Можешь загуглить по -fsanitize флажку компилятора.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. Скрыто модератором	+/–
	Сообщение от Аноним (-), 13-Ноя-24, 08:57
	> Ворованные санитайзеры, судя по всему. Как и всё остальное - уже имеется в гцц. Как украсть санитайзер? И зачем все это делать? :)
	Ответить \| Правка \| К родителю #77 \| Наверх \| Cообщить модератору


	98. Скрыто модератором	+1 +/–
	Сообщение от помпезный (?), 13-Ноя-24, 09:16
	Также, как и компилятор. Можешь посмотреть как раст ворует ллвм. Хотя судя по твоим вопросам ты как раз агитатор подобного "подхода".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	109. Скрыто модератором	–2 +/–
	Сообщение от Аноним (-), 13-Ноя-24, 10:24
	> Также, как и компилятор. Можешь посмотреть как раст ворует ллвм. У него что, borrow checker - кредит вам не отдал? Экий он злодей! А так - я почему-то думал что либа кодогенерации нужна - чтоб ей пользоваться. Что хруст и делает :) А вон там gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое. И решили позаимствовать (borrow) из хруста вот прям next gen их боррова-чекера, который на хрусте же и написан. Это ведет к довольно забавным проблемам бутстрапа такого компилера, ибо надо собрать код на хрусте при том что хруста еще нет, но это решаемо.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	114. Скрыто модератором	+2 +/–
	Сообщение от помпезный (?), 13-Ноя-24, 10:35
	> А так - я почему-то думал что либа кодогенерации нужна - чтоб ей пользоваться. Что хруст и делает Агитатор путается в показаниях. Выше он спрашивал "зачем все это делать?", а теперь он оказывается уже знал зачем. > gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое Сообщил что можно своровать ещё и гцц. Молодец.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	122. Скрыто модератором	–1 +/–
	Сообщение от Аноним (-), 13-Ноя-24, 11:52
	> Агитатор путается в показаниях. Выше он спрашивал "зачем все это делать?", а > теперь он оказывается уже знал зачем. А за что я агитирую? Если за хруста - то я им пользоваться если и начну то не раньше чем его в gcc запилят в потребном виде (такой проект есть и довольно активно развивается). >> gccrs вообще сделал финт ушами и сообщил что в эту игру могут играть двое > Сообщил что можно своровать ещё и гцц. Молодец. Gccrc - это, так то, фронтэнд Rust для GCC. И его базовую часть уже в последний gcc даже вроде комитнули. Но у них был затык в том что borrow checker - довольно сложная штука и прогать его весьма канительно. С ним есть проблемы даже у хрустиков, о чем написано https://rust-lang.github.io/rfcs/2094-nll.html ибо их боров который здесь и сейчас порой рубит лишку и заставляет вбивать весьма забавные костыли чтобы вообще компилилось. В силу сложности действа авторы gccrs и приняли решение - утащить next-gen версию боров-чекера (она пишется на хрусте) к себе. Но т.к. это часть фронтэнда компилера, который они и делают - вопрос а как тогда GCCом самого себя собирать, если хруста еще нет, но надо уже собрать код на хрусте как часть фронтэнда - становится довольно интересным вопросом. Хоть и решаемым многофазным бутстрапом. Первая версия билдится без борова, билдит себе борова, и ребилдят всю тушку уже с боровом. И да, я уже несколько запутался кто у кого и что украл в результате в этой схеме? :)
	Ответить \| Правка \| Наверх \| Cообщить модератору