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

"C++ Alliance продвигает в C++ механизмы безопасной работы с памятью, опробованные в Rust"	+/–
Сообщение от opennews (??), 17-Сен-24, 14:41
Президент организации C++ Alliance объявил о  работе над спецификацией, добавляющей в язык C++ расширения для безопасной работы с памятью, напоминающих возможности, реализованные в языке Rust. Для осуществления проекта привлечён Шон Бакстер (Sean Baxter), автор экспериментального C++-компилятора Circle, развивающего идеи по повышению безопасности кода C++, реализуемые  на стороне компилятора без использования сборки мусора. В рамках проекта Шон опубликовал документ с анализом применимости тех или иных мер защиты, предлагаемых в языке Rust, оценкой возможности их реализации для C++ и предложениями по добавлению в язык C++ расширений, повышающих безопасность кода... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=61878
Ответить | Правка | Cообщить модератору

Сообщения

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

2. Сообщение от Минона (ok), 17-Сен-24, 14:42	+14 +/–
> C++-компилятора Circle Убийца Rust № 1. Кто следующий?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #89, #385

4. Сообщение от Аноним (4), 17-Сен-24, 14:43	+7 +/–
+100500% compilation times?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #91, #123

5. Сообщение от Аноним (5), 17-Сен-24, 14:43	–1 +/–
Ёж++ птица гордая... Но лучше поздно, чем никогда. Ещё бы модули везде были.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #31

6. Сообщение от 13 (??), 17-Сен-24, 14:44	+12 +/–
> растущую в среде разработчиков потребность в безопасных методах программирования Эталонная подмена понятий. Браво.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34

7. Сообщение от Аноним (7), 17-Сен-24, 14:45	–3 +/–
В C++ первым делом нужно добавить стандартные профили, ограничивающие некоторые возможности языка (вроде арифметических операций с указателями или вообще доступность указателей как таковых) по требованию и более полно определяющие поведение в различных ситуациях.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #156, #161

8. Сообщение от Аноним (8), 17-Сен-24, 14:48	+1 +/–
Вот только это уже будет не С++, сломается обратная совместимость, деды и тут будут недовольны.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #50, #83, #113, #129

10. Сообщение от Аноним (10), 17-Сен-24, 14:51	+7 +/–
Порог входа неуклонно растёт, а количество полностью знающих язык и его стандартную библиотеку падает.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #60, #86, #90, #454

11. Сообщение от Аноним (7), 17-Сен-24, 14:55	+/–
Был проект по добавлению аннотаций времени жизни в Clang C++, но почему-то сдулся: https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/...
Ответить | Правка | Наверх | Cообщить модератору

12. Сообщение от Rev (ok), 17-Сен-24, 15:00	–4 +/–
Какой только хернёй они не занимаются, чтобы только не переходить на Раст... Не получится навязать готовому языку безопасность в виде костылей.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #25, #52, #57, #63, #414

15. Сообщение от Аноним (15), 17-Сен-24, 15:05	+1 +/–
1. зачем чучхе, вместо интеграции в clang и LLVM? 2. Есть же уже Cabron.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32, #75, #76

21. Сообщение от Аноним (21), 17-Сен-24, 15:09	+1 +/–
Теперь еще это в сишку, чтоли, запилить - и вообще нормуль. А то плюсы - больно уж навороченные. И это вовсе и не фича даже.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #41, #238

23. Сообщение от Аноним (-), 17-Сен-24, 15:10	+10 +/–
> и более полно определяющие поведение в различных ситуациях. Может ты еще и UB предложишь убрать?? На последние скрепы решил покуситься?! На костер еретика!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #314

24. Сообщение от Fjyj (-), 17-Сен-24, 15:11    Скрыто ботом-модератором	–1 +/–
"Сначала они тебя не замечают, потом смеются над тобой, затем борются с тобой. А потом т̶ы̶ ̶п̶о̶б̶е̶ж̶д̶а̶е̶ш̶ь̶ они начинают копировать твои идеи" Вот оно признание от плюсовиков: что их язык из прошлого века не может обеспечить нынешние требования к программам, что есть идеи которые позволяют сделать лучше, что надо что-то делать... Но думаю если оно пойдет в стандарт, то это будет в году так 2030 или даже позже. Пока коммитет позаседает, пока все обсудят... Ну и слом совместимости (особенно в мозгах дидов) тоже неизбежен.
Ответить | Правка | Наверх | Cообщить модератору

25. Сообщение от Аноним (25), 17-Сен-24, 15:12	+18 +/–
Нельзя было что-ли сделать раст нормальным языком? Тогда бы все на него перешли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #233

26. Сообщение от Аноним (15), 17-Сен-24, 15:16	+4 +/–
>#feature on safety В C и C++ для этого используются #pragma
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #237

27. Сообщение от Аноним (39), 17-Сен-24, 15:16	+4 +/–
> переводить проекты на безопасные методы, сохраняя при этом совместимость с уже существующим "небезопасным" кодом. Странная идея. Нужен Раст - берите Раст, в чем проблема-то? Если эту спеку и примут, то сперва бюрократы из комитета C++ будут мусолить ее лет шесть, а потом еще лет шесть-десять придется ждать ее сколь-нибудь сносной поддержки в компиляторах. Обалденный план  с учетом того, в Расте все эти упомянутые фичи работают прямо здесь и сейчас. Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35, #43, #319

28. Сообщение от Аноним (15), 17-Сен-24, 15:17	+/–
>mut >std2 >safe Можно хоронить. Плюсовые компиляторы сами умеют определять. Вместо того, чтобы всё вручную аннотировать, нужно развивать встроенный статический анализ.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #30

29. Сообщение от Аноним (29), 17-Сен-24, 15:19    Скрыто ботом-модератором	–1 +/–
Вот с таким же, незнаю как это назвать, "стремлением", "рвением", "жаждой", "одержимостью", "кровьизносостью", "дуростью", "дебилизмом", "укуренностью", "смузизахлеблённостью" ли могли бы продвигать механизмы безопасТных компьютерный (аппаратных) архитектур. Ведь грош цена вашему "механизму безопасТной работы памяти" при заведомо небезопасТной аппаратной  архитектуре этой "памяти", все яйца в одной корзине, и как их не пытайся складывать, разобьются все.
Ответить | Правка | Наверх | Cообщить модератору

30. Сообщение от Аноним (30), 17-Сен-24, 15:27	+/–
> сами Неверно. Проблема pointer provenance до сих пор не решена в силу ее сложности. См. статьи Ralf Jung.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #428

31. Сообщение от Fjyj (-), 17-Сен-24, 15:31	–10 +/–
Так боюсь уже поздно. Просто представь новичков, которые ищут "а какой язык стоит учить?". Если они поумнее и не хотят идти в вебкамаки на всяки JS/TS, то выбора из современных у них не так уж много. Если мобилки - то swift/kotlin,  ну и всякие флаттеры. Если серваки то там гошка и прочая вебня. Если хочеться в геймдев (с кранчами по 80 часов) - С++. Но не факт, что там будет это новый C++ Circle. Значит или учить оба или выбирать. Чистую СИшку учить может только любитель всяких некропрограмм и легаси. Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Когда это примут, будет ли оно частью стандарта или просто сбоку прилеплено.. А тут уже есть Rust, который добавляют в ядро, на котором уже пишут проекты и даже ОС. Выбор кажется очевидным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #39, #66, #94, #111, #143, #302, #424

32. Сообщение от Аноним (-), 17-Сен-24, 15:33	+1 +/–
1. Ну так свой продвигает, разве не очевидно? 2. Карбона нет. github.com/carbon-language/carbon-lang "Carbon Language is currently an experimental project." Причем они сами рекомендуют использовать раст если есть возможность. "Existing modern languages already provide an excellent developer experience: Go, Swift, Kotlin, Rust, and many more. Developers that can use one of these existing languages should"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #285, #316

34. Сообщение от Аноним (39), 17-Сен-24, 15:34	+/–
Какие именно понятия тут подменили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #40, #58

35. Сообщение от Аноним (35), 17-Сен-24, 15:35	+/–
Тяжело им в Rust идти. Вакансий нет и специалистов нет. Как они пойдут сами что ли проичтабт книжку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #112

36. Сообщение от eugene_martein (ok), 17-Сен-24, 15:37	+5 +/–
Я принёс вам современное безопасное программирование на C++: target_compile_options(${target} PRIVATE                 -Wall                 -Werror                 -Wextra                 -Wpedantic                 -pedantic-errors                 -Wunused                 -Wctor-dtor-privacy                 -Wnon-virtual-dtor                 -Wnrvo                 -Wimplicit-fallthrough                 -Wshift-negative-value                 -Wswitch-default                 -Wswitch-enum                 -Wuseless-cast                 -Wuninitialized                 -Wstrict-overflow=5                 -Wstringop-overflow=4                 -Warray-bounds=2                 -Wduplicated-cond                 -Wfloat-equal                 -Wshadow                 -Wunsafe-loop-optimizations                 -Wcast-qual                 -Wconversion                 -Wparentheses                 -Wenum-conversion                 -Wflex-array-member-not-at-end                 -Wlogical-op                 -Wmissing-declarations                 -Wpacked                 -Wredundant-decls                 -Winline             )
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #37, #61

37. Сообщение от Аноним (37), 17-Сен-24, 15:38	+/–
Видимо ты не знаешь о существовании -Weverything
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #44

38. Сообщение от Аноним (38), 17-Сен-24, 15:39	+/–
Позитив. Ибо нефиг выпендриваться. Тоже могём.
Ответить | Правка | Наверх | Cообщить модератору

39. Сообщение от Аноним (39), 17-Сен-24, 15:40	+4 +/–
> Если хочеться в геймдев (с кранчами по 80 часов) - С++. Но не факт, что там будет это новый C++ Circle. В геймдеве в гробу видали как новые стандарты C++, так и стандартную библиотеку полюсов.  А на вопросы безопасности там и подавно наплевать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #142, #257

40. Сообщение от Хру (?), 17-Сен-24, 15:41	+3 +/–
Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!) Ну а разрабы 99% работают "на отъе..сь", ну а конечным покупателям кто ж обеспечит безопасность за те копейки, которые они платят?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #46

41. Сообщение от Аноним (7), 17-Сен-24, 15:42	+2 +/–
Уже запилили: https://en.wikipedia.org/wiki/Zig_(programming_language)#Memory_handling
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #48, #186

43. Сообщение от Аноним (-), 17-Сен-24, 15:45	+1 +/–
> Странная идея. Нужен Раст - берите Раст, в чем проблема-то? Тогда г-н Vinnie Falco не сможет влиять на развитие языка и на программеров, которые им будут пользоваться. Когда у тебя есть власть, то всегда хочется еще. > Ну и самое главное: кто-то всерьез считает, что все так и ломануться переводить свои десятилетиями пишущиеся легаси-копролиты в миллионы строк C++ на эти новые костыли? Ну.. во-первых были бы деньги))) Во-вторых - даже если завернуть в эти костыли какие-то особо кривые куски кода, типа парсинг пользоватльского ввода - то уже стало бы гораздо лучше. Но да, возникнет вопрос "а чего не создать раст обертку?" Как поступает например гугл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27

44. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 15:50	+2 +/–
Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #49, #130

45. Сообщение от keydon (ok), 17-Сен-24, 15:51	+2 +/–
Раст здорового человека.
Ответить | Правка | Наверх | Cообщить модератору

46. Сообщение от Аноним (39), 17-Сен-24, 15:53	–3 +/–
> Подмена в том, что это не разработчикам, а крупным клиентам корпооаций надо (и самим корпам!) А ты в курсе, что разработчики - это работники тех самых корпораций? И задача  их буквально состоит в решении проблем корпораций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #85

47. Сообщение от Karl Richter (?), 17-Сен-24, 15:55	+1 +/–
Вот, теперь C++ начало этим заниматься, потому что есть потребность в это. В первую очередь, потребность США по кибербезопасности.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #56, #79

48. Сообщение от Аноним (-), 17-Сен-24, 15:56	+/–
О... опять эта поделка. Когда оно мне попадалось пару лет назад на глаза, то позволяло весело и непринужденно делать всякие непотребства. var hello = try allocator.dupe(u8, "zig sucks"); allocator.free(hello); std.debug.print("{s}\n", .{hello}); и получаем use after free Не знаю исправил ли автор такое, но судя по доке где Out of Bounds Float to Integer Cast TODO оно еще очень сырое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #317

49. Сообщение от Аноним (39), 17-Сен-24, 15:56	–2 +/–
> Явное указание все опций не сломает сборку на новом компиляторе, Каким образом предупреждения могут сломать сборку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #53, #59

50. Сообщение от Аноним (50), 17-Сен-24, 15:58	+3 +/–
Гы, считай что в каждом стандарте плюсов есть "Removed and deprecated". Для примера: C++20: Use of comma operator in subscript expressions has been deprecated C++23: Use of comma operator in subscript expressions was no longer deprecated but the semantics has been changed to support overloadable n-adic operator[]
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #453

52. Сообщение от Аноним (52), 17-Сен-24, 16:01	+2 +/–
Давно уже есть smart pointers в C++. unique_ptr с move semantics это то что в Rust реализуется как владение (ownership) с той разницы что в C++ это не реализовано  на уровне компиляции программы, а во время выполнения. Что мешает делать подобные вещи во время компиляции? Ничего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #80, #283

53. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:01	+5 +/–
>> Явное указание все опций не сломает сборку на новом компиляторе, > Каким образом предупреждения могут сломать сборку? -Werror
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #62

54. Сообщение от Аноним (60), 17-Сен-24, 16:01	+2 +/–
Я как программист полностью одобряю: теперь мне ту же работу нужно будет делать в 5 раз дольше, а мне кредит за дом платить и вообще деньги откладывать. а на плюсах быстро всё сделал и не остаётся уже, что делать
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #70, #139, #295

56. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:03	+1 +/–
> Вот, теперь C++ начало этим заниматься, потому что есть потребность в это. > В первую очередь, потребность США по кибербезопасности. Им потребно наличие бэкдоров. На расте можно встроить прямо в компилятор, затимв разум неокрепшим умам верой в безопасность.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #64, #71

57. Сообщение от Karl Richter (?), 17-Сен-24, 16:03	+/–
А в чем костыль? В компилятор не смогут реализовать статическую проверку памяти для C++?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #196

58. Сообщение от Анонимусс (-), 17-Сен-24, 16:03	+4 +/–
Оно скорее больше юзерам нужно, а не разрабам. Потому что их задобало, что им могут ломануть напр. телегу или фейсбучек просто прислав картинку. Ну а какой умелец в либе разбора не проверил входные данные и всё - кровь, кишки... А юзеры в свою очередь делают дырку в голове корпам, предоставляющим сервис... Да и просто новости про дыры хорошо тиражируются журналистами и немного портят настроение совету директоров)))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #124

59. Сообщение от Аноним (7), 17-Сен-24, 16:04	+/–
-Werror
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #65

60. Сообщение от Аноним (60), 17-Сен-24, 16:05	+3 +/–
неправда, книги как были около 1300 страниц в 2003, так и остались по с++23
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #67, #88, #259, #381, #413

61. Сообщение от Аноним (50), 17-Сен-24, 16:05	+/–
Ещё бы к этому добру аналог: cargo fix
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

62. Сообщение от Аноним (39), 17-Сен-24, 16:05	+/–
-Werror не входит в -Weverything.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #104

63. Сообщение от Аноним (52), 17-Сен-24, 16:06	+1 +/–
Другое дело что ownership (владение) давно уже реализовано в Spark (язык Ada) и было заново переизобретено в Rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #456

64. Сообщение от Аноним (-), 17-Сен-24, 16:07	+/–
> Им потребно наличие бэкдоров. Всем потребно. Но кроме бекдоров есть еще и дыры. И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые и чучхе. > На расте можно встроить прямо в компилятор Можно. И в сишку можно. Но в сишке проще на null проверочку забыть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #68

65. Сообщение от Аноним (39), 17-Сен-24, 16:07	–1 +/–
-Werror - это не предупреждение и в -Weverything не входит 🤦
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59 Ответы: #69

66. Сообщение от Аноним (66), 17-Сен-24, 16:10	+4 +/–
> Т.к даже под микроконтролееры можно писать и на плюсах и на расте Так можно хоть на луа писать, вот только пишут все равно на сишке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #93

67. Сообщение от Аноним (66), 17-Сен-24, 16:12	+1 +/–
> книги как были около 1300 страниц в 2003 Так ты забыл умножить количество страниц на количество стандартов. В новых книгах и акцент на новом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #102

68. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:14	–1 +/–
>> Им потребно наличие бэкдоров. > Всем потребно. Но кроме бекдоров есть еще и дыры. > И они не хотят, чтобы их ломали через эти дыры всякие узкоглазые > и чучхе. В эту игру в одного не играют. >> На расте можно встроить прямо в компилятор > И в сишку можно. Компилятор для си можно забутстрапить, притом там все начинается с простого компилятора, написанного на scheme, которым уже потом собирается tcc. Кто собирает раст? Где исследование исходников на бэкдоры? Одна реализация по факту, все качают бинари. Куда проще встроить?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #72, #81

69. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 16:15	+/–
> -Werror - это не предупреждение и в -Weverything не входит 🤦 И дальше что? Оно указано отдельно в начальном комментарии.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #74

70. Сообщение от Аноним (-), 17-Сен-24, 16:18	+/–
Глупости ты говоришь. Да возможно переписать займет не год, а пять.. (в чем я очень сомневаюсь тк гугл переучивает 2/3 гошников и фортовиков на раст, за 2 месяца!) А если писать на С - то можно годами ковырять древние баги, которым по 20-30 лет, и создавать новые, для будущих поколений. Как в том анекдоте про адвокатов "Что же ты сынок наделал! Это дело нас уже четверь века кормило!!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54

71. Сообщение от Karl Richter (?), 17-Сен-24, 16:18	+/–
Бэкдоров полно, что в ПО, что в процессорах. У США явно будет/есть возможность получить к ним доступ. А обезопасить свою инфраструктуру не только от бэкдоров, но и багов - это задача. Уязвимости, связанные с памятью - самые распространенные, поэтому Rust привлекателен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #82, #105, #195

72. Сообщение от Karl Richter (?), 17-Сен-24, 16:21	+/–
В эту игру играют в OpenSorce ПО.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #201

74. Сообщение от Аноним (39), 17-Сен-24, 16:26	+/–
> И дальше что? То, что ты умничаешь в ветке, где ответили на: > Явное указание все опций не сломает сборку на новом компиляторе, если в эврифинг что-то добавят.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #101

75. Сообщение от Маняним (?), 17-Сен-24, 16:28	+/–
Гугли, после того как их выкинули из С++ комитета за попытку загнуть плюсы под свои хотелки, высрали кирпичей и один из них оказался карбон. Но как оказалось звездеть о новом убийце плюсов проще чем создать востребованный язык и потому карбон так и остался кирпичом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #96

76. Сообщение от ProfessorNavigator (ok), 17-Сен-24, 16:29	–2 +/–
> Есть же уже Cabron. Да, есть. И даже не один. Только это - не ЯП. Посмотрите перевод слова "cabron" с испанского...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #284

77. Сообщение от leap42 (ok), 17-Сен-24, 16:33	+1 +/–
Надо добавить все фичи всех языков... и не останавливаться на этом 😆😆😆
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #255

78. Сообщение от НяшМяш (ok), 17-Сен-24, 16:34	–6 +/–
Этап "принятие". Видимо ощутили, как от плюсовиков денежки утекаю, вот и начали суетиться и воровать хорошие идеи. Безопаснее кресты конечно же не станут, а вот повыступать на конференциях и пособирать донаты на этом ужасе - благое дело.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #92, #120, #166, #203

79. Сообщение от Аноним (29), 17-Сен-24, 16:44	+1 +/–
> В первую очередь, потребность США по кибербезопасности. они 4 летний опыт работы отменили буквально на днях, делайте вывод.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

80. Сообщение от Аноним (39), 17-Сен-24, 16:46	+2 +/–
> move semantics это то что в Rust реализуется как владение (ownership) Эмм... Нет, это вообще практически не связанные вещи. В плюсах компилятор не знает и знать не может, что ты там внутри своих unique_ptr делаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

81. Сообщение от Аноним (-), 17-Сен-24, 16:46	+/–
> Компилятор для си Какой именно)? У нас их просто куча! Даже пованивает, тк минимум половина уже померла и разложилась. > притом там все начинается с простого компилятора, написанного на scheme, которым уже потом собирается tcc. ... а потом им делают use-after-free Потому что оно ущербное dy design) Раст кстати тоже можно бустстрапить github.com/rust-lang/rust/tree/master/src/bootstrap > Кто собирает раст? Очевидно что такой же несчастный, как те что собирают gcc gcc.gnu.org/mirrors.html Чего можно напхать в tar.gz мы уже видели на примере библиотеки XZ > Где исследование исходников на бэкдоры? Не знаю, можешь поискать. > Одна реализация по факту, все качают бинари. И много людей собирают из исходников GCC и CLang? Точно так же качают из исходников. И ядро тоже, и пакеты. Те кто не в секте гентушников все так делают. > Куда проще встроить? Зачем что-то встраивать в компилятор, если проще сделать out-of-bounds прямо в коде? Или просто внести бекдор в ядро, которое мало кто сам соберет.. А стоп, так уже сделали - Bvp47 жил в ядре 10 лет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #163, #164, #165, #200

82. Сообщение от Аноним (29), 17-Сен-24, 16:49	+1 +/–
> Уязвимости, связанные с памятью там выше мой комент как раз про это - скрыли, ну пусть с такой же "пеной у рта" придумают "безопасТную модель памяти", а не 1000500-ый "безопасТный механизм" работы с "небезопасТной моделью памяти".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #217

83. Сообщение от Bottle (?), 17-Сен-24, 16:56	+/–
Да пох на этих дедов, ни один компилятор не соответствует стандарту на 100%, а значит, в общем случае невозможно написать корректный кроссплатформенный код. Либо корректный, либо кроссплатформенный (и то второе не гарантируется).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

85. Сообщение от Аноним (85), 17-Сен-24, 17:05	+/–
зачем ему на такие мелочи обращать внимание. он отважный диванный борец с корпорациями, четкий бородатый админ на бюджете. его красные глаза наполняются слезами, когда видят как злобные корпы угнетают все открытое и доброе
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

86. Сообщение от Bottle (?), 17-Сен-24, 17:05	+/–
Это нормально. Со временем комитет осознаёт, какие вещи наиболее востребованы среди программистов и стандартизирует подход.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #95

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

89. Сообщение от Аноним (89), 17-Сен-24, 17:08	+5 +/–
Если в какой-нибудь C++2next примут, то все компиляторы станут убиийцами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

90. Сообщение от Аноним (123), 17-Сен-24, 17:08	+1 +/–
Другие языки тоже обрастают фичами. Я думаю, немногие питонисты или яваскриптчики знают вот прямо абсолютно все фичи Питона или Яваскрипта. > стандартную библиотеку Стандартная библиотека Явы гораздо больше, чем у С++, все её уголки тем более никто не знает. Однако же пишут как-то на Яве. :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #149, #247

91. Сообщение от Аноним (89), 17-Сен-24, 17:12	+15 +/–
Ради такого дела и дела вытеснения Rust стоит подождать. Это лучше, чем +90 Gb для сборки Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #99, #175

