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

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

Сообщения

[Сортировка по ответам | RSS]

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

4. Сообщение от Аноним Анонимович Анонимов (?), 12-Ноя-24, 23:07	+10 +/–
На моей памяти это уже не первая попытка исправить, «оберткой», чужой, прямо скажем, говнокод. Челику бы вместо разработки очередного диалекта направить потуги в сторону будущего стандарта С, судя по новости он что-то в этом понимает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70, #133

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

9. Сообщение от ijuij (?), 12-Ноя-24, 23:19	+/–
Ну и зачем это? Уже пилят Safe C++: https://safecpp.org/
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #66, #194

13. Сообщение от Аноним (13), 12-Ноя-24, 23:27	–4 +/–
Rust на минималках.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #134

20. Сообщение от Аноним (20), 12-Ноя-24, 23:57	–1 +/–
В свифте сделали же автоматическое управление памятью без гц. И никаких боровов чекать не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #30, #156

30. Сообщение от Аноним (30), 13-Ноя-24, 00:29	+1 +/–
> В свифте сделали же автоматическое управление памятью без гц. Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках) объявили "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ообщить модератору
Родитель: #20 Ответы: #49, #79, #88

32. Сообщение от Аноним (32), 13-Ноя-24, 00:32	+6 +/–
"Answers the call from NSA, white house, fbi..." Яснопонятно. Это кого надо инициатива, дед тут как Линус с Столманом - для ширмы
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #48, #135

36. Сообщение от Аноним (36), 13-Ноя-24, 00:38	–1 +/–
Будет смешно, если из-за академичности и известности автора все эти zig и им подобные выставят на мороз и будут забыты.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #51, #73, #118

37. Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 00:41	+4 +/–
> академичности Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу. >  и известности Настолько известный, что пришлось писать кто он и чем занимался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #60

48. Сообщение от нах. (?), 13-Ноя-24, 01:13	–2 +/–
А, знач - хорошие сапоги, надо брать!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32 Ответы: #87

49. Сообщение от Аноним (49), 13-Ноя-24, 01:48	+2 +/–
Ну так в C++ тоже есть shared_ptr который делает то же самое. И никто не говорит что это GC. В р@сте тот же самый подход есть, аналог плюсовых shared_ptr и unique_ptr.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #161

51. Сообщение от Вася Пупкин (?), 13-Ноя-24, 01:51	+/–
В языке сейчас важно сообщество и экосистема, не считая корневой идеи где он может быть удобно применен. Синтаксис и имя автора лишь могут немного поспособсвовать их становлению.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #97

52. Сообщение от htmldevelob (?), 13-Ноя-24, 01:51	+1 +/–
а вообще по теме мне кто то может пояснить что за вечная проблема с памятью ? в си и си++ и наверно в ассемблере нету такой проблемы ? а если есть может кто то тогда ассемблер сделает получше?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #58, #119, #171

53. Сообщение от solardiz (ok), 13-Ноя-24, 02:14	+11 +/–
Спросил автора 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

58. Сообщение от Йцукенг (?), 13-Ноя-24, 03:00	+4 +/–
Просто прочитайте, что такое переполнение буфера, висячие указатели, переполнение стека. Программы на Си, на Си++ и, тем более, на ассемблерных языках имеют такие проблемы. Для борьбы с ними программист, который пишет на этих языках, должен вручную прописывать в коде дополнительные проверки и очень хорошо понимать, как его программа будет работать с памятью. И он должен нигде не ошибиться. Это трудно. В других языках такие проверки и работу с памятью обеспечивают компиляторы. Но тогда, обычно, эти языки ограничивают программиста в работе на низком уровне и плохо подходят для написания системных программ, в которых нужно работать напрямую с ячейками памяти. Про безопасные ассемлерные языки: В начале 2000-х был создан язык Сиклон (Cyclone), в котором часть проблем языка Си была устранена. Некоторые из авторов Сиклона участвовали также в работе над типизированным ассемблером TAL — Typed Assembly Language. Информация в сети есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #78

60. Сообщение от HyC (?), 13-Ноя-24, 03:16	+2 +/–
> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу. И все как на подбор кривые как турецкий ятаган.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #67

61. Сообщение от Аноним (61), 13-Ноя-24, 03:17	–1 +/–
> бывший профессор компьютерных наук что за ...?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #75, #83

66. Сообщение от Аноним (66), 13-Ноя-24, 04:48	+14 +/–
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ообщить модератору
Родитель: #9 Ответы: #89

67. Сообщение от Вы забыли заполнить поле Name (?), 13-Ноя-24, 04:53	+/–
>> Aкадемка обычно к успеху обычно не приходит. Из более-менее используемого ocaml. Всякие си, питоны и жс простите не из академки ни разу. > И все как на подбор кривые как турецкий ятаган. Чтож поделать. Взлетает почему-то именно такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #91, #95, #208

69. Сообщение от Аноним (69), 13-Ноя-24, 05:33	+1 +/–
Вообще интересно, но пока ещё сыро и не опенсорс.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80, #140

70. Сообщение от Bottle (?), 13-Ноя-24, 06:09	+9 +/–
Зная говноделов в комитете, этот стандарт будут внедрять ещё один десяток лет, а софт нужно писать уже сейчас. К тому же, обязательно напишут про implementation-defined behaviour. Т.е. стандарт опять окажется нерабочим дерьмом из разряда "А вот тут как хотите так и делайте. Кроссплатформенная арифметика? Нет, не слышали".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

73. Сообщение от Аноним (73), 13-Ноя-24, 07:17	+/–
Ну если предположить, что Си не из академки, то впоследствии стал использоваться академкой и много чего академического на нем было написано. Так что можно считать, что Си - академка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #82, #124

75. Сообщение от Аноним (78), 13-Ноя-24, 07:23	+2 +/–
Карабас-Барабас - профессор кукольных наук. Всё нормально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61

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

