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

"Выпуск языка программирования Rust 1.46"	+/–
Сообщение от opennews (?), 27-Авг-20, 21:49
Опубликован релиз 1.46 языка системного программирования Rust, основанного проектом Mozilla. Язык сфокусирован на безопасной работе с памятью, обеспечивает автоматическое управление памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime... Подробнее: https://www.opennet.me/opennews/art.shtml?num=53610
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Урри (?), 27-Авг-20, 21:49	+13 +/–
А вот и констэкспрешшены из плюсов подвезли. Глядишь, лет через 30 будет новый нескучный С++. Зачем, только, если уже есть один...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #3, #70

2. Сообщение от Аноним (3), 27-Авг-20, 21:52	–13 +/–
Всех программистов уже выгнали за то что не смогли нормальный язык сделать, а они все равно новые релизы это ненужно пилят.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7, #77

3. Сообщение от Аноним (3), 27-Авг-20, 21:54	–5 +/–
У Раста нет ниши, они даже нишу языков для браузерных движков занять не смогли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #19

4. Сообщение от Ordu (ok), 27-Авг-20, 22:00	+7 +/–
> Для повышения информативности сообщений об ошибках стабилизирована поддержка атрибута "#[track_caller]", полезного для функций, подобных unwrap, в которых не исключается возникновение сбоев (panic) при некорректном использовании типов. Указанный атрибут будет использован обработчиком panic для вывода местоположения вызывающего в сообщении об ошибке. Полезная штука. А то обработка паники накидывает несколько стековых фреймов, поверх того места, где panic! был вызван, при этом, часто мне не интересно где был вызван panic!, мне интересно где был сделан unwrap, приведший к панике, и приходится этот бектрейс глазами сканировать, выискивая нужное место. А тут можно сразу пропустить кучу неинтересных стековых фреймов и начать втыкать глазами туда, куда собственно нужно.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от Аноним (5), 27-Авг-20, 22:03	+/–
когда, интересно, тип f16 добавят в rust?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #6, #28

6. Сообщение от Ordu (ok), 27-Авг-20, 22:14	–2 +/–
А надо? Мне кажется, это что-то очень-очень специальное, не? Так ли это надо в языке, если можно сделать в библиотеке?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #9, #13

7. Сообщение от Аноним (7), 27-Авг-20, 22:14	+8 +/–
Мне так нравится, что старым сишникам  от этого неприятно. Казалось бы ну пилят и пилят, но на опеннете каждый раз такая боль у комментаторов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #8, #11, #33

8. Сообщение от аноним3 (?), 27-Авг-20, 22:21	+3 +/–
просто пользователи раста еще более помешанные паломники растоманства чем си. ну и их вечное хвастовство о превосходстве и безопасности раста, хотя если взять этот самый раст куда нибудь в системщину или похожие ниши он становится опаснее с++.)) вот и не любят их.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #25, #42

9. Сообщение от Аноним (-), 27-Авг-20, 22:24	+3 +/–
есть сомнения, что, как минимум, в embedded это очень актуально; в игроделании тоже используется для экономии ресурсов
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #15

10. Сообщение от Аноним (10), 27-Авг-20, 22:30	–1 +/–
Любому нормальному комментатору с опеннет ясно что недоязык с ужасным непонятным синтаксисом, небезопасный (потому что есть unsafe блоки), на котором даже не смогли браузер написать, не должен существовать. Все нормальные программисты пишут на Си
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #14, #20, #22, #75

11. Сообщение от ObjectiveC Alive (?), 27-Авг-20, 22:30	+3 +/–
Так это не сишники, а школота строчки кода ни на чем не написавшая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #27

12. Сообщение от ObjectiveC Alive (?), 27-Авг-20, 22:31	+3 +/–
Лол, чем оне тебе не понятен? Сложнее чем JavaScript ты хотел сказать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #17

13. Сообщение от anonymous (??), 27-Авг-20, 22:32	+/–
В нейронных сетях используются
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #16

14. Сообщение от Hellscream (?), 27-Авг-20, 22:37	+1 +/–
Все нормальные программисты пишут на ассемблере.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #74

15. Сообщение от Ordu (ok), 27-Авг-20, 22:39	+2 +/–
> есть сомнения, что, как минимум, в embedded это очень актуально; в игроделании > тоже используется для экономии ресурсов Я сомневаюсь насчёт embedded: это нужна железная поддержка этих самых short float, и это должно быть лучше, чем fixed point, который реализуется на обычной арифметике. То есть, у short float есть свои перки, типа диапазона +/-65k при 11 значимых двоичных цифр, но и всё же. Мне кажется, довольно специальная ситуация нужна. Вполне возможная ситуация, но очень редкая. (Впрочем, если ты можешь привести конкретный юзкейс, с которым столкнулся, я с удовольствием почитаю, для расширения кругозора.) А игроделам это слабо поможет, по-моему. 11 двоичных цифр точности, это примерно как три десятичных. Несколько операций над числами, и вот у тебя уже 5-7 двоичных цифр точности, то есть всего пара десятичных. Ты получишь 1.46, но 0.06 уйдёт в погрешности вычисления, то есть результат будет неотличим от 1.5. Может и можно найти какие-то задачи, где этого будет достаточно, но я чёт как-то затрудняюсь предположить. В графическом коде (куда я иногда заглядываю) я вижу чаще f64, чем f32.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #193

16. Сообщение от Ordu (ok), 27-Авг-20, 22:40	+/–
> В нейронных сетях используются А, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #36, #85, #117

17. Сообщение от Ordu (ok), 27-Авг-20, 22:42	+/–
> Лол, чем оне тебе не понятен? Сложнее чем JavaScript ты хотел сказать? Не ему не понятен. Он говорит про такую мифическую личность, как "нормальный комментатор opennet".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

18. Сообщение от Неа (?), 27-Авг-20, 22:50	+/–
Раст нужен только неосиляторам нормальных ЯП.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #21, #23

19. Сообщение от Аноним (19), 27-Авг-20, 22:52	–1 +/–
Ниша - замена легаси вроде C/C++ + веб-разработка. Отличные ниши.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #39, #90, #140

20. Сообщение от Аноним (19), 27-Авг-20, 22:57	+2 +/–
Прикол в том, что unsafe всё еще безопаснее C А Раст скорее конкурент C++, и в чем-то плюсы еще надо догонять. C по удобству он уже превосходит, хотя бы даже за счет трейтов (подобие ооп вместо беспощадных костылей C), карго и serde.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #38

21. Сообщение от Аноним (19), 27-Авг-20, 22:58	+/–
Раст сложнее большинства языков, дурилка)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #24, #26

22. Сообщение от Аноним (19), 27-Авг-20, 23:00	+2 +/–
Мне Раст казался непонятным, пока не начал вникать. Теперь понимаю, что всё более чем на своем месте и сделано с умом.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32

23. Сообщение от Аноним (32), 27-Авг-20, 23:01	+/–
+1
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #102

24. Сообщение от Аноним (32), 27-Авг-20, 23:02	+/–
> Раст бесполезнее и неудобнее большинства языков, дурилка) Поправил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #29

25. Сообщение от Аноним (19), 27-Авг-20, 23:04	–1 +/–
Если пользователи чего-либо за бесплатно хвалят и тем более защищают нечто - это очень весомый довод в пользу этого нечто, не правда ли?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

26. Сообщение от Аноним (44), 27-Авг-20, 23:06	+/–
Самый сложный — это C++. Учитывая темпы его развития, никто не сумеет перегнать этого монстра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #30

27. Сообщение от Аноним (19), 27-Авг-20, 23:06	–3 +/–
Зачем школоте поддерживать си вместо чего-то нормального?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #35

28. Сообщение от Аноним (28), 27-Авг-20, 23:07	+/–
crate half зачем прямо в язык-то? чтобы было?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #34

29. Сообщение от Аноним (19), 27-Авг-20, 23:08	–1 +/–
Фигню спорол и рад) Раст удобен и быстр, zero cost abstraction, и конкурентов по сути нет
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24

30. Сообщение от Аноним (32), 27-Авг-20, 23:09	–3 +/–
Что-то у нормальных людей в плюсах всё просто, логично и понятно. И нормальная инфраструктура. В отличии от этого ни на что не годного выкидыша. Как не написали на нём ничего, так и не напишут.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #31

31. Сообщение от Аноним (44), 27-Авг-20, 23:13	–1 +/–
А я и не спорю. Я, лишь хотел сказать, что C++ никак не ограничен. Программист самостоятельно думает, как решать задачи. У растоманов же многое предопределено и закостылено.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

32. Сообщение от Аноним (32), 27-Авг-20, 23:19	+4 +/–
Только вот писать на нём не удобно и не приятно. Ни одной нормальной и полнофункциональной IDE нет. Те плагины что есть в vim или emacs - да, подсветка синтаксиса. Ну плюс ещё какой минимум. Чувствуешь себя в 90-х когда пишешь на rust. Где вот это всё? Контекстный поиск, контекстный рефакторинг, встроенная справка, способность разобрать doxygen на лету и выдавать короткую справку по фонкциям, поддержка отладки с навигацией по коду. Где вот эта автоматическая навигация по коду при ошибках компилятора? Где это всё? Ну да, лабу написать можно, но начинаешь серьёзный проект и фуууууу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #66, #73, #80

33. Сообщение от Аноним (33), 27-Авг-20, 23:20	+1 +/–
Так это никакие не старые сишники, а студенты с хеллоуворлдами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

34. Сообщение от ANonym (?), 27-Авг-20, 23:30	+/–
зачем i128/u128 в rust добавили?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #37

35. Сообщение от аноним3 (?), 27-Авг-20, 23:34	+3 +/–
школота посмотрит на код си и код раст и скажет что код раст только для растаманов))) нет ну реально он весьма специфичен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #27 Ответы: #51

36. Сообщение от Аноним (36), 27-Авг-20, 23:40	+/–
А есть аппаратные FPU, которые могут в такие вещественные числа?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #40, #43

37. Сообщение от Аноним (36), 27-Авг-20, 23:42	+/–
Ну это ещё можно понять. Например, адреса IPv6 128 бит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #143

38. Сообщение от Аноним (36), 27-Авг-20, 23:46	+/–
>и в чем-то плюсы еще надо догонять Вот это точно. Догонять ему C++ в объектности, чтобы не подобие было, а полноценно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #50, #56, #78

39. Сообщение от Аноним (39), 27-Авг-20, 23:59	–6 +/–
Но ведь си это не легаси. Это модерн. Сказал я, только вчера выяснял почему в программе происходит какая-то дичь, оказалось на этой строчке int ret=execvp(args->argv[0], args->argv); argv не был инициализирован. Упс. Да, конечно, санитизеры без проблем нашли это в рантайме, но компилятору было норм. Копипаста до добра не доводит. Там ещё с фоновым тредом развлекуха была. Помог бы тут руст? Ну, вряд ли. Смысл как раз в том, чтобы иметь минимальный оверхэд в рантайме.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #41, #54, #81

40. Сообщение от Аноним (-), 28-Авг-20, 00:08	+1 +/–
В POWER10 есть аппаратные float16 и bfloat16
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

41. Сообщение от Аноним (39), 28-Авг-20, 00:17	–3 +/–
Ps. но я что-то не понял чем санитизер сейчас не доволен, кто-нибудь может пояснить мне? 223 ему нравится, а меньше нет. У меня там стояло 16 и больше 12 быть не может. void get_vals(char **buf,unsigned *var) {     char varbuf[223];     char *varbufp=varbuf;     unsigned char vari=0;     for(char *bufp=*buf;*bufp!='\0';bufp++) {         if (*bufp==' '||*bufp=='\n') {             if (varbufp==varbuf) continue;             else {                 *varbufp='\0';                 var[vari++]=atoi(varbuf);                 varbufp=varbuf;                 continue;             }         }         *varbufp++=*bufp;     }     *varbufp='\0'; }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #45, #46, #69, #91, #99, #128, #132