92. Сообщение от Аноним (123), 17-Сен-24, 17:14	+4 +/–
Таким как ты не угодишь. Не тащат в С++ фичи Раста - плохо. Тащат - тоже плохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #98

93. Сообщение от Аноним (-), 17-Сен-24, 17:18	–4 +/–
Естественно. У нас есть целые поколения покалеченные сишкой.. на чем им еще писать? Когда тебе просто плевать на надежность кода и ты как "самые лучшие инжинеры тойоты" просто ребутаешь микроконтролер в случае ошибки,  то можно и на дыряшке писать. А если нет, то испольузется Ada/SPARK. Сейчас к этому списку может добавиться раст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #267

94. Сообщение от Аноним (89), 17-Сен-24, 17:18	+1 +/–
>Так боюсь уже поздно. Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #103

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

96. Сообщение от Аноним (95), 17-Сен-24, 17:24	+1 +/–
Бедный Гугл быстро нашел раст на замену плюсов (для нового кода). А гордый коммитет сейчас питыется лепить костыли. Может если бы послушали гугловцев, то идеи начали реализовывать лет 5-8 назад, а не только начинать разглагольствовать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #457

98. Сообщение от Аноним (-), 17-Сен-24, 17:29	+/–
> Не тащат в С++ фичи Раста - плохо. Кто сказал что плохо? Те самые, которые кричали "ненужОн нам ваш раст с его боровом, нам и с++ хватит!" ? Или это другие?)) > Тащат - тоже плохо. Наоборот хорошо! До них наконец-то стало доходить!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #325

99. Сообщение от Аноним (99), 17-Сен-24, 17:33	+12 +/–
> Это лучше, чем +90 Gb для сборки Rust. А почему не 900 Gb? Слабенько набрасываешь...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

101. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 17:46	+1 +/–
Опять кексперт пытается поднять своё эго в комментариях. Изначально обсуждались конкретные опции и там был werror, перечитай ветку.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #138

102. Сообщение от 12yoexpert (ok), 17-Сен-24, 17:54	–2 +/–
ну так а нефиг в 2024 писать while(*dst++=*src++)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67 Ответы: #107

103. Сообщение от Аноним (103), 17-Сен-24, 17:54	–3 +/–
> Не поздно. Тот пресловутый корован, который, как бы, идёт, но только всё ещё больше лает, чем идёт. А ты думал будет легко? Что авгиевые конюшни овнокода разгребутся на раз-ва? Что диды неосиляторы, которые одной ногой в маразме, скажут "да, конечно, я готов учить что-то новое"? Хаха, тогда твоя наивность просто необъятная. Естественно копротивеление будет максимальное. Понятно что старички будут держаться за насиженные теплые местечки и делать себе job safety любыми способами. И у меня очень большие сомнения, что в ядре будет успех. Но это не значит, что не нужно было пробовать. Вот коммитет С++ о чем-то тоже задумался
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94 Ответы: #109, #145, #176

104. Сообщение от 12yoexpert (ok), 17-Сен-24, 17:58	+/–
учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #134

105. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 18:00	+1 +/–
> что в процессорах Поэтому важно в этом направлении тоже развиваться. > поэтому Rust привлекателен Пока что это решение вендорлок, со стремным вектором развития, одной реализацией, странным сообществом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #121

107. Сообщение от Аноним (107), 17-Сен-24, 18:04	+/–
Только что писал для выноса анимации в вебе на C/WASM. Видишь ли libc чтобы дёрнуть memcpy нет в среде исполнения Wasm.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #102

109. Сообщение от Аноним (109), 17-Сен-24, 18:05	+2 +/–
> "да, конечно, я готов учить что-то новое" как в анекдоте про байкеров "вы каждый год новые". Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #119, #132

111. Сообщение от Аноним (111), 17-Сен-24, 18:06	+2 +/–
> Чистую СИшку учить может только любитель всяких некропрограмм и легаси. > Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Можно. Но... 1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках. 2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а. А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело. Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #114, #115, #147

112. Сообщение от Аноним (112), 17-Сен-24, 18:08	+/–
Просто выкинут раст и всё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

113. Сообщение от Аноним (-), 17-Сен-24, 18:09	–1 +/–
> Вот только это уже будет не С++, сломается обратная совместимость, деды и > тут будут недовольны. Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;). Просто придется сказать "проект юзает C++98". А не C++23 или сколько там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #117

114. Сообщение от Аноним (-), 17-Сен-24, 18:12	+1 +/–
> safety critical и прочие требовательные штуки на сях - тупо проще и быстрее Слава богу, в safety critical сишку чаще всего не подпускают на пушечный выстрел. Иначе бы был целый самолетопад. А где пускают - то там всякие мисры, которые к си отношения практически не имеют, один синтаксис общий. > использование своего субдиалекта Не хуже чем написание своих велосипедов на си, когда чего-то не находится в стандартной либе. Вон недавно свой сплит писали... и дописались до CVE.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

115. Сообщение от Аноним (-), 17-Сен-24, 18:16	+/–
> Можно. Но... > 1) На сях вы будете выдавать продуктивный результат сильно быстрее чем на вон тех кошмариках. Что такое "продуктивный результат"? Если х-к-х-к и в продакшн, то да. > 2) safety critical и прочие требовательные штуки на сях - тупо проще и быстрее, из-за педальности его окружения и минимализма рантайма, особенно ежели без stdlib'а. Но почему-то все равно пишут на ADA/Spark)) Потому что убогость в которой дыреней больше чем в швейцарском сыре, нужна только там где другого не знают. Вот появится там хотя бы defer из коробки, тогда мождно будет говорить)) > А про C++ хорошо написали в книжке "Scalable C". И хотя это весьма biased и специфичное чтиво от автора ZMQ - но плюсам оно наподдает весьма за дело. Так biased или за дело? Если у тебя какая-то сложнейшая задача - например писать в одну и ту же память одновременно с кучи потоков... Но везде ли есть такое? > Все перечисленные проблемы я там видел лично. В том числе и уход кодеров в астрал^W использование своего субдиалекта, а потом... потом... потом этот код майнтайнить никто не может  и наступает - ж@па! То что делает 1 кодера мощнее не обязательно что круто при командной игре. Ой, а типа у нас в ядре не свои гнутые экстеншины? И 20 лет вендорлока на один раковый компилятор? Ты ж понимаешь, что на любом языке можно сделать свой диалект, хоть на СИ, хоть на JS. Накрутить абстракций или сложных алгоритмов.. Ну чтобы быть незаменимым. Т.к мы говорим про микроконтролеры, то думаю ты в курсе про Тойоту и их "шЫдевр". Функция с цикломатикой в 150. На такое мало кто способен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

117. Сообщение от Аноним (-), 17-Сен-24, 18:19	+/–
> Ну так пусть и компилят под свой замшелый стандарт типа CPP98, никто ж не запрещает! ;). Ты тут такого не говори (с) > Просто придется сказать "проект юзает C++98". А не C++23 или сколько там. Нытье и вой будет.. до небес) Понятно что обратная совместимость это хорошо, но меру надо знать. А у комитетчиков (что СИ, что плюсы) ее нету. Так и будут тянуть поддержку инструкций для всяких допотопных архитектур "а вдруг кто-то найдет на складе 100500 миллионов 8008"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113

119. Сообщение от Аноним (-), 17-Сен-24, 18:23	+2 +/–
> как в анекдоте про байкеров "вы каждый год новые". Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки. Мало того что жужжит, так еще и топливо в аптеке покупать нужно, оно воняет.. не то что родной конский навоз! > Диды просто видят, что не осилят и свою работу и переписывание и видят, что осиляторов полным-полно Да, по кол-ву CVE видно как диды осиливают свою работу. Бедняга Линус ноет что за 33 года (наверное на печи лежали) не осилили даже базовый менеджмент памяти: "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #160, #204

120. Сообщение от Аноним (120), 17-Сен-24, 18:24	+/–
Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78 Ответы: #125, #144, #297

121. Сообщение от Аноним (-), 17-Сен-24, 18:31	–1 +/–
> Пока что это решение вендорлок, Что правда? Там те самые компании в foundation'е сидят, что и в ядре. И почти те же самые корпорации, что в коммитете С++. > со стремным вектором развития, стремное - это твое мнение, на которое, как ты догадываешься, всем плеевать но зато развитие есть, а не деградация > одной реализацией, Неправда, есть как минимум 2 компилятора + еще несколько надстроект ferrocene. Другое дело, что тут нет такого "мы не знаем как сложить 2 числа, пусть разработчики компилятора как-то сделают" > странным сообществом. Тоже оценочное мнение. На код и его работоспособность не влияет. Я понимаю, что многие по понятиям начинают заглядывать разработчикам в труселя...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

122. Сообщение от Аноним (122), 17-Сен-24, 18:35	+2 +/–
Оригинал всегда лучше копии!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #128, #327

123. Сообщение от Аноним (123), 17-Сен-24, 18:35	+/–
Так-то и Раст довольно медленно компилиться, медленнее С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #412, #448

124. Сообщение от Аноним (89), 17-Сен-24, 18:37	+/–
> Потому что их задобало, что им могут ломануть напр. телегу или фейсбучек Ломануть Фейсбучек - смишно. Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #155

125. Сообщение от Аноним (-), 17-Сен-24, 18:39	+2 +/–
> Принятия что все будет в плюсах и ни в каком расте нет необходимости? А когда будет? В 26 стандарт уже не попадает, в 29й тоже сомнительно. Т.е возможно, если они договорятся в 32-35 году на плюсовиком снизойдет благодать. > Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет. Странно, раньше талдычили что "раст не нужон! боров ваш тоже не нужон!! смартпойнтеров всем хватит!". А тут целый президент C++ Alliance говорит "там классные идеи". Вот это переобувание в прыжке))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #127, #154

127. Сообщение от Аноним (112), 17-Сен-24, 18:46	+1 +/–
Так в нынешнем стандарте и ненужен. А в будущем может ещё телепатию в стандарт примут кто знает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

128. Сообщение от Аноним (112), 17-Сен-24, 18:47	–1 +/–
Да Пёрл лучше всех.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122 Ответы: #258

129. Сообщение от Аноним (129), 17-Сен-24, 18:53	+/–
> сломается обратная совместимость Каким образом, если проверка только на стороне комрилятора?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #133, #380

130. Сообщение от Соль земли (?), 17-Сен-24, 18:54	+1 +/–
Лучше, если сломает. Явное лучше неявного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #419

132. Сообщение от _ (??), 17-Сен-24, 19:00	+/–
Хороший анекдот! Таки надо рассказать Сонечке (С)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109

133. Сообщение от Аноним (-), 17-Сен-24, 19:00	+/–
>> сломается обратная совместимость > Каким образом, если проверка только на стороне комрилятора? Не знаю. Но разработчики стандарта такие затейники, что думаю что-то придумают. Например в C23 они поменяли zero-sized reallocations with realloc are undefined behavior. Т.е был валидный код void *ptr = malloc(0); free(ptr); а вот void *ptr = malloc(4096); ptr = realloc(ptr, 0); уже UB на откуп разработчикам компилятора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

134. Сообщение от Аноним (99), 17-Сен-24, 19:02	+/–
> учи матчасть. ты понятия не имеешь, о чём говорят в этой ветке. ... и кидает ссылку да доку GCC. Чел, -Weverything - это опция clang. Хотел поумничать, но как всегда сел в лужу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104 Ответы: #140

138. Сообщение от Аноним (99), 17-Сен-24, 19:15	–1 +/–
> Изначально обсуждались конкретные опции и там был werror, перечитай ветку. Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку на новом компиляторе, если в *эврифинг* что-то добавят". Когда тебе написали, что новые проверки -Weverything сломать ничего не могут (ибо они только предупреждения), ты в ответ с умным видом упомянул -Werror. Который вообще сам по себе не ворнинг и потому в -Weverything никогда не будет добавлен. Ну а потом твои аргументы вообще съехали в "и что дальше?" и "кексперт". Опять экперт уровня "слышал звон" пытался поумничать, но сел в лужу...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101 Ответы: #162

139. Сообщение от Аноним (99), 17-Сен-24, 19:21	–1 +/–
> а на плюсах быстро всё сделал и не остаётся уже, что делать В смысле "не остается"? Если в плюсах "быстро все сделал", то у тебя еще на полгода вперед будет работы над списоком багов из-за висячих ссылок, протухших итераторов, выходов за пределы буфера, UB и прочих C++ чудес. Ты наоборот должен быть против!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #153

140. Сообщение от 12yoexpert (ok), 17-Сен-24, 19:22	+4 +/–
тебе про Фому, ты про Ерёму. иди читай, что такое -Werror
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #134

142. Сообщение от Александр (??), 17-Сен-24, 19:25	+/–
Ну, не то, что бы видали. Сам из геймдева. Стандартную библиотеку используем, ибо со своими граблями проблем больше. На соседнем проекте своя, но там исторически сложилось: игре порядка 15 лет, ещё под симбианы выпускалась. Да и то пытаются отвинтить. Что касается новых стандартов, это похоже у всех в плюсах. И дело не в том, что не нужно, а в том, что: 1. Свежие стандарты сырые. Минимум следующий жди. 2. Не очень поддержка (в пример модули те же). 3. Переход бывает затратен без особого профита.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

143. Сообщение от Александр (??), 17-Сен-24, 19:27	+/–
С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм, а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержки
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #159

144. Сообщение от Аноним (99), 17-Сен-24, 19:27	+/–
> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим, а до тебя всё не дойдет. Только вот в Расте это все уже есть здесь и сейчас. А в плюсах нет и не будет ближайшие лет 10 точно. Талдычте дальше...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #146

145. Сообщение от Александр (??), 17-Сен-24, 19:31	+/–
Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #167, #188, #194

146. Сообщение от Аноним (112), 17-Сен-24, 19:37	+1 +/–
Трехтысячный раз лично тебе повторяю. Раст это отсутствие совместимости между версиями и полное отсутствие бекпортировпния фиксов в старые версии. Ужасный синтаксис переполненный спецсимволы и ужасное комьюнити. Поэтому раст не может взлететь как концепция. Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще. Добавить новую спецификацию в будущем почему бы и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #151, #152, #174, #235

147. Сообщение от Bottle (?), 17-Сен-24, 19:38	+/–
Чел, этот миф про субдиалект уже всем порядком надоел. В любом тьюринг-полном языке можно выработать свой особый стиль написания кода. Си, к слову, ещё хуже, так как то, что решается из коробки плюсовыми шаблонами и consteval'ом, решается в Си через такой жуткий костыль как макросы, и то не полностью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #111

149. Сообщение от Bottle (?), 17-Сен-24, 19:40	+/–
Даже более того, её кто-то да знает. Например, сами разработчики из Oracle.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #228

151. Сообщение от Аноним (99), 17-Сен-24, 19:45	+/–
Как скажешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

152. Сообщение от Аноним (39), 17-Сен-24, 19:48	+/–
> Борова почекать можно в с++ прям сейчас. Умные указатели нет ничего проще. Oh my sweet summer child... Я смотрю, чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще" и "Rust не нужен".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #157

153. Сообщение от Bottle (?), 17-Сен-24, 19:49	+1 +/–
>выходов за пределы буфера Используй умные указатели. >UB В C++ используются нормальные строки, это уже улучшает ситуацию значительно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #219

154. Сообщение от Аноним (99), 17-Сен-24, 20:00	+/–
> А тут целый президент C++ Alliance говорит "там классные идеи". > Вот это переобувание в прыжке)) Так это засланный казачок от проклятых корпораций коварно пускает метастазы раковой опухоли в чистый, свободный, независимый сад C++ 😂
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

155. Сообщение от Анонимусс (-), 17-Сен-24, 20:01	–1 +/–
> Те, "кому положено" и "там разберутся", в Фейсбучеках и без взломов пасутся. Да. У них есть если не прямой доступ, то доступ по запросу "выгрузите мне все". И с этим ты ничего не сделаешь. Но речь не про них. А про угоны самих учеток для рассылки спама и просьб "дай 2000 до следующей зп". Про майнеров, который через браузер пролазят, про шифровальщиков, про скраперы банковких данных и тд. Сейчас это все чуток сложнее стало делать, обновлением флешплеера не отделаешься. А вот регулярные дыры очень помогают.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #124

156. Сообщение от slavanap (?), 17-Сен-24, 20:04	+1 +/–
Так это уже можно сделать. Определить шаблоны, перекрывающии такие операции, но без реализации или со static_assert(false) и линковка/компиляция начнёт падать. Тут, скорей, проблемы не только в указателях, но и в ссылках на объекты, у которых может истечь время жизни раньше разрушения объекта с ссылкой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

157. Сообщение от Аноним (112), 17-Сен-24, 20:05	–1 +/–
Чекер борова просто при существовании алиаса для ссылки запрещает мутации. Чем ужасно всех бесит даже адептов раста. И пишется кем угодно левой ногой настолько он приметивен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152 Ответы: #269

159. Сообщение от Аноним (-), 17-Сен-24, 20:16	+/–
> С МК у раста пока не шибко хорошо. Какие-нибудь arm - норм, > а вот тот же avr, на сколько знаю, ещё в третьей стадии поддержки Вообще не вижу смысла в avr для новых проектов. Вот совсем. Для новых есть сотни вариантов stm32, причем младшие дешевле avr и производительнее. Есть прочие ARMы, есть ESP32, есть еще куча других. А старые никто переписывать не будет. Но если вы в теме, может опровергнете такое мнение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #143

160. Сообщение от Аноним (109), 17-Сен-24, 20:20	+/–
> Угу, думаю конюхи точно так же думали про эти ваши новомодные тарахтелки. А тарахтелки тоже появились сразу в неограниченном количестве? А новые типы тарахтелок с измененным интерфейсом "конюха" как часто появляются? А тарахтелки уже имеют конструкционные зависимости от других тарахтелок? > Да, по кол-ву CVE видно как диды осиливают свою работу. да я уже понял, что диды плохие. Я не понял, почему они должны что-то осиливать в отношении раста. Вообще не понимаю зачем чего-то требовать от плохих дидов, если можно сделать хорошо. Сделаете хорошо -- диды останутся без работы и им придется выучить раст
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

161. Сообщение от Аноним (161), 17-Сен-24, 20:21	+3 +/–
С любыми этими профилями это уже будет не C++. Делайте свой язык, а там видно будет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #313

162. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:24	+1 +/–
>> Изначально обсуждались конкретные опции и там был werror, перечитай ветку. > Нет, обсуждалось конкретно твое заявление "Явное указание всех опций не сломает сборку > на новом компиляторе, если в *эврифинг* что-то добавят". Выше читай https://www.opennet.dev/openforum/vsluhforumID3/134833.html#37 и https://www.opennet.dev/openforum/vsluhforumID3/134833.html#36 где и указаны опции и если бы ты внимательно почитал, то увидел бы там -werror.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #138

163. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:27	+1 +/–
> Раст кстати тоже можно бустстрапить > github.com/rust-lang/rust/tree/master/src/bootstrap > Bootstrap build system goes through a few phases to actually build the compiler. What actually happens when you invoke bootstrap is: > 1. The entry point script (x for unix like systems, x.ps1 for windows systems, x.py cross-platform) is run. This script is responsible for downloading the stage0 compiler/Cargo binaries То есть на первом шаге бутстрапинга предлагается скачать бинари компилятора и cargo? Это бред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #364

164. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:28	+2 +/–
> И много людей собирают из исходников GCC и CLang? Clang хз, gcc - да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

165. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:29	+2 +/–
> Зачем что-то встраивать в компилятор, если проще сделать out-of-bounds прямо в коде? За свой код ответственнен ты. За компилятор нет, как и за уровни ниже. Разницу понимаешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81

166. Сообщение от Вы забыли заполнить поле Name (?), 17-Сен-24, 20:32	+1 +/–
> воровать хорошие идеи Какое слово нехорошее подобрал, явно специально. Раст, конечно, все изобрел с нуля. Многие идеи перекачевывают из проекта в проект. Что в этом плохого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

167. Сообщение от Аноним (-), 17-Сен-24, 20:32	+/–
> Проблема не в осиляторстве. Проблема в том, что за это осиляторство платить никто не будет. Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Просто так, ради искусства? Не, тогда не имеет смысла. Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT. Их зарплату тоже нужно учитывать. Добавь сверху репутационные потери, например от порчи юзерских данных. (Опенсорс проекты это не касается, тут народ привык "жрать чо дали" главное открыто и бесплатно). А может еще штраф за утечку прилетит.. это у нас 40к рублей, а по GDPR может и 4% годового дохода. С этой точки уже не так и дорого может получится. > Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать. Плюс пайплайн сборки курочить. На это добрый мес уйти может вполне, а за чей счёт? Естественно за свой. Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр. Или переделать старое. Особенно если достаточно сделать обертки и переписать самые стремные места.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #198, #207

169. Сообщение от Аноним (175), 17-Сен-24, 20:58	–1 +/–
Спали, спали, зачем проснулись? Итак, какие минусы у данного решения? Ошибки, в частности ошибка на миллиард долларов(наличие null) из плюсов никуда не денется. Существующие проекты, если и будут переписываться, то всё это будет крайне медленно. Понять, переписан уже какой-то проект или нет будет крайне затруднительно, особенно для тех, кто не знаком именно с плюсами. Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороны. Это не раст, в котором нужно оборачивать код в unsafe. Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные места, в том числе с возможностью циклических зависимостей(аналогичная проблема в си), продолжая всякими шаблонами и прочим. Судя по всему, коммитет это не волнует. Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить. Стандарт плюсов уже огромен, со всем этим он станет ещё больше. И самое главное: появление этих возможностей никак не заставит разработчиков им следовать. Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей. Так что закапывайте уже плюсы. Хотите - создавайте новый язык, хотите, развивайте любой существующий. Посмотрите на фичи других языков, типа зависимых типов в ATS.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #205, #206, #208, #209, #210

174. Сообщение от Аноним (175), 17-Сен-24, 21:11	+/–
>Раст это отсутствие совместимости между версиями https://doc.rust-lang.org/edition-guide/introduction.html >Ужасный синтаксис переполненный спецсимволы Взяли худшее от семейства си. Кресты так же уродливы, со своими cout << "123"; T<A> a; [&, i]{}; [=, *this]{ };
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146 Ответы: #231, #232

175. Сообщение от Аноним (175), 17-Сен-24, 21:17	+/–
>Это лучше, чем +90 Gb для сборки Rust. А зачем вы его пересобираете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91 Ответы: #213, #250

176. Сообщение от Диды (?), 17-Сен-24, 21:21	+1 +/–
>Что диды неосиляторы, которые одной ногой в маразме Как же вы задрали! Всё что есть в индустрии - это написали мы, диды. Пишем как считаем нужным и указывалка ещё у вашего поколения не выросла
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #190

186. Сообщение от Аноним (175), 17-Сен-24, 22:29	+1 +/–
>Уже запилили >First appeared 8 February 2016; 8 years ago >Preview release 0.13.0 Сейчас языка нет, есть только идея языка, без обратной совместимости. И с учётом времени прошедшего после начала разработки, в ближайшем времени ничего не будет. Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки. Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #271, #318