78. Сообщение от Аноним (78), 13-Ноя-24, 07:39	–4 +/–
> В других языках такие проверки и работу с памятью обеспечивают компиляторы. Вы давно не программировали? Я пользуюсь g++. Он многие из таких ошибок отслеживает. >  Но тогда, обычно, эти языки ограничивают программиста в работе на низком уровне и плохо подходят для написания системных программ, в которых нужно работать напрямую с ячейками памяти. Это верно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #158

79. Сообщение от Пользователь (?), 13-Ноя-24, 07:59	+1 +/–
Как выше указали, ARC это подобие shared_ptr от Apple, в целом никакой магии. Стоит отметить что в Swift активно агитируют использовать структуры везде где только можно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

80. Сообщение от КО (?), 13-Ноя-24, 08:11	+1 +/–
Пока сыро - это всё состояние опенсорса, так что вполне подходит
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #105

81. Сообщение от Аноним (-), 13-Ноя-24, 08:16	+3 +/–
> Спросил автора 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ообщить модератору
Родитель: #53 Ответы: #92, #100

82. Сообщение от Жироватт (ok), 13-Ноя-24, 08:26	+/–
Удобно перехватил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

83. Сообщение от Жироватт (ok), 13-Ноя-24, 08:29	+2 +/–
Помнишь такого вот кривого доцента с кафедры АСУП, САПР или ВТ? Который в жизни не написал ничего реально применимого, но очень гордящегося своим алгоритмом подсчёта синуса от количества усов на морде среднестатистического кота? Такое же, только англоязычное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #101

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

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

87. Сообщение от Аноним (84), 13-Ноя-24, 08:58	+/–
Сапоги от NSA - лучше сапоги! PS А от отечественного тащ майора ещё лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

88. Сообщение от Аноним (-), 13-Ноя-24, 08:59	+/–
>> В свифте сделали же автоматическое управление памятью без гц. > Сделали, ага. Просто поменяли терминологию и (громко, во всех форумах и теле-инстаграмчиках) > объявили "ARC - это не GC, вот!" Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #162

89. Сообщение от Аноним (-), 13-Ноя-24, 09:01	+11 +/–
> 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ообщить модератору
Родитель: #66

91. Сообщение от Аноним (-), 13-Ноя-24, 09:04	+/–
> Чтож поделать. Взлетает почему-то именно такое. Потому что делать что-то практическое на академхрености получается где-то в интервале от неудобно до жутко назойливо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

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

95. Сообщение от Анониссимус (?), 13-Ноя-24, 09:13	–1 +/–
Во-первых, миллионы мух. А во-вторых, уж очень велик соблазн взять что-то из пары костылей, скреплённых дерьмом, но которое работает здесь и сейчас, вместо того чтобы доделывать более качественное решение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

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

97. Сообщение от Анониссимус (?), 13-Ноя-24, 09:16	+/–
Самое важое в любом языке -- это количество библиотек, которые можно использовать. Если там действительно можно использовать си-либы без всяких проблем, то пользоваться этим можно будет и с минимальным сообществом и экосистемой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

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

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

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

101. Сообщение от eugene_martein (ok), 13-Ноя-24, 09:36	+/–
Типа, как Зуев, который один год писал синтаксическое AST-дерево для несостоявшегося отечественного компилятора C++ в 90-ых, но получил такую психотравму, что по сей день орёт, что отечественный компилятор есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #115

102. Сообщение от Данные в так называемом поле Name (?), 13-Ноя-24, 09:39	+2 +/–
Я когда был маленький, мне казалось что мир информационных технологий огромен. Казалось, что на каждую, даже самую бредовую репу найдётся орда энтузиастов. Сейчас мнение поменял на прямо противоположное. Индустрия едет по рельсам, которые прокладывают некоторые сверх богатые компании. Смотрю как Oracle пыхтит пытаясь жабу тащить и как ему не хватает силёнок, чего уж говорить об энтузиастах? Короче, не знаю на что рассчитывает "бывший профессор", но безумству храбрых поём мы славу!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #111, #157

103. Сообщение от Аноним (103), 13-Ноя-24, 09:53	+2 +/–
А зачем тогда вообще Си? Открою секрет. Си изобрели, чтобы на ассемблере не писать. Еще тогда если вы хотели не скорости и компактности, а надежности и безопасности - могли писать на басике или паскале.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #141

105. Сообщение от Аноним (78), 13-Ноя-24, 09:59	+/–
> Пока сыро - это всё состояние опенсорса, так что вполне подходит Неочевидно. GCC - опенсорс, но не сыро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

106. Сообщение от Додо (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

107. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #92 Ответы: #116, #195

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

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

110. Сообщение от YetAnotherOnanym (ok), 13-Ноя-24, 10:25	–1 +/–
> Вызовы free и delete отсутствуют Ну и зря.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #184

111. Сообщение от Аноним55 (?), 13-Ноя-24, 10:26	+/–
Увидел иронию в словах "бывший профессор". Но с другой стороны, когда в новом сезоне шоу под названием "университет", видимо для экономии средств, мне предложили из доцентов перейти в старшие преподаватели, наши пути в науке разошлись. Кто его знает, что там произошло.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102 Ответы: #170

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

115. Сообщение от Жироватт (ok), 13-Ноя-24, 10:57	+/–
Таких у нас вагон и полная тележка сверху. Не пониманию я этого наяривания на "академичность". Хотя зубров, вроде Кнута, стоит исключить, там где серьёзный стык высшей математики и алгоритмов - от них и от их изысканий есть реальная польза, но вот остальное...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #138

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

118. Сообщение от Аноним (118), 13-Ноя-24, 11:15	+/–
Известности ноль. И уже есть Carbon.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #136

119. Сообщение от Аноним (-), 13-Ноя-24, 11:20	+5 +/–
Основная проблема с памятью, что тебе надо дёрнуть 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 памяти хватало для всех, и пара однобайтовых инструкций, позволяющая временно освободить дефицитный регистр для чего-то, была очень полезна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

120. Сообщение от X86 (ok), 13-Ноя-24, 11:26	–3 +/–
Это все пустое. Еще пара лет и нейронки смогут сделать простой и более безопасный язык программирования, взяв лучшее из Питонов и Си, разработать к нему понятную документацию и т.д. Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #126, #131

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

122. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #114

124. Сообщение от Аноним (124), 13-Ноя-24, 12:20	+/–
>Так что можно считать, что Си - академка. Т.е. C взял академический отпуск... от академиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73

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

126. Сообщение от Аноним (124), 13-Ноя-24, 12:36	+/–
>Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать) Да, такие бинари, что всякие NSA курят в сторонке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

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