42. Сообщение от topin89 (ok), 28-Авг-20, 00:17	+8 +/–
Мне вот любопытно, те кто хейтят язык, они реально на С/C++ писали что-то сложнее, чем хелловорлд? И почему достаточное количество людей, которые писали -- не хейтят. У Раста есть проблемы, но они мало связаны с самим языком. Нет простой связи c C++, нельзя просто взять и сделать замену старым либам. Интерфейсы из коробки не умеют работать с нехваткой памяти, иногда это важно. Нет стабильного ABI в рамках платформ, нельзя распространять бинарные либы. Компилятор пока не такой крутой, как для C. Выстроить код так, чтобы оптимизация под SIMD была сама собой -- такая же магия, как и для плюсов. Наверняка есть другие реальные проблемы. Но вот этот реальный хейт на язык, для которого математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafe -- я не могу понять. Серьёзно, Майки пытались запилить свой клон, Гугол пытается понять, можно ли его плавно внедрять в свой хром, в Линукс впилили поддержку модулей на расте. Однозначно они все повелись на хайп, особенно Линус, да. Короче, мнение всех, кто не сможет сказать, чем он конкретно хуже C+± -- ничего не стоит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #44, #53, #63, #76, #155

43. Сообщение от Anonymous7879 (?), 28-Авг-20, 00:24	+1 +/–
The Arm architecture provides high-performance and high-efficiency hardware support for floating-point operations in half-, single-, and double-precision arithmetic.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

44. Сообщение от Аноним (44), 28-Авг-20, 00:30	+/–
>математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafe Ага, как скажешь. Если в программе есть UB, то оно может проявиться где угодно. Неопределённому поведению плевать safe тут код или нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #47

45. Сообщение от topin89 (ok), 28-Авг-20, 00:34	+/–
Ошибка здесь скорее всего var[vari++]=atoi(varbuf); вместо var[vari++]=atoi(varbufp); Думаю, не ругается, потому что при таком размере стека его не пробивает. Кстати, почему передаётся **buf, но используем только первая строка? Думаю, будет лучше void get_vals(char * const buf,unsigned *var) EDIT: Наглядный пример, что санитайзеры не всегда дают ответ, на какой конкретно строчке проблема. Как и то, что уж лучше с ними, чем совсем без них.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #48

46. Сообщение от None (??), 28-Авг-20, 00:38	+/–
Эммм... а что, готовой функции распарсить не нашлось? тот же scanf Ну и тут санитарзер особо не нужен - из исходного buf идёт копирование без каких-либо проверок, вписались в выделенный размер или нет. Так на C нельзя писать. Что вы выиграете? Некую производительность ценой порчи стека в непредсказуемой ситуации?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #49

47. Сообщение от topin89 (ok), 28-Авг-20, 00:42	+/–
>>математически доказано, что весь безопасный код безопасен в работе с памятью, и что если с ней есть неуловимые проблемы, то искать их надо строго внутри unsafe > Ага, как скажешь. Если в программе есть UB, то оно может проявиться > где угодно. Неопределённому поведению плевать safe тут код или нет. Всё верно. Но причины UB по памяти искать можно чисто в небезопасных блоках. Заметим, только по памяти. Проблемы с многопотоком компилятор ловит далеко не все. А часть штук типа signed overflow так и не считаются за UB, но если не знать -- ничто не поможет, кроме отладочной сборки, которая не всегда возможна из-за низкой скорости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #165

48. Сообщение от Аноним (39), 28-Авг-20, 00:49	+/–
Там buf байты на хипе (да, теоретически может быть переполнение, там их 256, но практически этого не случится никогда и 16 байтов на одно значение за глаза -- там UINT_MAX ограничено), var инты на стеке. Я так и не понял, как передать инты на хипе, выдаёт note: expected 'unsigned int *' but argument is of type 'unsigned int (*)[3]', но на стеке вполне работает. varbufp вместо varbuf выдаёт одни нули, а не значения, это явно не то что мне нужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #52

49. Сообщение от Аноним (39), 28-Авг-20, 00:51	+/–
В непредсказуемой ситуации мы уже потеряли ядро, это единственный вариант. Или космические лучи, я не знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46

50. Сообщение от Аноним (19), 28-Авг-20, 01:04	+1 +/–
Ну ООП в чистом виде не надо, трейты гибче, но пока иногда немного _недостаточно_
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

51. Сообщение от Аноним (19), 28-Авг-20, 01:05	–2 +/–
Та ладно, C объективно такая же мутатень, только в своем Не принижаю достоинства ни C, ни Раста, но вот просто как есть
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

52. Сообщение от topin89 (ok), 28-Авг-20, 01:09	+/–
А какая разница, на чём buf? Да хоть из общей памяти, зачем передавать указатель на указатель на строку, чтобы тут же его разименовывать? Как ты создаёшь это buf в таком случае? Принтами или дебаггером, проверь, что воообще у тебя в varbufp сразу перед atoi(varbufp). то что вообще в *buf в этот момент, может, там не только цифры и пробелы с новыми строками. Да и новые строки не всегда на '\n' оканчиваются, может, там '\r' затесалось. Чёрт, да там сам buf может быть не тем, что ожидаешь. EDIT: ОК, я ожидал, что это учебный или одноразовый код, и там заранее известно, что есть в строках, чего нет. Теперь я ничего не понимаю. Так что мне нужно как можно больше информации.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #55

53. Сообщение от Аноним (19), 28-Авг-20, 01:15	+2 +/–
> Нет простой связи c C++ С C достаточно простая. А с C++ мало у кого в целом есть простая связь из-за шаблонов, классов и этого всего > сделать замену старым либам На Расте даже замену либы C видел) Всё возможно, что совместимо с C > нельзя распространять бинарные либы Разве? У меня не было с этим проблем, включая на Андроиде (интеграция либы на расте в плюсовый Qt-проект) Можно примеры? Интересно чего стоит опасаться > Компилятор пока не такой крутой, как для C. LLVM и в Африке LLVM) (да, я понимаю, что речь не о том, но всё же)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #113, #173

54. Сообщение от Аноним (19), 28-Авг-20, 01:20	–2 +/–
Руст скорее всего не дал бы это использовать и ругнулся бы И Руст как раз минимален, поскольку тоже zero cost abstraction
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

55. Сообщение от Аноним (39), 28-Авг-20, 01:21	+/–
Не-не, там всё в порядке.   char *fbuf=malloc(256); rlen=read(fd,fbuf,256-1); unsigned varvals[3]; get_vals(&buf,varvals); При этом varbufp нужен только чтобы занулять последний байт, в buf всегда числа разделённые пробелом и завершающиеся \n, ничего иного там быть не может (никогда не было и не будет).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52 Ответы: #57, #58

56. Сообщение от topin89 (ok), 28-Авг-20, 01:24	+/–
Да фиг с ней, с объектностью. Банальные user-defined literals не помешали бы. Когда работаешь с углами и расстояниями, набивать 120_deg и 1_cm, чтоб оно само переводилось в радианы и метры очень удобно. Была инициатива, но уже 1,5 года как заглохла: https://internals.rust-lang.org/t/pre-rfc-custom-suffixes-fo...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #82

57. Сообщение от Аноним (39), 28-Авг-20, 01:32	+/–
get_vals(&fbuf,varvals); Если точнее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #59

58. Сообщение от topin89 (ok), 28-Авг-20, 01:34	+/–
Ух. Надеюсь, ты сейчас в процессе обучения. Тогда ошибки -- это нормально, а ругаться за незнания -- зло и неправильно, поэтому не буду. Итак, char *fbuf=malloc(256); Не инициализорован, последний символ не факт, что '\0' rlen=read(fd,fbuf,256-1); Тут всё верно, читаем 255 символов. Но вот потом нужно обязательно fbuf[rlen]='\0'; unsigned varvals[3]; Магические константы, а максимальный размер нужно обязательно проверять внутри get_vals. И передавать туда же. get_vals(&buf,varvals); Это всё круто, но где собственно &buf инициализируется? И нах он вообще нужен, передавай сразу fbuf и измени сигнатуру get_vals, чтобы он принимал указатель сразу на char * const вместо двойного указателя. Сорян, но None прав, C не Питон, ошибок не прощает и требует всё проверять самому. Edit: ну и сразу, всё верно, нельзя просто взять и передать массив в функцию в C. Хотя можно передать указатель на массив и уже в теле разименовывать. Что то в духе void random_func(int (*varname)[3]){ (*varname)[0] = 1; (*varname)[1] = 2; } Или передать указатель на структуру, внутри которой массив. Но обычно просто передают указатель и размер отдельной переменной, так проще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #60, #62, #127

59. Сообщение от topin89 (ok), 28-Авг-20, 01:43	+/–
> > get_vals(&fbuf,varvals); > > Если точнее. Ответил чуть ниже. И тогда ты должен изменить тип первого аргумента. Сейчас поясню в деталях. char **buf -- это массив массивов по факту. Если бы код был const int N = 10 char **buf = malloc(N*sizeof(char *)); for(int i=0; i < N; ++i){    buf[i] = malloc(256); } fbuf = buf[0]; то всё было бы норм. А так у тебя переход в случайный участок памяти, и как оно всё работало -- вообще загадка. И выходит, санитайзер такое не словил, учту на будущее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57 Ответы: #65

60. Сообщение от Аноним (39), 28-Авг-20, 01:44	+/–
В чём твоя проблема? Последний символ факт что \0 потому что я пишу if(-1==(rlen=read(fd,fbuf,256-1))){perror("can't read");_exit(EXIT_FAILURE);} else {fbuf[256-1]='\0'; fbuf[rlen-1]='\0';} вместо calloc >Магические константы, а максимальный размер 3 инта, и не изменится в обозримом будущем, если когда-нибудь через годы изменится, то это будет меньшая из проблем. >Это всё круто, но где собственно &buf инициализируется? Это fbuf и есть, ошибся при написании поста. >Сорян, но None прав, C не Питон, ошибок не прощает и требует всё проверять самому. Всё отлично и никаких ошибок в этом коде у меня нет, просто я не понимаю, чем санитизер не доволен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #61

61. Сообщение от topin89 (ok), 28-Авг-20, 01:47	+/–
> Всё отлично и никаких ошибок в этом коде у меня нет, просто > я не понимаю, чем санитизер не доволен. Хех. Ладно, троллинг засчитан, спокойной ночи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #64

62. Сообщение от Аноним (39), 28-Авг-20, 02:03	+/–
>Edit: ну и сразу, всё верно, нельзя просто взять и передать массив в функцию в C. Хотя можно передать указатель на массив и уже в теле разименовывать. Что то в духе Ну не знаю, я передавал указатель на указатель на байты, чтобы отправить в функцию чужой объект на хипе, я не вижу где там const, кроме самого указателя. Я всегда так делаю и всё нормально, лучше меня не научили. >передать указатель на структуру Ну тут я хотел передать 3 инта (с выделенной под них памятью, естественно) на хипе, аллоцированных в чужой единице трансляции, но компилятор меня обломал (аж несколько раз). Массив передать таким образом можно, и поскольку там всего 3 значения, я не стал заморачиваться и пихнул на стеке.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

63. Сообщение от deeaitch (ok), 28-Авг-20, 02:04	+2 +/–
Я писал и пишу. Большие диагностические вещи. Я пробовал элементарно перевести интереса ради на раст. Не то чтобы у меня не получилось. Но я не получил удовольствия от языка. В начале выглядит здорово и многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается ад. Нет инфраструктуры для раста. И не будет. Дальше микро веб сервисов и лабораторных он не пойдёт. Ну вставочки небольшие "типа" безопасные можно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #96, #104

64. Сообщение от Аноним (39), 28-Авг-20, 02:05	+/–
> Хех. Ладно, троллинг засчитан, спокойной ночи. Ну нет. Этот код успешно работает в продакшене больше года, и если бы с ним были проблемы, уже заметили бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #67

65. Сообщение от Аноним (39), 28-Авг-20, 02:12	+/–
> char **buf -- это массив массивов по факту. это переданный в единицу трансляции указатель на выделенные в хипе байты, что такое &fbuf? > Если бы код был Вообще не релевантно ведь, нет? Тут просто строка с байтами, адрес которой мы разыменовываем "где-то там".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #59

66. Сообщение от Аноним (66), 28-Авг-20, 02:52	+/–
https://www.jetbrains.com/rust/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

67. Сообщение от Аноним (39), 28-Авг-20, 03:13	+/–
>> Хех. Ладно, троллинг засчитан, спокойной ночи. > Ну нет. Этот код успешно работает в продакшене больше года, и если > бы с ним были проблемы, уже заметили бы. После уменьшения malloc и увеличения varbuf компилятор успокоился (и гцц и шланг), но теперь выдаёт некорректные значения. Т_Т Где я туплю? Чёрт, ладно, пора спать давно, потом разберёмся. Я просто знал что это прекрасный образец кода на UB в лучшем случае, и потому его не трогал. D: Алсо, шланговый мемори санитайзер пожаловался на неинициализированную память в unsigned varvals[3];, ну, тут я согласен, хотя в гцц она и инициализируется нулями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64