188. Сообщение от Аноним (175), 17-Сен-24, 22:41	+/–
>Вот есть проект, хотя бы на 500тыс строк. Сколько надо влить, дабы его переписать на раст? Допустим, частично, ок. Тогда ловим траблы со связыванием: обиблиотечивание того, что не особо надо обиблиотечивать Нужно переписывать плавно и неспеша. https://habr.com/ru/articles/511478/ >На это добрый мес уйти может вполне, а за чей счёт? Не важно. Поскольку функционал перетекает плавно, можно хоть десять лет делать. А делается это за счёт тех, кому данный проект нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #211, #436

190. Сообщение от Аноним (175), 17-Сен-24, 22:45	+/–
>Всё что есть в индустрии - это написали мы, диды. Спасибо, диды, за IE 6, сам по себе такой бы монстр не появился. А ведь сколько подобных монстров диды насоздавали: SysVinit, bash, perl, make, autotools и куча прочего. До сих пор от всего не избавились.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176

192. Сообщение от maxis11 (ok), 17-Сен-24, 23:00	+1 +/–
Я так и не понял почему надо создавать новый продукт, если можно подключить clang-tidy в CI/CD с проверкой на cppcoreguidelines-owning-memory (можно ещё кучу дополнительных проверок взять)? Суть такова: в CI/CD добавить этап, который будет блокировать PR изменений если они не прошли проверку линтера, зе энд.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #202, #300

194. Сообщение от adolfus (ok), 17-Сен-24, 23:19	+5 +/–
Есть проект на коболе. Сколько нужно заплатить, чтобы переписать его на <...>? Есть проект на фортране. Сколько нужно заплатить, чтобы переписать его на <...>? Так вот, никто никому ничего платить не будет, поскольку все написанное на "опасных", бл..ть, для тупых программиздовъ языках, работает без осечек. Пример: "дид" Д. Кнут xep знает когда написал TeX. Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается. Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #241, #242

195. Сообщение от yet another anonymous (?), 17-Сен-24, 23:22	+/–
cargo, доставка on-the-fly, и т.д. Конечно, rust привлекателен. Для доставки чего надо куда надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

196. Сообщение от yet another anonymous (?), 17-Сен-24, 23:33	+/–
При наличии indirect pointers? Флаг вам в руки и ветер в спину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

198. Сообщение от Аноним (109), 17-Сен-24, 23:50	+/–
> Или у нас просто куча багов, и пограммисты сидят днями раcковыривая очередной SIGABRT. только проблема в том, что куча багов у нас уже есть и теперь нужны еще программисты чтобы переписывать все. Их зарплату тоже нужно учитывать. А новые программисты нужны потому что > Добавь сверху репутационные потери, из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество) А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь. > Вопрос что будет выгоднее, постоянно тратить деньги на заплатки и затыкание дыр. там еще вопрос, как потом жить с тем, что переписали. В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить > Особенно если достаточно сделать обертки и переписать самые стремные места. и посчитать как эти обертки повлияют на производительность
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #244

200. Сообщение от Аноним (201), 18-Сен-24, 00:55	+3 +/–
> У нас их просто куча! А знаешь почему? Потому что есть стандарт. > Даже пованивает Пока тут ты пованиваешь только.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #216

201. Сообщение от Аноним (201), 18-Сен-24, 00:56	+/–
Ты не понял.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72

202. Сообщение от Аноним (201), 18-Сен-24, 00:58	+/–
> clang-tidy Это отдельная тулза. Нужно в стандарте чтобы что-то было прямо в компиляторе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192

203. Сообщение от Аноним (201), 18-Сен-24, 01:00	+1 +/–
> Видимо ощутили, как от плюсовиков денежки утекают, вот и начали суетиться и воровать хорошие идеи. Не пишешь на плюсах, вот и бесишься!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

204. Сообщение от RM (ok), 18-Сен-24, 01:02	+/–
> "You'd think that all the basics would have been fixed long ago, but they're not. We're still dealing with basic issues such as memory management." Сдается мне что это не про аллокатор, а про 12309 и обработку oom.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119

205. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:04	+/–
> Код хромиума уже может собираться больше суток на среднем ноутбуке, упираясь как в количество ядер, так и в количество оперативки, без возможности как-то это ускорить. На расте он быстрее будет собираться что-ли? > типа зависимых типов И зачем они если тебе не нужны доказательства?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #220

206. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:05	+2 +/–
> Стандарт плюсов уже огромен, со всем этим он станет ещё больше. А зачем тебя это так волнует? Вон в расте стандарта никакого нет, каждый релиз новую порцию апи публичат (и не малую).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #226

207. Сообщение от Александр (??), 18-Сен-24, 01:07	+/–
Не знаю, как там на сях, у нас sigabrt 2-5 раз в год (по большей части либо в древнем C-style коде, либо в рендере OpenGL, где из-за критичности к скорости на расте скорее всего влепили бы unsafe). При этом гораздо больше проблем бывает с use after free на пуле (раст такое ловить не сможет скорее всего), когда нужно втыкать, какие переменные должны уйти в пул, а какие нет; анимациями, развалом контента. То есть, то, где раст мимо. И таким образом, ради пары багов год (по 2-4ч на каждый) должны потратить от мес до пары лет, дабы переплыть на раст? > порчу юзерских данных Клиент мобильной MMO RPG. Не знаю, что там испортить можно. Да и по sigabrt данные скорее всего не запортишь. Быстрее другими багами (копипастой например). > GDPR Снова мимо: данные на сервере. Он на шарпах. > естественно за свой То есть мне, как программисту, предлагаете сидеть вместо 8 часов все 24 часа в сутки и отверженно переводить проект на раст?) Если для вас это норм, вы мазохист. > самые стрёмные места Не менее 30% проекта
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167

208. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:07    Скрыто ботом-модератором	+/–
> Некоторые пишут на си с классами, теряя часть гарантий плюсов, типа умных указателей. Ну Кармак так id tech 4 написал, а растоманы за 14 лет не шмогли. Может дело в чем-то другом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169

209. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:10	+/–
> Время компиляции: в плюсах есть десятки разных способов затормозить компиляцию, начиная с возможности инклюдить произовльные файлы в произвольные места То есть ты предлагаешь СПЕЦИАЛЬНО делать ерунду и говорить что все плохо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #222

210. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 01:12	+3 +/–
>  Часть проектов будут сочетать в себе безопасные и небезопасные части, при этом любой коммит будет менять их в произвольные стороны У нормальных проектов есть различные чекеры (тот же clang-tidy, который можно настроить на следование различныи фичам) и ревью. А проблема, которую ты описываешь - это общая проблема всех развивающихся во времени систем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #169 Ответы: #223

211. Сообщение от Александр (??), 18-Сен-24, 01:13	+/–
> Нужно переписывать плавно и неспеша. Статья про си. С плюсовым такое не проканает: минимальная переписываемая единица будет класс, да и то не всегда, если он покрыт шаблонной магией. А это от дня до недели разработки + тестирование > А делается это за счёт тех, кому данный проект нужен Им нужен проект и деньги с него, а не защита от каких-то мифических багов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

212. Сообщение от Аноним (212), 18-Сен-24, 01:29	+1 +/–
вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ? капец просто, сколько это уже можно мусолить.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #215, #245, #251, #273, #306

213. Сообщение от Прохожий (??), 18-Сен-24, 01:45	+4 +/–
Как-то время скоротать, например. Видимо, других, более полезных занятий не нашлось.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

215. Сообщение от Аноним (215), 18-Сен-24, 02:27	+/–
Опять про Настоящих Сишников™®© заливает. У Линуса спроси, он разъяснит как они там тридцать лет в ядре по этим граблям зодят и конца-края этому не видно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #218, #229, #249

216. Сообщение от Прохожий (??), 18-Сен-24, 02:44	+/–
>Потому что есть стандарт. Конечно, причина не в этом. Обусловлено это всё относительной простотой языка и разнообразием архитектур. Отсутствие стандарта для того же Rust не помешало разработчикам gcc начать создание для него компилятора.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #200 Ответы: #261, #321

217. Сообщение от Прохожий (??), 18-Сен-24, 02:49	–1 +/–
Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами. Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти. Люди пытаются с этим бороться с помощью безопасных языков. Вроде, простая мысль. А поди ж ты, приходится разжевывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #289

218. Сообщение от Аноним (218), 18-Сен-24, 03:17	+1 +/–
Он наверное про RAII.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

219. Сообщение от Аноним (175), 18-Сен-24, 04:13	+/–
>Используй умные указатели. В лучшем случае получится только в своём коде, но не в библиотечном.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153 Ответы: #256

220. Сообщение от Аноним (175), 18-Сен-24, 04:16	+/–
>На расте он быстрее будет собираться что-ли? А при чём тут раст? Я писал про то, какой монстр плюсы >если тебе не нужны доказательства С чезо вдруг тагие утверждения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205 Ответы: #224

222. Сообщение от Аноним (175), 18-Сен-24, 04:20	+/–
>СПЕЦИАЛЬНО делать ерунду Во-первых, хорошие языки ерунду не компилируют, а пишут ошибку. Во-вторых, я крайне сомневаюсь, что в команде хромиума сидит злодей и внедряет пакости. Просто компилятор плюсов тормозит из-за сложности последних
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #209 Ответы: #290

223. Сообщение от Аноним (175), 18-Сен-24, 04:27	–1 +/–
>У нормальных проектов есть различные чекеры Вот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее. И редко, когда всё совпадает. Вот когда анализатор встроен в язык, тогда всё работает из коробки. В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из раста
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #210 Ответы: #291

224. Сообщение от Аноним (175), 18-Сен-24, 04:29	+/–
>С чего вдруг такие утерждения?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220 Ответы: #292

226. Сообщение от Аноним (175), 18-Сен-24, 04:43	+/–
>А зачем тебя это так волнует? Вопрос возможности чтения кода посторонними людьми и понимания самим автором. А то с этим частенько бывают проблемы, когда автор сам не понимает, как должен работать его код >новую порцию апи публичат Есть огромная разница между добавлением новой семантики и новым апи. При добавлении апи, язык остаётся тем же, порой даже это можн о было бы реализовать и в старой версии, ну а с новым апи нужно в корне менять подход
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206 Ответы: #293, #294

228. Сообщение от Аноним (228), 18-Сен-24, 06:53	+1 +/–
Имеется ввиду, что ни один человек её целиком от и до не знает. Разумеется эти знания размазаны по большому числу людей...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149

229. Сообщение от Аноним (229), 18-Сен-24, 07:17	–1 +/–
std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. Прям капец трудно, дааа ? 1000 страниц прочитать надо, даааа ? Для клас-обертка вокруг ресурса с освобождением в деструкторе тоже пишется без каких-либо проблем... раст делает это "по умолчанию" с++ делает только то о чем его явно попросили. Затем статческий анализ не позволит васяну использовать чистые указатели и ресурсы без обертки с деструктором. Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215 Ответы: #272, #286, #307

231. Сообщение от bOOster (ok), 18-Сен-24, 07:37	–1 +/–
В С++ у тебя есть выбор писать коряво спецсимволами либо в нормальный синтаксис. В расте этой возможности много где нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174 Ответы: #240, #270, #308

232. Сообщение от bOOster (ok), 18-Сен-24, 07:40	+/–
А писать несколько операторов в одну строчку - это неизлечимая болезнь в мозгу недопрограммиста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #174

233. Сообщение от Проходил мимо (?), 18-Сен-24, 07:45	–1 +/–
Rust - это нормальный язык. В чем-то даже офигенный. Просто факт в том, что не все иксперды с OpenNET способны его осилить. Реально некоторые косяки есть не с самим языком а с отдельными вещами в стандартной библиотеке Rust, но их, при желании, так или иначе можно обойти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #315

235. Сообщение от Проходил мимо (?), 18-Сен-24, 08:03	+/–
Не надо пороть чушь - ей больно. Написанное вами показывает, что в предмете вы не разбираетесь от слова совсем и язык Rust просто не осилили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

237. Сообщение от bOOster (ok), 18-Сен-24, 08:18	+3 +/–
Точно. на текущий момент есть always acceptable #pragma region .... #pragma endregion .... Реализовать логику #pragma region safe/unsafe Особой проблемы нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

238. Сообщение от bOOster (ok), 18-Сен-24, 08:23	+/–
Не осиливаешь все навороты - пользуйся только тем что осиливаешь. Никаких проблем с этим нет. Шаблоны мощная штука - но многие их реализации практически нечитаемы и сложны в понимании и отладке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

240. Сообщение от Проходил мимо (?), 18-Сен-24, 08:26	–1 +/–
Не будет ли любезен многоуважаемый джинн привести небольшой пример кода на Rust с "корявыми спецсимволами" и "ненормальным синтаксисом"? Как человек, который иногда пишет всякие полезные вещи на данном языке, мне стало очень интересно посмотреть на подобное, потому что я, в своей скромной практике, с подобным почти не встречался. Лично мне вот не нравится синтаксис, когда надо руками указывать время жизни - на мой взгляд решение с апострофом явно неудачное и невнятное. Все остальное вполне нормальное и достаточно понятное. Пример кода для того, чтобы те, кто не в курсе про Rust вообще и про время жизни в частности, поняли о чем речь: //------------------------------------------------------------------- //  Структура для описания поля. Время жизни 'a необходимо, чтобы ссылка //  на внешний буфер buf внезапно не оказалась висячей pub struct  Field<'a> {     //  Ссылка на внешний буфер для разбора     buf:    &'a[u8],     //  Позиция начала текущего поля     f_pos:  usize,     //  Флаг окончания строки     endl_flag:  bool, } //------------------------------------------------------------------- //  Методы для структуры Field impl<'a>    Field<'a> {     //-----------------------------------------------------------     //  Сохраним ссылку на внешний буфер     pub fn  from_buf( slice: &'a[u8] ) -> Field<'a>     {         // Конструктор возвращает экземпляр структуры Field, в которой сохранена ссылка         // на внешний буфер, из которого потом будут выделяться поля         Field         {             buf : slice,             f_pos:  0,             endl_flag:  false,         }     }     //----------------------------------------------------------- } //-------------------------------------------------------------------
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231

241. Сообщение от Аноним (241), 18-Сен-24, 08:33	–1 +/–
> Может просто признать, что 99% так называемых "программистов" тупые дoлбойoбы, не способные без сработавшего UB даже helloword написать. О, ну это классика. "Зачем вы пишете с багами? Просто пишите без багов!".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194

242. Сообщение от Аноним (-), 18-Сен-24, 08:44	+/–
> работает без осечек. Только если это хеллоуволрд) Посмотри на ядро где менеджмент памяти до сих пор с базовыми ошибками, по мнению Торвальдса. Или на ХОрг - просто куча овнокода, где ошибки живут по 30 лет. > Одна из тех программ, которые не нуждаются в постояном дописывании/переписывании. И никаких проблем с выделением/освобождением памяти и выходом за какие-то пределы там не наблюдается. Отлично! Нам повезло и у нас есть одна программа, которая не подарит рут, когда ты в нее напишешь 28 бекспейсов! > не способные без сработавшего UB даже helloword написать. Что значит "сработавшего UB"? UB оно или есть, или нету. Причем что в дыряшке, что в плюсах int a + int b - это уже UB! И по стандарту, результирующий код уже не strictly conforming. Так что удачи тебе написать helloword, без UB. Спасибо качественному "стандарту"))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #194 Ответы: #418

244. Сообщение от Аноним (-), 18-Сен-24, 08:56	+/–
> только проблема в том, что куча багов у нас уже есть и На божественной сишечке куча багов? А не еретик ли ты))? Но даже если эта куча есть, а вы еще не разорились.. то значит пользователи привыкли. > теперь нужны еще программисты чтобы переписывать все. Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода > из-за репутационных потерь мы не можем не фиксить ту кучу багов, что уже есть. И не выкатывать новые фичи, мы тоже не можем (хотя может и можем ограничить их количество) Ты что взял и всю команду перекинул напереписывание? Но зачем? У вас должен быть какой-то запас по капасити. В крайнем случае, не все фичи одинаково полезны, и минорные низко-приоритетные можно отложить. > А потом новый код надо будет еще усиленно тестировать, чтобы не появилось еще больше репутационных потерь. Судя по огромной куче багов - вы его вообще не тестируете. Так что особо ничего не поменятся. > там еще вопрос, как потом жить с тем, что переписали. А как люди живут, когда в проекте одновременно C, C++, Java и Kotlin? (Это реальный пример - андроид). Вот гугловцы новый код пишут на Расте, вот с таким результатом "To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code." security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html > В погоне за переписыванием можно получить кадавра, в которого уже ничего нового нормально не добавить Ну так делай нормально, нормально и будет. > и посчитать как эти обертки повлияют на производительность Никак. Уже считали, там на уровне погрешности измерений.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #198 Ответы: #268

245. Сообщение от Аноним (249), 18-Сен-24, 09:07	+/–
>>> запросил памяти отработал, освободил. кто отменил культуру написания кода ? <<< Это хорошо звучит только в теории, на практике это не работает, - просто смиритесь с этим! Rust придумали не просто так!!!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #253

247. Сообщение от Писатель (?), 18-Сен-24, 09:09	+/–
> Стандартная библиотека Явы [ ... ], все её уголки тем более никто не знает - JavaDoc? - Не-е ... Не слышали ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #90 Ответы: #274

249. Сообщение от Аноним (249), 18-Сен-24, 09:14	+/–
Ну верит человек до сих пор в Деда мороза, - пускай и дальше верит!:)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #215

250. Сообщение от Аноним (250), 18-Сен-24, 09:15	+/–
Чтобы пересобирать, надо для начала хотя бы собрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175 Ответы: #262, #310

251. Сообщение от Аноним (250), 18-Сен-24, 09:23	+/–
При этом котроль выхода за границы массива, как бы, не помешает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212

253. Сообщение от Аноним (250), 18-Сен-24, 09:28	+/–
Конечно не просто так, а из-за NIH.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #245

255. Сообщение от Аноним (250), 18-Сен-24, 09:30	+/–
А не остановившись, что же добавлять дальше?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

256. Сообщение от Аноним (250), 18-Сен-24, 09:31	+/–
А, ну да, Rust же не используют библиотеки, написанные на C.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #219 Ответы: #266

257. Сообщение от n00by (ok), 18-Сен-24, 09:36	+/–
> В геймдеве в гробу видали как новые стандарты C++, так и стандартную > библиотеку полюсов. EASTL stands for Electronic Arts Standard Template Library. It is a C++ template library of containers, algorithms, and iterators useful for runtime and tool development across multiple platforms. It is a fairly extensive and robust implementation of such a library and has an emphasis on high performance above all other considerations. https://github.com/electronicarts/EASTL
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

258. Сообщение от Аноним (250), 18-Сен-24, 09:36	+/–
Нишевый язык. Можно сказать, DSL.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

259. Сообщение от n00by (ok), 18-Сен-24, 09:40	+/–
N4860 - 1829 страниц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

261. Сообщение от Аноним (112), 18-Сен-24, 09:41	+/–
Начать, начать, Карл!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216

262. Сообщение от that is not this (?), 18-Сен-24, 09:43	+/–
beyond from beyond from rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250

265. Сообщение от n00by (ok), 18-Сен-24, 09:51	+/–
Таким образом дальше может возникнуть подозрение, что кого-то после знакомства с OCaml посетила гениальная идея сделать члены class по умолчанию const и перенести часть работы сборщика мусора на этап трансляции. Но потом что-то пошло не так и автор Rust нарулил из проекта.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #451

266. Сообщение от Аноним (241), 18-Сен-24, 09:59	–1 +/–
Какое мастерское приплетание Расте в ветке обсуждения C++...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #256 Ответы: #323

267. Сообщение от cr (??), 18-Сен-24, 10:04	+1 +/–
что вы носитесь из темы в тему с этой тоётой? какбудто она единственная кто пишит МК на сях, а остальные на божественном^W расте^W хз чём. в чём язык виноват, если тоёта набрала чудаков
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

268. Сообщение от Аноним (109), 18-Сен-24, 10:05	+/–
> На божественной сишечке куча багов? А не еретик ли ты))? так вроде никто не утверждал, что на божественной сишечке не делают логических ошибок > Выдели одного-двух, пусть работают по принципу парето и закрывают самые опасные участки кода ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью > Ты что взял и всю команду перекинул напереписывание? а мы про какой проект говорим? Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика? > У вас должен быть какой-то запас по капасити. кому должен? У нас с тем кому должен товарно-денежные отношения? > Судя по огромной куче багов - вы его вообще не тестируете. тогда смысл от переписывания? > А как люди живут, когда в проекте одновременно C, C++, Java и Kotlin? там следующее предложение продолжает мысль. Зачем отвечать на часть мысли? > Ну так делай нормально, нормально и будет. а при чем тут раст? > Уже считали, там на уровне погрешности измерений. дай ссылку на исследование
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #244 Ответы: #275

269. Сообщение от Аноним (241), 18-Сен-24, 10:15	+/–
> Чекер борова просто при существовании алиаса для ссылки запрещает мутации. Так может в этом есть какой-то смысл? Или для всего непонятного у тебя есть одно универсальное объяснение, что авторы - дураки? > И пишется кем угодно левой ногой настолько он приметивен. Молодец: ты еще раз подтвердил утверждение выше "чем меньше эксперт шарит в C++ и Rust, тем сильнее у него "нет ничего проще".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157

270. Сообщение от Аноним (241), 18-Сен-24, 10:16	–1 +/–
> В С++ > нормальный синтаксис Ты же шутишь, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231

271. Сообщение от Самый умный аноним (?), 18-Сен-24, 10:27	+2 +/–
> можно за условные пару месяцев реализовать первую версию Пара месяцев это для новичков. Ты за 21 день бы сделал новый язык
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186

272. Сообщение от Аноним (241), 18-Сен-24, 10:27	–1 +/–
> std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. > Все загоны растоманов от не знания базовых вещей, что етсь в с++ с 11 стандарта. Лол. Если бы у тебя было знание базовых вещей C++, то был бы в курсе, что проблема владения не ограничивается возней с heap и RAII. Это проблема в дырявом фундаменте языка. Как твой shared_ptr поможет в этом: auto a = 0; auto& b = std::max(a, 1); Вот у тебя b - висячая ссылка. > с++ делает только то о чем его явно попросили. C++ ничего не делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #337

273. Сообщение от Аноним (241), 18-Сен-24, 10:32	+/–
> вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? Не понимаешь потому, что проблема владения не ограничивается возней с new/delete. В плюсах ты можешь в это вляпяться вообще без динамического выделения памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #277

274. Сообщение от Аноним (274), 18-Сен-24, 10:45	+/–
И Doxygen, ага. Что сказать-то хотел?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #247