128. Сообщение от Аноним (129), 13-Ноя-24, 13:02	+/–
Стыдно признаваться будет, что используешь язык с таким названием
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #137

129. Сообщение от Аноним (129), 13-Ноя-24, 13:03	+2 +/–
Зиг улучшил так улучшил, даже многострочные комменты вырезали
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

131. Сообщение от Аноним (131), 13-Ноя-24, 13:23    Скрыто ботом-модератором	+/–
> Возможно, даже готовые бинари сразу из чатгпт можно будет скачивать) - Джинн, сделай мне ЗБС! - (дымяшаяся воронка на этом месте) - Во, теперь - ЗБС!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120

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

133. Сообщение от Аноним (133), 13-Ноя-24, 15:09	+1 +/–
Вроде всего третья попытка A, B+ и вот теперь C++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

134. Сообщение от Аноним (133), 13-Ноя-24, 15:10	–1 +/–
Совместимый по памяти и рантайму без этих всяких жужжаний про safe не safe
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

135. Сообщение от VladSh (?), 13-Ноя-24, 15:13	+/–
> // darpa_tractor.c DARPA...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

136. Сообщение от Аноним (133), 13-Ноя-24, 15:13	+/–
Carbon нихрена не собрать не затаoив половину Google к себе на домашний серверный шкаф из 40 серверов с дисковым массивом - шутка про Java и Gradle артефакты доставаемые гигабайтами какое-то невероятное зависимое говны. Пока они не освоят хотя бы CMake не о чем говорить
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #143

137. Сообщение от Аноним (133), 13-Ноя-24, 15:16	+/–
Вы свои проблемы из Java не тащите. Всем давно известно корреляция обратная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

138. Сообщение от Аноним (138), 13-Ноя-24, 15:49	+/–
> Не пониманию я этого наяривания на "академичность". Она нужна тем кто хочет быть "услышен", а за других говорят их "дела". > Хотя зубров, вроде Кнута, стоит исключить Говорят, математика это язык природы, просто словарь этого языка переполнен "словами паразитами" ввиде имен всяких "профессоров".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

140. Сообщение от Аноним (140), 13-Ноя-24, 16:11	+/–
Как говорится, ничто не вечно, ничто не закончено и ничто не совершенно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #145

141. Сообщение от Аноним (141), 13-Ноя-24, 16:28	–1 +/–
> Си изобрели, чтобы на ассемблере не писать Your computer is not a fast PDP-11
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #155

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

143. Сообщение от Аноним (143), 13-Ноя-24, 17:30	+/–
Релиз в 27-м году. Осталось только подождать, затяните пояса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #136

145. Сообщение от Аноним (145), 13-Ноя-24, 17:37	+/–
А я бы стал утверждать, что программа достигает совершенства к ... концу развития. После чего выбрасывается, и всё начинается сначала. Потребуются примеры? Ну, NC и NU под MS-DOS, да и сама MS-DOS.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #164

146. Сообщение от anonimous (?), 13-Ноя-24, 17:54	+/–
Цель понятная и они не не скрывают - найти инвесторов. Спрос есть? Будет и предложение!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #127

147. Сообщение от Аноним (147), 13-Ноя-24, 18:00	+4 +/–
Кстати, интересная видеопрезентация, посмотрите кто не смотрел.
Ответить | Правка | Наверх | Cообщить модератору

151. Сообщение от Аноним (-), 13-Ноя-24, 18:22	–1 +/–
Есть безопасный диалект чистого Си, называется Cyclone. Последний стабильный релиз вышел в 2006 году. Диалект разрабатывали в стенах AT&T labs. Разработчики TrapC велосипедят? Если уж на то пошло, взяли бы готовые наработки "Циклона".
Ответить | Правка | Наверх | Cообщить модератору

155. Сообщение от нах. (?), 13-Ноя-24, 20:28	+1 +/–
>> Си изобрели, чтобы на ассемблере не писать > Your computer is not a fast PDP-11 А гораздо, гораздо хуже. На 11й можно не то что на ассемблере, а прямо в машинных кодах писать (и да, они специально сделаны удобочитаемыми) На современной интеловской архитектуре - это рожать ежа против шерсти. Получится мало того что с нечеловеческими усилиями, так запросто еще и медленнее чем у компилятора (потому что тот умеет в execution reordering а ты парные команды подбирал-подбирал, а потом при отладке пришлось вставить еще одну и все пошло по п-де).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141

156. Сообщение от Аноним (156), 13-Ноя-24, 21:11	+/–
Ага, с утечками памяти при циклических ссылках
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

157. Сообщение от Аноним (156), 13-Ноя-24, 21:13	+/–
>Смотрю как Oracle пыхтит пытаясь жабу тащить и как ему не хватает силёнок, чего уж говорить об энтузиастах? Можно подробнее?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

158. Сообщение от Аноним (156), 13-Ноя-24, 21:16    Скрыто ботом-модератором	+1 +/–
>Он многие из таких ошибок отслеживает. Не многие, а всего лишь некоторые, самые простые. Остальные живут десятилетиями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