68. Сообщение от deeaitch (ok), 28-Авг-20, 03:32	+9 +/–
Вот заметил такую штуку. У приверженцев Rust всё время проблема с C/C++. То у них с памятью всё плохо, то ещё что непонятное и сложное. То они вечно себе в ногу стреляют. Зачем вы стреляете себе в ногу? Мазохисты? Вспоминается сразу две вещи: 1) Доктор, когда я делаю вот так, мне больно. А вы так не делайте. 2) Старая добрая игра Fallaut 2: "Вы стреляли в златоящеря и попали в себя, вы потеряли 20 пунктов жизни" Этакие люди неудачники. Но и приверженцы C/C++ не отстают. Но другая ситуация немного. У тех кто знает, понимает и умеет писать на C/C++ проблема не с языком Rust, у них проблема с фанатами Rust.  Что-бы не случилось, фанаты Rust вылазят везде и поносят всех. При этом не осилив даже элементарных правил работы с памятью. Они не могут. Вот честно, очень токсичное общество любителей Rust. У них все плохие, кругом дыры. Одни они умные. Всех надо обосрать. Приведешь им два аналогичных кода, с аналогичным поведением (вылетанием проги) на C++ и на Rust - Плюсовеки молчат, потому что понимают. Что слышно от любителей раста? - "Ты де.....л, ты ничего не понимаешь, ваш C++ от....ой." А поведение то одинаковое. Мне интересно. Откуда столько желчи и РЖАВЧИНЫ у приверженцев Rust. Тот кто его назвал так что-то подозревал?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #72, #79, #101, #103, #150, #176, #224

69. Сообщение от Webmonkey (?), 28-Авг-20, 03:55	+4 +/–
Какой п****ц. Кто-то реально так пишет, или это толстый траллинг был?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #84

70. Сообщение от Аноним (70), 28-Авг-20, 04:17	+7 +/–
Затем, что современный С++ - это лютый пипец на 2000 страниц стандарта. Такое ощущение, что туда пихают все, что приходит комитету в голову. Выучить это нереально и уж конечно на все 100% этот монстр использоваться не будет. Ну так и нафига он нужен, если есть более компактные и удобные языки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #83, #108, #188

71. Сообщение от Аноним (70), 28-Авг-20, 04:18	–1 +/–
Интересные фичи. Еще бы время найти поковырять...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #86

72. Сообщение от Аноним (70), 28-Авг-20, 04:23	+3 +/–
Так проблема не в языке, а в людях. Пользователи С++ в большинстве своем люди среднего или выше возраста, набившие на нем шишек, пробовавшие другие языки и прекрасно знающие о достоинствах (по-моему их нет, потому что есть С и Rust) и недостатках плюсов. А в Rust в основном (по крайней мере, в русскоязычном сегменте) молодежь, особо пороху не нюхавшая, зато кровь у них кипит. А еще у меня подозрение, что большая часть комментаторов тут ни на том ни на другом никогда не писала и просто сотрясает воздух: "Все ругают Rust, ну и я поругаю до кучи".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #87

73. Сообщение от Аноним (70), 28-Авг-20, 04:24	+/–
Ну так сделай. Сообщество спасибо скажет. Лично меня устраивает rust-mode + racer.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

74. Сообщение от Аноним (70), 28-Авг-20, 04:26	+/–
А чего не в машинных кодах сразу? Непорядок, ненастоящие программисты. Реально крутые программисты пишут в машинных кодах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14

75. Сообщение от Аноним (70), 28-Авг-20, 04:28	+/–
Мне неясно. Нормальный язык с нормальным и вполне понятным синтаксисом. Unsafe тебя из-под палки никто не заставляет использовать. Браузер написать смогли бы, если б не эффективные манагеры Мозиллы, у которых видение поменялось. И да, я пишу на Erlang, по-твоему я ненормальный программист?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

76. Сообщение от Аноним (70), 28-Авг-20, 04:32	+/–
> Мне вот любопытно, те кто хейтят язык, они реально на С/C++ писали что-то сложнее, чем хелловорлд? вот точно такие же мысли. Под каждой новостью про Rust лютый срач. И подавляющее большинство, по-моему, просто сотрясает воздух.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

77. Сообщение от Аноним (70), 28-Авг-20, 04:36	–2 +/–
Интересное наблюдение. При том, что никто никого не выгнал, а перевели фактически в Rust Foundation, что как раз просто замечательно ибо зависимость от компании - ну такое себе. Go вон полностью зависим от Google и как Google захочет, так и будет развиваться. Захочет - закроет обратно, и миллионы вебмакак останутся без работы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #92

78. Сообщение от Аноним (70), 28-Авг-20, 04:40	+/–
Не надо. ООП в том виде, в каком оно есть сейчас давно пора закопать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38

79. Сообщение от Nick (??), 28-Авг-20, 06:45	–1 +/–
> Что-бы не случилось, фанаты Rust вылазят везде Вот только в этот раз ты вылез и начал хейтить Раст в теме про Раст. Так что фанатики С++ ни чем не лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #189

80. Сообщение от Аноним (80), 28-Авг-20, 07:28	+/–
rust-analyzer посмотри, активно развивается и уже много чего умеет, есть интеграция в разные редакторы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #32

81. Сообщение от Lex (??), 28-Авг-20, 08:11	+/–
Ууу. Обращение к элементу массива без проверки его наличия и длины.. Нынче за это нередко даже в JS карают
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #164

82. Сообщение от Аноним (82), 28-Авг-20, 08:14	+/–
А в чем проблема сделать такой атрибут и положить во внешний крейт. Кому надо, тот подключит. Зачем это тащить в язык?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56 Ответы: #174

83. Сообщение от asd (??), 28-Авг-20, 08:38	+1 +/–
Аминь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

84. Сообщение от Онаним (?), 28-Авг-20, 08:41	+3 +/–
Вы удивитесь, но куча народу пишет именно так. Даже если в конкретном случае это троллинг. А потом мы удивляемся - "ачигосишечкатакаядырявая". Это не сишечка дырявая, это головы дырявые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69 Ответы: #95

85. Сообщение от Онаним (?), 28-Авг-20, 08:44	+/–
Чисел много, и что там в этих числах - безразлично. Всё равно шум на выходе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #115

86. Сообщение от Брат Анон (?), 28-Авг-20, 08:58	+1 +/–
Бери Go. Там давно и panic есть, и функции возвращающие константы на этапе компиляции. И автоматический сборщик мусора без всякого геморроя.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71 Ответы: #89

87. Сообщение от Козлетто (?), 28-Авг-20, 09:04	+/–
Молодежь аха? У меня целая куча знакомых, как раз среднего и выше возраста. Они не то что программировать, а просто включить пк целое достижение. Не говоря ещё о бабульках. Так что нечего гнать на молодёжь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #72 Ответы: #88

88. Сообщение от Аноним (70), 28-Авг-20, 09:15	+/–
И вот что это было? При чем тут выключить/выключить? Речь-то было про то, что срачи устраивают в основном молодые.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87 Ответы: #94

89. Сообщение от Аноним (70), 28-Авг-20, 09:16	+1 +/–
Спасибо, Go я ковырял 2 года, хватит с меня. Когда надоело материться и блевать с этой корявой поделки Гугла, вернулся к Erlang'у.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #86 Ответы: #171

90. Сообщение от Аноним (90), 28-Авг-20, 09:18	+1 +/–
Лол, так почему он её так и не занял?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

91. Сообщение от Ordu (ok), 28-Авг-20, 09:20	+1 +/–
А можно поинтересоваться для повышения образованности? Что за схема именования переменных? У меня эти имена вообще в голове не укладываются, я не могу читать код, потому что они путаются у меня в голове. Не вижу схемы, не вижу смысла => они все одинаковы для меня. Мне кажется, что рандомно-сгенерированные наборы букв были бы читаемее. var, buf, p, и всё возможные комбинации из трёх. Зачем? В латинском алфавите 26 букв, можно было бы под каждую переменную выделить свою букву, и было бы читаемее чем это. И, кстати, короче.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #163

92. Сообщение от Аноним (90), 28-Авг-20, 09:24	+1 +/–
Это такой же отстойник ненужных проектов как и Апач Фаундейшн. У Раст Фаундейшн даже инвестора нет, а на 250 программистов им надо не меньше 25 млн долларов в год. Которые им никто не даст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77 Ответы: #93

93. Сообщение от Аноним (70), 28-Авг-20, 09:29	–1 +/–
При том, что Растом активно интересуются Microsoft и Google (при всей моей нелюбви к ним), конечно, им никто не подаст.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92 Ответы: #105, #114

94. Сообщение от 1 (??), 28-Авг-20, 10:03	+3 +/–
просто дедушки и бабушки с успехом программируют на Rust
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #88

95. Сообщение от Tita_M (ok), 28-Авг-20, 10:04	+/–
Шоко... т.е. Си ни в чём не виноват!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

96. Сообщение от topin89 (ok), 28-Авг-20, 10:51	+3 +/–
> Я писал и пишу. Большие диагностические вещи. Я пробовал элементарно перевести интереса > ради на раст. Не то чтобы у меня не получилось. Но > я не получил удовольствия от языка. В начале выглядит здорово и > многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается > ад. О, реальный опыт, это ценно! Можешь рассказать, в чём именно был ад, что есть или чего нет в Расте и C/C++, что делает его менее удобным в работе с 50+ файлами? > Нет инфраструктуры для раста. И не будет. Дальше микро веб сервисов и > лабораторных он не пойдёт. Возможно. Но тоже не факт. Вряд ли кто думал, что питон как язык для data science. Чего уж там, что он вообще взлетит, он же старше Java, но долго проплывал мимо радара. > Ну вставочки небольшие "типа" безопасные можно. Даже это уже неплохо.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #183

97. Сообщение от Аноним (97), 28-Авг-20, 10:52	+1 +/–
Пишу на Си и на asm, зарабатываю на жизнь в embedded. Хочется вкатиться в rust но не знаю, откуда и главное как начать. Хотелось запустить с отладкой mips(pic32mm) или risc-v(gd32) в eclipse. У кого-нибудь есть такой опыт?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #98, #162, #201, #202

98. Сообщение от Аноним (70), 28-Авг-20, 11:03	–1 +/–
>но не знаю, откуда и главное как начать так отсюда же: https://www.rust-lang.org/what/embedded. А вот более детально не расскажу. Самому интересно повозиться, но времени нет совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

99. Сообщение от охохо (?), 28-Авг-20, 11:14	+/–
strtok_r + atoi ?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #160

101. Сообщение от Аноним (102), 28-Авг-20, 11:15	+2 +/–
Т.е. все CVE по памяти подлые растоманы в плюсовые проекты накоммитили? Только на этом сайте в месяц пара-тройка новостей про то что тут буфер переполнился, там за границы массива вышли (и рут получили) и это по большим проектам, на которые обратили внимание. Может это все неправда и происки хейтеров-злопыхателей? Или это все наделали "ненастоящие С++ программисты"™ потому что "настоящие С++ программисты"™ такие ошибки не допускают? Вы можете ненавидеть раст всеми фибрами своей с++ной души, но отрицать проблему стабильно повторяющиеся багов с памятью на плюсах в разнообразнейших больших проектах... это просто непрофессионально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #178

102. Сообщение от Аноним (102), 28-Авг-20, 11:16	+/–
Т.е. все CVE по памяти подлые растоманы в плюсовые проекты накоммитили? Только на этом сайте в месяц пара-тройка новостей про то что тут буфер переполнился, там за границы массива вышли (и рут получили) и это по большим проектам, на которые обратили внимание. Может это все неправда и происки хейтеров-злопыхателей? Или это все наделали "ненастоящие С++ программисты"™ потому что "настоящие С++ программисты"™ такие ошибки не допускают? Вы можете ненавидеть раст всеми фибрами своей с++ной души, но отрицать проблему стабильно повторяющиеся багов с памятью на плюсах в разнообразнейших больших проектах... это просто непрофессионально.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

103. Сообщение от Аноним (103), 28-Авг-20, 11:40	–2 +/–
Мне понравился на опеннете пару месяцев назад достаточно адекватный коммент, что Rust по факту энфорсит бест практизы C++ (RAII) через синтаксис, следуя уже бест практизам некоторых функциональных языков (типа Idris), что некорректное состояние должно быть формально невыразимым. Тот же Idris достигает это через зависимые типы, в Rust такого нет и формальная корректность гарантируется только для овнершипа по памяти. Собственно, хороший специалист в С++ с набитой рукой будет пользоваться смартпоинтерами практически безошибочно, но даже у него может замылиться взгляд. Rust vs C++ это примерно как Go vs Java, т.е. просто новый язык, призванный снизить порог входа и удешевить разработку, за счет снижения сложности некоторых областей до неприличия (Go имеет крайне скудный и неудобный синтаксис, отсутствие дженериков, но работа с многопоточностью в нем шикарна).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #141