275. Сообщение от Аноним (-), 18-Сен-24, 10:46	+/–
> так вроде никто не утверждал, что на божественной сишечке не делают логических ошибок Так проблема не в логических ошибках. Против них реально работает только формальная верификация - но это просто тонны денег. > ну то есть сделать как было в ядре. Там как раз было трое, но один уже не смог переписывать обвязки для раста с нужной скоростью И в итоге ядро как было дырявым, так и осталось. У нас же нет времени подождать, нам надо CVE плодить. > а мы про какой проект говорим? про твой в 500k loc'ов > Про такой, где тысячи разработчиков и 1-2 будут переписывать долго и печально или про такой, где всего 1-2 разработчика? У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую. > кому должен? У нас с тем кому должен товарно-денежные отношения? Себе хотя бы) Ну чтобы если вдруг заболел или вдруг второго разработчика сбил автобус, то не было просранных сроков. Но если ты про опенсорс, то да, тут всем плевать на сроки, приоритезацию, планирование. Как-то оно катится и пусть катится. > тогда смысл от переписывания? Чтобы багов стало меньше) Можно же переписывая часть багов исправить. >> Ну так делай нормально, нормально и будет. > а при чем тут раст? Потому что ни на плюсах, ни на дыряшке уже пол века не выходит. >> Уже считали, там на уровне погрешности измерений. > дай ссылку на исследование можешь посмотреть бенчи benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #268 Ответы: #296

277. Сообщение от Аноним (249), 18-Сен-24, 11:09	+2 +/–
Да, забей! Таким бесполезно что-то объяснять; cразу видно, что человек никогда не писал ничего серьёзного на С++, иначе он бы не писал глупости в стиле - да это же элементарно! ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustc, который скажет мне если я, скажем на 10 часу, когда я устал и моя концентрация упала, попытаюсь сделать какую-нибудь "элементарную" глупость, что я не прав, где именно, в чём не прав и самое главное как это исправить, вместо того, чтобы разбираться в "шаблонных портянках C++" из серии - упс извините, но "что-то" не так!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #273 Ответы: #279, #288

279. Сообщение от Аноним (112), 18-Сен-24, 11:24	+1 +/–
Только на раст для той же работы тебе понадобится 60 часов. Но да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #281, #282, #379

281. Сообщение от Аноним (281), 18-Сен-24, 11:40	+1 +/–
> Только на раст для той же работы тебе понадобится 60 часов. Ты наверное написал тысячи строк на Расте, раз так уверенно утверждаешь. Хотя, скорее всего, ты не написал ни одной. У гугла как-то получается, что раст-команды продуктивнее чем плюсовики. Но туда конечно не васянов с улицы берут. > да компилятор тебе точно скажет и много плохих слов про себя от него узнаешь. Компилятор не анон, он если ругается - то по делу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279 Ответы: #339

282. Сообщение от Аноним (249), 18-Сен-24, 11:45	+/–
>>> Только на раст для той же работы тебе понадобится 60 часов. <<< Разумеется в С++ есть херова туча библиотек почти на все случая жизни в отличии от Раста, - и именно поэтому вам кажется что писать код на плюсах быстрее, - и это нормально! Однако, если вы Раст не знаете, то вполне возможно вам и этого будет мало (и как это часто и бывает) вы вообще ничего не напишите!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279 Ответы: #340

283. Сообщение от Аноним (283), 18-Сен-24, 12:37	+/–
нет в C++ move-семантика изначально убогая, т.к. делалась с оглядкой на обратную совместимость искать "c++ destructive move", если что
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

284. Сообщение от Аноним (285), 18-Сен-24, 13:15	+/–
Я как бы знаю, игра слов намеренная.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #287

285. Сообщение от Аноним (285), 18-Сен-24, 13:17	+1 +/–
Как будто сабж не экскрементальный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

286. Сообщение от Facemaker (?), 18-Сен-24, 13:21	+/–
>от не знания базовых вещей Вот эта вот системная безграмотность очень красноречива.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

287. Сообщение от ProfessorNavigator (ok), 18-Сен-24, 13:22	+/–
> Я как бы знаю, игра слов намеренная. Ну тогда будем считать, что я шутку оценил))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #284

288. Сообщение от Аниним (?), 18-Сен-24, 14:20	+/–
> ПС: Лично у меня бывали случаи когда приходилось писать код по 10, а то и по 12 часов в день. В таких случаях, лично я предпочту компилятор rustc А йа лучше меньше часов попрогаю :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #277 Ответы: #320

289. Сообщение от Аноним (29), 18-Сен-24, 14:23	+/–
> Твой комментарий выше - это мешанина тёплого с мягким, или мух с котлетами. а кто-то отменил существование котлет из мух? азиаты с вами бы поспорили бы, у них там бигмак из тараканов есть, это как про "мешанину Канта", Кантом надо быть, чтобы понять, короче, проехали. > Небезопасные языки добавляют проблем к потенциально нестабильной работе аппаратной памяти. Нету такого определения "небезопасТные" или "безопасТные" языки. Определение "потенциальная нестабильность" не приемлема там где необходима "надежность" аппаратная. Вы хотите сказать, что допустимо, что-либо "аппаратно-нестабильное" использовать там где необходима "надежность"? > Люди пытаются с этим бороться с помощью безопасных языков. Нету определения "безопасТных" языков. То есть люди должны были строить мельницы не похожие на мельницы, чтобы доны Кихоты с ними не сражались, за место того, чтобы лечить самих донов? > Вроде, простая мысль. А поди ж ты, приходится разжевывать. Ну да, простая, вот и я разжевал: «Класть все яйца в одну корзину» — народная поговорка, которая говорит о том, что как раз не стоит этого делать. Потому как положил все яйца в одну корзину, уронил ее нечаянно — и остался без яиц.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #217

290. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 14:54	+1 +/–
Нужно переписать весь хромитам на раст и померить время сборки на холодную. А без этого твои слова ничем не доказуемы. У них много кода, вот он долго и компилится первый раз. К слову в расте раньше не было инкрементальной сборки и Дропбокс плакался по этому поводу достаточно сильно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222 Ответы: #299

291. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 14:58	+1 +/–
> Вот вы и назвали важный недостаток. Нужно, чтобы повезло и в проекте оказался анализатор, чтобы договорились включить диагностику, чтобы если диагностика выдаст пару сотен тысяч ошибок её не отключили, чтобы библиотеки тоже проверялись и так далее. Если у тебя в этом месте проблемы, то и срастом такие же будут. Кто будет следить, что я не расставляю ансейфы для обхода борова? Кто будет следить, что я не подключаю левые либы? Итд итп. К слову даже в расте есть клиппи, а это отдельная тулза. > В реальности же целый гугл не смог реализовать парсер json, и им пришлось брать его из раста Бред.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #223 Ответы: #298, #301

292. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:07	+/–
Потому что одна из основных задач для завтипов — это различные пруверы типа Идриса и кока. Если нет, то приведи пример зачем нужны завтипы для бытового программирования. Возможность взять голову пустого списка и получить ошибку не принимается.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224 Ответы: #305

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

294. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 15:12	+1 +/–
> Есть огромная разница между добавлением новой семантики и новым апи. И где кроме 11 стандарта как-то в корне меняли семантику? Ты не переживай, раст это не про стабильность компилятора, там семантику сменят и узнаешь об этом по сломаной сборке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #226 Ответы: #303

295. Сообщение от Аноним (295), 18-Сен-24, 16:10	–1 +/–
> теперь мне ту же работу нужно будет делать в 5 раз дольше ... а на плюсах быстро всё сделал и не остаётся уже, что делать Тебе? Может быть. У середнячков-неосиляторов нового всегда так. А у чуть более хороших разработчиков, у которых мозги еще не заржавели, вот так: Ларс Бергстром (технический директор Google): "Команды, работающие на Rust, в два раза продуктивнее команд, использующих C++". (это он в марте на какой-то конференции заявлял) "...Some additional context on these two specific claims: Google found that porting Go to Rust "it takes about the same sized team about the same time to build it, so that's no loss of productivity" and "we do see some benefits from it, we see reduced memory usage [...] and we also see a decreased defect rate over time" On re-writing C++ into Rust: "in every case, we've seen a decrease by more than 2x in the amount of effort required to both build the services written in Rust, as well as maintain and update those services. [...] C++ is very expensive for us to maintain." Так что так. "C++ очень дорог для нас в обслуживании". Причем "дорог" здесь, как ты понимаешь, не положительная оценка. С++ как раз, для таких, как ты, которые "...мне ту же работу [c C++] нужно будет делать в 5 раз [в два раза] дольше, а мне кредит за дом платить и вообще деньги откладывать...". А главное! главное! - потом годами сопровождать, ошибки искать и фиксить. Главное неспеша, по одной, чтобы до пенсии хватило. Ну прям как в том анекдоте про юристов отца и сына.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #54 Ответы: #324

296. Сообщение от Аноним (109), 18-Сен-24, 16:23	+/–
> Так проблема не в логических ошибках. Проблема, что их тоже надо исправлять Но это не я еретиков каких-то рассмотрел > И в итоге ядро как было дырявым, так и осталось. > У нас же нет времени подождать, нам надо CVE плодить. так а сколько ждать? В комментариях какие-то абстрактные требования и судя по всему в обычной манере "нужно вчера" Как потребитель — я железки купил и мне нужна поддержка в ядре, а не ждать когда кто-то что-то перепишет. Как разработчик — конкуренты тоже подождут? > У тебя 1-2 тащат такой проект в одиночку? Я им слегка сочувствую. это не я предложил выделить 1-2 на переписывание без обсуждения сложности проекта > Себе хотя бы) себе я не должен работы, на которую нет спроса и которая не оплачивается. Личные проектики — если он вдруг кому-то внезапно понадобилось (и они это как-то нашли), то сами перепишут, проекты конторы — контора не заинтересована. > Чтобы багов стало меньше) > Можно же переписывая часть багов исправить. или наоборот добавить, гарантий никто не дает > Потому что ни на плюсах, ни на дыряшке уже пол века не выходит. так и причем тут раст? Судя по статьям, на раст выходит сильно по разному > можешь посмотреть бенчи там нет бенчмарков гипотетических оберток в гипотетическом проекте, гипотетически переписывываемом на раст Вспомнил как "переписали" ioquake на раст, почти пять лет прошло. Я тогда почти поверил
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #275

297. Сообщение от Аноним (295), 18-Сен-24, 16:25	+/–
> Принятия что все будет в плюсах и ни в каком расте нет необходимости? Так мы тебе это уже который год это талдычим О какое виртуозное переобувание в воздухе. Лицемеры. Вы который год уже талдычите, что Настоящему Погроммисту все эти ваши боровы чекеры и битиЕ компилятором линейкой по рукам не нужно, ибо Он, Богоподобный Погроммист, сам всё знает и умеет, и, главное, НЕ ОШИБАЕТСЯ (а кто ошибается, те не настоящие и гнать их в дворники). А тут такое.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #120 Ответы: #326

298. Сообщение от Аноним (295), 18-Сен-24, 16:42	+/–
> Кто будет следить, что я не расставляю ансейфы для обхода борова? Тут два варианта - у вас есть код-ревью или ты сам себе хозяин.   Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать. Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора.   Ну а если ты сам себе начальник, то, получается, сам себе в штаны накладываешь и вообще не будет разговора об "кто следить будет" - сам себя обманываешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #330, #331

299. Сообщение от Аноним (310), 18-Сен-24, 16:46	+/–
>Нужно переписать весь хромитам на раст У вас болезненная зацикленность на расте? >А без этого твои слова ничем не доказуемы. Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.dev/opennews/art.shtml?num=56475 >У них много кода, вот он долго и компилится первый раз. Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема выше решится сама собой, без необходимости строчить огромные патчи. А даже если патч примут, то снова разведут бардак.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #290 Ответы: #328, #329, #334

300. Сообщение от Аноним (295), 18-Сен-24, 16:47	+/–
Гуглу всякие "анализаторские" инструменты и фаззинг-тестирования не помогают в сишных/плюсовых проектах, всё равно ошибки просачиваются. Потому они и нахваливают раст и горлапанят о желании всю новую или ответственную нативную системщину в андроиде писать на расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #192 Ответы: #332, #336

301. Сообщение от Аноним (310), 18-Сен-24, 16:53	+/–
>Если у тебя в этом месте проблемы, то и срастом такие же будут При чём тут раст? И да, в расте это делатся явно и проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строк >Бред Вашемнение реальность не изменит, а аргументов от вас нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #291 Ответы: #333

302. Сообщение от 1 (??), 18-Сен-24, 17:01	+/–
> Выбор кажется очевидным. JAVA ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

303. Сообщение от Аноним (310), 18-Сен-24, 17:02	+/–
>И где кроме 11 стандарта как-то в корне меняли семантику? А зачем её менять в корне? Достаточно добавить каких нибудь модулей
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #294 Ответы: #312

304. Сообщение от Аноним (310), 18-Сен-24, 17:10	+/–
>Чтобы писать на с++ не надо досконально знать стандарт, Я не пишу ни на c ни на c++. Однако, читая код на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8... https://habr.com/ru/articles/522208/ И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низок
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #293 Ответы: #311, #358

305. Сообщение от Аноним (310), 18-Сен-24, 17:16	+/–
>Возможность взять голову пустого списка и получить ошибку не принимается. Почему это? Вы предпочитаете попортить память/упасть? Типизация поможет в том чиле и против утечек памяти и против двойного освобождения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #292 Ответы: #309

306. Сообщение от Аноним (310), 18-Сен-24, 17:18	+/–
>вот реально не понимаю проблемы - запросил памяти отработал, освободил. кто отменил культуру написания кода ? или вообще все без задней мысли как все работает ? Вы не знаете про существование кучи? Где вы там память освобождать собрались?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #212 Ответы: #322

307. Сообщение от Аноним (310), 18-Сен-24, 17:21	+/–
> std::shared_ptr<Твой суперский тип> и все, как только исчезнут владельцы ссылок на объект он освободится. Простейший двусвязный список и объект застрял навечно. А если это подкостылить слабыми ссылками, то уже можно получить висячий указатель
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229 Ответы: #335

308. Сообщение от Аноним (310), 18-Сен-24, 17:24	+/–
Что из этого необычный синтаксис плюсов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #231

309. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:25	+/–
>>Возможность взять голову пустого списка и получить ошибку не принимается. > Почему это? Вы предпочитаете попортить память/упасть? На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов. > Типизация поможет в том чиле и против утечек памяти и против двойного > освобождения. Завтипы? Можно подробнее в этом месте? Вроде же idris, coq, lean все с gc.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #305 Ответы: #344

310. Сообщение от Аноним (310), 18-Сен-24, 17:27	–1 +/–
Бинарный кеш в ваших репах не изобретён?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #250

311. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:30	+/–
>>Чтобы писать на с++ не надо досконально знать стандарт, > Я не пишу ни на c ни на c++. Однако, читая код > на этих языках, регулярно вижу отсутствие понимания происходящего типа такого https://github.com/ProfessorNavigator/mylibrary/blob/b249bf8... > https://habr.com/ru/articles/522208/ Можно обернуть данный код в с++ в класс, в котором надо проверять ошибку типа absl::Status, outcome::result, Boost::Outcome или std::expected из с++23. Просто это разный подход к обработке ошибок. > И я крайне сомневаюсь, что те, кто не осилили парсер не побьют > память, ведь их общийуровень понимания крайне низок Есть готовые библиотеки для разбора. Если человек не читает документацию, то проблема сильно ниже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304 Ответы: #345

312. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 17:32	+/–
>>И где кроме 11 стандарта как-то в корне меняли семантику? > А зачем её менять в корне? Достаточно добавить каких нибудь модулей И в чем проблема? Ну ты реально пытаешься, что-то доказать, но сам кажется до конца не понимаешь что именно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #303 Ответы: #346

313. Сообщение от Аноним (314), 18-Сен-24, 17:39	+2 +/–
Если это будет строгое подмножество, то это все еще C++.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #161

314. Сообщение от Аноним (314), 18-Сен-24, 17:42	+3 +/–
Нет стандарта - нет UB.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

315. Сообщение от Аноним (314), 18-Сен-24, 17:49	+/–
Ясно, не язык плохой, а программисты плохие. Где-то мы это уже слышали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #233 Ответы: #378

316. Сообщение от Аноним (314), 18-Сен-24, 17:52	+1 +/–
Swift и Kotlin будут получше и перспективнее с точки зрения работы. В Swift также есть Automatic Reference Counting (ARC), что гораздо более практично для безопасного управления памятью.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

317. Сообщение от Аноним (314), 18-Сен-24, 17:55	+2 +/–
Пару лет назад это вечность для нового языка. Сейчас многие переходят на Zig, разочаровавшись в Rust, так что его развитие заметно ускорилось. У него больше перспектив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48

318. Сообщение от Аноним (314), 18-Сен-24, 17:58	+1 +/–
>Если иметь чёткое представление, что должно получится, то можно за условные пару месяцев реализовать первую версию, и объявить о стабилизации апи, после чего можно годами неспешно расширять библиотеки. Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него: >Если же чёткого представления нет, то будут пробы разных подходов, с отказам от них, что выльеться в постоянное переписывание разных частей.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #186 Ответы: #343

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

320. Сообщение от Аноним (29), 18-Сен-24, 18:04	+/–
я даже не представляю, что можно прогать 12 часов, кек
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #288 Ответы: #388

321. Сообщение от Аноним (314), 18-Сен-24, 18:07	+/–
Закончить помешало. Как обычно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #216

322. Сообщение от Аноним (29), 18-Сен-24, 18:08	+/–
> Вы не знаете про существование кучи? программист на "высокоуровневом безопасТном ЯП" - знать не должен!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #306 Ответы: #352

323. Сообщение от Аноним (314), 18-Сен-24, 18:15	+/–
Какой детский уход от темы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #266 Ответы: #354

324. Сообщение от Аноним (314), 18-Сен-24, 18:18	+/–
Да ты это уже раз 50 в комменты вставлял. И одно это говорит как мало положительных отзывов о внедрении Rust в реальные проекты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #295

325. Сообщение от Аноним (314), 18-Сен-24, 18:19	+1 +/–
Ну вот теперь C++ действительно хватит, непонятно чем ты недоволен ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #98

326. Сообщение от Аноним (314), 18-Сен-24, 18:31	+1 +/–
Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи". И он еще что-то говорит про лицемерие.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #297 Ответы: #382, #427

327. Сообщение от Аноним (314), 18-Сен-24, 18:33	+/–
У нас вестник из будущего, ловите!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

328. Сообщение от Аноним (314), 18-Сен-24, 18:38	+/–
Зато сишники освоили более одного production-ready компилятора, и все благодаря наличию стандарта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299

329. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:41	+/–
>>Нужно переписать весь хромитам на раст > У вас болезненная зацикленность на расте? Критикуя, предлагай. с++ единственный вариант для хромиума. Кода много, поэтому и компилится долго. Просто это овердофига большой проект. Возможная замена - это раст. Но как сильно изменится время компиляции? Попробуй собери что ли компилятор раста или firefox и сравни. >>А без этого твои слова ничем не доказуемы. > Вы не видите очевидных доказательств. Вот один из примеров https://www.opennet.dev/opennews/art.shtml?num=56475 Нашел новые?) Могу еще подсказать поискать новости про то, что в ядре повторяется куча кода в разных подсистемах. >>У них много кода, вот он долго и компилится первый раз. > Нет, это сишники не осилили нормальный компилятор. Запрети циклические зависимости, и проблема > выше решится сама собой, без необходимости строчить огромные патчи. Ну ты же не пишешь на си и с++ как ты говоришь. Почему ты судишь осили кто-то или нет? > А даже если патч примут, то снова разведут бардак. Попробуй посопровождай проект подобного уровня и посмотрим какой там будет бардак. Чел, это не бардак)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299 Ответы: #348

330. Сообщение от Аноним (314), 18-Сен-24, 18:42	+/–
Ну так это работает и с C++. Есть кому следить за использованием анализатора кода - будет толк, нету - сам себе злобный буратино и никакой раст не спасет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298

331. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:43	+/–
>> Кто будет следить, что я не расставляю ансейфы для обхода борова? > Тут два варианта - у вас есть код-ревью или ты сам себе > хозяин. Ну дык в проекте на с++ также. >   Если на код-ревью у тебя в растовском коде увидят сотни/тыщщи > участков с ансейфом, к тебе возникнут вопросы. Почитают комментарии к этим > участкам кода, присмотрятся, подумают, насколько это оправданно и заствят переписать. > Повторится - скорее всего выкинут на улицу как диверсанта или неосилятора. Тоже самое для проекта на ___ (подставь что хочешь).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #298

332. Сообщение от Аноним (314), 18-Сен-24, 18:45	+/–
Вот именно что нахваливают и горланят, но переходить не торопятся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #300

333. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:47	+/–
>>Если у тебя в этом месте проблемы, то и срастом такие же будут > При чём тут раст? И да, в расте это делатся явно и > проверяется примитвно, банальным grep. В плюсах вручную перелопачивать миллионы строк Зачем перелопачивать миллионы строк. Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырыми. >>Бред > Вашемнение реальность не изменит, а аргументов от вас нет Чел, ты видимо не переписывал большие проекты. Никто не будет переписывать на раст сложные подсистемы в хроме, а начнут с чего пропроще. Генерато qr кодов там или вот парсер json. Потому что повесточка такая от начальсва, а глупцам наружу скажут, что безопасно. Ну по CVE парсер json явно не на 1-ом месте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #301 Ответы: #362

334. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 18:50	+/–
> это сишники не осилили нормальный компилятор Для си есть верифицированный компилятор https://compcert.org/, компиляторы попроще tcc (используется для бутстрапинга) и куча других проектов. Так что тут не прав. Выбор - это всегда хорошо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #299

335. Сообщение от Аноним (314), 18-Сен-24, 18:51	+/–
Если так старатся, то можно и ошибку памяти в Rust организовать https://github.com/Speykious/cve-rs
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #307 Ответы: #350

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

337. Сообщение от Аноним (314), 18-Сен-24, 18:53	+1 +/–
А ты делай так: auto a = std::make_shared<int>(0); auto b = std::max(*a, 1); C++ ничего не делает за ленивых программистов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #272

338. Сообщение от nc (ok), 18-Сен-24, 18:55	+2 +/–
У меня проблем с памятью в С++ вообще не было, хотя и смартпоинтерами практически не пользуюсь, и отслеживание владения объектами мне как-то не требуется - объекты просто не меняют владельца в течение всего времени жизни. А вот чего не хватает, так это рефлексии и императивных синтаксических макросов.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #351

339. Сообщение от Аноним (314), 18-Сен-24, 18:56	+/–
"Сначала добейся", и сразу ссылка на авторитет. Просто ходячая демагогия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #281

340. Сообщение от Аноним (314), 18-Сен-24, 18:59	+/–
но люди не поэтому пишут статьи "Почему я отказался от разработки игр на Rust"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #282

342. Сообщение от Аноним (342), 18-Сен-24, 19:12	+/–
Это уже можно назвать Rust с классами?
Ответить | Правка | Наверх | Cообщить модератору

343. Сообщение от Аноним (175), 18-Сен-24, 19:14	+/–
>Что же тогда разработчики Раста не использовали этот разумный подход, а вместо него: Раст уже давным давно зарелизил 1.0, и имеет обратную совместимость https://doc.rust-lang.org/edition-guide/editions/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #318 Ответы: #450

344. Сообщение от Аноним (175), 18-Сен-24, 19:21	+/–
>На мой взгляд это не токое важное место, чтобы так сильно усложнять систему типов. Ими пользуются по необходимости >Завтипы? Можно подробнее в этом месте? Посмотри на ATS - язык с линейными и зависимыми типами, по умолчанию без GC, правда он скорее экспериментальный, чем практический.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #309