159. Сообщение от Аноним (156), 13-Ноя-24, 21:18	+1 +/–
>Как именно достигается подобная защита не поясняется. Можно расходится, чуда не будет
Ответить | Правка | Наверх | Cообщить модератору

160. Сообщение от Аноним (156), 13-Ноя-24, 21:19	+/–
Сколько уже языков изобретено, например тот же ATS? Осталось дело за малым - убедить погромистов на них писать.
Ответить | Правка | Наверх | Cообщить модератору

161. Сообщение от Аноним (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ообщить модератору
Родитель: #49

162. Сообщение от Аноним (30), 13-Ноя-24, 22:26	+/–
> Зашибись, а оверхед и непредсказуемость они под ковер как сныкали? :) Оверхед - никак (у них там компилятор вставляет Inc_Ref(X)/Dec_Ref(X)), а вот с предсказуемостью у RC-сборщиков как раз все в полном порядке - вполне пригодны для RT-задач.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

163. Сообщение от Аноним (163), 13-Ноя-24, 22:55	+/–
Чем его РуСи Терехова не устроил?
Ответить | Правка | Наверх | Cообщить модератору

164. Сообщение от arisu (ok), 13-Ноя-24, 23:25	+/–
NC достиг совершенства в VC. ;-) к сожалению, Волков не дал исходников. не то чтобы груда асм-кода была сейчас сильно нужна, но чисто для исторического интересу было бы неплохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #172

166. Сообщение от _kp (ok), 13-Ноя-24, 23:42	+1 +/–
>>Вместо malloc .. new.. за освобождение памяти отвечает компилятор Не понял шутку, типа еще на этапе компиляции виднее когда объект не будет нужен. Тут, или не будет работать, или не освобождается память. Более иого,даже со сборщиком мусора, ну не верится что оно будет предвидеть возникающие события, при которых надо освободить объект ;) В остальном все хорошо. Да, понятно, что рантайм должен быть напичкан проверками, ибо на этапе компиляции все не проверить. Но ведь и не обязательно всё писать на этом. И изюминка на торте... А зачем Си, почему не С++? Что то низкоуровневое или высокопроизводительное все равно писать на обычных C и С++, а для более высокоуровнего кода С++ удобней.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #178

167. Сообщение от Ivan_83 (ok), 14-Ноя-24, 02:28	+1 +/–
> Все создаваемые переменные и буферы явно инициализируются или заполняются нулями компилятором. Уже минус производительности. Дебажные сборки С такое же делают, и кажется флаг для этого есть отдельный компелятору. > Вызовы free и delete отсутствуют, а за освобождение памяти отвечает компилятор, что защищает от ошибок, приводящих к утечке памяти. И откуда компелятору знать нужна мне эта память или уже нет? Типа ссылки по указателям посчитать? - так а мне потом бегать всё занулять чтобы он память освободил? Странное в общем оно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #189

168. Сообщение от 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ообщить модератору
Родитель: #106 Ответы: #188

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

170. Сообщение от Аноним (-), 14-Ноя-24, 07:55	+1 +/–
> Увидел иронию в словах "бывший профессор". Но с другой стороны, когда в > новом сезоне шоу под названием "университет", видимо для экономии средств, мне > предложили из доцентов перейти в старшие преподаватели, наши пути в науке > разошлись. Кто его знает, что там произошло. В смысле - что? По сторонам посмотри, прфоессор. Увидишь куда идут ломовые выплаты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

171. Сообщение от Анониматор (?), 14-Ноя-24, 08:02	+/–
Никакой проблемы насамом деле нет. Сын учится в вышке, учат кондовый С на указателях и маллоках, причём всего за пару месяцев уже сильно далеко за пределами моего понимания. Любые утечки которые сдают студенты препод сразу видит. Дело в квалификации мне кажется.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #193

172. Сообщение от Incorporated (?), 14-Ноя-24, 08:05	+/–
NC достиг совершенства в MC. ;-) Cтаричок до сих пор живее всех живых с далекой середины 90-x! И продолжает активно сопровождаться, в отличии от того же FAR есть еще TC - но это оффтопик Так что даже в деле классических файловых менеджеров семейства NC движуха идет и они показали свою востребованность сообществом
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #173

173. Сообщение от arisu (ok), 14-Ноя-24, 08:35	+/–
а MC не надо сопровождать никуда. последнее хорошее, что с ним случилось — это mc^2. который, естественно, в апстрим не взяли, и продолжают там заниматься ерундой. я этот самый mc^2 спокойно использую, и за восемь лет отсутствия очень необходимых сопровождений и обновлений весьма доволен. была ещё, кстати, очень крутая штука — x northen captain. уже иксовая, но ещё приличная. жаль, что померла. я как-то думал её оживить, но традиционно заленился.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #172 Ответы: #198

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

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

178. Сообщение от Аноним (-), 14-Ноя-24, 17:57	+1 +/–
>А зачем Си, почему не С++? Ну так ты сам пиши на плюсах! Зачем других агитируешь-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

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

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

183. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #182 Ответы: #187

184. Сообщение от LinupsCrashGitz (ok), 15-Ноя-24, 11:23	+1 +/–
Нет памяти - нет проблем
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #110

186. Сообщение от Аноним (-), 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ообщить модератору
Родитель: #181

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

188. Сообщение от Аноним (-), 15-Ноя-24, 18:42	+/–
> По мне sizeof(buff) удобнее константы. > Хотя вероятно машинный код будет идентичный. sizeof(buff) лучше приучиться просто не юзать - грабельная конструкция, и если там не char был, на этом можно налететь при случае. Даже если вот конкретно тут оно и катит. >> strncpy(buff, argv[1], buff_size); > А кто будет проверять что argc >= 1?) Да, дорогой Додо, если вам такой втык делает Ivan_83 известный своим пофигизмом на все, вы таки - конкретно облажались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #168 Ответы: #190