104. Сообщение от DEV (?), 28-Авг-20, 11:41	+4 +/–
>>В начале выглядит здорово и многообещающе. Но стоит разрастись проекту до хотябы 50-ти файлов и начинается ад. интересно послушать в чём заключается ад, можешь рассписать?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #184

105. Сообщение от Аноним (105), 28-Авг-20, 11:47	+/–
Языку десятый год. И им только интересуются, но не используют. А все эти новости где один программист из Гугла затестил Раст сразу в среде растошкольников выливается в то что Гугл полным составом перешел на Раст. Никто на него не перешел и нигде не использует успокойтесь уже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93 Ответы: #110, #111

108. Сообщение от Аноним (-), 28-Авг-20, 11:50	+2 +/–
Ты так пишешь, будто современный Ржавч лучше. Стандарта нет, но для языка, который кичится отсутствием UB, это только показатель его недоделанности. Синтаксис страшнее самых страшных плюсовых шаблонов, а поддержка ООП при этом даже не заявлена.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #109

109. Сообщение от Аноним (70), 28-Авг-20, 11:55	+2 +/–
Да и нафиг не надо ООП, я в нем разочаровался, когда попробовал ФП в лице Erlang. Синтаксис нормальный, страшно только поначалу. А то что стандарта нет... Видели мы эти стандарты, 30 страниц стоит 11 килорублей, в общий доступ никто не выложил. Спрашивается, на кой х мне этот стандарт, если я его прочитать не могу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #108 Ответы: #112

110. Сообщение от Аноним (70), 28-Авг-20, 11:59	–2 +/–
Детка, я спокоен как фугас. И школу закончил в далеком 2004. А то, что им интересуются (и не один программист), показывает только то, что язык наконец дорос до продакшена и что в традиционных языках интересующиеся разочаровались.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

111. Сообщение от Аноним (70), 28-Авг-20, 12:03	+/–
И собственно, меня мало волнует, кто и по какой причине им интересуется. Я не фанат ни мелкомягких ни корпорации зла - они уроды и лицемеры. Однако ж гугл интересуется им, а не кидается хромиум переписывать на своем Го. Лично я интересуюсь Растом, потому что он мне нравится. Точно также как нравятся Erlang и Lisp, которыми никто не интересуется, и нравится С, чьи мнимые фанаты под каждой новостью про Раст ссут кипятком от негодования.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #105

112. Сообщение от Аноним (240), 28-Авг-20, 12:10	+/–
Ага, сделать софтинку, типа какого CAD'а, без ООП - мазохизм.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #109 Ответы: #118, #119

113. Сообщение от Аноним (240), 28-Авг-20, 12:12	+/–
LLVM и в Африке не нужен. (да, я понимаю, что речь не о том, но всё же)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #126

114. Сообщение от Аноним (240), 28-Авг-20, 12:16	+1 +/–
>Растом активно интересуются Microsoft У них свой Verona. Похожий, но не Rust.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #93

115. Сообщение от Аноним (240), 28-Авг-20, 12:21	+/–
На выходе булева переменная - узнал/не_узнал (фейс Онанима).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #85 Ответы: #157, #243

117. Сообщение от freehck (ok), 28-Авг-20, 12:27	+/–
> А, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно. От себя  добавлю немного: в нейронках может точность нужна и повыше, но вот в научных расчётах оперируют точностью до порядка. Наверняка есть области, в которых три значащие десятичные цифры -- это вполне себе нормальное значение. Однако я давно не встречал, чтобы кому-то было f16 нужен. Учёные народ не замороченный, херачат максимальный размер как правило и ждут более производительного кластера.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16 Ответы: #135

118. Сообщение от Аноним (70), 28-Авг-20, 12:29	+/–
И как же ж их делали до появления ООП... Наверно, мазохистами все были.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #122

119. Сообщение от Аноним (70), 28-Авг-20, 12:32	+/–
И то, что есть в C++, Java и других монстрах - не ООП в том виде, в каком оно задумывалось. В этом смысле как раз Erlang со своей моделью акторов ближе к оригинальной идее ООП.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #112 Ответы: #123

122. Сообщение от Аноним (240), 28-Авг-20, 12:35	+/–
В те времена они ещё были такие, что умещались в 640 кбайт или меньше. И да, мазохисты, на разработку тратили гораздо больше человекочасов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #118 Ответы: #154

123. Сообщение от Аноним (240), 28-Авг-20, 12:37	+/–
Может быть, но Erlang, мягко говоря, не взлетел дальше телекоммуникаций.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #119 Ответы: #124, #125

124. Сообщение от Аноним (240), 28-Авг-20, 12:39	+1 +/–
И, вроде, считается, что самое правильное ООП было в Smalltalk.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123

125. Сообщение от Аноним (70), 28-Авг-20, 12:40	+/–
Расскажите это Facebook, чьи сервера WhatsApp поголовно на нем. Или тем, кто использует RabbitMQ или cowboy, написанные на Erlang. Я сейчас пишу на нем и проект настолько далек от телекоммуникаций, насколько это можно, но близок к блокчейнам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #123 Ответы: #129, #130

126. Сообщение от Ordu (ok), 28-Авг-20, 12:45	+/–
> (да, я понимаю, что речь не о том, но всё же) "Но всё же" смолчать никак не можешь? Такая острая тема, так подгорает, что даже понимая оффтопичность её, молча пройти мимо никак не можешь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #113 Ответы: #131

127. Сообщение от Ordu (ok), 28-Авг-20, 13:16	+/–
> Edit: ну и сразу, всё верно, нельзя просто взять и передать массив > в функцию в C. Хотя можно передать указатель на массив и > уже в теле разименовывать. Что то в духе Можно. Глянь: #include <stdio.h> #include <stdlib.h> void fill_array(int arr[3]) {     for(int i = 0; i < 3; i ++) {         arr[i] = i;     } } int main() {     int arr[3];     fill_array(arr);     printf("%d, %d, %d\n", arr[0], arr[1], arr[2]);     return 0; } Можно в аргументах написать: int arr[3] int arr[] int *arr Всё это разные записи для плюс-минус одного и того же, но первый способ даст возможность статическим анализаторам ругнутся, при очевидных выходах за границу массива. Последний способ даст возможность менять arr, а не только *arr.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58

128. Сообщение от имя_ (?), 28-Авг-20, 13:30	+/–
>++= руки бы тебе оторвать за такое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #161

129. Сообщение от имя_ (?), 28-Авг-20, 13:34	+1 +/–
эрланг хорош, но ведь фейсбук не выбирал его, это выбор изначального разработчика
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125

130. Сообщение от Аноним (240), 28-Авг-20, 13:39	+/–
Ну так я же и написал, кроме телекоммуникаций. Что не так-то?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #125 Ответы: #133, #134

131. Сообщение от Аноним (240), 28-Авг-20, 13:42	+/–
А ты для чего упомянул?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #126 Ответы: #136

132. Сообщение от Ordu (ok), 28-Авг-20, 14:00	+/–
Задумка этого кода в том, чтобы прочитать три инта из строчки? Инты разделены пробельными символами? На, держи. Код совсем уж безбажен (как минимум там может быть переполнение unsigned в my_atoi), но навскидку это должно выглядеть так. Длинее чем у тебя, но зато читабельнее: проще понять и проще мейнтейнить #include <stdio.h> #include <stdlib.h> #include <ctype.h> static const char *skip_spaces(const char *p) {     while(isspace(*p) && *p != '\0')         p ++;     return p; } static const char *skip_digits(const char *p) {     while(isdigit(*p) && *p != '\0')         p ++;     return p; } // my_atoi: Преобразует первые len байт строки p в unsigned, и возвращает. // NB: не проверяет корректность строки, это забота вызывающего кода // Rationale: Библиотечные C'шные функции совершенно убоги, любят менять // указатели, или хотят '\0' в конце, не умеют сообщать об ошибках,... У каждой // свои косяки, нет ни одной пристойной. Проще самостоятельно проверить ввод и // самостоятельно преобразовать. static unsigned my_atoi(const char* p, size_t len) {     unsigned ret = 0;     for(size_t i = 0; i < len; i ++) {         ret *= 10;         ret += p[i] - '0';     }     return ret; } // get_vals: читает из buf три числа, разделённых пробельными символами, и // пишет их в массив vars. // Возвращает количество успешно прочитанных чисел. int get_vals(const char *buf, unsigned var[3]) {     const char *p = buf;     if(buf == NULL) {         fprintf(stderr, "KILL YOURSELF MOTHERFUCKER, BUF CANNOT BE NULL\n");         exit(-1);     }     for(size_t i = 0; i < 3; i ++) {         const char *start = skip_spaces(p);         const char *end = skip_digits(start);         if(start == end)             return i;         var[i] = my_atoi(start, end - start);         p = end;     }     return 3; } int main() {     unsigned arr[3];     char* bufs[] = {         "1 2 3", "    12\t398746 \n 2397\n\n",         "12345", "1 2, -100"     };     for(size_t i = 0; i < sizeof(bufs)/sizeof(bufs[0]); i ++) {         int ret = get_vals(bufs[i], arr);         printf("ret: %d; vals: (%u, %u, %u)\n", ret, arr[0], arr[1], arr[2]);     }     return 0; } Вывод: ret: 3; vals: (1, 2, 3) ret: 3; vals: (12, 398746, 2397) ret: 1; vals: (12345, 398746, 2397) ret: 2; vals: (1, 2, 2397)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41 Ответы: #152, #159

133. Сообщение от Аноним (70), 28-Авг-20, 14:08	+/–
> Erlang, мягко говоря, не взлетел дальше телекоммуникаций Я привел примеры не из сферы телекома, где есть Erlang.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

134. Сообщение от Аноним (70), 28-Авг-20, 14:12	+/–
Еще примеры, и там тоже не только телеком: https://www.erlang-solutions.com/blog/which-companies-are-us... Амазон и Yahoo вроде еще что-то на Erlang'е делали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #130

135. Сообщение от Ordu (ok), 28-Авг-20, 14:19	+/–
>> А, да, вот этим может помочь, точно. Чисел много, но хрен его знает сколько точности не нужно. > От себя  добавлю немного: в нейронках может точность нужна и повыше, > но вот в научных расчётах оперируют точностью до порядка. В научных расчётах _иногда_ оперируют точностью до порядка. Я часто в уме такого рода расчёты провожу, чтобы прикинуть что к чему. Очень удобно. > Однако я давно не встречал, чтобы кому-то было f16 > нужен. Учёные народ не замороченный, херачат максимальный размер как правило и > ждут более производительного кластера. Какая бы точность не была нужна на выходе, если ты считаешь дифуру, то в этих расчётах могут быть тысячи шагов по дискретизированному времени, например, и каждый шаг привносит ошибки округления, потому что машинное представление числа неидеально. Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #117 Ответы: #137

136. Сообщение от Ordu (ok), 28-Авг-20, 14:22	+/–
> А ты для чего упомянул? Потому что для меня больная тема -- это анонимы, которые не могут молчать. Точнее, это частный случай проявления темы: вообще забавно наблюдать, когда людьми начинают рулить их убеждения и они с этим ничего не могут поделать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #131

137. Сообщение от freehck (ok), 28-Авг-20, 14:35	+/–
> Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата. Вот к чёрту теоремы о сходимости, да? В подобных расчётах смотрят не на эволюцию, а ищут стационарное решение. Можно уменьшить шаг по времени и удовлетворить тем самым условия сходимости. Можно увеличить дискретность эйлеровской сетки. Считать будешь дольше, зато на меньших ресурсах, и придёшь к тому же результату. > В научных расчётах _иногда_ оперируют точностью до порядка. Такие расчёты проводятся весьма часто.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #135 Ответы: #138