345. Сообщение от Аноним (175), 18-Сен-24, 19:23	+/–
>Можно обернуть данный код в с++ в класс Для этого, нужно как минимум подозревать о проблеме. В плюсах компилятор никак не подскажет, что здесь что-то не то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #311

346. Сообщение от Аноним (175), 18-Сен-24, 19:25	+/–
>И в чем проблема? Проблема в понимании c++ кода. Огромное количество фич, и у каждой фичи есть свои особенности. Возможно, новые способы отстрелить ногу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #312

347. Сообщение от Аноним (314), 18-Сен-24, 19:35	+2 +/–
Безопасная работа с памятью и 100% совместимость с существующей кодовой базой. И даже специалистов не нужно переучивать на новый язык. Что еще нужно для счастья.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #353

348. Сообщение от Аноним (175), 18-Сен-24, 19:38	+/–
>Кода много, поэтому и компилится долго Вы ссылку читали? >При использовании Clang применение патчей позволило сократить время сборки на 88% или на 77% Функционал остался тем же, но собираться стал более чем в четыре раза быстрее >Критикуя, предлагай Я ясно сказал, что нужно сделать: запретить циклические зависимости, хотя бы на уровне линтера. Вот вам Ocaml https://wiki.xenproject.org/wiki/OCaml_Cyclical_Build_Depend... Слышал, что в делфи аналогично, но утверждать не берусь. >Почему ты судишь осили кто-то или нет? Потому, что когда я создал подобную проблему в Ocaml, в гораздо меньшем масштабе, то компилятор меня сразу же предупредил. При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод. >Чел, это не бардак) Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы. Ну и что, что время компиляции растягивается, типичный сишник и не знает, что компиляция может быть быстрой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #329 Ответы: #360, #361

350. Сообщение от Аноним (175), 18-Сен-24, 19:43	+/–
>Если так старатся Что значит стараться? Условный студент по вашему специально ошибки в курсовую вносит?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #335 Ответы: #440

351. Сообщение от Аноним (175), 18-Сен-24, 20:01	+/–
>У меня проблем с памятью в С++ вообще не было Откуда вы это знаете? Фазеры, например, находят неочевидные проблемы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #338 Ответы: #442, #458

352. Сообщение от Аноним (175), 18-Сен-24, 20:03	+/–
>программист на "высокоуровневом безопасТном ЯП" - знать не должен! Зато плюсовики просто обязаны
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #322

353. Сообщение от Аноним (-), 18-Сен-24, 20:41	+/–
> даже специалистов не нужно переучивать на новый язык Ага, мечтай. У них в драфте есть пример: int main() safe {   std2::vector<int> vec { 11, 15, 20 };   for(int x : vec) {     // Ill-formed. mutate of vec invalidates iterator in ranged-for.     if(x % 2)       mut vec.push_back(x);     std2::println(x);   } } Невозможность мутабельно работать с vec, если у тебя есть активный итератор овер vec. В этом примере, может не очень видно, насколько это большое препятствие для мозгов воспитанных на C и C++, но я заверяю тебя, крутизна кривой обучения расту для C/C++ программистов в основном так закручивается благодаря вот именно этой фишке. В терминах раста, итератор борроуит vec, и поэтому сам vec не может быть использован через мутабельную ссылку. Если итератор мутабельный, то он мутабельно борроуит vec, а это значит что даже немутабельные обращения к vec запрещены борроу-чекером. Но это цветочки, ягодки дальше: селфреференшл структуры становятся запрещёнными компилятором. Например, циклические списки. Или если ты хочешь создать структуру в которой будет буфер и указатель внутрь буфера, то опять же у тебя не выйдет это без unsafe. C/C++ программисту приходится учиться программировать заново, чтобы научиться писать программы при таких ограничениях. Очень интересно посмотреть, что из этого выйдет в результате. Когда C/C++ программист оказывается в расте, он испытывает сильное давление культуры, запрещающее ему пользоваться unsafe. Иногда это давление культуры выливается в давление бескультурья, когда растоманы накидываются на бедного программиста, и начинают его чмырить за обилие unsafe'ов. Результатом этого получается то, что программист постоянно преодолевает свои ограничения, и через полгода-год научается писать код так, чтобы не биться с борроу-чекером. Но с псевдо-растом, реализованном нашлёпкой поверх C++, может получиться иначе, поскольку не будет столь мощного давления нацеленного на отказ от unsafe. Вероятно это приведёт к тому, что на этом псевдорасте будет больше unsafe кода написано, и я это было бы круто. Растоманам бы не помешали бы примеры тому, как надо использовать unsafe, чтобы избегать нагораживать конструкции-франкенштейны из типов, только для того, чтобы избежать чутка ансейфа. На мой взгляд, они выбрали избыточно параноидальный компромисс между "safe + даёптваюмать-сколько-можно-типов-плодить" и "unsafe и просто и понятно". Растоманский компромисс не дотягивает до отмороженности того, что в начале 00 C++-программисты творили под разлагающим влиянием Александреску, но примерно в ту сторону. В общем, я желаю успехов данному начинанию, если получится, оно сделает раст ещё лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #347 Ответы: #443

354. Сообщение от Аноним (175), 18-Сен-24, 20:59	+/–
Если уж брать раст, то там можно взять банальный grep и проверить. А вот в плюсах - нельзя. И говоря про выход за границы, то непонятно, это обычный массив, или оператор индексации. Это уже как минимум языковой сервер нужен
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #323 Ответы: #438

355. Сообщение от Аноним (-), 18-Сен-24, 22:09	–1 +/–
NVIDIA пишет драйвер на Rust, но тут многим виднее... https://lists.freedesktop.org/archives/dri-devel/2024-March/...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #356, #446

356. Сообщение от Аноним (-), 18-Сен-24, 22:11	+/–
точнее RedHat
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #355

358. Сообщение от ProfessorNavigator (ok), 18-Сен-24, 22:24	+/–
> И я крайне сомневаюсь, что те, кто не осилили парсер не побьют память, ведь их общийуровень понимания крайне низок Опять вы со своей чушью. Так и будете таскать свои глупости из поста в пост, в надежде, что никто не будет вникать? Ну-ну, продолжайте... Посмотрим, чем это закончится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #304 Ответы: #359

359. Сообщение от Аноним (175), 18-Сен-24, 23:34	+/–
>в надежде, что никто не будет вникать Как вижу, вы до сих пор не поняли в чём проблема, и не поправили парсер
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #358 Ответы: #366

360. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 23:36	+/–
> При работе с Ocaml периодически чувствуешь, как компилятор активно мешает писать плохой код, в то же время, когда я собирал си/плюсы, то компиялторы собирали абсолютно любой синтаксически корректный говнокод. Зачем сравнивать функциональный язык с GC и императивный без GC? Блин, да для ocaml даже нормальной gui библиотеки нет. Ну что-то браузера на ocaml не видел, хотя вот на common lisp есть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #348 Ответы: #365

361. Сообщение от Вы забыли заполнить поле Name (?), 18-Сен-24, 23:40	+/–
> Вот в этом то и проблема. Сишники/крестовики будут отказываться признавать наличие проблемы. > Ну и что, что время компиляции растягивается, типичный сишник и не > знает, что компиляция может быть быстрой. Никто не отказывается ничего признавать. Ее решают по другому просто. Я тебе еще раз говорю: возьми свой любимый яп, возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для него. Ну только чтобы без рантайма яп был.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #348 Ответы: #367

362. Сообщение от Аноним (175), 18-Сен-24, 23:49	+/–
>Можно достаточно быстро увидеть как в проекте ведется работа с памятью, используются ли умные указатели, раи или они пишут как на си и жанглируют сырыми Интересно и как? Вот в расте - понятно, берём grep unsafe -rn и готово. В языках с GC скорее всего искать не нужно. Может быть ещё несколько ключей добавить. Что вместо unsafe подставлять в grep? Звёздочку - как мне отличить умножение от разыменновывания? Это уже не grep нужен, а какой-то специализированный инструмент. malloc искать? Но это не поможет, если кто то прошолся по коду, и заменил malloc на new, free на delete. Просмотреть пару файлов? А остальные как? >Никто не будет переписывать на раст сложные подсистемы в хроме >а глупцам наружу скажут, что безопасно Давайте посмотрим, что в новости: >Отмечается, что переход на новый парсер может привести к прекращению разбора некоторого некорректно оформленного контента в формате JSON, но при этом он также решает проблемы при работе с некорректным JSON, который раньше вызывал аварийное завершение, а теперь приводит к возврату кода ошибки. То есть во-первых, старый парсер не следовал спецификации JSON, а во-вторых, вызывал аварийное завершение. Вы считаете нормальным, что парсинг такого простого формата выполняется так криво?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #333 Ответы: #392

363. Сообщение от Другой Аноним (?), 18-Сен-24, 23:50	–3 +/–
Есть всего одна простая опция как радикально повысить безопасность C++ - отбросить поганое наследие Си: - char* в коде?  Ошибка, остановка компиляции. - memcpy в коде? Ошибка, остановка компиляции. - malloc/free в коде? Ошибка, остановка компиляции. - сишное преобразование переменных? Ошибка, остановка компиляции. и.т.п. Всё, безопасность вашего кода улучшена многократно.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #369, #411

364. Сообщение от Аноним (175), 18-Сен-24, 23:55	+/–
>То есть на первом шаге бутстрапинга предлагается скачать бинари компилятора и cargo? Это бред. Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. А вы что предлагаете, скачивать llvm ir код? Для тех, кто не доверяет текущему компилятору есть возможность собирать его версию за версией, начиная с той, что написана на ocaml.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #163 Ответы: #390

365. Сообщение от Аноним (175), 19-Сен-24, 00:00	+/–
>Зачем сравнивать функциональный язык с GC и императивный без GC? А какая разница? Почему нельзя запретить циклические ссылки на исходники в империативном языке?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #360

366. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 00:16	+/–
> Как вижу, вы до сих пор не поняли в чём проблема, и > не поправили парсер Ну так расскажите)) А то я от вас ничего, кроме всякого бреда, пока что-то не видел. Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительный. Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступало. У меня у самого нареканий тоже нет. Со скоростью работы там есть проблемы, но отнюдь не в парсере, а в той части, что работает с архивами. Вот там - да, есть ещё над чем поработать. Да и дело то не в этом. Я тоже человек, вполне могу ошибиться - мои программы не истина в последней инстанции. Дело в том, что вы тут проповедуете, какими методами и для чего. Как иллюстрация - вторая ссылка, которую вы тут из поста в пост таскаете. Повторю ещё раз - там проблема банальна и проста. Функция в случае ошибки возвращает -1. И если вы не проверите на минус единицу, то естественно у вас будут проблемы. В программировании оно везде так - любая мелочь имеет значение, потому что любой символ - это вполне определённые машинные инструкции.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #359 Ответы: #368

367. Сообщение от Аноним (175), 19-Сен-24, 00:21	+/–
>Ее решают по другому просто Как решают? Периодически патчи присылают, как с linux? Это не решение проблемы языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать с нуля. >возьми проект уровня хромиума (по кол-ву кода) и покажи мне время сборки для него Вопрос не в количестве строк как таковых(тут да, chromium - рекордсмен). Вопрос в том, что существуют короткие примеры, порой меньше сотни строк, которые растягивают время компиляции в несколько раз, а то и на несколько порядков. К сожалению не могу найти статью про c++, вот пример со swift https://habr.com/ru/articles/283106/ >Ну только чтобы без рантайма яп был. У плюсов есть рантайм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #361 Ответы: #370, #371

368. Сообщение от Аноним (175), 19-Сен-24, 00:47	+/–
>Про производительность, если что, можете сказки сразу не рассказывать - тестировалось это всё на 500+ Гб файлов, результат - вполне удовлетворительный Удовлетворительный результат - это понятие весьма растяжимое. >Утечек памяти нет, ошибок - тоже. По крайней мере с февраля жалоб не поступало Я не будут перечислять все проблемы заново, но ещё раз повторюсь, у вас нет совместимости со всей семантикой xml. Банально код <tag attr1="attr3" attr2="val1" attr3="val2"/> ваш парсер не сможет разобрать. И подобных примеров, когда ваш парсер будет работать неправильно - куча. Если вам повезло, и подобные строки не встретились, это всё ещё не говорит, о том, что ваш парсер работает нормально >В программировании оно везде так Как раз для таких случаев и придумали алгебраические типы данных, если уж исключения бросать не хочется. Там не получится случайно передать ошибку в другую функцию - только намеренно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #366 Ответы: #373

369. Сообщение от Аноним (175), 19-Сен-24, 00:48	+/–
Этого не хватит - останется как минимум ошибка на миллиард долларов - null.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #363 Ответы: #374

370. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 01:49	+/–
>>Ее решают по другому просто > Как решают? Периодически патчи присылают, как с linux? Это не решение проблемы > языка, это исправление одного единственного проекта. Для freebsd нужно будет начинать > с нуля. Кэш, распределенная сборка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367 Ответы: #372

371. Сообщение от Аноним (175), 19-Сен-24, 01:59	+/–
Нашёл пример для плюсов https://habr.com/ru/companies/jugru/articles/438260/ >Время компиляции этого реально наипростейшего примера заняло на 2.85 секунды дольше, чем версия с «простым C++». >Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #367 Ответы: #406

372. Сообщение от Аноним (175), 19-Сен-24, 02:02	+/–
>Кэш Я не помню точных цифр, но вместе с кешем хромиум собирался не больше суток, а часов за шесть, что всё равно много.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #370 Ответы: #405

373. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 02:34	+/–
> Удовлетворительный результат - это понятие весьма растяжимое. Нет, не растяжимое. Задача была - создать программу, которая будет собирать базу данных из различных типов электронных книг и архивов любой глубины. Вторая задача - организовать поиск по этой базе данных по определённым критериям и открытие найденных файлов. Именно это программа и делает. Это называется "удовлетворительный результат". Хорошим он станет, когда удастся избежать крахов на rar архивах, а также улучшить кое-какие мелочи. С rar архивами проблема, потому что падает библиотека libarchive, а не сама программа. Падает во вполне конкретном месте - оно мне известно. Временные пути обхода сделаны, багрепорт в libarchive висит. На этом мои возможности заканчиваются. Можно конечно написать реализацию распаковки rar архивов самому, но на это у меня нет времени. И нет желания - формат проприетарный, используется по большей части в Windows. Программа же в первую очередь предназначена для пользователей Linux, бодаться с юристами по поводу возможных проблем с лицензиями и раскапывать спецификации формата не вижу никакого смысла. В том числе потому, что не было задачи написать полноценный архиватор. Распаковка архивов - лишь бонус к основным функциям программы. Там и так пришлось костыль для zip архивов написать, чтобы ускорить их обработку. > Я не будут перечислять все проблемы заново, но ещё раз повторюсь, у > вас нет совместимости со всей семантикой xml. Банально код <tag attr1="attr3" > attr2="val1" attr3="val2"/> ваш парсер не сможет разобрать. И подобных примеров, когда > ваш парсер будет работать неправильно - куча. Если вам повезло, и > подобные строки не встретились, это всё ещё не говорит, о том, > что ваш парсер работает нормально Как раз это и говорит, о том, что программа работает нормально. Цели реализовать полноценный парсер xml не было. Реализовано только то, что встречается в форматах fb2 и ebub, в соответствии с их документацией. Реализовано опять же не полностью, потому что не было задачи отображать весь текст, стояла задача лишь добиться корректного отображения общей информации о книгах. И задача достигнута. Если возникнет такая необходимость, то парсер легко может быть адаптирован для полноценной работы с xml. > Как раз для таких случаев и придумали алгебраические типы данных, если уж > исключения бросать не хочется. Там не получится случайно передать ошибку в > другую функцию - только намеренно. Алгебраические типы данных придумали для того, чтобы работать с большими числами в первую очередь. Там, где это требуется, например - в научных расчётах. Потому что у всего есть цена. Если вы работаете с алгебраическими типами данных, то платите за это повышенным расходом памяти и снижением быстродействия. Т.к. данные хранятся в оперативной памяти, а не в стеке (есть естественно нюансы, я их сознательно сейчас опускаю). И во многих процессорных архитектурах специально предусмотрены инструкции для работы с типами данных фиксированной длины. А алгебраические типы данных - это всегда реализация на уровне софта, а не железа. И никаким преимуществом алгебраические типы данных не являются, поскольку если речь идёт о C/C++, то много лет уже существует библиотека gmp, в которой всё это реализовано. А также есть куча математических функций для работы с алгебраическими данными. Кроме того, нет никаких проблем написать всё это самому - я знаю, я делал. Чисто для тренировки, работало на базе std::vector<bool>. То же самое можно реализовать с помощью std::bitset или с помощью массивов char. Ну а приведённая вами ссылка и вовсе ко всему этому не имеет никакого отношения, поскольку там функция может в случае ошибки вернуть -1. И возвращаемое значение нужно проверять, иначе ничего хорошего не получится. Хоть с алгебраическими типами данных, хоть без них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #368 Ответы: #375

374. Сообщение от Аноним (374), 19-Сен-24, 03:00	–1 +/–
Если запретить хранить "сырые" указатели, то нужно очччень постараться чтобы сломать себе ногу о nullptr. Так и на автомобиле можно в дерево въехать если очень захотеть. Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему.  В отличие от того же use-after-free, от которого у сишных программистов на лбу уже должна быть вмятина по форме ручки от грабель. Вот последнее реально на миллиард долларов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #369 Ответы: #376

375. Сообщение от Аноним (175), 19-Сен-24, 03:16	+/–
>Алгебраические типы данных придумали для того, чтобы работать с большими числами в первую очередь Что? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных, это например type 'a option =   | None   | Some of 'a >Реализовано опять же не полностью Наконец-то мы договорились. >потому что не было задачи отображать весь текст Мне всё равно непонятно, зачем нужны такие костыли >Если вы работаете с алгебраическими типами данных, то платите за это повышенным расходом памяти и снижением быстродействия Вы уверены, что сможите заметить различие в объёме данных, которые возвращает fork? >Т.к. данные хранятся в оперативной памяти, а не в стеке Стек тоже хранится в оперативной памяти. >А алгебраические типы данных - это всегда реализация на уровне софта, а не желез Откуда такой вывод? >то много лет уже существует библиотека gmp Это вообще не то >Ну а приведённая вами ссылка и вовсе ко всему этому не имеет никакого отношения, поскольку там функция может в случае ошибки вернуть -1 В си сигнатура fork int fork() В rust сигнатура pub enum Fork {     Parent(pid_t),     Child, } pub fn fork() -> Result<Fork, i32> Вы просто физически не сможете в pid_t засунуть результат fork-а в rust, у вас будет ошибка, что типы pid_t и тип Result<Fork, i32> различаются. match fork() {    Ok(Fork::Parent(child)) => {        println!("Continuing execution in parent process, new child has pid: {}", child);    }    Ok(Fork::Child) => println!("I'm a new child process"),    Err(_) => println!("Fork failed"), } В ocaml есть исключения, и fork их кидает. >Хоть с алгебраическими типами данных, хоть без них. Хорошо, с парсером разобрались, что такое алгебраические типы данных я вам объяснил, что ещё вы понимаете не так?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #373 Ответы: #386

376. Сообщение от Аноним (175), 19-Сен-24, 03:29	+/–
>Вообще ошибки с nullptr - самые простые для отлова и исправления, всегда понято где навернулось и почему. Нет, же, нет. Даже мне, человеку не пишущему на c++ известно, что a[b] аналогично *(a+b). И если взять достаточно большой массив, то в итоге адресной арифметики хватит, чтобы указатель вышел за несколько первых зарезервированных страниц памяти и влез в чужую память. Насколько мне известно, это не единственный вариант
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #374 Ответы: #377, #387

377. Сообщение от Аноним (374), 19-Сен-24, 05:41	+/–
> что a[b] аналогично *(a+b) Есть такое, да. Только это не проблема null, а buffer overflow. Может придумают что с этим делать, как решили проблему use-after-free и владения памятью. Пока что есть range based for и всякие отладочные костыли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376

378. Сообщение от Проходил мимо (?), 19-Сен-24, 07:19	+1 +/–
Вы таки думаете, что среди хаящих Rust икспердов с OpenNET есть программисты?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #315 Ответы: #437

379. Сообщение от Проходил мимо (?), 19-Сен-24, 07:35	–1 +/–
Уважаемый анонимный иксперд, довожу до вашего сведения, что настолько большой разницы в скорости написания сферического кода в вакууме на Си, Си++, GoLang и Rust нет от слова совсем. Хотя, в некоторых случаях, вам потребуется гораздо меньше времени для написания кода на Rust, но это касается тех случаев, когда что-то, реализованное в стандартной библиотеке Rust, отсутствует в стандартной библиотеке Си++ либо сделано там через жопу. Стандартная библиотека GoLang в этом отношении еще круче, особенно в плане обработки связанных с вебом вещей и генерации страниц по шаблонам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #279 Ответы: #441

380. Сообщение от Хоан Неб (?), 19-Сен-24, 11:43	+/–
таким, что если раньше какие-то хаки были "ничего", то теперь компиллер откажется это собирать или будет сыпать ворнингами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #129

381. Сообщение от Хоан Неб (?), 19-Сен-24, 11:46	+/–
[учебники] и [спеки] - это, какбы, разные книги
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

382. Сообщение от Аноним (382), 19-Сен-24, 11:59    Скрыто ботом-модератором	+/–
> Вы хотели чекер борова Нет, мы хотели чтобы перестали писать на дыряшке/плюсах, и писали на расте. > Но внезапно это оказывается - "воровать хорошие идеи". поэтому никакого противоречия. > И он еще что-то говорит про лицемерие. Именно. Это именно лицемерие. Когда годами вы говорили "ненужОн нам ваш боров, нам и так нормально!", а потом такие "хотя... подождите!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326

383. Сообщение от Аноним (249), 19-Сен-24, 12:08	+/–
Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение". Например, недавно наткнулся на вот такое: https://www.hylo-lang.org/ https://www.youtube.com/watch?v=5lecIqUhEl4
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #384, #402, #410, #416

384. Сообщение от Аноним (-), 19-Сен-24, 12:17	+2 +/–
> Кстати, походу Rust это только начало! На горизонте уже появляется "следующее поколение". > Например, недавно наткнулся на вот такое: > https://www.hylo-lang.org/ Конечно подражателей будет много. Если уже плюсовики задумались что "заимствование это круто", то более гибкие языки тоже могут заимствовать идеи. У некоторых будут новыи идеи, которые возможно перекочуют в раст. А может нет. Другие пока не приносят ничего супер ценного - как например зиг, который типа безопасный, но use-after-free позволяет. Будет ли hylo успешный? Может быть. Но протолкнуться в ядро, в дрова или андроид будет очень сложно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #383 Ответы: #444

385. Сообщение от adolfus (ok), 19-Сен-24, 12:22	–2 +/–
Смишно. Этот альянс -- сборище жуликоватых хитрованов. Зарегистированы, как торговая организация с очень интересными правами -- донаты юридических и физлиц не облагаются налогами, плюс исключаются из налогооблагаемой базы донатящих.Ну и фоты на интернет-простыне -- к ак говорится, бог шельму метит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #422

386. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 12:38	+/–
> Что? У вас какое-то своё собственное понимание данного термина. Алгебраические типы данных, > это например > type 'a option = >   | None >   | Some of 'a Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И всё оказалось ещё большей чушью, чем я думал. Как говорится - поздравляю. Вы заново изобрели те же классы С++. Осталось выяснить - зачем? Только не надо мне отвечать - это был риторический вопрос, я прекрасно понимаю - зачем. Вам нужно пропихнуть ваше "поделие" всеми правдами и неправдами - вам за это платят. Или нет. Но тогда всё ещё хуже.    > Наконец-то мы договорились. А я хоть где-то утверждал, что реализовал полную спецификацию xml? Зачем мне бы это делать? У меня стояла узкая задача: организовать обработку книг в форматах fb2 и epub. Я её решил. Понадобится написать например парсер html страниц - буду решать эту задачу. И напомню, что изначально речь шла о том, что в С++ нельзя нормально работать со строками и текстом. Я вам наглядно показал, что это не так. Т.е. одно из "преимуществ" Rust - фикция. И все остальные - тоже. Потому что если разобраться, то всё уже давно есть (только не начинайте по тридцать третьему кругу заводить шарманку про работу с указателями, массивы и прочее - надоело). > Мне всё равно непонятно, зачем нужны такие костыли Какие костыли? Покажите мне хоть одну нормальную библиотеку для работы с xml на С++. Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая. Тащить ради этого очередную зависимость, не пойми кем и как реализованную, или бодаться с корпорациями из-за лицензий? Зачем? Тем более, что там по итогу +/- пара сотен строчек кода. При этом я точно знаю, как это работает, и в любой момент могу что-либо откорректировать или улучшить, если возникнет такая необходимость. > Стек тоже хранится в оперативной памяти. Да что вы говорите. Правда-правда?)) Значит, аппаратный стек уже не существует? Ну ладно... >[оверквотинг удален] > различаются. > match fork() { >    Ok(Fork::Parent(child)) => { >        println!("Continuing execution in parent process, > new child has pid: {}", child); >    } >    Ok(Fork::Child) => println!("I'm a new child process"), >    Err(_) => println!("Fork failed"), > } > В ocaml есть исключения, и fork их кидает. Ну и на кой изобретать вот это вот всё, когда достаточно банального switch? И, напомню, речь про С++ вообще-то. По крайней мере в контексте новости. pid_t t = fork(); switch(t) {   case -1:   {     std::cout << "Oh, shit!" << std::endl;     break;   }   case 0:   {     std::cout << "WTF are you doing? It's a child process already" << std::endl;     break;   }   default:   {     std::cout << "Dancing: " << t << std::endl;     break;   } } > Хорошо, с парсером разобрались, что такое алгебраические типы данных я вам объяснил, > что ещё вы понимаете не так? Наверняка есть ещё немало вещей, которые я не знаю или не понимаю. Вопрос то в другом - в том, что вы всё равно пишете чушь. И знаете почему? Потому что нормальные люди, когда создают некое новое техническое изделие, делают примерно такое описание: "ЯП Rust... Компилятор выполняет проверки... (перечисление, чего там он делает)". Всё, на этом точка. Допустимы также комментарии вида: "Я попробовал Rust, и увидел что он на мой взгляд лучше подходит для <перечисление задач>, потому что...". Когда же нестандартизированный ЯП пропихивают в ядро ОС, широко используемой по всему миру, а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи. Маркетологи всегда работают в чьих-то корыстных интересах. Корыстные интересы всегда направлены против общества. Т.е. в том числе против вас и меня. Даже если сами вы этого не понимаете и участвуете в пропихивании чужих корыстных интересов. Дальше - обсуждать нечего. Rust может быть как угодно прекрасен (что в реальности, мягко говоря, не так), но пока за ним стоят барыги - нет, нет и нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #375 Ответы: #389, #395

387. Сообщение от Аноним (274), 19-Сен-24, 12:45	+/–
В С++ есть некоторые средства, снижающие риск, хоть и не убирающие его полностью: * std::vector и std::array вместо "сырых" массивов и их функция at() * Итерация контейнеров без указателей и индексов через for (auto& obj: container), std::for_each() Но иногда надо и проверять индексы, да. Например, получил какие-то данные из сети и парсишь их. Но и в таких случаях, если ты контролируешь формат обмена - можно использовать форматы обмена, для которых есть готовые библиотечные парсеры. Например, JSON, CBOR, Protobuf.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #376 Ответы: #397

388. Сообщение от Аноним (89), 19-Сен-24, 12:49	+/–
"Hello, World!" на Rust? Borrow checker-с, знаете ли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #320

389. Сообщение от Аноним (-), 19-Сен-24, 13:15	+/–
> Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И не в первый раз вы с умным видом рассуждаете про вещи, о которых почти ничего не знаете. > И всё оказалось ещё большей чушью, чем я думал. Как говорится - поздравляю. Спасибо за поздравление) Через сколько комментов будет очередное "я не почитал что оно значит"? > Вы заново изобрели те же классы С++. Осталось выяснить - зачем? ADT впервые были представленный в языке Hope аж в 1970 году. До изобретения СИшки было еще два года, до появления плюсов - больше десятка лет... > Только не надо мне отвечать - это был риторический вопрос, я прекрасно понимаю - зачем. Вам нужно пропихнуть ваше "поделие" всеми правдами и неправдами - вам за это платят. Или нет. Но тогда всё ещё хуже. Конечно это все заговор! И ничего, что они же применялись в Миранде и Хаскеле. А ведь есть еще обобщенные АТД, которые появлись немного позже. Но судя по вашим познаниям, про такие слова как OCaml, Agda или Idris вы даже не слышали. > Наверняка есть ещё немало вещей, которые я не знаю или не понимаю. О, ну хоть какая-то здравая мысль. > Вопрос то в другом - в том, что вы всё равно пишете чушь. А нет, я ошибся(( > И знаете почему? Потому что нормальные люди, когда создают некое новое техническое изделие, делают примерно такое описание: "ЯП Rust... Компилятор выполняет проверки... (перечисление, чего там он делает)". Всё, на этом точка. Странно. Они обычно пишут "UB это самая ценная вещь! она позволяет коду выдавать разыњй результат на разных компиляторах!!" > Допустимы также комментарии вида: "Я попробовал Rust, и увидел что он на мой взгляд лучше подходит для <перечисление задач>, потому что...". Угу, именно это пишется в почти каждой новости про раст: "Позволяет решать часть проблем с памятью". > Когда же нестандартизированный ЯП пропихивают в ядро ОС, широко используемой по всему миру, Имеют право. Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. Интересно, были ли тогда подобные зануды, которые ныли "как можно UNIX писать на новом нестандартизированном ЯП!" ? Надо будет - стандартизируют. Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем коммитетом не смогли за 3 года решить как складывать 2 инта.. так что пусть будет UB". > а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи. Неправда) Мы просто говорим - "Ваш ЯП - овно". А когда нас спрашивают "критикуя предлагай", от только тогда мы предлагаем. > Маркетологи всегда работают в чьих-то корыстных интересах. Дааа, заговоры! заговоры везде!! Та толпа которые в каждой теме оправдывает убогие языки "ну вышли за границы массива, это просто неправильный программист был!" это тоже маркетологи или просто местные сумасшедшие? > Корыстные интересы всегда направлены против общества. Т.е. в том числе против вас и меня. Даже если сами вы этого не понимаете и участвуете в пропихивании чужих корыстных интересов. А если я сам пишу на Расте и "пропихивание" обеспечивает мне большее число вакансий? Может это мои корыстные интересы. > Дальше - обсуждать нечего. Конечно нечего - ваша компетентность на уровне "что-то-где-то слышал, но не понял". Насколько я вижу, вы самоучка без университетского мат. образования? > Rust может быть как угодно прекрасен (что в реальности, мягко говоря, не так), но пока за ним стоят барыги - нет, нет и нет. Посмотрите кто в коммитете плюсов или си и заканчивайте пороть чушь. isocpp.org/std/the-committee Microsoft, Edison Design, Google - это те же самые "барыги". Так что выкидывайте с++ на помойку и пользуйтесь православным ДРАКОНон или КуМиром.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386 Ответы: #393

390. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 13:40	+1 +/–
> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. И стадию внедрения бэкдора. Это не бутстрапинг. Почитай как сделано в gnu mes.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #364 Ответы: #391

391. Сообщение от Аноним (-), 19-Сен-24, 13:46	–1 +/–
>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. > И стадию внедрения бэкдора. Бремя доказательства лежит на утверждающем. Даже если он балаболка. Но пруфов от тебя, я даже не надеюсь увидеть > Это не бутстрапинг. Почитай как сделано в gnu mes. Жду определение bootstrapping, где сказано что так делать нельзя) То что ГНУтики делают как-то по другому не говорит ни о чем. Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за ними повторять.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #390 Ответы: #404

392. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 13:49	+/–
> То есть во-первых, старый парсер не следовал спецификации JSON, а во-вторых, вызывал аварийное завершение. Вы считаете нормальным, что парсинг такого простого формата выполняется так криво? Я просил в той новости привести пример такого некорректного джейсона, но никто не указал. Считаю ненормальным, что за столько лет существования хрома там был невалидный (по из словам парсер) и все им пользовались и не страдали. Это просто лапша на уши, наподобие причин плохой работы ютупа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #362

393. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 14:07	+/–
> И не в первый раз вы с умным видом рассуждаете про вещи, > о которых почти ничего не знаете. Да-да, я ничего не знаю, конечно)) Но, проблема, повторюсь не в моём знании или незнании, а в том, что всё, что вы пишите про преимущества Rust - маркетинговая чушь. > Спасибо за поздравление) > Через сколько комментов будет очередное "я не почитал что оно значит"? Да ни через сколько - мне делами заниматься нужно, а не проплаченные комментарии по тридцать третьему разу разбирать. Так что в данном случае - этот последний, можете даже не трудиться отвечать. > ADT впервые были представленный в языке Hope аж в 1970 году. > До изобретения СИшки было еще два года, до появления плюсов - больше > десятка лет... И что?)) > Конечно это все заговор! Где заговор? Обычные коммерческие интересы и попытка устранить/подмять под себя конкурента. > И ничего, что они же применялись в Миранде и Хаскеле. И что?)) > А ведь есть еще обобщенные АТД, которые появлись немного позже. > Но судя по вашим познаниям, про такие слова как OCaml, Agda или > Idris вы даже не слышали. А оно точно надо?)) > О, ну хоть какая-то здравая мысль. Да, у меня тоже бывают озарения)) > А нет, я ошибся(( И даже не подозреваете - в чём ваша ошибка на самом деле. > Странно. Они обычно пишут "UB это самая ценная вещь! она позволяет коду > выдавать разыњй результат на разных компиляторах!!" Ну т.е. вы лишний раз только подтверждаете мои слова про крикунов и маркетологов. > Угу, именно это пишется в почти каждой новости про раст: "Позволяет решать > часть проблем с памятью". И под каждой новостью вам пишут, что - ну и пускай себе. Проблема не в этом, а в вас. В том числе лично в вас. > Имеют право. Нет, не имеют. Но видимо придётся вам это объяснять другими методами, а не словами. Поскольку по-хорошему вы, и подобные вам, не хотите. И я сейчас не про ЯП совсем. > Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. И что? > Интересно, были ли тогда подобные зануды, которые ныли "как можно UNIX писать > на новом нестандартизированном ЯП!" ? Тогда ситуация совсем другая была - вычислительная техника в современном виде только-только появлялась. Про стандартизацию никто и не вспоминал ещё. > Надо будет - стандартизируют. Вот тогда и поговорим. > Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем > коммитетом не смогли за 3 года решить как складывать 2 инта.. > так что пусть будет UB". И снова наброс. Т.е. снова вы расписались в своей ангажированности. > Неправда) Мы просто говорим - "Ваш ЯП - овно". > А когда нас спрашивают "критикуя предлагай", от только тогда мы предлагаем. А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. > Дааа, заговоры! заговоры везде!! Дааа, нужно облить оппонента грязью, объявить психом, и т.д. и т.п. Лишь бы пропихнуть своё. А какое оно по качеству - да плевать. "Умри ты сегодня, а я - завтра". > Та толпа которые в каждой теме оправдывает убогие языки "ну вышли за > границы массива, это просто неправильный программист был!" это тоже маркетологи или > просто местные сумасшедшие? Кто тут и чего оправдывает? Вам нормальным языком говорят: про проблемы мы в курсе, только вот решать их будем без ваших "ценных" предложений, поскольку на поверку все они - рекламная глупость. > А если я сам пишу на Расте и "пропихивание" обеспечивает мне большее > число вакансий? Вам - да. А обществу от этого польза будет? Если нет, то придётся вам чем-нибудь другим заняться. Не можете, потому что нет денег на переобучение? Ну поздравляю, вы на себе почувствовали, что такое капитализм, и как он работает. Может быть даже осознаете, в чём ваша проблема на самом деле заключается. > Может это мои корыстные интересы. Не может, а точно. Только на вас свет клином не сошёлся. Вы для общества важны, но не более важны, чем любой другой человек. > Конечно нечего - ваша компетентность на уровне "что-то-где-то слышал, но не понял". Ну т.е. в очередной раз будем обсуждать мою компетентность. Потому что по существу ответить нечего. > Насколько я вижу, вы самоучка без университетского мат. образования? Самоучка - да. В плане программирования. Без университетского образования - да. Поскольку заканчивал таки ГМА им. адм. Макарова (которая теперь по иронии - университет, но это совсем другая история). Так что с математическим образованием у меня всё в порядке. А ещё с техническим, да и с естественно-научным - тоже (но это уже больше заслуга школы, а также самообразование). > Посмотрите кто в коммитете плюсов или си и заканчивайте пороть чушь. > isocpp.org/std/the-committee > Microsoft, Edison Design, Google - это те же самые "барыги". > Так что выкидывайте с++ на помойку и пользуйтесь православным ДРАКОНон или КуМиром. Весь вопрос в том, что в комитете С++ - они конкуренты, поэтому в итоге мы получаем пусть шаткий, но баланс. Плюс к тому есть независимая реализация компилятора (что на самом деле важнее). А в Rust - они тоже конкуренты. Будут, чуть по позже. Когда удастся подмять Linux под себя. Впрочем, есть неплохой шанс, что они таки поссорятся на этой теме. Но вряд ли успеют. Потому что в самом ближайшем будущем никаких корпораций вообще не останется. По одной из двух причин: будет революция или все сдохнут. Выбирайте, что вам больше нравится.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #389 Ответы: #394, #396

394. Сообщение от Аноним (-), 19-Сен-24, 15:47	+/–
> Да-да, я ничего не знаю, конечно)) Подмена понятий это не очень красивая манипуляция. Приравнивание "почти ничего" и "ничего". > вы пишите про преимущества Rust - маркетинговая чушь. Бездоказательное утверждение. > а не проплаченные комментарии по тридцать третьему разу разбирать. Обвинить в пропалченности - всегда легко. Особенно бездоказаетльно. Но считать всех, кто с вами не согласен, ботами или проплаченными это довольно сильно. ВОзможно сильно глупо. >> ADT впервые были представленный >> И ничего, что они же применялись в Миранде и Хаскеле. > И что?)) А ничего. Просто эти подходы очень старые. Их преимущества и недостатки известны. Оно позволяет делать классные вещи для сложных систем. > А оно точно надо?)) Конечно, оно позволяет совершать меньше ошибок. >> Имеют право. > Нет, не имеют. Но видимо придётся вам это объяснять другими методами, а не словами. Поскольку по-хорошему вы, и подобные вам, не хотите. И я сейчас не про ЯП совсем. Т.е автор не может со своим проектом делать то, что пожелает? Сменить лицензию. Удалить весь код и тд? Думаю, вам бы не понравилось если бы я начал менять ваш проект без спросу. Линус и разработчики решили что в ядре будет Раст - это их право. Ваше - не пользоваться или форкать. >> Про стандартизацию.. сишка была стандартизована спустя 17 лет после создания K&R C. > И что? Это то, что даже на нестандартизованном языке можно писать серьезные системы. >> Но желатьельно чтобы стандарт не был как в дыряшке "мы тут всем коммитетом не смогли за 3 года решить как складывать 2 инта.. так что пусть будет UB". > И снова наброс. Т.е. снова вы расписались в своей ангажированности. Наброс? Могу процитировать "так называемый стандарт" Пункт 6.5.6 Additive operators подпункт 8 the evaluation shall not produce an overflow; otherwise, the behavior is undefined > А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. А вам говорят: ваши предложения - чушь. И опровергнуть это вы не можете. Стрелочка, она в обе стороны может поворачиваться. > Дааа, нужно облить оппонента грязью, объявить психом, и т.д. и т.п. Никогда такого не делал. У меня математическое образование. И принимать что-то на веру я не привык. Если бы вы сказали "вот доказательства", то разговор был бы другой. А если кричать "волк! волк!" то на третий раз уже никто всерьез воспринимать не будет. > А какое оно по качеству - да плевать. Лучше чем то, что было. Этого достаточно. > "Умри ты сегодня, а я - завтра". Так все умрем когда-то. Может у меня даже больше шансов чем у вас тк я моложе. Я думаю мы понимаем о чем речь. > Кто тут и чего оправдывает? Вам нормальным языком говорят: про проблемы мы в курсе, только вот решать их будем без ваших "ценных" предложений, Кто такое говорит? Как раз разработчики ядра другого мнения. Но да, они разберутся без ваших ценных предложений и без моих тоже. Т.к они разработчики, а не я или вы. > Вам - да. А обществу от этого польза будет? Если нет, то придётся вам чем-нибудь другим заняться. Не можете, потому что нет денег на переобучение? Ну поздравляю, вы на себе почувствовали, что такое капитализм, и как он работает. Может быть даже осознаете, в чём ваша проблема на самом деле заключается. Общество получит: 1. более надежный код, которые не разваливается от 28 бекспейсов 2. код не нужно будет годами чинить, находя все новые и новые баги То что мне придется переучиваться.. Это назывется не капитализм, а прогресс. Без него мы бы до сих пор с каменными топорами ходили, и то если бы с дерева слезли. > Самоучка - да. В плане программирования. Без университетского образования - да. Поскольку заканчивал таки ГМА им. адм. Макарова (которая теперь по иронии - университет, но это совсем другая история). Так что с математическим образованием у меня всё в порядке. А ещё с техническим, да и с естественно-научным - тоже (но это уже больше заслуга школы, а также самообразование). Я спросил это просто для понимания, слушали ли вы лекции по мат.логике, теории множеств и тд > Весь вопрос в том, что в комитете С++ - они конкуренты, поэтому в итоге мы получаем пусть шаткий, но баланс. Плюс к тому есть независимая реализация компилятора (что на самом деле важнее). А в Rust - они тоже конкуренты. Будут, чуть по позже. Почему будут позже? Они вполне могут стараться протолкнуть свои наработки в язык. > Когда удастся подмять Linux под себя. А... а зачем? Просто открываем linuxfoundation.org/about/members ... А там Майкрософт, Оракл и фейсбук в платиновых спонсорах. Смотрим на директоров www.linuxfoundation.org/about/leadership Да что ж такое! Опять эти корпы. Ладно, сообщество же пишет код.. 80% вклада - это программисты на зарплате корпов. Они УЖЕ его подмяли, хотя чеснее сказать "они его создали". Пример с системмд и вейландом это только подтвердят мое утверждение. > Впрочем, есть неплохой шанс, что они таки поссорятся на этой теме. Но вряд ли успеют. Потому что в самом ближайшем будущем никаких корпораций вообще не останется. По одной из двух причин: будет революция или все сдохнут. Выбирайте, что вам больше нравится. Ну революция уже была, лет 100 назад. И закончилось все голодом, мировыми войнами, геноцидами и прочим. Спасибо не надо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #393

395. Сообщение от Аноним (175), 19-Сен-24, 17:56	+/–
>Да, каюсь - не посмотрел значение термина сначала. Теперь выяснил. И всё оказалось ещё большей чушью, чем я думал Хорошо, что вы не закостенелив в своём незнании >Вы заново изобрели те же классы С++ Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через классы будет гораздо многословнее, но проблема даже не в многословности. Проблема в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу есть хорошая статья). >Ну и на кой изобретать вот это вот всё, когда достаточно банального switch? И, напомню, речь про С++ вообще-то. Всё просто и понятно. Во-первых, данное решение проверяется компилятором. Если я из вашего примера удалю case -1, то код по прежнему будет компилироваться, и никто мне никакую ошибку не выдаст. При работе со сложными форматами крайне важно понимать, что обработал все варианты. Во-вторых, добавив к этому монады получаем крайне высокую выразительность, в то время как ваш код превратится в ад вложений. >А я хоть где-то утверждал, что реализовал полную спецификацию xml? У вас файл называется XMLParser. >Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая Вот эта вот часть мне в плюсовиках не нравится: они вначале пишут непонятно что, а потом, после того, как им расскажут, почему их решение плохое, они начинают оправдываться. >Понадобится написать например парсер html страниц - буду решать эту задачу HTML это типичный кошмар, изобретённый сишниками/плюсовиками. Огроменная спецификация, огроменное количество подводных камней. Могли бы сделать XHTML, но сишников/плюсовиков тянет к уродству. Как следствие, для того, чтобы реализовать правильный парсер html - нужно приложить ещё больше усилий >Я вам наглядно показал, что это не так У вас как таковой работы и нет. Вы используете поиск по строке и берёте подстроки. Вы не делаете каких-то сложных преобразований >Покажите мне хоть одну нормальную библиотеку для работы с xml на С++ Я на плюсах не пишу, по этому ничего сказать не могу. Но вы же утверждаете, что работать со строками легко. И потом, xml это хоть и сложный формат, но реализовать парсер с нуля должно быть по силам даже одному человеку. >Да и не нужна она в данном случае - потому что задача узкая и весьма специфическая Всегда, когда вы работаете с какими-то форматами, вы должны реализовывать работу по спецификации. В данном случае, даже если бы вы писали просто Proof of Concept, то это не дало бы вам выигрыша по времени, поскольку нормальный парсер пишется совершенно иначе. Ваш код в любом случае нужно будет просто выкинуть. https://dev.realworldocaml.org/parsing-with-ocamllex-and-men... >Тащить ради этого очередную зависимость, не пойми кем и как реализованную Вы не доверяете авторам библиотек на плюсах? Я без сомнений использую чужой код в Ocaml >Тем более, что там по итогу +/- пара сотен строчек кода XML это не JSON, строк там понадобится куда больше. >Значит, аппаратный стек уже не существует? И что по вашему хранится в этом аппаратном стеке? Учтите, что вам туда надо будет засунуть буквально всё: стек каждого процесса, стек каждого потока. Надеюсь, вы понимаете, что держать запущенными на одном устройстве пусть две тысячи одновременных стеков - это не что-то выдающееся? >а везде, где только можно, набегает толпа крикунов с лозунгами: "Ваш ЯП - говно, Rust лучший!",- это может означать только одно: в игру вступили маркетологи Если вы не заметили, то конкретно я говорю про Ocaml. Может быть, я когда-нибудь напишу что-то на PureScript или Gluon, но на данный момент я говорю про Ocaml, а rust - так, по остаточному принципу >Ваш ЯП - говно, Rust лучший! Я устал от говнокода. Когда очередная программа падает с сегфолтом или работает неправильно, в 2024 году, у меня и возникает желаение рассказывать, какое уродство си и c++. Когда я понимаю, как легко создать баг на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький патч для этих программ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #386 Ответы: #407