189. Сообщение от Аноним (-), 15-Ноя-24, 18:46	+/–
> И откуда компелятору знать нужна мне эта память или уже нет? А посмотри как боров-чекер например работает. Некоторые плюсеры смогли посмотрев на это все и довольно сравнимую логику и на плюсах местами захреначить. > Странное в общем оно. В этом мире есть много странного. Это не значит что оно непременно плохое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

190. Сообщение от Ivan_83 (ok), 15-Ноя-24, 23:37	+/–
Мой пофигизм обычно кончается после того как PoC начал работать :) И на самом деле в моём коде скорее наоборот избыточно много проверок входных аргументов. В этом плане я не согласен с теми же гномерами которые предпочитают падать по раньше на ошибках. Насчёт sizeof() - с ней всё нормально пока в объявлении переменной не добавят * или не уберут. Я в целом считаю что это не проблема, потому что заменяя тип переменной пограмит должен убедится что оно не только собирается но и что переменная везде корректно используется. И на самом деле я просто не люблю объявлять константы в функциях, у меня как правильно и без этого там куча переменных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #191, #199

191. Сообщение от arisu (ok), 15-Ноя-24, 23:40	+/–
> И на самом деле я просто не люблю объявлять константы в функциях, > у меня как правильно и без этого там куча переменных. ой вэй!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

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

193. Сообщение от freecoder (ok), 17-Ноя-24, 11:20	+1 +/–
*Никакой проблемы при написании лаб на Си на самом деле нет Поправил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

194. Сообщение от nc (ok), 17-Ноя-24, 12:16	+/–
Горшочек не вари, я еще доки по Carbon и Circle до конца не дочитал а тут еще и это
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

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

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

197. Сообщение от Аноним (-), 21-Ноя-24, 21:44	+/–
> затем, что виртовские языки не защищают от идиота. чтобы защитить от идиота > — надо идиота просто не допускать к программированию. 1) Си это немного не виртовский язык вроде бы? 2) И вот как раз для перечисляемого типа - было бы очень логично заметить что вон там в функции с таким заявленным типом аргумента - дали нечто совершенно левое, отсутствующее в перечислении. И если это реально капец как надо - затребовать каст. Как аннотацию что этот явный левак и правда задуман - так. > а виртовские языки защищают не-идиота от случайных, непреднамеренных ошибок. Так я и дал пример этого самого - дали явно кривое значение функции с типом перечисления где этого значения в перечислении нет. И по аннотациям - можно в 2 счета поймать такое. Но увы. Enum в сях - декорация. Настолько что даже хрен поймешь в какой тип реально это преобразуется. Если кажется что все это круто скажи gcc -Wconversion - и все увидишь сам. > один из видов защиты — трапнуться в рантайме, если обнаружено что-то не то. Всю жизнь мечтал чтобы у меня управляющий фирмвар в рантайме брякнулся. > да и с мозгом паскаль ничего такого не делает. просто предполагает программиста, > а не кодира. кодиры, конечно, стонут и убегают. Увы, синтаксис пасквиля у меня ничего кроме отвращения не вызывает. Так что я на самом деле хочу - "better C". Нет, пасквиль за это вообще совсем не считается. И архитектур оно поддерживает как я понимаю сильно меньше. На мой вкус пасквиль - приколен как обучалка, но реальные проекты на этом делать? Ни за что. А реальная претензия к сям - ну вот намерения же аннотированы. Так какого? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #200, #202

198. Сообщение от Аноним (-), 21-Ноя-24, 21:48	+/–
> там заниматься ерундой. я этот самый mc^2 спокойно использую, и за > восемь лет отсутствия очень необходимых сопровождений и обновлений весьма доволен. А что за mc^2 такое? Ну, кроме Эйнштейна :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #173 Ответы: #201

199. Сообщение от Аноним (-), 21-Ноя-24, 22:11	+/–
> Мой пофигизм обычно кончается после того как PoC начал работать :) Да я так то видел ваш код - и в принципе он был лучше чем ваши коменты :) > Насчёт sizeof() - с ней всё нормально пока в объявлении переменной не > добавят * или не уберут. Я имел в виду что для array размер массива лучше как sizeof(x)/sizeof(x[0]) считать. Иначе если там sizeof() элемента не 1 - конкретная лажа выйдет. Хотя даже это имеет свои ограничения. https://en.wikibooks.org/wiki/C_Programming/Pointers_and_arr... > Я в целом считаю что это не проблема, потому что заменяя тип > переменной пограмит должен убедится что оно не только собирается но и > что переменная везде корректно используется. Есть такой подход - antibug coding. Он спасает от множества горя. Если грабли не раскладывать - не придется подбирать правлиный бинт для расшибленного лба вообще. Так намного лучше. А к тому же прикольно когда программа либо корректно работает, либо не компилится, если sanity checks провалились. > И на самом деле я просто не люблю объявлять константы в функциях, > у меня как правильно и без этого там куча переменных. Это как бы понимаемо. А в вон том случае обычно типичную макросню делают. Один из случаев когда макросы это не фу такими быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #190

200. Сообщение от Аноним (-), 21-Ноя-24, 22:31	+/–
>> один из видов защиты — трапнуться в рантайме, если обнаружено что-то не то. > Всю жизнь мечтал чтобы у меня управляющий фирмвар в рантайме брякнулся. Представь что у тебя есть какой-то агрегат. Например рентгеновский аппарат и в фирмваре произошла ЧУДОВИЩНАЯ ОШИБКА И у тебя есть два стула: - брякнуть фирмварь и вырубить аппарат - отправить на управление трубкой рандомное число после, напр. переполнения Думаю пациент не будет в восторге от второго)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #203