138. Сообщение от Ordu (ok), 28-Авг-20, 15:20	+/–
>> Ошибка накапливается, и поэтому часто расчёты проводятся с заведомо большей точностью, чем требуется от конечного результата. > Вот к чёрту теоремы о сходимости, да? Теоремы о сходимости чего? Даже если ты возьмёшь заросшую мхом проблему трёх тел, даже там есть элементы хаотического поведения, когда небольшие флуктуации вырастают в большую разницу. Не, ну ты прикинь, вот есть у тебя реккурентное соотношение (x[n+1], x'[n+1]) = F(x[n], x'[n]). Ты берёшь и считаешь 100k шагов, чтобы промоделировать поведение тел в Солнечной системе на 10 лет вперёд. И чё? Что и куда у тебя будет сходится? Твоя реккурентная формула будет чем дальше, тем больше расходится с дифурой. > В подобных расчётах смотрят не > на эволюцию, а ищут стационарное решение. Естественно. Никому не интересно предсказывать движение тел СС, всем интересны исключительно стабильные орбиты. Кстати, гравитационные дифуры тоже отличаются тем, что там иногда мелкие изменения приводят к большим последствиям. И это ты не решишь никак без увеличения точности расчётов. > Можно уменьшить шаг по времени > и удовлетворить тем самым условия сходимости. Можно увеличить дискретность эйлеровской > сетки. Считать будешь дольше, зато на меньших ресурсах, и придёшь к > тому же результату. Хехе. Чем меньше шаг, тем больше шагов. То есть, если бы ты считал, оперируя вещественными числами, то точность у тебя бы расла несомненно. Но поскольку на каждом шаге, после каждой арифметической операции, ты округляешь результат, то количество округлений растёт, а значит растёт и погрешность. То есть тут всё неоднозначно. Даже если при окрулениях у тебя не будет систематического bias'а, и ошибка будет случайной, то вообще-то случайные брождения, если мне память не изменяет, сдвигают на расстояние l*sqrt(n), где l -- это длина одного случайного шага, а n -- количество таких шагов. В многомерных случаях будет сложнее, но ты сам можешь посмотреть. >> В научных расчётах _иногда_ оперируют точностью до порядка. > Такие расчёты проводятся весьма часто. Ты пытаешься доказать мне, что эти расчёты надо проводить в f16? Где диапазон +-65k? Где 5 бит под показатель степени двойки? Не, если всё прологарифмировать заранее, перейти в логарифмическую шкалу и заменить умножения сложениями, так чтобы f16 представлял бы собой тот самый порядок, с точностью до которого мы считаем, то может и ничего так, покатит. Но не проще ли взять f64, посчитать как есть и прологарифмировать после? Или ты знаешь примеры, где эти расчёты с точностью до порядка нагружали систему так, что имело смысл подбирать специальное железо со специальными какими-то типами данных? Расскажи о них, всем будет интересно и познавательно. Да вообще, выкинь всё вышенаписанное и расскажи мне о тех научных вычислениях, которые ты проводил в f16.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #137

139. Сообщение от СССР (?), 28-Авг-20, 15:34	+/–
"Автоматическое управление памятью в Rust избавляет разработчика от ошибок при манипулировании указателями" - что бы ваши ети передвигались на инвалидных креслах. Я исключительно ради заботы, ведь передвигаясь на ногах можно споткнуться , забить лоб и умиреть! поэтому пусть передвигаются на инвалидных кресах от проктэр&гэмбэл с автоматизированной головкой!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #142, #169, #225

140. Сообщение от СССР (?), 28-Авг-20, 15:37	+/–
С++ развиватсяв ногу со временем, почему это легаси? а вот наоборот легаси это некогда современный взгляд на через чур абстрауцию работы с данными. это легаси.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #196

141. Сообщение от Аноним (141), 28-Авг-20, 15:44	+/–
>Собственно, хороший специалист в С++ с набитой рукой будет пользоваться смартпоинтерами практически безошибочно если вообще будет ими пользоваться, а не указатели гонять как все настоящие программисты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #103 Ответы: #144

142. Сообщение от Аноним (142), 28-Авг-20, 16:11	–1 +/–
А мне лень открывать рот и жевать. Я хочу чтобы пища сама попадала в желудок. Мне лень срать хочу чтобы пища сама выводилась из кишечника.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139 Ответы: #182

143. Сообщение от Аноним (143), 28-Авг-20, 16:32	+/–
В сишке это обернуто в структуру.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

144. Сообщение от Аноним (143), 28-Авг-20, 16:33	+/–
Оверхед от того же unique_ptr нулевой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #141 Ответы: #149

145. Сообщение от Кайф (?), 28-Авг-20, 17:21	+3 +/–
смузихлебы ликуют! Теперь они смогут в системное программирование, по крайне мере они так думают... Но POSIX и WinAPI смотрят на них как на говно
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #146

146. Сообщение от Аноним (141), 28-Авг-20, 17:43	–6 +/–
Вот интересно, почему странные личности с интеллектом школьников ненавидят Rust?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #145 Ответы: #147, #148

147. Сообщение от Аноним (70), 28-Авг-20, 17:48	+/–
Да пускай. Собака лает - караван идет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

148. Сообщение от Кайф (?), 28-Авг-20, 17:57	–1 +/–
Сишный API ядра передаёт пламенный привет всем смузихлебам
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #146

149. Сообщение от Аноним (103), 28-Авг-20, 18:07	+/–
Это не отменяет того, что безопасная работа с кучей в С++ реализуется, по факту, через паттерн. Плюс еще неудобная возня с циклическими ссылками в shared_ptr, которые можно разбить только через weak_ptr. В С++ на уровень "человеческого фактора" выводится очень многое и без статических анализаторов в проектах, где больше сотни классов, просто не уследить за всем. У Rust не очень удобный синтаксис, но в целом идея вынести RAII на уровень синтаксиса и семантики позволяет исключить утечки памяти по невнимательности, при этом не пользуясь сборщиком мусора. Если в Rust программе память и утечет, то это будет осознанная диверсия, когда сотрудник с доступом к мастеру для кучи короткоживущих, но относительно "жирных" объектов выставит lifespan, равный времени жизни долгоживущего объекта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #144 Ответы: #153, #167

150. Сообщение от анинимус (?), 28-Авг-20, 19:21	+1 +/–
>Зачем вы стреляете себе в ногу? Мазохисты? Хуже, это sjw, которые в большинстве своем кодить не умеют.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

151. Сообщение от Аноним (151), 28-Авг-20, 19:23	–1 +/–
Почему D не упомянули, непорядок
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #226

152. Сообщение от Ололо (?), 28-Авг-20, 19:35	+/–
> while(isspace(*p) && *p != '\0') > while(isdigit(*p) && *p != '\0') На этом мог бы и закончить очередной сеанс самолюбования. Уже из этих двух строчек твой уровень в программировании (не только в C) вполне ясен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #179

153. Сообщение от Аноним (153), 28-Авг-20, 20:04	+/–
>В С++ на уровень "человеческого фактора" выводится очень многое Да, к сожалению. Но программист должен быть программистом, а не макакой, полагающимся на компилятор и магию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #170

154. Сообщение от microsoft (?), 28-Авг-20, 20:06	+/–
И при этом софт был стабильнее и шелковистее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #122

155. Сообщение от microsoft (?), 28-Авг-20, 20:09	–1 +/–
Дурачек, Линуса уже не спрашивали че он тпм хочет, просто взяли и запилили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42

156. Сообщение от anonymous yet another (?), 28-Авг-20, 20:17	–2 +/–
Очень живой и динамичный язык. Только за этот год вышло, кажется, больше версий "языка программирования Rust" чем ISO-IEC-14882-xxxx за всё время (лет за 25, кажется). Опять же встроенный подтягиватель updates, packages и всего остального, о чём вы не знаете, но ... --- да и не надо забивать себе этим голову.
Ответить | Правка | Наверх | Cообщить модератору

157. Сообщение от Аноним (157), 28-Авг-20, 20:37	+/–
Плохо ты знаешь нейросети. На выходе тебя ждёт "да нет наверное". И этот ответ сравнивая с константой выбранной программистом трактуется как 0 или 1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115 Ответы: #241

159. Сообщение от Аноним (39), 28-Авг-20, 20:48	+/–
Да, да, спасибо. Одна строка, три инта разделённых пробелами, завершается новой строкой. Эта штука вызывается для каждого процесса (которых спавнится тысячи подряд) и инлайнится, и уж точно я хочу избежать isdigits и isspace, как и scanf (довольно вредная дрянь, 99% времени я провишу в ней). А можно же изменять инты, выделенные кем-то другим? Это именно то, что я пытаюсь сделать. Как я ни пробовал выделять инты на хипе (malloc и передать 3 указатель на 3 указателя на инты емнип), компилятор был недоволен (хотя и работало). Добавил assert(vari!=2) на всякий случай (код ожидаемо ломается, когда в конце нет новой строки, такого быть не может потому что малформед строки не случится никогда) -- теперь мы защищены от всего, а то вдруг не сможем последний байт прочитать. :3 Кстати, ошибка была вот тут else {fbuf[256-1]='\0'; fbuf[rlen-1]='\0';} я не знаю зачем я поменял rlen на rlen-1 и всё сломал. :/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #132 Ответы: #177

160. Сообщение от Аноним (39), 28-Авг-20, 20:49	+/–
А вот это правильный ответ! В данном случае оверкил, мне кажется, но этот вариант намного лучше альтернатив.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #99

161. Сообщение от Аноним (39), 28-Авг-20, 20:50	+/–
>>++= > руки бы тебе оторвать за такое Себе лучше оторви что-нибудь. Небось и от готу бегаешь, как от огня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #128

162. Сообщение от alex312 (?), 28-Авг-20, 21:02	+/–
В телеге есть группа по эмбедед расту - https://t.me/embedded_rs Поспрашивай там.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

163. Сообщение от Аноним (39), 28-Авг-20, 21:06	+/–
Суффикс p использован для указателя, вполне читаемое, если видеть, что varbuf это максимум 1 инт в виде текста (до 10 байт по-моему), buf это весь текст прочитанный из файла, а var и vari это искомые значения в виде интов и текущий индекс в массиве. Мне так удобно. Я бы мне смог воспринимать это в виде i j k l m.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #91

164. Сообщение от Аноним (39), 28-Авг-20, 21:09	+/–
Так прелесть си как раз в том, что от таких проверок можно отказаться, если они совершенно точно не нужны никогда. На постоянные проверки уходит не мало ресурсов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #81 Ответы: #187

165. Сообщение от Аноним (39), 28-Авг-20, 21:44	+/–
Там только на прошлой неделе исправили уб с флоатами, какие унсафе? Компцерт больше доверия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #172

166. Сообщение от Аноним (166), 28-Авг-20, 21:45	+/–
А на нем можно делать окна, кнопочки, черепашью графику?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #168

167. Сообщение от коржик (?), 28-Авг-20, 21:54	+/–
> Если в Rust программе память и утечет... Вообще, утёкшая память в расте не считается за неопределённое поведение. Течёт всё, даже сборщик мусора дотнета легко обмануть банально не отписавшсь от события
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #149 Ответы: #175

168. Сообщение от Аноним (168), 28-Авг-20, 22:21	+/–
https://www.areweguiyet.com/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #166

169. Сообщение от red75prim (?), 28-Авг-20, 22:25	+/–
Кому какое дело на чём программисты катаются и тешат своё ЧСВ.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

170. Сообщение от red75prim (?), 28-Авг-20, 22:29	+2 +/–
Монтажник должен быть монтажником, а не тупым жлобом, полагающимся на каску, страховку, изолированную проводку, строительные леса и прочие глупости.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #153

171. Сообщение от Забыл заполнить (?), 28-Авг-20, 22:36	+/–
Тогда на окамл.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #89 Ответы: #186

172. Сообщение от topin89 (ok), 28-Авг-20, 22:44	+/–
> Там только на прошлой неделе исправили уб с флоатами, какие унсафе? Компцерт > больше доверия. Ну да. Исправили (если речь идёт о сведении всех флоатов больше 255.0 к 255 u8, ну и к нулю для всех меньше нуля). И добавили явный unsafe для тех, кому скорость важнее. А В C/C++ оно как было undefined, так навеки и останется: https://wandbox.org/permlink/BT5leyjGx5TZhmFh Вопрос в приоритетах создателей, и у комитета C++ пока по ощущениям в приоритетах новые плюшки без потери обратной совместимости, в то время как у Раста в приоритете явное разделения безопасного и опасного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #165