396. Сообщение от Аноним (175), 19-Сен-24, 18:17	+/–
>> До изобретения СИшки было еще два года, до появления плюсов - больше >> десятка лет... >И что?)) А то, что нормальные языки появились давным давно, но были затмены говнокодом. И если си ещё мог с ними соревноваться, так как он ровесник некоторых из них, то вот уже c++ или python - появились после них, и уже на момент своего релиза отставали по фичам. Про голанг и говорить не приходится >Вам нормальным языком говорят: про проблемы мы в курсе А точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш код читал и про парсер вам писал? Другие части ревьювил? Увы, но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему что и почему он сделал неправильно. >Самоучка - да. В плане программирования. Без университетского образования - да Учитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не гарантирует. Если это не МГУ какое-нибудь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #393 Ответы: #400, #408

397. Сообщение от Аноним (175), 19-Сен-24, 18:25	+/–
>Но иногда надо и проверять индексы, да. Тогда чем это будет отличаться от условного Ocaml/Java, где границы точно так же проверяются? Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Тут уже ATS нужен или любой другой язык с зависимыми типами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #387 Ответы: #398, #399

398. Сообщение от Аноним (-), 19-Сен-24, 18:46	–1 +/–
> Тогда чем это будет отличаться от условного Ocaml/Java, где границы точно так же проверяются? Сборка мусора? Джава машина? Функциональный или нет. Отличий куча. > Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Но смысла в типичный ошибках тоже мало. Менять скорость на дыры в крптогрфической либе, может только очень пофигистичный человек. Хочется спросить, а зачем тебе вообще эта либа? Тем более не все CVE это out-of-bounds. Use-after-free и double-free тоже весьма распространены. Но кроме них, есть еще множество ошибок которые легко решаются более продвинутыми языками. Например когда есть ENUM_1 и ENUM_2, естественно это инты, другое в дыряшке невозможно. И сравнивает пограммист (самый лучший) две переменных разных енумом... и все отлично сравнивается. > Тут уже ATS нужен или любой другой язык с зависимыми типами. Возможно это перебор. Тут староверы не могут осилить логику заимствования, а ты предлагаешь им покрутить лямбда-куб и погрузиться в кортежи и монады))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397

399. Сообщение от Аноним (374), 19-Сен-24, 18:55	+1 +/–
> Смысл плюсов в скорости, а с такими ручными проверками они её потеряют. Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив,  рекомендую. Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #397 Ответы: #401, #403

400. Сообщение от Fyjy (-), 19-Сен-24, 19:06	+/–
> А то, что нормальные языки появились давным давно, но были затмены говнокодом. О да) СИшка это ПХП из 70х, чтобы любой б-ло кодер мог забацать какой-то код, и если ему удача повернется лицом, даже переносимый. Можно вспомнить как разрабатывалась АДА. Сначала они 2 года и 5 итераций собирали требования. Потом они устроили конкурс на разработку нового языка и 5 лет он был написан. Потом они запретили выпускать компиляторы, которые не прошли пакет тестов (больше тысячи). Хотя бы один тест провалился - всё, ты идешь лесом. Если вспомнить как рождался СИ и его стандарт (на который тая неистово фапают фанатики), то это десятки не совместимых друг с другом компиляторов, куча противоречий в стиле "ХЗ чо тут делать, компилятор сам разберется" и как вишенка на торте и овна - стандарт не обязателен к выполнению. Отрываешь C compiler support en.cppreference.com/w/c/compiler_support смотришь на красные пятна неподдерживаемых фич и думаешь, а почему это овно вообще называется "компилятор С"? И с плюсами история почти такая же. С теми же последствиями. en.cppreference.com/w/cpp/compiler_support Но, история не имеет сослагательного наклонения, и быд-о код победил. Язык для которого уровень квалификации пограммиста нужен был "бибизяна умеет жать на клавиши" распространился в очень важные проекты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #396

401. Сообщение от Fyjy (-), 19-Сен-24, 19:13	+1 +/–
> Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива. Брат жив,  рекомендую. Думаю это редкость. У вас это правило в проекте или ты сам так решил? Если работаешь с коллегами, как они на это смотрят? > Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны. Предвижу ответ "Но я же потеряю одну секунду пока бегу за пивом!" Ты не поверишь сколько таких умственно отсталых погибают под колесами каждый год. И главное когда его доктора собирают и спрашивают "О чем ты думал, дeбuл?" (c) то зачастую ответ "ну там автобус уже собирался уехать, я не хотел еще 10 минут стоять ждать" Так и в теме про уязвимость в очередной SSL начинается "проверки замедлят программу!"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #399

402. Сообщение от Аноним (402), 19-Сен-24, 19:13	+/–
На первый взгляд выглядит как наркомания. Объявлена непримиримая борьба не только с указателями, но и со ссылками. Вместо них предлагается писать какие-то subscripts, которые напоминают то ли питоновские генераторы, то ли плюсовые getter'ы на шаблонах. Дальше пошла квази-функциональщина, когда эти subscripts пихают в функции, и типа там должно что-то сгенерироваться без злых указателей, мягкое и плюшевое. На примитивных примерах то понятно, но не представляю как на этом писать что-то более сложное. Функциональщину вообще не перевариваю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #383

403. Сообщение от Аноним (175), 19-Сен-24, 20:04	–1 +/–
>Пишу по работе высокопроизводительный код, всегда проверяю выход за границы массива И что мешает это делать на языке где проверки делаются автоматически компилятором? >Хотя это странно, словно рекомендовать не перебегать дорогу, предварительно не посмотрев в обе стороны Если нужна производительность, то нужны и зависимые типы. Если производительность не важна, то зачем тогда нужен c++?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #399

404. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 20:21	+1 +/–
>>> Да, и это более чем логично, так как компилятор уже прошёл стадию раскрутки. >> И стадию внедрения бэкдора. > Бремя доказательства лежит на утверждающем. Даже если он балаболка. > Но пруфов от тебя, я даже не надеюсь увидеть Качай бинари с интернета и запускай локально, кто тебе мешает. А как надо бутстрапить читай как уже выше сказал в gnu mes. >> Это не бутстрапинг. Почитай как сделано в gnu mes. > Жду определение bootstrapping, где сказано что так делать нельзя) > То что ГНУтики делают как-то по другому не говорит ни о чем. В основе бутстрапинга не может лежать неиследованный бинарь. > Они могут хоть мозоли кушать, хоть коммуизм продвигать, это не повод за > ними повторять. А, ну понятно с тобой все.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #391

405. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 20:26	+/–
>>Кэш > Я не помню точных цифр, но вместе с кешем хромиум собирался не > больше суток, а часов за шесть, что всё равно много. Поэтому в гугле используют распределенную сборку. Написал же. Ну и не только там если что.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #372

406. Сообщение от Вы забыли заполнить поле Name (?), 19-Сен-24, 20:28	+/–
> Нашёл пример для плюсов https://habr.com/ru/companies/jugru/articles/438260/ >>Время компиляции этого реально наипростейшего примера заняло на 2.85 секунды дольше, чем версия с «простым C++». >>Например, за какое время clang сможет скомпилировать настоящий полноценный движок базы данных (SQLite) в отладочном режиме, включая все 220 тысяч строчек кода? За 0.9 секунд на моём ноутбуке. Ой, там сравнивают с c#. Как говорится в одной известной цитате из собачьего сердца "поменьше читайте газет"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #371

407. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 21:10	+/–
> Хорошо, что вы не закостенелив в своём незнании Чего-то не знать не стыдно. Стыдно не стремиться расширять свой кругозор. > Алгебраические типы данных решают схожую, но всё же отличающуюся задачу. Решение через > классы будет гораздо многословнее, но проблема даже не в многословности. Проблема > в том, чтобы убедить плюсовиков преодолеть "парадокс блаба"(да, по этому поводу > есть хорошая статья). А зачем собственно? Не устраивает - пишите на том языке, на котором вам удобно. Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве заняты. А эта область - далеко не весь IT сектор, и даже не самый важный (если не сказать больше - на 99,9% ненужный). Хотя язык сам по себе - очень даже неплох. И реализации есть нормальные. И лично мне например непонятно, почему тот же Торвальдс не хочет его разрешать использовать в ядре. Но это моё личное мнение, я его никому не навязываю. > Всё просто и понятно. Во-первых, данное решение проверяется компилятором. Если я из > вашего примера удалю case -1, то код по прежнему будет компилироваться, > и никто мне никакую ошибку не выдаст. При работе со сложными > форматами крайне важно понимать, что обработал все варианты. Во-вторых, добавив к > этому монады получаем крайне высокую выразительность, в то время как ваш > код превратится в ад вложений. Есть и противоположные варианты - когда вам по большому счёту всё равно, стартовал процесс или нет, главное - сохранить работоспособность программы и не тратить ресурсы на обработку ошибок. Их и потом собрать можно, по результатам работы программы. Ну и зачем мне в таком разе компилятор, который будет нудеть про необработанные варианты? Если же вы не обработали ошибку по незнанию, то тут уж извините - это сугубо проблема вашей квалификации. Вы на то и программист, чтобы такими вещами заниматься, и учитывать всё, что нужно. > У вас файл называется XMLParser. И что? Как он ещё должен называться? Если по факту - это и есть xml парсер. Потому как что в fb2, что в epub используются урезанные специфические xml форматы. > Вот эта вот часть мне в плюсовиках не нравится: они вначале пишут > непонятно что, а потом, после того, как им расскажут, почему их > решение плохое, они начинают оправдываться. Да при чём тут оправдания, если вы не разобравшись, пишете чушь? Ещё раз - в данном случае есть форматы fb2 и epub, в них используется вполне определённый набор xml свойств, которые к основной части формата имеют достаточно косвенное отношение. Найдите спецификацию того же fb2 на github - поймёте, о чём я говорю. > HTML это типичный кошмар, изобретённый сишниками/плюсовиками. Огроменная спецификация, > огроменное количество подводных камней. Могли бы сделать XHTML, но сишников/плюсовиков > тянет к уродству. Как следствие, для того, чтобы реализовать правильный парсер > html - нужно приложить ещё больше усилий Это только ваше мнение)) > У вас как таковой работы и нет. Вы используете поиск по строке > и берёте подстроки. Вы не делаете каких-то сложных преобразований А зачем? Задача данного парсера - достать из файла точно то, что от него попросили. Например - имя автора. Всё остальное обрабатывается уровнем выше. > Я на плюсах не пишу, по этому ничего сказать не могу. Но > вы же утверждаете, что работать со строками легко. И потом, xml > это хоть и сложный формат, но реализовать парсер с нуля должно > быть по силам даже одному человеку. Да не вопрос - я бы даже взялся. Если мне за это заплатят. И не потому что я такой жадный, а потому, что мне нужно что-то есть, при этом лично мне xml не упёрся ни разу. Понадобилось обрабатывать его частный вариант - я сделал. Если понадобится полный - тоже сделаю. Пока что он мне не нужен. > Всегда, когда вы работаете с какими-то форматами, вы должны реализовывать работу по > спецификации. В данном случае, даже если бы вы писали просто Proof > of Concept, то это не дало бы вам выигрыша по времени, > поскольку нормальный парсер пишется совершенно иначе. Ваш код в любом случае > нужно будет просто выкинуть. https://dev.realworldocaml.org/parsing-with-ocamllex-and-men... Так я и сделал по спецификации. https://github.com/gribuser/fb2 > Вы не доверяете авторам библиотек на плюсах? Я без сомнений использую чужой > код в Ocaml Я в принципе стараюсь использовать как можно меньше зависимостей. И дело даже не в том, что я кому-то не доверяю. Просто вот вам наглядный пример с libarchive - баг с rar архивами висит, исправлений нет. Потому что сопровождающим видимо не до того. Или нет таких. Сам я тоже этим возможности заниматься не имею. Да и желания тоже - как и писал выше, это проприетарь (имеется ввиду rar). Разбираться с ней - себе дороже. А альтернатив для libarchive пока что нет особо. > XML это не JSON, строк там понадобится куда больше. Ну понадобится и понадобится - если нужно будет, сделаю. > И что по вашему хранится в этом аппаратном стеке? Учтите, что вам > туда надо будет засунуть буквально всё: стек каждого процесса, стек каждого > потока. Надеюсь, вы понимаете, что держать запущенными на одном устройстве пусть > две тысячи одновременных стеков - это не что-то выдающееся? Мне не нужно в аппаратный стек чего-то засовывать. Всё происходит автоматом при исполнении программы. Дело в том, что определённые типы данных, вроде того же int такие, какие есть, потому что они напрямую завязаны на аппаратную реализацию. За счёт этого они работают очень быстро, но при этом имеют ограничения по размеру в битах. А значит и ограничения по максимальным значениям. Тут "или-или": или вы имеете данные произвольного размера, но тогда обрабатывает их как массивы, что относительно медленно (в стек их засовывать неразумно, а значит будете дёргать их из памяти), или работаете с данными фиксированного размера, но тогда вам нужно учитывать соответствующие ограничения. > Если вы не заметили, то конкретно я говорю про Ocaml. Может быть, > я когда-нибудь напишу что-то на PureScript или Gluon, но на данный > момент я говорю про Ocaml, а rust - так, по остаточному > принципу Ну и зачем вы мне тогда всё это пишете? Вам не всё ли равно, что я думаю о Rust? Да и я против других языков ничего не имею. Уже устал повторять - пишите вы на чём хотите, это ваше дело. Меня в данной ситуации напрягает именно само пропихивание языка и методы этого пропихивания. Потому что технически оно явно неоправданно. А значит - кто-то пытается на этом поиметь личную выгоду. За счёт общественного достояния, каковым ядро Линукс по сути и является. Я, если вы не заметили, вообще ничего не пишу, когда тут идут новости про ОС на Rust: хотят люди - пусть делают, это их время и им решать, на что его тратить. > Я устал от говнокода. Когда очередная программа падает с сегфолтом или работает > неправильно, в 2024 году, у меня и возникает желаение рассказывать, какое > уродство си и c++. Когда я понимаю, как легко создать баг > на си/плюсах, у меня отпадает малейшее желание писать хоть самый маленький > патч для этих программ. Ну так и не пишите, и не пользуйтесь "говнокодом" - вас насильно никто не заставляет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #395 Ответы: #409

408. Сообщение от ProfessorNavigator (ok), 19-Сен-24, 21:24	+/–
> А то, что нормальные языки появились давным давно, но были затмены говнокодом. > И если си ещё мог с ними соревноваться, так как он > ровесник некоторых из них, то вот уже c++ или python - > появились после них, и уже на момент своего релиза отставали по > фичам. Про голанг и говорить не приходится Ну т.е. опять безосновательный наброс. Какие "фичи", вы о чём вообще? У вас на С++ стандартная библиотека такого размера, что её ни один программист целиком не знает (да и не нужно это - нормальные люди перед реализацией интересуются наличием необходимых инструментов). Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямую. Если не хватает и этого - вам сделали ассемблерные вставки: делайте, что хотите.   > А точно в курсе? Вы давненько уже опубликовали свою программу, кто-то ваш > код читал и про парсер вам писал? Другие части ревьювил? Увы, > но далеко не у каждого сишника/плюсовика есть человек, который объяснит ему > что и почему он сделал неправильно. Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить. А мне бы этого не хотелось - здесь детей много. > Учитывая то, какие в некоторых ВУЗ-ах программы, то диплом тоже ничего не > гарантирует. Если это не МГУ какое-нибудь. Хы)) Я таких выпускников МГУ видал, что их на пушечный выстрел вообще ни к чему подпускать нельзя. Это я к том, что ВУЗ - да, не показатель. А вот профессия - по обстоятельствам. В моей (теперь уже бывшей), если вы не будете нормально применять знания, то всё закончится или вашей смертью, или тюрьмой. Я пока жив и даже на свободе, так что, видимо, образование у меня неплохое))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #396 Ответы: #435

409. Сообщение от Аноним (175), 19-Сен-24, 23:59	+/–
>Зачем плюсовиков в чём-то убеждать? Они ж по большей части в геймдеве заняты Увы, но нет. Огромное количество софта написано на си/плюсах. Vim, jq, Inkscape, Firefox, NetworkManager и так далее. Это очень разные сферы, с очень разными требованиями, но все как под копирку. В последнее время немного go популяризуется, но он в основном в мелких консольных утилитах. >и не тратить ресурсы на обработку ошибок Откуда такое нежелание обрабатывать ошибки? И потом, даже если размер возвращаемый fork-ом возрастёт в несколько раз, это всё равно не получится заметить. Это буквально экономия на спичках >Потому как что в fb2, что в epub используются урезанные специфические xml форматы Вот пример, есть два атрибута, и оба - строки. https://github.com/gribuser/fb2/blob/master/FictionBookLinks... Каким образом вы гарантируете, что в эти строки случайно или умышеленно не попадёт имя атрибута как подстрока? И потом, экранироваться должен любой пользовательский ввод, иначе программа ненадёжна. Слишком велик шанс того, что в противном случае нужное значение забудут обработать. >Как он ещё должен называться? Если по факту - это и есть xml парсер Этот код имеет к парсеру отношение не больше чем grep и sed. Он не обрабатывает ни ошибки синтаксиса, ни экранирование спецсимволов в атрибутов, ни прочие вещи >Да не вопрос - я бы даже взялся. Если мне за это заплатят. Пара минут поиска, и я выяснил, что существует libxml2. >Дело в том, что определённые типы данных, вроде того же int такие, какие есть, потому что они напрямую завязаны на аппаратную реализацию. За счёт этого они работают очень быстро, но при этом имеют ограничения по размеру в битах. Почитайте, как алгебраические типы данных реализованы в rust и ocaml(подсказка: очень эффективно). Rust это вообще системный язык(с вытекающей отсюда производительностью и низкоуровневостью). >Ну так и не пишите, и не пользуйтесь Увы, но я не могу писать абсолютно весь софт для себя сам. Вот не смогу я написать, например видеоредактор для того, чтобы однократно видео обрезать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #407 Ответы: #420

410. Сообщение от Аноним (411), 20-Сен-24, 00:37	+1 +/–
Язык с таким названием был бы настоящим подарком.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #383 Ответы: #445

411. Сообщение от Аноним (411), 20-Сен-24, 00:39	+/–
Мыши, станьте ежиками ))
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #363

412. Сообщение от xPhoenix (ok), 20-Сен-24, 08:46	+/–
Какое это имеет значение, если этим всё равно машины будут заниматься?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #423

413. Сообщение от BeLord (ok), 20-Сен-24, 09:53	+/–
Я могу написать отчет строго по внутренним стандартам компании на 300 страниц, а могу его же написать по делу, будет 30, так и с книгами. Порог вхождения действительно растет, с учетом того, что системы усложняются, все это умножается на повесточное образование и вуаля, реальных спецов становится все меньше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

414. Сообщение от BeLord (ok), 20-Сен-24, 09:56	+/–
Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент. Если сегодня устроить тендер на 10 млн долларов, написание Вордпад на С++, так чтобы код был безопасным, думаете спецы не справятся?-)) А если справятся, значит С++ проблем не имеет или имеет?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #415

415. Сообщение от Аноним (-), 20-Сен-24, 11:04	+/–
> Зачем, переход ради перехода? Для каждой задачи/бюджета свой инструмент. Потому что уже сейчас есть рабочий интрумент, который успешно применяется например  в андроиде. А с другой стороны - планы когда-то сделать возможно крутую штуку, но в году так 30м. > Если сегодня устроить тендер на 10 млн долларов, написание Вордпад на С++, так чтобы код был безопасным, думаете спецы не справятся?-)) Думаю нет. Посмотри какие бюджеты (можно прикинуть по средней зп на глассдоре) у таких проектов как андроид или хром. А ошибки там находят регулярно. > А если справятся, значит С++ проблем не имеет или имеет? Ну вот когда справятся, тогда и поговорим) Пока есть только такие старые данные In Android 13, about 21% of all new native code (C/C++/Rust) is in Rust. To date, there have been zero memory safety vulnerabilities discovered in Android’s Rust code. security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #414

416. Сообщение от Аноним (416), 20-Сен-24, 11:30	+/–
Раньше ради смеха си делали дифайнами внешне похожим на паскаль (фигурные скобочки бегин и энд заменяли) - ну хоть какая-то выдумка школьников. Сейчас просто взять Си и назвать его другим именем - норма. И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #383 Ответы: #417

417. Сообщение от Аноним (417), 20-Сен-24, 11:43	–1 +/–
> Сейчас просто взять Си и назвать его другим именем - норма. Это ти про сабж? Ну я бы сказал что он на СИ не похож совершенно. > И обязательно рассуждения - как включить это в состав ядра. Отстаньте уже - займитесь делом. А то что)? Будешь ныть? Мы как раз делом занимаемся, стараемся сделать ядро хоть немного лучше. И разгрести ту кучу кода, которую диды навалили.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #416 Ответы: #455

418. Сообщение от Аноним (418), 20-Сен-24, 12:17	+/–
> Причем что в дыряшке, что в плюсах int a + int b - это уже UB! О, а что нам даст rust? Он будет на всех вариантах процессоров ловить переполнение? Или будет тратить время на предварительные проверки? Каким из двух вариантов rust облажется? Или то же приемлемое для скорости UB?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #242

419. Сообщение от Аноним (418), 20-Сен-24, 12:21	+/–
> Лучше, если сломает. Явное лучше неявного. Явно перечисленные предупреждения лучше чем неявно, скрытые в чем-то другом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