201. Сообщение от arisu (ok), 22-Ноя-24, 07:01	+/–
>> там заниматься ерундой. я этот самый mc^2 спокойно использую, и за >> восемь лет отсутствия очень необходимых сопровождений и обновлений весьма доволен. > А что за mc^2 такое? Ну, кроме Эйнштейна :) понимаю. муффи имечко выбрал такое, что фиг найдёшь даже если знаешь, что ищешь. вот: https://www.geek.co.il/~mooffie/mc-lua/docs/html/ фактически, он сделал доступ ко всем потрохам mc из Lua. не просто «пару методов высунули», а всё. можно дополнять, можно писать новые фичи, можно делать vfs, можно допиливать редактор, можно… да, кажется, почти всё можно. там в поставке идёт огромное количество примеров, многие из которых никакие не примеры, а очень крутые и удобные плугины (как новые, так и улучшения существующих диалогов). Visual Rename, например, попробуй — очень удобная штука. в общем, бери исходники, читай "official-suggestions.lua" — и обалдевай. p.s.: ах, да. Lua-подсистему можно полностью перезапустить не закрывая mc, и не теряя остальное состояние. так что экспериментировать очень удобно. p.p.s.: там есть документация! нет, не «документация», а документация! не просто «смотри в пример/исходник и делай так же», а внятные описания на человеческом языке, с хинтами, подсказочками неочевидного, и такое вот. настоящая, реальная документация, которая полезна и удобна. чудо!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #206

202. Сообщение от arisu (ok), 22-Ноя-24, 08:14	+/–
>> затем, что виртовские языки не защищают от идиота. чтобы защитить от идиота >> — надо идиота просто не допускать к программированию. > 1) Си это немного не виртовский язык вроде бы? там выше речь про дельфи зашла. который очень-очень изуродованый, но всё ещё паскаль. отсюда и появились «виртовские языки». >> один из видов защиты — трапнуться в рантайме, если обнаружено что-то не то. > Всю жизнь мечтал чтобы у меня управляющий фирмвар в рантайме брякнулся. а не надо кодировать. надо программировать. это во-первых. формальные доказательства не просто так придумали. а во-вторых — ты предпочитаешь, чтобы вместо этого просто молча ерунду выдавало? причём вполне возможно, что ерунда будет расползаться, если какие-то данные повредили. никто не мешает тебе поставить обработчик рантайм-трапов, в котором как-то куда-то что-то сигнализировать (это уже зависит от наличия подобного), и, например, перезапускать из безопасного состояния. или другое всякое делать, что понадобится. и нет, это не исключения, это глобальный обрабочик трапов. потому что он не должен вызываться никогда. > Увы, синтаксис пасквиля у меня ничего кроме отвращения не вызывает. он немного неудобен. в модуле-2 Вирт сделал значительно лучше, в обероне — почти идеально. > На мой вкус пасквиль - приколен как обучалка, но реальные проекты на > этом делать? Ни за что. и правильно. оберон значительно лучше. я сейчас на сишечке пишу только если надо обеспечить сборку где-то, где или нет моего компилятора оберона, или есть желание чтобы собиралось без доустановки чего-то кроме gcc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #204

203. Сообщение от Аноним (-), 22-Ноя-24, 20:37	+/–
> Представь что у тебя есть какой-то агрегат. Представь себе что ты это все рассказываешь тому кто фирмвари кодит. Просто представь себе. > Например рентгеновский аппарат и в фирмваре произошла ЧУДОВИЩНАЯ ОШИБКА > И у тебя есть два стула: > - брякнуть фирмварь и вырубить аппарат Простите но в слове panic нигде нет ни звука про "вырубить аппарат". Это собссно небольшой нюансик того подхода и есть - если оно НЕКОНТРОЛИРУЕМО брякается, без особых возможностей рекавери и обработки - это ну такое себе :) Характерный пример - Rust VS LinuxKernel. Не, оказывается, совсем вынести ядро ОС в панику от всего лишь нехватки RAM - это совсем не круто, и даже идет вразрез с вон теми желаниями. Ибо какой, нахрен, корректный шатдаун чего либо при внезапной панике, не говоря о восстановлении state после этого?! > - отправить на управление трубкой рандомное число после, напр. переполнения > Думаю пациент не будет в восторге от второго) Когда мне говорят что у меня только 2 опции, я начинаю призадумываться не втирают ли мне очки. Передо мной открыт весь мир. У меня бесконечное количество опций. А мне пытаются всучить только 2 в которые я должен уткнуться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200