173. Сообщение от topin89 (ok), 28-Авг-20, 22:51	+/–
>> Нет простой связи c C++ > С C достаточно простая. А с C++ мало у кого в целом > есть простая связь из-за шаблонов, классов и этого всего У Julia есть вроде. >> сделать замену старым либам > На Расте даже замену либы C видел) > Всё возможно, что совместимо с C Про C я молчу, там просто. >> нельзя распространять бинарные либы > Разве? У меня не было с этим проблем, включая на Андроиде (интеграция > либы на расте в плюсовый Qt-проект) > Можно примеры? Интересно чего стоит опасаться Опять же, про C я молчу, там чёрт знает когда ABI стабилизировался. А вот просто так, не через С связать бинарную библиотеку раста с другой библиотекой или экзешником нельзя, сколько я знаю. Только исходники. Да, я понимаю, кому нужны либы без исходников, но такие платные штуки есть для C/C++ и микроконтроллеров. Для раста так вроде нельзя: https://users.rust-lang.org/t/compiling-a-rust-library-as-a-... >> Компилятор пока не такой крутой, как для C. > LLVM и в Африке LLVM) > (да, я понимаю, что речь не о том, но всё же) Не бэкэндом единым жив компилятор. И для части чисто растовых оптмимизаций уже пилят mid-level IR: https://blog.rust-lang.org/2016/04/19/MIR.html
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53

174. Сообщение от topin89 (ok), 28-Авг-20, 22:55	+/–
> А в чем проблема сделать такой атрибут и положить во внешний крейт. > Кому надо, тот подключит. Зачем это тащить в язык? А что уже ввели саму возможность? Как именно сделать аналог этому: constexpr long double operator"" _deg ( long double deg ) {     return deg * 3.14159265358979323846264L / 180; } Если что, в плюсах этих _deg и _mm нет, да и литералы времени (1s, 1000ms, 1000000us) или преобразования C-строки в std::string ("пример"s) тоже в стандартной библиотеке, а не прям нативно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82

175. Сообщение от Аноним (103), 28-Авг-20, 22:59	–1 +/–
Ну что сборщику мусора легко устроить протечку в Java/C# - это и так очевидно, достаточно иметь долгоживущий объект-коллекцию, хранящую strong ссылки. В C++ легко устроить протечку, потому что в языке нужно 99% вещей делать руками, а там, где ручная работа - там ошибки от невнимательности/усталости/лености/недостатка скилла. Rust тоже может потечь при неаккуратной работе с циклическими ссылками в растовых смартпоинтерах, но большую часть времени можно обойтись обычными ссылками и явным связыванием лайфспанов. Да простят сравнение такое, но С++ это как обычный уровень, а Rust - как лазерный. Просто более навороченный инструмент, сглаживающий болезненные в повседневной разработке места другого, более раннего, инструмента. Думаю, никто не будет поливать помоями Javа-истов, что они без своей супервумной IntelliJ IDEA с автокомплитом на машинном обучении имена методов и классов помнят ну очень смутно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #167 Ответы: #234

176. Сообщение от СССР (?), 28-Авг-20, 23:54	+/–
хорошо сказал про то что с++ молчат, потому что знают что так не нужно делать )). Вот например топор, юнец колол дрова, обух отлител и прямо в ногу, юнца в больничку, выписали, ходит юнец и рассказывает что нужно заменить топор на бензопилу и приводит свой случай, взрослые мужики молчат, слушают и молчат ибо чо им сказать то еще не окрепшему разумом юнцу? про эллементарные правила колки дров? про то что в руках в общем то оружие которым можно и себя поколечить и соседа? А молчат еще и потому что этому юнцу и бензопилу в руки давать нельзя, максимум пластмассовый нож, и то, глаз себе может выколоть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #185