420. Сообщение от ProfessorNavigator (ok), 20-Сен-24, 12:59	+/–
> Увы, но нет. Огромное количество софта написано на си/плюсах. Vim, jq, Inkscape, > Firefox, NetworkManager и так далее. Это очень разные сферы, с очень > разными требованиями, но все как под копирку. В последнее время немного > go популяризуется, но он в основном в мелких консольных утилитах. Спасибо, но вот go - точно не надо. > Откуда такое нежелание обрабатывать ошибки? Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? А системы реального времени? Где критически важно время обработки того или иного сигнала, а ошибки - можно и потом обработать. Например проверив - отработал ли процесс. > И потом, даже если размер возвращаемый fork-ом > возрастёт в несколько раз, это всё равно не получится заметить. Это > буквально экономия на спичках Ну во-первых, на fork свет клином не сошёлся. Во-вторых, опять же там, где достаточно банального int размером 16-32 бита, вы предлагаете запихнуть целый класс. Зачем? Более того, если уж так зачесалось - то на С++ делается это элементарно. Можно даже класс не создавать, обойтись локальной struct. Эффект будет тем же самым. Так что снова мимо. В общем - не нужен Rust, не нужен. Смиритесь уже)) И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. > Вот пример, есть два атрибута, и оба - строки. https://github.com/gribuser/fb2/blob/master/FictionBookLinks... > Каким образом вы гарантируете, что в эти строки случайно или умышеленно > не попадёт имя атрибута как подстрока? И потом, экранироваться должен любой > пользовательский ввод, иначе программа ненадёжна. Слишком велик шанс того, что в > противном случае нужное значение забудут обработать. Смотрите код, как обрабатываются атрибуты. > Этот код имеет к парсеру отношение не больше чем grep и sed. > Он не обрабатывает ни ошибки синтаксиса, ни экранирование спецсимволов в атрибутов, > ни прочие вещи Всё он прекрасно обрабатывает)) И вопрос не в том, как файл называется, а в том, что код делает. В данном случае - ровно то, что от него требуется. Если у вас есть желание докопаться до столба - пожалуйста, но только без меня. Потому как сути дела всё это не поменяет - ваши наезды на С/С++ абсолютно безосновательны, и вызваны отнюдь не техническими особенностями того или иного ЯП. Дальше данную тему смысла обсуждать не вижу. > Пара минут поиска, и я выяснил, что существует libxml2. Ну во-первых, она на С, а не на С++. Но это не суть важно. Важно другое: как и писал выше - зачем? Пара сотен строчек кода, и я получил ровно то, что мне нужно. После чего продолжил заниматься своими делами. А не ковыряться в незнакомом API, разбираясь, как его подогнать под выполняемые программой задачи. При этом моя программа не зависит от сторонней библиотеки. Т.е. ошибки/изменения  API в ней мне абсолютно по барабану, и не придётся тащить в систему нехилый кусок лишнего кода. > Почитайте, как алгебраические типы данных реализованы в rust и ocaml(подсказка: очень эффективно). Всё равно они работают медленнее банального int. Как и написал выше - вы мне предлагаете вместо 16-32 бит использовать целый класс. Зачем? Тем более, что на этапе проектирования программы всегда ясно - будет ли значение выходить за пределы размерности того или иного типа данных. И если такая вероятность есть, то нормальный программист это будет учитывать. > Rust это вообще системный язык(с вытекающей отсюда производительностью и низкоуровневостью). Да без проблем. Дело в другом - он просто не нужен. Он возник, потому что несколько "не таких, как все" чисто по приколу решили написать свой язык. А корпорации в нём увидели способ нажиться - и понеслась. С технической точки зрения оно бесполезно от слова совсем, поскольку создаёт ненужные проблемы на ровном месте, а вот преимущества - весьма сомнительные. Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. И предлагаемыми методами этого не решить. Потому что источник проблемы лежит не в ЯП, и даже не в IT в целом. Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++? В общем лучше, как уже написал выше, смиритесь и потратьте время на что-то более полезное, чем на споры со мной.   > Увы, но я не могу писать абсолютно весь софт для себя сам. > Вот не смогу я написать, например видеоредактор для того, чтобы однократно > видео обрезать. Не нужно ничего писать. Просто бросьте ф...ней страдать, и внезапно всё наладится. У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #409 Ответы: #425, #432

422. Сообщение от pavlinux (ok), 20-Сен-24, 13:11	+1 +/–
> Смишно. Этот альянс -- сборище жуликоватых хитрованов. The C++ Standards Committee - ISOCPP прокатит для твоего авторитета :D? https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #385 Ответы: #452

423. Сообщение от pavlinux (ok), 20-Сен-24, 13:13	+1 +/–
> Какое это имеет значение, если этим всё равно машины будут заниматься? Чинить и покупать они сами себя будут?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #412

424. Сообщение от pavlinux (ok), 20-Сен-24, 13:23	+/–
> Чистую СИшку учить может только любитель всяких некропрограмм и легаси. > Т.к даже под микроконтролееры можно писать и на плюсах и на расте. Чтоб рожать бинарники  размером с ROM? Я тя расстрою, DSP/MC и вообще embedded еще и на ассемблере пишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31

425. Сообщение от Аноним (-), 20-Сен-24, 13:25	+/–
> Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? А системы реального времени? Нет конечно. Но речь идет о ядре линукс или вообще о телефонах с андроидом. Для микроконтроллеров и тем более RTOS подходы совершенно другие. > Где критически важно время обработки того или иного сигнала, а ошибки - можно и потом обработать. Например проверив - отработал ли процесс. Прям как сделали разработчики Therac-25 убившие кучу народу. Или просто перезагрузив весь контроллер, как сделали Тойотовцы, и тоже с человеческими жертвами. > В общем - не нужен Rust, не нужен. Смиритесь уже)) Вы видели мемное видео про "не нужон ваш интернет!"? Оно мне чего-то вспомнилось) > И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. Комментарии полезные. Придует такой зеленый программист, студент или даже школьник. Почитает какое дно языки прошлого столетия и возможно не будет вкладывать в них усилия. Это же просто забота о нашем будущем! > Да без проблем. Дело в другом - он просто не нужен. Он возник, потому что несколько "не таких, как все" чисто по приколу решили написать свой язык. Примерно как Страуструп расширял СИшку? И потом выкатил си++? Вы не слышали как появилась QNX? Пара студентов после базового(!!) курса "как разработать ОС" решили попробовать. И у них получилось! А еще можно взять в пример одного матюкающегося фина, который решил "буду не такой как все! запилю свое ядро". > А корпорации в нём увидели способ нажиться - и понеслась. Хм.. и как они на нем наживаются? > С технической точки зрения оно бесполезно от слова совсем, поскольку создаёт ненужные проблемы на ровном месте, а вот преимущества - весьма сомнительные. Не уверен что моих или ваших компетенций достаточно, чтобы оценить техническую точку зрения. > Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. О, начинается)) "раньше програмитсы быљи огого, а сейчас... И код был оггого! Не то что сейчас" Можно просто написать в поиске этого сайта "уязвимость" и посмотреть как "качественно" писали раньше. > Решать же проблему предлагается... встраиванием статического анализатора кода в компилятор. И зачем? Если можно просто написать нормальный статический анализатор кода для тех же С/С++? Но за пол века его никто не написал. Наверное никому не нужно. > У вас проблемы есть куда как посерьёзнее, чем бессмысленные споры о ненужных ЯП - вот-вот мировая война очередная начнётся. А может даже и уже идёт. Т.е если где-то идет война, можно работу делать тяп-ляп? А может я уже на войне и мне нужен надежный ЯП, программу на котором не смогут взломать "написав" 28 бекспесов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #420 Ответы: #430

427. Сообщение от Аноним (295), 20-Сен-24, 14:24	+/–
> Вы хотели чекер борова - вам дают чекер борова в C++. Но внезапно это оказывается - "воровать хорошие идеи" Термин "воровать" человек применил в сердцах, от раздражения на вашу флюгерность. Да воруйте (или как хотите называйте) на здоровье! Бог в помощь! Вот только сначала долгое время кричать, что эти идеи "плохие", а потом их "воровать", соглашаясь, что они "хорошие" - вот это верх лицемерия и переобувания. Теперь объясни, когда вы были правы - тогда или сейчас, каким вашим словам верить? П - Последовательность. П.С. Можешь не отвечать, после такой последовательности в убеждениях Ваше мнение (не) ценно для нас.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #326 Ответы: #439

428. Сообщение от Аноним (428), 20-Сен-24, 14:56	+/–
1. Он говорит о безопасности, а не об оптимизациях, ты чего. И для опеннета можно добавить, что в линуксовой сишке это направление оптимизаций исключено (provenance-based alias analysis - это развитие type-based alias analysis, который отключён через -fno-strict-aliasing). 2. Если хочется и оптимизации в этом направлении, и безопасность в виде отсутствия UB, то мы возвращаемся в ~1989, когда в первый стандарт C добавили понятие UB без оговорок, что UB предпочтительно обнаруживать статическим анализом и предупреждать. То есть это в идеологии post-K&R C (& C++) заложено - компилятор может делать "глупые и опасные" оптимизации без предупреждений (пусть программист *сам* ищет у себя UB), потому что - видимо - в 1989 компьютеры были медленные, а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #429

429. Сообщение от Аноним (-), 20-Сен-24, 15:11	+/–
> 1. ... в линуксовой сишке это направление оптимизаций исключено Логично, нам же нужно быстрое ядро, а не надежное. > 2. в первый стандарт C добавили понятие UB без оговорок, что UB предпочтительно обнаруживать статическим анализом и предупреждать. Насчет статического анализа ты прав, возможно мощностей и алгоритвом, тогда действительно не хватало. Но хотя бы определение UB описано достаточно нормально. > То есть это в идеологии post-K&R C (& C++) заложено - компилятор может делать "глупые и опасные" оптимизации без предупреждений (пусть программист *сам* ищет у себя UB), В стандарте есть классный раздел Conformance. В котором указывается что A strictly conforming program shall use only those features of the language and library specified in this International Standard.2) It shall not produce output dependent on any unspecified, undefined, or implemen Т.е наличе UB сразу выкидывает написанный код из этой категории. А теперь подумаем, а есть ли у нас хотя бы одна программа на СИшке без UB))? > а компиляторщики пролоббировали свои интересы в комитете (чтобы им было меньше работы). Думаю проблема была в том, что уже были написанны тонны кода с разным поведением. И никто не хотел оказаться за бортом. Чтобы никого не обидеть - постановили "на усмотрение компилятора, пусть творит что хочет".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #428 Ответы: #434

430. Сообщение от ProfessorNavigator (ok), 20-Сен-24, 15:13	+/–
Давайте так. Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #425 Ответы: #431, #433

431. Сообщение от Аноним (-), 20-Сен-24, 16:46	+/–
> Давайте так. Я вам отвечу, но при одном условии Да вы не утруждайтесь вы так. Зачем тратить время на каких-то анонимов. > - вы честно  скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. Предложение конечно интересное, но ответу "мне не платят, я просто весело провожу время" вы наверняка не поверите. И это ваше полное право. > В противном случае - общайтесь с зеркалом. Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно. Так ответов особо и не было. Были какие-то бездоказательные утверждения про "не нужно", "маркетинг", "получают выгоду", "ничем не лучше". Которые как чайник рассела - ни опровергнуть, ни подтвердить. Причем они пихаются как аксиомы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #430

432. Сообщение от Аноним (175), 20-Сен-24, 19:26	+/–
>Спасибо, но вот go - точно не надо. Уж лучше уж go, чем си/плюсы, там хоть программистов муштруют GC, и постоянными err != nil. Авось, go-шник, уставший после каждой строки писать err != nil оценит красоту того же Ocaml. >Дело не в нежелании, а в возможностях. Вы уверены, что на каком-нибудь микроконтроллере у вас будет достаточно ресурсов? С какого момента речь зашла о микроконтроллерах? Почему при программировании десктопного/серверного софта меня должны волновать микроконтроллеры? >Во-вторых, опять же там, где достаточно банального int размером 16-32 бита, вы предлагаете запихнуть целый класс Во-первых, шестнадцатиразрядные ОС уже давно ушли в историю. Во-вторых, вы упорно повторяете свою же придуманную идею про классы. Вы так и не почитали, как это под капотом устроено, а устроено оно достаточно эффективно. >Более того, если уж так зачесалось - то на С++ Вот самая большая проблема - убедить плюсовика в том, что портить память, спотыкаться на UB, жонглировать магическими константами, велосипедить прочие вещи - неправильно. Вы мне сейчас предлагаете всю стандартную библитеку переделывать, когда в том же Ocaml всё это уже есть из коробки >И лучше своё время потратьте на что-нибудь более полезное, чем бесполезные комментарии на форумах. На любом форуме нужно предупреждать новичков о существовании хороших языков, типа Ocaml, и языков для отстрела ног, типа си или плюсов. >Смотрите код, как обрабатываются атрибуты. Вы мне не поверите до тех пор, пока я вам не скину файл, который будет неправильно обрабатываться вашей программой? >Ну во-первых, она на С, а не на С++. И что? Найдите на плюсах, несколько минут поиска. >Но это не суть важно. Важно другое: как и писал выше - зачем? Вам не нужна корректная обработка xml? У вас плохо работает почти всё: и распознавание атрибутов, и значение этих атрибутов и так далее. Или вам нужно буквально скинуть файл, который ваша программа не распознает? Мне лень править файл. >А не ковыряться в незнакомом API, разбираясь, как его подогнать под выполняемые программой задачи. Я был о вас лучшего мнения. Вот что-что, а взять библитеку, и разобрать с её помощью xml - это гораздо проще, чем реализовывать парсер с нуля >Rust и прочие подобные ЯП пытаются решить ровно одну проблему: падение уровня квалификации программистов. А вы сами - квалифицированный программист? Ещё раз повторюсь, если вашей библитеке подать на вход специально созданный под неё xml, то она не сможет его правильно разобрать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #420

433. Сообщение от Аноним (175), 20-Сен-24, 19:49	+/–
>Я вам отвечу, но при одном условии - вы честно скажете, сколько вам платят за комментарий и/или выложите в открытый доступ вашу методичку. Рыцарь на белом коне, вы Дон Кихот. Достаточно просто почитать спецификации си/плюсов, чтобы было понятно какой это ужас. Если вы недостаточно компетентны, то пойдите, почитайте, например блог PSV-Studio, разработавший статический анализатор для данных языков. >Поскольку одно и то же мне обсуждать по тридцать третьему кругу не интересно. Вы не обсуждаете, вы строите свои догадки, и блуждаете в плену иллюзий. Я вам несколько раз писал про алгебраические типы, но вы не удосужились прочитать, что это, и высказали своё неприятие. Только после того, как я привёл вам пример, вы признались в собственном незнании. Теперь вы придумали, что ADT реализуются как классы, с алокацией памяти в куче. Далее, будет идти вопрос о том, зачем нужен тип Option, когда есть null, но вы настолько застряли в "парадоксе Блаба", что отвергаете всё вам непонятное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #430

434. Сообщение от Аноним (428), 21-Сен-24, 17:40	+/–
> Но хотя бы определение UB описано достаточно нормально. Таки нет, потому что у него множество толкований и обоснование (в C Rationale) разошлось со сложившейся практикой. C89[1]: "Undefined behavior — behavior ... for which the Standard imposes no requirements. Permissible undefined behavior ranges from ... to ..." Часть "Permissible..." можно проигнорировать, потому что "no requirements" же (так и сделали в C99). "for which" можно истолковать как ограничение расползания UB (HDD отформатируецца, но только при исполнении строчки с UB), а можно не толковать. Обоснование говорит про "errors that are difficult to diagnose" и про расширяемость языка: "augment the language by providing a definition of the officially undefined behavior"[2]. Предложение сделать определение более человеколюбивым было[3]. C(++) здесь попали в бюрократическую ловушку. Стандарт не стимулирует компиляторщиков делать с UB что-нибудь осмысленное. Компиляторщики и не делают осмысленное, потому что стимула нет. Может, они ждали стимула со стороны (все, кто вкладывались в Ada, принесут им много денег, чтобы язык менялся в сторону большей безопасности), но за 30-35 лет не дождались, а теперь DARPA, АНБ и проч. смотрят в сторону Rust. К слову об осмысленности. Бесконечные циклы в C++ могут иметь UB, просто потому что они бесконечные[4]. Там в 1-м примере по ссылке шланг выкидывает такой цикл и вызывает функцию, которая нигде не вызывается. Потому что может. [1] http://port70.net/%7Ensz/c/c89/c89-draft.html [2] http://port70.net/%7Ensz/c/c89/rationale/a.html#undefin... [3] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2769.pdf [4] https://isocpp.org/files/papers/P2809R3.html связанное: https://github.com/llvm/llvm-project/issues/60622 https://lobste.rs/s/wwgxzk/infinite_loops_are_ub_c https://lists.isocpp.org/std-proposals/2020/05/1322.php
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #429

435. Сообщение от Аноним (175), 21-Сен-24, 17:41	+/–
>Какие "фичи", вы о чём вообще? Например, алгебраические типы данных. Никаким размером стандартной библиотеки их отстутствие не компенсировать >Плюсом к этому в С++ вы вполне можете использовать примерно 99% кода из С напрямую В какой-то момент хочется не количества, а качества >Прикрутите фонтан самомнения, иначе мне придётся вам в грубой форме пояснить, куда вам следует сходить. Самомнение здесь только у вас, раз на обоснованную критику вы готовы посылать в грубой форме
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #408

436. Сообщение от Аноним (449), 21-Сен-24, 20:34	+/–
>https://habr.com/ru/articles/511478/ В статье сразу же: "В предыдущей статье мы говорили о том, как избежать переписывания библиотеки на Rust, когда вам это не нужно." "Джоэл Сполски гораздо лучше меня объясняет это в статье о том, почему полные переделки проектов — плохая идея."
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188 Ответы: #447

437. Сообщение от Аноним (449), 21-Сен-24, 20:40	+/–
Проблема в обратном что программистов на Rust мало среди фанатиков Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #378

438. Сообщение от Аноним (449), 21-Сен-24, 20:55	+/–
Так используй языковой сервер и статические анализаторы, на дворе 21 век все-таки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #354

439. Сообщение от Аноним (449), 21-Сен-24, 21:03	+/–
А кто кричал, что идеи плохие? Воображаемые растохейтеры в твоей голове? Идеи хорошие, но сам Rust недостаточно хорош для перехода на него. Что тут непонятного и непоследовательного в этой позиции? P.S. Можешь не отвечать, все равно фанатики Rust ничего нового не напишут кроме своих стандартных агиток.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #427

440. Сообщение от Аноним (449), 21-Сен-24, 21:11	+/–
Значит что с правильным применением std::shared_ptr<> количество ошибок с памятью радикально уменьшается без всякого Раста.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #350

441. Сообщение от Аноним (449), 21-Сен-24, 21:18	+/–
Мы разумеется поверим на слово вам, анонимный иксперт с опеннета, а не опытным разработчикам на Rust, подробно описавшим в своих статьях причины дороговизны разработки на этом языке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #379

442. Сообщение от Аноним (449), 21-Сен-24, 21:20	+/–
Программа просто работает, например?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351

443. Сообщение от Аноним (449), 21-Сен-24, 21:24	+1 +/–
Переучатся, куда денутся. Как будто это первое изменение стандарта, к которому нужно привыкнуть. Я тоже желаю успехов данному начинанию. Если получится, оно сделает Раст ненужным.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #353

444. Сообщение от Аноним (449), 21-Сен-24, 21:36	–1 +/–
Так и Раст подражает другим языкам во многом. А тут буквально напрашивается следующий язык как он, только лучше, без его многочисленных недостатков. Тот же Zig это только первая ласточка и у него уже довольно большое коммьюнити, в основном бывших программистов на Расте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #384

445. Сообщение от Kuku (?), 21-Сен-24, 21:44	+/–
Да, но буковки "u" там все-таки не хватает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #410

446. Сообщение от Аноним (446), 22-Сен-24, 07:51	+/–
> NVIDIA пишет драйвер на Rust, но тут многим виднее... И при чём здесь NVIDIA? https://www.opennet.dev/60821-nova
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #355

447. Сообщение от n00by (ok), 22-Сен-24, 09:56	+/–
А в статье "Огонь и движение" тот же Джоэль Спольски объясняет, почему (и для кого) переделки проектов - хорошие не только идея, но и дело.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #436

448. Сообщение от laindono (ok), 22-Сен-24, 17:02	+/–
У типичной проги на расте тысячи зависимостей, суммарно миллионы строк. У типичной крестовой проги 1.5 зависимости завендорены в репозиторий. Но при этом время компиляции сравнимо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #449

449. Сообщение от Аноним (449), 23-Сен-24, 23:52	+1 +/–
Звучит как настоящее чудо. Поэтому хотелось бы увидет пруфы на данное чудо-утверждение.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #448

450. Сообщение от Аноним (449), 23-Сен-24, 23:54	+/–
Это костыль для отмазки, а не обратная совместимость. По факту старую прогу на Расте фиг соберешь без бубна.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #343

451. Сообщение от Аноним (451), 27-Сен-24, 01:11	+/–
Видимо, подустал от пропитанного "любовью" сообщества.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #265

452. Сообщение от adolfus (ok), 27-Сен-24, 12:27	+/–
>> Смишно. Этот альянс -- сборище жуликоватых хитрованов. > The C++ Standards Committee - ISOCPP прокатит для твоего авторитета :D? > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p34... $ ping www.open-std.org PING www.open-std.org (192.38.78.170) 56(84) bytes of data. ... ждите ответа ... ждите ответа ... ждите ответа ... Даже если, и что? С 1999 года было опубликовано несколько тысяч предложений, из которых в стандарты С (9899) и С++ (14882) вошло менее процента. Даже предложение MS про "безопасные" потоковые и строковые функции "*_s", поданное к стандарту 9899-2011, было отвергнуто абсолютным большинством из-за несовместимости интерфейса cо стандартными, что они специально сделали, с целью насрать и развалить стандарт. Но из-за того, что Mammoth Shit донатит, оно таки вошло, однако существует с 2011 г. в виде приложения. В 14882 вносят только то, что действительно повышает безопасность, а не понижает уровень вхождения нубов и возможность лажануться у борзопрограммеров. Повышение безопасности для снижения уровня вхождения -- тупик и комитет это четко понимает. Любые предложения в этом ключе, по крайней мере, до 14882-2017 отвергались. Более нового стандарта у меня нет, только последний драфт, поэтому оценить их не могу. Что касается "безопасности" программирования, то отказ от наследования и полиморфизма практически полностью ликвидирует проблемы с указателями, при этом производительность и компиляции и исполнения существенно растет. Проблемы с выходом за границы массивов? Ну так это логическая ошибка в чистом виде и за нее отвечает только программист. Он должен следить за тем, куда пишет и откуда читает. Кстати, оператор "[ ]" -- это синтаксический сахар для операций с указателями, о чем в стандарте четко написано. Соответсвенно, без навыков работы с арифметикой указателей с C и C++ с массивами нечего делать. Кто желает работать с массивами, не держа в уме при этом, как и что там происходит с адресами, пусть пишет свои тормоза с использованием STL. ЕНсть правило -- если функция что-то возвращает, возврат нельзя игнорировать или отдавать на откуп реакции по умолчанию. Все возвраты, особенно обернутые в исключения  в С++, должны контролироваться, Иначе уровень программиста расти не будет, сколько бы он лишнего прикладного кода вместо контрольного не написал.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #422

453. Сообщение от ДаНуНафиг (?), 03-Окт-24, 05:34	+/–
Это еще дожить надо до "removed"... std::auto_ptr с момента внесения до удаления жил 19 лет в стандарте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50

454. Сообщение от ДаНуНафиг (?), 03-Окт-24, 05:36	+/–
У меня ощущение, что порог входа наоборот падает. Раньше без арифметики указателей ничего не сделать было, а сейчас приучились все на векторах и shared_ptr делать, где надо и где не надо...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

455. Сообщение от Аноним (455), 03-Окт-24, 22:23	–1 +/–
ИИ разгребет, чисто вручную это малореально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #417

456. Сообщение от Аноним (456), 21-Окт-24, 19:58	+/–
ownership всегда было известно тому кто хотел его знать, с момента изобретения динамического выделения памяти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

457. Сообщение от Аноним (456), 21-Окт-24, 20:01	+/–
Даже нового кода на расте Гугл пишет очень малую долю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96

458. Сообщение от Аноним (456), 21-Окт-24, 20:29	+/–
Неочевидные проблемы, которые как правило не имеют отношения к реальной работе приложения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #351

459. Сообщение от Аноним (456), 21-Окт-24, 20:33	+/–
Очень своевременная и важная инициатива, которая позволит повысить безопасность без переписывания кода существующих проектов. Только нужно еще добавить автотранслятор на новый стандарт.
Ответить | Правка | Наверх | Cообщить модератору

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

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