204. Сообщение от Аноним (-), 22-Ноя-24, 21:02	+/–
> там выше речь про дельфи зашла. который очень-очень изуродованый, но всё ещё > паскаль. отсюда и появились «виртовские языки». А, я этот момент упустил. >> Всю жизнь мечтал чтобы у меня управляющий фирмвар в рантайме брякнулся. > а не надо кодировать. надо программировать. это во-первых. Смотря что под этим понимать. Заметная часть фирмвары состоит из довольно рутинных и неинтересных вещей, далеких от полета мысли Вирта и прочих Кнутов. То-есть на уровне алгоритмики многие вещи в упраляющих системах - совершенно ничего эпичного. > формальные доказательства не просто так придумали. Реальный мир не очень хорошо формализуется. Он довольно хаотичный и сложный. Де факто лучше всего работает здравый смысл и эмпирика. А также здоровая порция пессимизма по части "should never happen - не про нас". И просто "antibug coding" на максималках. Всякие MISRA и ко придумали свои рулесы не просто так. > а во-вторых — ты предпочитаешь, чтобы вместо этого просто молча ерунду выдавало? Именно молча и ерунду - нет, конечно, но вот "вместо этого" - я не согласен. В мире есть бесконечно возможностей. Скажем, обработка ошибок и корректная реакция на них. А fail fast лишь одна из многих парадигм. > причём вполне возможно, что ерунда будет расползаться, > если какие-то данные повредили. При чем возможно что я накодил sanity check и он это в два счета заметит. И как минимум попытается в "safe state" вогнать эту штуку до более радикальных вещей. > никто не мешает тебе поставить обработчик рантайм-трапов, в котором как-то куда-то что-то > сигнализировать (это уже зависит от наличия подобного), Мой пойнт прост: все что можно поймать в compile time - нужно поймать в compile time. Есть довольно большая разница между моей недовольной рожей и пинком рекомпила VS факап какого-то управляющего процесса, даже если failsafe обыгран корректно, это может и не быть free lunch. > не исключения, это глобальный обрабочик трапов. потому что он не должен > вызываться никогда. Оно как бы да. На самом деле у Cortex M есть нечто примерно такое хардварно, HardFault, на всякие совсем уж странные системные факапы. И в принципе его можно и из софта провоцировать, ubsan урезанный так и делает (он на минималках - bad opcode при провале проверки). > он немного неудобен. в модуле-2 Вирт сделал значительно лучше, в обероне — > почти идеально. Увы, мое сердце принадлежит Curly Bracket. И я никогда не видел никакой убедительной системщины на всем том. Системщики и академики мыслят довольно по разному. > и правильно. оберон значительно лучше. я сейчас на сишечке пишу только если > надо обеспечить сборку где-то, где или нет моего компилятора оберона, или > есть желание чтобы собиралось без доустановки чего-то кроме gcc. А я на сишечке пишу в основном. Немного на плюсах еще - не потому что мне сильно нравится, но на этом есть довольно много крутых проектов, и возможность перепахать некий дредноут под себя это так то новые возможности и качественно иной уровень. А потом этот код еще и другие смогут читать. А если прогать на обероне и пользоваться фоссилом как ты - ну, тогда проект будем читать только я и моя ср@ная кошка. И все бенефиты опенсорса пройдут мимо меня. Не, так даже мизерный и тривиальный таск за меня никто не рюхнет, co-op не состоится, и это довольно сильно ограничивает возможности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #202 Ответы: #205

205. Сообщение от arisu (ok), 22-Ноя-24, 21:24	+/–
>> а не надо кодировать. надо программировать. это во-первых. > Смотря что под этим понимать. Заметная часть фирмвары состоит из довольно рутинных > и неинтересных вещей, далеких от полета мысли Вирта и прочих Кнутов. > То-есть на уровне алгоритмики многие вещи в упраляющих системах - совершенно > ничего эпичного. а программирование — это вовсе не про эпичность. это про рутину done right. про эпичность — это как раз «йа закодел!» >> формальные доказательства не просто так придумали. > Реальный мир не очень хорошо формализуется. а тебе не надо формализовать реальный мир. тебе надо формализовать решение для автомата, который ведёт себя полностью предсказуемо. и тогда из картины можно исключить проблемы софтвари, оставив обработку проблем хардвари. > Всякие MISRA и ко придумали свои рулесы не просто так. конечно, не просто так. это следствие выбора неправильного языка (и методологии). вот и получаем попытки хоть как-то починить результат костылями. >> а во-вторых — ты предпочитаешь, чтобы вместо этого просто молча ерунду выдавало? > Именно молча и ерунду - нет, конечно, но вот "вместо этого" - > я не согласен. прости, а какие варианты-то? > В мире есть бесконечно возможностей. Скажем, обработка ошибок > и корректная реакция на них. я не понимаю, кто запрещает это делать. взял — и проверил все нужные preconditions перед операциями. всё, не будет fail. а если всё-таки будет — то как раз трап если и не спасёт, то хотя бы позволит узнать, что всё пошло не в ту дверь. > Мой пойнт прост: все что можно поймать в compile time - нужно > поймать в compile time. опять же: разве ж я против? > Увы, мое сердце принадлежит Curly Bracket. И я никогда не видел никакой > убедительной системщины на всем том. Системщики и академики мыслят довольно по > разному. а я видел. Oberon System, например. операционная система. с гуями. на голом железе. с нуля. с кучей приложений. пользовался весь ETHZ. нет, не только для обучения. а ещё AOS. операционная система. с гуями и поддержкой SMP. активно используется на, например, армах. ссылок не покажу, потому что в основном это проприетарные форки, о которых я знаю… ну, потому что знаю. ;-) форки не потому что в основной чего-то не хватает, а потому что в основной всего слишком много. гуй, например, нужен далеко не всегда. и другие инструментальные средства. они-то отрываются, но иногда их надо чем-то заменить. иногда кое-что из этого возвращается в оригинал, но обычно оно довольно сильно специализировано для того, чтобы возвращать смысла не имело. и да, в AOS нет *никаких* других языков высокого уровня кроме Оберона. как и в Oberon System. > А если прогать на обероне и пользоваться фоссилом как ты - ну, > тогда проект будем читать только я и моя ср@ная кошка. И > все бенефиты опенсорса пройдут мимо меня. Не, так даже мизерный и > тривиальный таск за меня никто не рюхнет, co-op не состоится, и > это довольно сильно ограничивает возможности. я тебе сейчас расскажу удивительное: контрибуторы не приходят. нет никакого смысла выбирать инструменты с расчётом на будущих контрибуторов — их не будет. равно как и нет смысла писать проект для кого-то кроме себя — по тем же причинам. а если проект реально кому-то понравится настолько, что захочется контрибутить — оберон и фоссил его не остановят. да, возможно мои проекты «невостребованы обществом». но они востребованы *мной*. жизнь длиннее… ну, ты понял. и я теперь предпочитаю потратить немного времени на то, чтобы получить удобное лично мне, а не пытаться сделать удобное из чего-то другого, изо всех сил преодолевая сопротивление как маинтайнеров, так и кривых языков. всё равно в итоге получается форк, только времени и усилий потрачено больше, а толку таки меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