177. Сообщение от Ordu (ok), 29-Авг-20, 00:00	+/–
> Да, да, спасибо. Одна строка, три инта разделённых пробелами, завершается новой строкой. > Эта штука вызывается для каждого процесса (которых спавнится тысячи подряд) и > инлайнится, и уж точно я хочу избежать isdigits и isspace, Ты сначала напиши, померь скорость, а потом думай где тормозит. Если ctype.h будет слишком медленным, напишешь свои аналоги. Заинлайнишь. Будет тебе щщасте. > и scanf (довольно вредная дрянь, 99% времени я провишу в ней). > А можно же изменять инты, выделенные кем-то другим? Это именно то, > что я пытаюсь сделать. Как я ни пробовал выделять инты на > хипе (malloc и передать 3 указатель на 3 указателя на инты > емнип), компилятор был недоволен (хотя и работало). Эмм... Ты пытаешься избежать isdigits и isspace, но при этом думаешь о динамическом выделении памяти? Если тебе нужна скорость, кучу надо выкидывать в первую очередь. Но если тебе очень надо, то: int main() {     unsigned *arr = malloc(3 * sizeof(unsigned));     char* bufs[] = {         "1 2 3", "    12\t398746 \n 2397\n\n",         "12345", "1 2, -100"     };     for(size_t i = 0; i < sizeof(bufs)/sizeof(bufs[0]); i ++) {         int ret = get_vals(bufs[i], arr);         printf("ret: %d; vals: (%u, %u, %u)\n", ret, arr[0], arr[1], arr[2]);     }     return 0; } УМВР upd. Или тебе нужен массив указателей на инты? Ты в курсе что это _ещё_ хуже, с точки зрения производительности? Если да, то смотри: int get_vals(const char *buf, unsigned* var[3]) {      /// ...      *var[i] = чему-то-там      /// ... } int main () {     unsigned **arr = malloc(3 * sizeof(unsigned));     unsigned a, b, c;     arr[0] = &a;     arr[1] = &b;     arr[2] = &c;         /// ...                 printf("ret: %d; vals: (%u, %u, %u)\n", ret, *arr[0], *arr[1], *arr[2]); }
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #159 Ответы: #180, #181

178. Сообщение от СССР (?), 29-Авг-20, 00:02	+/–
пока студент то за 3-4 года приучиш себя пользоватся указателями как скальпилем для нерохирурга (с), как пулиметом для рэмбо (с++). да за месяц обучения программированию научится писать безопасный код скорее получится на php, js, но что может спроектировать такой скороучка? хеллоу ворд в браузире разве только что отобразить.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #101

179. Сообщение от Ordu (ok), 29-Авг-20, 00:02	+/–
>> while(isspace(*p) && *p != '\0') >> while(isdigit(*p) && *p != '\0') > На этом мог бы и закончить очередной сеанс самолюбования. > Уже из этих двух строчек твой уровень в программировании (не только в > C) вполне ясен. Ну да, ну да. Как же я мог...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #152

180. Сообщение от Ололо (?), 29-Авг-20, 00:51	+/–
> unsigned **arr = malloc(3 * sizeof(unsigned)); Ахаха, прекрати. С таким апломбом рассуждать об "убогих функциях библиотеки C" и второй раз садиться в лужу в простейшем коде (тут и в 132 -> 152) - это надо уметь. Не первый раз вижу, что за Rust топит индивид, попросту не умеющий программировать на Си. Да и умение программировать вообще здесь под вопросом. Может, тебе лучше вернуться к психологии?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #191

181. Сообщение от Аноним (39), 29-Авг-20, 00:54	+/–
>напишешь свои аналоги Их уже есть у меня, не в этом дело, мне вообще не нужны эти вычисления совершенно никак. Да, мне просто интересно с практической точки зрения. >    unsigned **arr = malloc(3 * sizeof(unsigned)); >    unsigned a, b, c; >    arr[0] = &a; >    arr[1] = &b; >    arr[2] = &c; Емнип вот это подвержено оптимизациям компилятора, я когда-то давно напоролся. А если я хочу вот это arr передать в другую единицу трансляции и модифицировать там? У меня получалось что-то вида **(**(**(* с указателями на инты, но я так подозреваю это тоже на милость компилятора, потому что он очень жаловался и не мог сказать на что и как его удовлетворить. Я так никогда не делал, и у меня совсем не получилось. :(
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #177 Ответы: #190

182. Сообщение от Андрей (??), 29-Авг-20, 01:50	+/–
- А вы, что, и есть, значит, за меня будете? - Ага!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #142

183. Сообщение от deeaitch (ok), 29-Авг-20, 03:40	+/–
> О, реальный опыт, это ценно! Можешь рассказать, в чём именно был ад, > что есть или чего нет в Расте и C/C++, что делает > его менее удобным в работе с 50+ файлами? Хорошо. Поделюсь. Не тролинга ради, и не ради поливания грязью. Только то через что прошёл сам. Прошу заметить, всё изложенное ниже моё исключительно субъективное мнение, никоим образом не претендующее на объективность. Коротко что это из себя представляет. Это большой комплекс диагностического оборудования и софта к нему. Облать аутомотив. Куча платформ и контроллеров. On board встроенных систем и т.д. управление из Linux, Windows, MacOs, iOS, Android. Основной код написан на C++, но да, такой код (писан до меня) показать человеку без опыта и он убежит от C++ далеко и надолго. Но не об этом. Жизненный цикл того оборудования подошёл к концу. Т.е. его будут менять (выбирается производитель сейчас). Встал вопрос о том чтобы перенести весь этот код на новое оборудование чему я воспротивился и повезло что начальство удалось убедить. Началась разработка всего с нуля. И вот тут на сцену выходит Rust. Не потому что я верю в его безопасность (более того я знаю что это нет) и превосходство. Я очень очень комфортно с C++. Rust я пробовал поковырять но это всё ниочём. Нельзя почувствовать язык без чего-то серьёзного. Поэтому и было принято решение. Параллельно с C++ вести разработку на Rust. Некоторые идеи из Rust мне понравились, поэтому а почему нет? И так. Начиная делать прототипы, проводить какие-то эксперименты с тем как представлять данные, передавать по сети, как описать порядка 500 параметров онита, однотипных, отличающихся всего-то смещением и размером (я не люблю парсинги, мне нравится мапить структуры на память, это быстрее с точки зрения ресурсов). Тут всё было хорошо, надо понимать что думать в рамках C++ для Rust не подходит. Не привычно, но ничего, так должно быть. Даже интересно смотреть на задачу с разных сторон. И так тут всё хорошо. Но и преимуществ перед C++ не видно. Порядка 50-ти прототипов. Прототипы не большие, по 5 - 10 файлов. Начинаем собирать всё это в месте. И вот начинается. Это нормальное явление рефакторинг в начале проекта. Переименовать что-то сразу во всём проекте (по контексту). И тут выяснятся что в случае с C++ это задача решается одним хоткеем. В случае с Rust я встречаю первую проблему. Нету IDE или чего-то что может это делать. Я пользовал kate для написания кода Rust. Синтаксис подствечивает и он уже не такой страшный как кажется в начале. Но понятное дело дальше оно ничего не умеет. Смотрим дальше, VSCode? Во первых это блевотня. Ну да ладно, поставлю. И так, оно тоже не может ничего кроме подсветки синтаксиса. Оказывается надо ставить плагины. Начинаем ставить, одно тянет другое, третье, десятое. Фух, поставилось. Ан нет. Конфликты, в форумах есть ответ. Я то почитал, можно решить. Но я понял что коллегам которые потом со мной будут работать я этого делать не буду. Я забуду. Не хочу. Выносите. Что там ещё? Ещё какой-то плагин к эклипсу. Спасибо, переодически падающий эклипс на плюсах, с отваливающейся индексацией и прочими граблями - нет, не надо. Ещё какие-то жавовские поделья в которых тоже только в виде плагинов. С неделю поковырялся и понял что ну просто нету ничего. Остановился на emacs, так как чуть с lisp знаком и при наличии времени и желания дописываю ту поддержку что есть сейчас. Но это медленно, времени не так много. Чуть допилил стало чуть проще. Но опять таки, это моя наколенная поделка. Вторая проблема - компиляция. Для C++ есть куча всего что поддерживает парсинг выхлопа компилятора. Т.е. у тебя ушибка в коде? перешел на неё, нажал Enter и оказался в строчке ошибки. В случае с Rust - нет. Надо смотреть самому в выхлоп и потом открывать этот файл в нужной строке, это время, это не удобно. Да в emacs потом допилилось. Но опятьтаки, надо допиливать. Сейчас ещё активная стадия не наступила, по этому я стараюсь держать код на Rust и на C++ в одинаково актуальном состоянии. Но по факту на C++ даже благодаря инструментам быстрее. Но бывает так что код на Rust отстаёт на неделю. Почему? тот-же рефакторинг. То что я сделал в C++ благодаря среде одним хоткеем в одно мгновение, в случае с Rust мне надо либо руками с грепом бегать, либо садиться допиливать emacs, или сидеть опять перебирать кучу недоделанных редакторов, форумов про поддержку раст в разных средах. На это просто нет времени если честно. Проект растёт. И он с нуля, и ещё не покрыл и 10% от того что должен. И проект не монолит, просто там много всего. Вот и получается, пока из чистого интереса я стараюсь держать этот проект на двух языках сразу. Кто победит покажет время. Как минимум я узнал много нового. Но пока увы, на практике, Rust пока проигрывает. Удовольствие от создания чего-то на языке получаешь не только от языка, но и от того что его окружает. В том числе среда которой пользуешься. Ну и да, по самому языку, честно вот функционала уровня шаблонов не хватает. Не надо тут кидать гнилыми помидорами. Я не предлагаю пихать шаблоны везде где не попадя. У них своё место. Во всём проекте что уже сделан у меня всего 3 шаблона. Но они так здорово экономят время, время на написание, время на отладку. Да и код меньше. Всего должно быть в меру. Где-то шаблоны это сила, где-то это будет фууууу. И конечно всё это должно будет потом общаться с пользователем. Т.е. должны будут быть пользовательские интерфейсы. Увы, у Rust Ui toolkit очень печален. Я сейчас активно пробую биндинг на Qt. Посмотрим что из этого выйдет буквально через 2 месяца. Я не говорю что я хорошо знаю Rust, более того я могу сказать что знаю его ну в лучшем случае средне. Часто приходится смотреть документацию. Кстати тоже момент, я не люблю лазить в браузер за документацией. Ну это не удобно и долго. Гораздо быстре нажать F1 и увидеть справку по команде, удобнее нажать ctrl+space и увидеть параметры с описанием. Но нет, у Rust с этим проблема пока. Не предлогайте мне только этот ужас VSCode, эклипсы, интелиж и прочие жавовские поделья. Два тулкита в Linux, это Qt и Gtk, весь остальной мусор можете оставить себе если вас устраивает. Поэтому пока emacs, но функционал оставляет желать лучшего. Словно на 20 лет назад отбросило по возможностям.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #96 Ответы: #195, #205

184. Сообщение от deeaitch (ok), 29-Авг-20, 03:47	+/–
> интересно послушать в чём заключается ад, можешь рассписать? Чуть выше написал, копипастить уже не буду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #104

185. Сообщение от qwerty (??), 29-Авг-20, 04:22	+3 +/–
Ты 100% прав. И вообще, настоящий мужик дерево свалить может и острым камнем, а топор для слабаков и баб.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #176 Ответы: #214

186. Сообщение от Аноним (192), 29-Авг-20, 06:26	+/–
Хоть брэйнфак лишь бы не раст?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #171

187. Сообщение от Lex (??), 29-Авг-20, 07:47	+/–
> Так прелесть си как раз в том, что от таких проверок можно > отказаться, если они совершенно точно не нужны никогда. На постоянные проверки > уходит не мало ресурсов. На самом деле, не так уж и много, поскольку тяжёлых вычислений и обращений к апи для этого не требуется. Просто в вебе может происходить что угодно( даже если на клиенте абсолютно уверен, что где-то какой-то ситуации уж точно быть не может, но данные добываются с бэка, проверку лучше сделать, ведь какая-нибудь бэкендомакака обязательно запилит свой крутой бэк так, что вместо оговорённого заранее массива в т.ч пустого иногда будет прилетать null, что приведёт к вылету даже при попытке просто узнать длину массива )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #164 Ответы: #204

188. Сообщение от asdasd (?), 29-Авг-20, 08:46	+1 +/–
Так, блин, и не используйте что вам не надо. Туда добавляют то что не хватало. В C++14 дали возможность в lambda'ы прокидывать значения, как в std::bind, make_unique и т.д. В C++17 fold expression что очень многие вещи упрощает, плюс теже constexpr if, плюс инициализация в if'е.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #192

189. Сообщение от asdasd (?), 29-Авг-20, 08:49	–1 +/–
Сами же себя и дискридитировали, не прочитав до конца и побежав строчить комент =) Фанат раста не умеет читать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #79 Ответы: #194

190. Сообщение от Ordu (ok), 29-Авг-20, 09:45	+/–
> Их уже есть у меня, не в этом дело, мне вообще не нужны эти вычисления совершенно никак. Какие вычисления тебе не нужны? Проверка на пробел не нужна? В твоём коде эта проверка тоже есть, почему ты оттуда её не выкинул, если она не нужна? > Емнип вот это подвержено оптимизациям компилятора, я когда-то давно напоролся. А какая тебе разница? Если компилятор может это оптимизировать, то значит ты пишешь слишком сложные вещи, и компилятор лучше знает. Если ты пишешь так, как надо, то компилятор не сможет это оптимизировать. Бывают исключения, когда оптимизации нарушают работу программы, но они редкость и вряд ли ты с ними столкнулся. > А если я хочу вот это arr передать в другую единицу трансляции и модифицировать там? Тогда компилятор не сможет оптимизировать. Он и в приведённом случае не сможет, на самом деле. Ты пытаешься решать несуществующие проблемы. Смотри, код работает? Но ты паришься об оптимизациях и о том, что в каком-то мифическом случае он не сработает. Или ты паришься о том, что в каком-то мифическом случае он начнёт тормозить. Так дела не делаются. Из мифического случая надо сделать реальный, который покажет как код не работает, тогда будет понятно с чем надо бороться. Надо померять производительность, отпрофайлить, и выяснить где и что тормозит. Может он у тебя на чтении с диска будет тормозить больше, чем ctype.h тормозит, а ты перед этим убьёшь несколько часов в то, чтобы сделать быстрее. И зачем это тебе?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #181

191. Сообщение от Ordu (ok), 29-Авг-20, 09:45	+/–
> Может, тебе лучше вернуться к психологии? Не, мне больше нравится накачивать твоё ЧСВ сверх меры.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #180

192. Сообщение от Аноним (192), 29-Авг-20, 11:53	+1 +/–
> Так, блин, и не используйте что вам не надо. Вот я и не использую С++
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #188

193. Сообщение от Аноним (193), 29-Авг-20, 13:04	+2 +/–
> можно найти какие-то задачи, где этого будет достаточно, но я чёт как-то затрудняюсь предположить. Текстурные координаты, нормали и прочие значения, практически никогда не выходящие за пределы диапазона [-1, +1]. На стороне CPU что-то с ними считать незачем, а в шейдерах они автоматически расширяются до f32/f64 при более эффективном использовании памяти и кэшей за счёт вдвое меньшего исходного размера. Игроделы ради этой эффективности иногда и не так изворачиваются (например, для единичных векторов типа нормалей даже f16 избыточен — можно весь вектор упихать в 32 бита с отклонением менее 0.1°, сравнение разных способов упаковки единичных векторов есть в статье на http://jcgt.org/published/0003/02/01/). :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

194. Сообщение от Nick (??), 29-Авг-20, 13:38	+/–
Пруфы будут или только общими фразами умеешь разбрасываться?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #189

195. Сообщение от Аноним (195), 29-Авг-20, 14:14	+/–
То есть это проблемы с инструментами и библиотеками - что ожидаемо, а не с самим языком. В Rust есть макросы - можно сгенерировать что угодно. Они чем то не подходят для замены шаблонов?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #203

196. Сообщение от Аноним (19), 29-Авг-20, 17:15	+/–
Настолько развивается, что до сих пор нет нормальной системы сборки без позорного синтаксиса и официального пакетного менеджера Даже модулей нигде нет и не будет ещё лет 10 C++ похож на бабулю, которая пытается одеваться в молодёжные шмотки, но в итоге косплеит колбасу Без обид, сам пишу на плюсах достаточный срок, и до сих пор на них остаюсь из-за Qt
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #140 Ответы: #215, #240

197. Сообщение от Аноним (197), 29-Авг-20, 17:29	+1 +/–
Можете, назвать меня неосилятором, но. Приходит директор и говорит. Вот тебе железка на rs485. Сделай утилиту для её конфигурации и настройки. Срок три дня. Беру я такой раст... И через два месяца меня увольняют. Берут парня, который на делфи зафигачил все за 4е часа. Все довольны. Ну кроме меня.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #209, #220

201. Сообщение от Аноним (201), 29-Авг-20, 19:26	+/–
На riscv и конкретно на gd32 все очень даже хорошо. Спасибо Disasm. А вот для mips'ов ты вряд ли найдешь что-то адекватное.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

202. Сообщение от Аноним (201), 29-Авг-20, 19:30	+/–
https://github.com/riscv-rust/gd32vf103xx-hal
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #97

203. Сообщение от deeaitch (ok), 29-Авг-20, 21:16	+/–
> То есть это проблемы с инструментами и библиотеками - что ожидаемо, а > не с самим языком. Да, я об этом и говорил, не с языком, с инструментами. То что я называю инфраструктурой. > В Rust есть макросы - можно сгенерировать что угодно. Они чем то > не подходят для замены шаблонов? Мне пока не удалось получить той-же гибкости что в C++, я не исключаю что я не до конца понял всё. На шаблоны в C++ у меня тоже ушло много времени чтобы научиться их правильно готовить. Несколько лет прежде чем пришло понимание. В Rust я зная что далеко не всё осилил. Но мне интересно, я в embedded с головой и руками, поэтому мне интересно. Если кому будет интересно продолжение, то я расскажу и об опыте связки Rust + Qt. Таки от интерфейса взаимодействия с пользователем не уйти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #195 Ответы: #206

204. Сообщение от Аноним (39), 29-Авг-20, 21:21	+/–
У веб-кодеров свои представления о "много", это да. Процессоры слишком быстрые стали. Вообще, правило номер один это не доверять клиенту. Немного иная специфика, и если ты экономишь ресурсы тебе разнесут сервер рано или поздно. А на клиента плевать, пусть обновит страницу на актуальную ревизию и всё ок, никакого смысла проверять невозможное на нём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #187 Ответы: #218

205. Сообщение от topin89 (ok), 29-Авг-20, 21:44	+/–
Вот! Вот хейт^Wфрустрация здорового человека! Спасибо! Итак, проблема инструментов серьёзная, в по-настоящему большом проекте скорость разработки резко падает. Как бы и не проблема языка самого по себе, но пользоваться им пока себе и работодателю дороже. Требуются большие компании, которые могут позволить себе всё это допилить, и для которых ключевые преимущества языка перевесят. Мелким пока рано. В ту же канву биндинги к популярным GUI-фреймворкам. Мало, недокументировано толком. Про язык были упомянуты нехватка шаблонов. В Rust есть дженерики и макросы, которые должны полностью покрывать область применения шаблонов. Тем интереснее узнать, что же шаблоны могут, что сочетание макросов с дженереками нет. Даже если это вопрос удобства. Особенно если это вопрос удобства. EDIT: уже прочёл ответ в другом комментарии. Принимается. > Не потому что я верю в его безопасность (более того я знаю что это нет) И это тоже интересно узнать. Это что-то в духе "В теории всё круто, но на практике полно unsafe-кода и ошибок в самом компиляторе"? Или "Да, можно и безопасно, но тогда производительность адски проседает"? Ещё раз спасибо! Наконец-то конструктивная критика вместо тупого "Rust говно, патамушта не C".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #183 Ответы: #216

206. Сообщение от topin89 (ok), 29-Авг-20, 21:48	+/–
> Если кому будет интересно продолжение, то я расскажу > и об опыте связки Rust + Qt. > Таки от интерфейса взаимодействия с пользователем не уйти. Определённо будет!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #203 Ответы: #217

209. Сообщение от Аноним (166), 29-Авг-20, 22:13	+/–
А если на Лазарус, то ещё и минус затраты/ворвство иде
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197

214. Сообщение от СССР (?), 30-Авг-20, 00:01	+/–
нет, про настоящих мужиков это уже юмор, сейчас то и нет таких, все вон полу-бабы, но это совсем другая истоия. Тут речь об идиотах и об отсутствия внимательности при написания кода. речь о вполне понятных проблемах инструумента которые могут привести к последствиям, но леквидировав эти проблемы - мы фактически уничтоаем сам инструмент. Вот взять острый нож, им можно порезаться, можно предложить пользоваться ножом для масла, да это решают проблему, ноги руки на месте, но о боже, им можно выколоть себе глаз! так же в ряде случаев масленного ножа хватит, но вот уже теряется универсальность, с этим ножом уже нельзя разделывать рыбу, мясо, даже хлеб начинает крошится. Т.е проблема не в языке, а в том что 1. есть руки кривоопые. 2. специализированные скриптовые языки необходимо воспринимать как узко-спецализированную. Взять к примеру QML, он как тот самый нож для масла, описывать гуи на js как объекты, параметр - значение и так далее - это прекрасно, удобно! т.е всему свое предназначение, но когда при сравнении инструментов С++/раст говорят что одним можно себе ногу отрезать (но умалчивают что другим можно себе глаз выколоть) - я вам так скажу, это не серьезно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #185

215. Сообщение от СССР (?), 30-Авг-20, 00:11	+/–
без официального пакетного менеджера - а что мешает либу так прикрутить? выбрал либу, скачал нужную версию. Вы хотите программу как сайт писать, в шапке указать 100500 ссылок на js и css ? Модули , хз в QT имеется. С++ на бабулю? )) только вот работает эта бауля как юнец - спортсмен, а тот же питон как дед пирдет. но это ладно. qt прикольная тема, если бы не она то да , кросплатверненные гуи наверное бы лучше было бы писать на электроне или флаттере. но это фрэйморк. Но если бы стояла бы задача написать бэк для хайлоад то я бы использовал си.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

216. Сообщение от deeaitch (ok), 30-Авг-20, 07:53	+1 +/–
> Итак, проблема инструментов серьёзная, в по-настоящему большом проекте скорость разработки > резко падает. Как бы и не проблема языка самого по себе, > но пользоваться им пока себе и работодателю дороже. Ну вот emacs я пилю для себя, но коллегам emacs далеко не всем зайдёт, будет время, пусть плагином но попробую к своей основной среде что-то сделать. > Требуются большие компании, которые могут позволить себе всё это допилить, и для > которых ключевые преимущества языка перевесят. Мелким пока рано. > В ту же канву биндинги к популярным GUI-фреймворкам. Мало, недокументировано толком. > Про язык были упомянуты нехватка шаблонов. В Rust есть дженерики и макросы, > которые должны полностью покрывать область применения шаблонов. Тем интереснее узнать, > что же шаблоны могут, что сочетание макросов с дженереками нет. Даже > если это вопрос удобства. Особенно если это вопрос удобства. Я не говорил что я знаю всё о раст, в C++ я как рыба в воде, в Rust всего-то год. Мне не удалось пока добиться функционала того что называется variadic templates. Не думаю что сюда уместно привести какой-то мой пример который я не могу покрыть. Я решил вопрос, но мне не показалось это так элегантно как на C++. Опять. Я далеко не эксперт в Rust. Может найду пример или что-то и смогу сделать так-же красиво и просто как в C++. Мне честно хотелось бы. >> Не потому что я верю в его безопасность (более того я знаю что это нет) > И это тоже интересно узнать. Это что-то в духе "В теории всё > круто, но на практике полно unsafe-кода и ошибок в самом компиляторе"? > Или "Да, можно и безопасно, но тогда производительность адски проседает"? Дело не в unsafe. Дело в том что в современном c++ уже нет тех проблем от которых якабы надо людей спасать. А то что у программистов голова не на месте ни один язык не спасёт. Если ты нагавнокодил ерунды, то уже не имеет разницы на каком языке. То что делает компилятор Rust, как раз пытается от гавнокода защитить, но не выйдет. Тут надо понимать, если дать обезьяне гранату..... Люди теряют бдительнось, думая что компилятор Rust их спатёт. На деле же я делал тесты, почти везде современных C++ и Rust имеют одни и те же проблемы. А именно гавнокодеры. Уже нет в современном C++ пробелм с памятью, нет проблем с выходами за границы и всего того от чего защищает Rust. При этом как уже писал, вся реклама вокруг вводит людей в заблуждение, они расслабляются, внимательность рассеивается, перестают думать, пологаются на компилятор. Это то что я видел на своих коллегах которые решили тоже поучаствовать в прототипах на Rust. > Ещё раз спасибо! Наконец-то конструктивная критика вместо тупого "Rust говно, патамушта > не C". Я бы вообще с удовольствием пообщался с кем-то кто в Rust ну лет так 5, кто хорошо знаком. Фик с ними с средами. У меня опыт в C\C++ у меня ничего не падает, меня не надо защищать от этого, у языка другой подход, я люблю другие подходы, я вообще люблю разные взгляды на одну и ту-же проблему.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #205

217. Сообщение от deeaitch (ok), 30-Авг-20, 07:54	+/–
> Определённо будет! Ок, но тогда видно это уже будет не комментарий к новости о новом Rust :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #206

218. Сообщение от Lex (??), 30-Авг-20, 09:20	+/–
> У веб-кодеров свои представления о "много", это да. Процессоры слишком быстрые стали. > Вообще, правило номер один это не доверять клиенту. Немного иная специфика, > и если ты экономишь ресурсы тебе разнесут сервер рано или поздно. > А на клиента плевать, пусть обновит страницу на актуальную ревизию и > всё ок, никакого смысла проверять невозможное на нём. Частоиспользуемые методы что на стороне браузера, что на стороне гибридных приложений, обычно JIT-ятся и проверка содержимого какой-либо переменной нередко состоит всего лишь из нескольких машинных инструкций. Но, кроме шуток, на каком-нибудь Си можно позволить себе наговнокодить несравненно больше, чем на JS, поскольку компилируемые ЯП прощают несравненно бОльшие огрехи в оптимизации. У бэкендеров - недоверие к фронтендерам( поскольку с клиента что угодно прилететь может ), у "фронтендеров" - к бэкендерам( поскольку с бэка черти что прилететь может, нередко вообще не соответствующее договоренностям о структуре ответов ). Поэтому в конторах, в которых ранее иногда работал, бэкендеров, которые нередко не способны были сделать корректное удаление данных( иначе, удаляется, к примеру, пользователь, а его предложения о товарах - выдаются как ни в чем не бывало, только user: null и любые попытки сделать заказ и проч вываливаются с ошибкой, но уже со стороны бэка ) или выдачу данных, согласно какой-то схеме, довольно часто под задницу выпинывали, поскольку предрелизное тестирования могло затянуться на недели из-за неведомых сбоев и ошибок, 95% которых приходилось на некорректную выдачу с сервера. Но, к сожалению, подобных бэкендеров на фрилансе больше половины. А потом - начал разрабатывать мобильные приложения, а привычки остались Все-таки, из-за криворуких бэкендописателей не должны страдать конечные пользователи, у которых приложение "валится", к примеру, при пустой коризне( ведь "гений" выдает в качестве списка товаров null вместо пустого массива ). Но, хотя бы какую-то минимальную проверку данных в плане соответствия структуре, особенно, тех, которые прилетают с АПИ, делать необходимо вне зависимости от ЯП и проч.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #204

220. Сообщение от Аноним (103), 30-Авг-20, 10:50	+/–
Ну и правильно уволили, не умеешь выбирать инструмент под задачу. Rust это жирный DLL/SO собрать с развесистой core логикой, а дельфях формочки нашлепать и через FFI вызывать процiдурки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #197 Ответы: #221

221. Сообщение от Аноним (221), 30-Авг-20, 12:47	+/–
А какой инструмент под задачу необходимо было выбрать? На производстве нужно: управление промышлееным оборудованием, работа с базой данных, формирование всяких протоколов и отчётов, следить за состоянием и работоспобоностью узлов и, естетсвенно, вменяемый, быстрый и отзывчивый пользовательский интерфейс. Смотрю вот в сторону реакта и Node.JS. Ещё бы во всё это дело внедрить Scrum. Мастера только хорошего надо найти, что бы минимум в два раза больше $ от разработчика получал. Желательно, что бы умел кататься на баланс борде.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #220 Ответы: #229

222. Сообщение от Аноним (-), 30-Авг-20, 20:03	+/–
Растаманы читайте Эриксона. Не гипнотезера. Джона. "Простота языка С позволяет делать приложения более эффективными и пред­ сказуемыми, но ошибки, допущенные во время написания кода, порой стано­ вятся причиной таких уязвимостей, как переполнение буфера и утечки памяти,поскольку не существует механизма, проверяющего, помещается ли содержимое переменной в выделенную для нее область памяти. Если программист захочет по­ местить десять байтов данных в буфер, под который выделено восемь байтов про­странства, ничто не помешает это сделать, хотя результатом, скорее всего, станет аварийное завершение программы. " Хакина. Искусство эксплойта. 2009 год.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #227, #242

224. Сообщение от burjui (ok), 31-Авг-20, 03:52	+/–
Может, не стоит судить о сообществе Rust по Опеннету? И, ради бога, завязывайте со сказками про мудрых плюсовиков, которые молча всё понимают и не стреляют себе в ноги. Таких единицы, а основная масса плюсового кода написана отвратительно и не падает от любого чиха потому, что разработчики компиляторов достаточно великодушны, чтобы предусматривать защиту от дурака. Вообще, весь ваш пассаж, по сути, высосан из пальца - сплошные обобщения и домыслы, никакой конкретики. Ну пожаловались, что растоманы плохо себя ведут, обижают седых мудрецов, у которых НИКАКИХ проблем с памятью. И как же без типичных острот про ржавчину.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68 Ответы: #228

225. Сообщение от burjui (ok), 31-Авг-20, 04:13	+1 +/–
Дженкем у вас не менее качественный, чем юмор. Я тут тоже нюхнул и шутку придумал: а давайте светофоры уберём, а то только трафик тормозят. Выбрал удобный момент - и перебежал, делов-то. Просто нужно быть внимательным и развивать реакцию.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #139

226. Сообщение от burjui (ok), 31-Авг-20, 04:14	+1 +/–
D
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #151

227. Сообщение от burjui (ok), 31-Авг-20, 04:29	+3 +/–
Сам себе противоречит. Более предсказуемые приложения, но с непредсказуемыми уязвимостями. Книга точно 2009, а не 1989 года? Не существует механизмов, конечно. А мужики-то не знали. Это же очень сложно - рядом с указателем на буфер положить размер этого буфера, назвать сию сложную структуру данных слайсом и работать с ней вместо голого указателя. Это ж лишние байты. Уж лучше предсказуемое поведение в виде мусора в памяти и, если повезёт, аварийного завершения программы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

228. Сообщение от deeaitch (ok), 31-Авг-20, 06:01	+/–
> Может, не стоит судить о сообществе Rust по Опеннету? Тут ты прав.  За то время которое я тут провел - ... > И, ради бога, > завязывайте со сказками про мудрых плюсовиков, которые молча всё понимают и > не стреляют себе в ноги. Таких единицы, а основная масса плюсового > кода написана отвратительно И тут прав. > и не падает от любого чиха потому, что > разработчики компиляторов достаточно великодушны, чтобы предусматривать защиту от дурака. > Вообще, весь ваш пассаж, по сути, высосан из пальца - сплошные > обобщения и домыслы, никакой конкретики. Ну пожаловались, что растоманы плохо себя > ведут, обижают седых мудрецов, у которых НИКАКИХ проблем с памятью. И > как же без типичных острот про ржавчину. А вот это уже эмоции.В прочем они у всех есть.  то буду пользовать дальше, просто птому что интересно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #224

229. Сообщение от Аноним (229), 31-Авг-20, 08:47	+/–
Командной строк достаточно. Мозг не выпаривайте. Не знание Линукса, не означает чтопод него нету хитрых инструментов.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #221 Ответы: #231

231. Сообщение от Аноним (141), 31-Авг-20, 13:23	+/–
>Берут парня, который на делфи зафигачил >Не знание Линукса, не означает Есть некоторая вероятность что в организации не линукс, а что-то другое
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #229

234. Сообщение от коржик (?), 31-Авг-20, 21:34	+/–
иногда лучше молчать
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #175

240. Сообщение от Аноним (240), 04-Сен-20, 17:09	+/–
>Даже модулей нигде нет и не будет ещё лет 10 В C++20 завезли.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #196

241. Сообщение от Аноним (240), 04-Сен-20, 17:13	+/–
Нечёткая логика тоже логика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #157 Ответы: #244

242. Сообщение от Ordu (ok), 04-Сен-20, 18:25	+/–
> "Простота языка С позволяет делать приложения более эффективными и пред­сказуемыми "Более" -- это по сравнению с чем?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #222

243. Сообщение от Онаним (?), 04-Сен-20, 20:33	+/–
> На выходе булева переменная - узнал/не_узнал (фейс Онанима). И значение этой переменной соответствует в лучшем случае шуму океанов Марса.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #115

244. Сообщение от Аноним (157), 05-Сен-20, 07:42	+/–
Женская логика это тоже логика, но сильно отличающаяся от строгой, булевой логики. Нейросети они такие же. Никогда не дают чёткого утверждения да или нет, поэтому логика построенная на них и называется нечёткой.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #241

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

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