Ржавчина (Rust)

Действительно, зачем: https://anonfiles.com/r4jana25q5/rusttest_exe

 

А мне идея Раста нравится, когда изучал его.
Но минусы мало проектов, где он используется.
В целом если-бы была возможность, я-бы с удовольствием на нем что-то бы поделал...)))

 

очередной гламур.. те же плюсы не смогли реально вытеснить сишечку, пч в куче РЕАЛЬНЫХ ЗАДАЧ классы нафиг не нужны. а любая годная фича может быть внедрена в с/с++ на уровне либ и\ль компиля, что делает то же ржавое ведёрко а-ля пятое колесо к телеге.

 

Ну подожди, через лет 10 может вполне себе стать стандартом для нативной разработки. Ты забываешь, что у сишечки фора в 30 лет.

 

мда...

 

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

Вот примеры распространенных ошибок в Си:

1)Переполнение например интовой переменной - В итоге у вас неопределенное поведение, давайте отловите эту ошибку потом, особенно если куча кода, ога...)
В Расте компилятор сразу сам укажет на ошибку.)

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

Вот пример:

Код (Text):

1. uintptr_t test(void) {
2. int buffer[20];
3. return buffer;
4. }

Опачки, выделяем память на стеке и возвращаем адрес, вроде всё будет работать, до поры до времени, и потом не одна бабка неотдебажет...

И это только часть проблем в Си.

А в плюсах сколько шишек нужно набить, что-бы дейсствительно стабильные программы писать ?)

Поэтому по мне лучше-уж заморочится с Растом, да по началу необычно там всё, но потом писать стабильный код, без вот-этих приколов C/C++.)

 

Сравнения разных ЯП. В том числе и раста.
http://rosettacode.org/wiki/Sorting_algorithms/Quicksort#Rust
А теперь UASM.

Код (ASM):

1.  
2. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
3. ;;  Quick sort
4. ;;  http://rosettacode.org/wiki/Sorting_algorithms/
5. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
6. .386
7. .model flat, stdcall
8. option casemap:none
9. include msvcrt.inc
10. include macros.asm
11. .code
12. align_proc
13. quicksort proc uses esi edi ebx array:ptr sdword, len:dword
14.     ASSUME  ebx:ptr sdword
15.     .if (len > 1)
16.         mov     ebx, array
17.         mov     edx, len
18.         shr     edx, 1  ;=len / 2
19.         mov     ecx, [ebx][edx*4]   ;= pivot
20.         .for (edi=0, esi=len, esi--: : edi++, esi--)
21.             .while (sdword ptr [ebx][edi*4] < ecx)
22.                 inc     edi
23.             .endw
24.             .while (sdword ptr [ebx][esi*4] > ecx)
25.                 dec     esi
26.             .endw
27.             .break .if (edi >= esi)
28.             swap    [ebx][esi*4], [ebx][edi*4]
29.         .endfor
30.         quicksort(ebx, edi)
31.         mov     edx, len
32.         sub     edx, edi    ;len - i;
33.         quicksort(&[ebx][edi*4], edx)
34.     .endif
35.     ASSUME  ebx:nothing
36.     ret
37. quicksort endp
38. static_int      spisok, 4, 65, 2, -31, 0, 99, 2, 83, 782, 1
39. size_spisok     = 10
40. main proc C argc:sdword, argv:ptr ptr, envp:ptr
41.     printf("Quick sort.\n")
42.     .for (esi = 0: esi < size_spisok: esi++)
43.         printf("%d ", spisok[esi*4])
44.     .endfor
45.     printf("\n")
46.     quicksort(&spisok, size_spisok)
47.     .for (esi = 0: esi < size_spisok: esi++)
48.         printf("%d ", spisok[esi*4])
49.     .endfor
50.     printf("\n")
51.     xor     eax, eax
52.     ret
53. main endp
54. main_startup3_END
55.  

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

 

Но ведь это не в Си проблемы, это ты рукожоп

Целочисленные переменные увеличиваются так:

Код (Text):

1.  
2. if (value < maxValue)
3.     value += (maxValue - value < delta) ? maxValue - value : delta;
4.  

и никаких переполнений не возникнет. Никогда.

Ну а возвращать из функции стековые переменные - это вообще топчик.

 

Даже если и так. Не всем подходит жить в вечном унижении. Несите свой крест плюсов сами

 

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

 

Сишечка то тут причем? у нее с андефайнед поведением таких фокусов нет. В сишечке то как раз все прозрачно.

 

В сишечке есть undefined behavior, даже деление на ноль по-моему андефайнд в сишечке.

--- Сообщение объединено, 22 фев 2021 ---

https://ru.m.wikipedia.org/wiki/Неопределённое_поведение - даже вики со мной согласна.

 

X-Shar, по первой ошибке, это проблема самой формулы.
По второй, сам не давно сделал такую.
SendMessage(hIndicator, WM_SETTEXT, 0, (LPARAM)strIndic);
И строку strIndic выделил в стеке, т.е. локальная переменная. Оказывается ожидается глобальный параметр, хотя я думал функция объекта копируем себе в свойство, и глобальный параметр использовать не надо.

 

Ну а что нужно сделать, что-бы перестать быть рукожопом ?)

Вот у меня уже пять лет ежедневной практики кодинга Си, под практикой я понимаю изучение всяких стандартов, в том-числе Misra-C и прочее...

Ну вот не могу похвастаться мега-стабильным кодом на Си, вот что я делаю нетак ? Про С++, там вообще черт ногу сломит.)

Поэтому я и говорю, мне может даже проще изучить этот Раст, или функциональное программирования и писать действительно стабильный код...)

Будущее покажет, но мне кажется будущее за функциональным программированием, даже не за языками типа Раст.)))

 

Это неправда. Передавать можно любой буфер.

 

Не ожидается, т.к. SendMessage() возвращает управление только после обработки сообщения и передавать стековые буферы в нее можно (в отличие от PostMessage()). Другое дело, если контрол hIndicator сохраняет у себя lParam, не создавая копию... Но это уже рукожопы наговнокодили, системные контролы такого не делают.

--- Сообщение объединено, 22 фев 2021 ---

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

 

И сколько на это лет уйдет, 10-20-30 ?)

Кто будет столько ждать ? Стандарты для этого и написали крутые спецы, что-бы спецы в роде меня не касячили, правда я и со стандартами касячу, хе-хе...)

Тут ещё вопрос, в цене ошибки. Если ты пишешь пресловутое бизнес-приложение, ну упало там что-то разок, никто не умрет, даже не обанкротится...
А если из-за переполнения упадет самолет, или спутник, тут цена ошибки уже критична.)))

Поэтому в сфере ответственного применения, я больше как-раз за Раст, а ещё больше за функциональное программирование...

Почему за функциональное программирование ?

Каждую функцию можно покрыть тестами.)

В си также можно покрывать тестами, но не всегда это спасает.

 

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

 

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

 

Кстати в доке к Яве (J2EE) раньше даже писали что не предназначена для написания критически важных приложений типа ядерной энергетики и пр. RTOS .... попу изначально прикрывали