206. Сообщение от Аноним (-), 22-Ноя-24, 21:31	+/–
> понимаю. муффи имечко выбрал такое, что фиг найдёшь даже если знаешь, что > ищешь. вот: https://www.geek.co.il/~mooffie/mc-lua/docs/html/ Забавная вундерфафла. И да, кажется я впервые про это слышу. > фактически, он сделал доступ ко всем потрохам mc из Lua. не просто > «пару методов высунули», а всё. можно дополнять, можно писать новые фичи, Скриптовать файловый манагер кажется мне несколько оверкилом. У меня и так терминалка с табами, а то что там несколько разных ms c разными state, при том некоторые вообще over serial или ssh (в чем ключевой аргумет за консольный FM и состоит). Вот links keys в mc я оценил, сделало навигацию быстрой. И еще исправили наконец заскоки с запоминанием дир и что там в шелле напечатано с ctrl+o vs без. А где мне спичило поскриптить околофайловые операции - я себе на баше весьма навороченые вещи сделал. Типа кастомных генераторов и враперов виртуалок и тому подобного, в общем повторяющиеся (около)файловые действия и проч, в этом смысле я кажется с файловыми операциями относително юниксвэен. > можно делать vfs, можно допиливать редактор, можно… да, кажется, почти всё > можно. там в поставке идёт огромное количество примеров, многие из которых > никакие не примеры, а очень крутые и удобные плугины (как новые, Честно говоря я в mc в основном ковыряю малоизученные проекты в exploratory mode, так что сильно твикать его эдитор мне ни к чему. Если я всерьез с жирным кодом зарубаюсь, я все же возьму что-то уровня Geany как минимум. Почему так? На большом экране я могу уместить скажем и свой код, и вон там сбоку терминалку. В нее может валиться допустим околореалтаймный трейс flow как оно себя ощущало. С небольшим DMA движком и 3MBps uart даже тайминги особо не импактит. Можно "интерфейснуться к реальному миру" и - посмотреть как это было. Сильно за пределами того что позволяли мои органы чувств и восприятие времени. И это больше про UI, из чисто текстового что-то такое же будет сложновато. > так и улучшения существующих диалогов). Visual Rename, например, попробуй — очень > удобная штука. в общем, бери исходники, читай "official-suggestions.lua" — и обалдевай. Как я уже сказал мне паскалеобразный синтаксис - не очень. Но все равно спасибо за ссыль, никогда не видел эту штуку. > p.s.: ах, да. Lua-подсистему можно полностью перезапустить не закрывая mc, и не > теряя остальное состояние. так что экспериментировать очень удобно. КМК я предпочитаю экспериментировать с чуть иными вещами. > p.p.s.: там есть документация! нет, не «документация», а документация! не просто > «смотри в пример/исходник и делай так же», а внятные описания на > человеческом языке, с хинтами, подсказочками неочевидного, и такое вот. настоящая, реальная > документация, которая полезна и удобна. чудо! Да я честно говоря миднайтом пользуюсь в основном для быстрого exploratory нового невзивестного проекта или смотрения в unknown формат файлов. А доки я кажется никогда и не читал :). А bulk rename мне надо было - пару раз в жизни. И конечно совсем не так как ты себе это представляешь. Как тебе 600 000 файлов вынутых photorec'ом? А теперь квест: юзер профакал 2 месяца из 2 лет, остальное в бэкапе было. И вот - разваленый ФС. Но как ЭТОМУ нормальные имена дать, учитывая что ФС кранты? И понять что есть, что нет? А, во, баш + ffprobe, спасибо камерам за тэги, скрипт пашет, файло разлетается по субдирам с именами "как от камеры", через 10 минут все разложено в лучшем виде. Но ты наверное не так себе bulk rename представлял? :) p.s. но да, твое упрямство в отстаивании своих предпочтений вызывает определенное уважение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #201 Ответы: #207, #209, #210

207. Сообщение от arisu (ok), 22-Ноя-24, 22:30	+/–
ну так я ж тебя не агитирую. просто лично мне проект показался очень удобным: я всегда первым делом запускаю двухпанельку, и очень много всего делаю именно из неё. не вижу смысла отказываться от удобств: и шелл под рукой, и панельки. соответственно, лично мне эти самые панельки часто хочется снабдить новыми фичами, и чтобы не пересобирать mc каждый раз. как будто панельки накладывают заклятие «умение в шелл минус сто», право. p.s.: редактор для проектов у меня вообще давно самописный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

208. Сообщение от Котофалк (?), 23-Ноя-24, 15:53	+/–
У меня уже давно есть полушутейный критерий "Это достаточно кривая хрень, чтобы стать популярной".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

209. Сообщение от Котофалк (?), 23-Ноя-24, 16:04	+/–
> Скриптовать файловый манагер кажется мне несколько оверкилом А это и есть оверкилл. При чём это не всегда плохо, но почти всегда - непопулярно. В идеале если есть небольшое крепкое комьюнити или один упоротый (в хорошем смысле) разраб-фанатик, проект будет долго жить и радовать это самое небольшое комьюнити.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

210. Сообщение от arisu (ok), 23-Ноя-24, 16:42	+/–
а! Зоркий Глаз заметил! ты воспринимаешь mc как файловый менеджер, о чём и написал открытым текстом. а в оригинале nc назывался «visual shell», и был именно этим: шелл плюс удобные панельки для разных операций, которые красиво на панельки ложатся. не то чтобы в досе был нормальный шелл, конечно, но идея-то именно такая. файловый менеджер же — это что-то типа XTree. соответственно, для меня миднайт — это именно расширение шелла, а не просто менеджер файлов. отсюда и желание его достраивать как мне удобно. конечно, можно обходиться и просто шеллом и его скриптами. а можно — не теряя этого — получить ещё одно дополнительное измерение для разных интересных операций (и не только файловых, хотя в основном и). ну да, вопрос привычки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

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

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