Войти
ФлеймФорумПрограммирование

Является ли управление памятью главной проблемой C/C++? (3 стр)

Страницы: 1 2 3 4 5149 Следующая »
#30
12:03, 1 фев. 2021

Panzerschrek[CN]
> Похоже на ошибку компилятора.
Нет. Это не ошибка компилятора. Это (совершенно внезапно) ожидаемое поведение. Компилятор делает всё в соответствии со спецификацией микрософта. Просто спецификация микрософта считает, что конкретно вот в этом случае нужно отойти от стандарта и повредить стек.


#31
12:21, 1 фев. 2021

pahaa

А что тут MS считает что надо делать не как все остальные?

#32
12:36, 1 фев. 2021

=A=L=X=
> На мой взгляд это выход за пределы массива. Это грёбанный heap/stack
> corruption.
> Вот это - бич и бич осязаемый от которого очень трудно избавиться - потому что
> он непредсказуем, трудно определяется где происходит
А что мешает делать вот так:

typedef struct int_array             
{                                    
    int    *body;                    
    size_t  count;                   
} int_array_t;                       
                                     
                                     
void array_print(int_array_t array)  
{                                    
    size_t u;                        
    for (u = 0; u < array.count; ++u)
    {                                
        ...                          
    }                                
}                                    

И прогонять тесты с -fsanitize=address,undefined ?

#33
12:38, 1 фев. 2021

=A=L=X=
> Так вот wstring в винде - это 16-битные чары, а в линупсе - 32-битные. Именно
> поэтому чтобы различать ввели u16/u32.
> Ну и конечно я на это напоролся когда реализовывал сетевое взаимодействие между
> Window и Android.
> Несмотря на то что как трушный сишник использовал std::wstring. Ну и получил
> heap corrupt как нефиг делать.
> Благо быстро локализовал, т.к. побитые символы сразу бросались в глаза.

Это не у std::string проблемы, это на уровне проектирования просчёт.  Есть понятие транспортной кодировки, которая должна быть всегда и везде utf8 и приниматься/передаваться, соответственно, только как std::string. То что там из Андроида торчит наружу utf16, - это тоже просчёт.

=A=L=X=
> std::wstring
> std::u16string
> std::u32string

Выпилить их нужно из стандарта, напрочь

#34
12:46, 1 фев. 2021

=A=L=X=
В дельфи не было проблем, т.к. автоматически убиваемые типы там есть. Например строки. Как легко работать со строками в дельфи и какая боль с этим в Си. А все потому что, в том числе, не надо в явном виде ничего удалять и выделять.
Ну и соответственно идея автоматического управления памяти в том чтоб так легко было работать не только со строками. Ведь также можно работать и с массивами (складывать, фильтровать, хранить отфильтрованные слайсы в других объектах, ну и так далее), хешмапами, пользовательскими структурами данных. Вот мы и пришли к автоматическому управлению памятью. В дельфи оно ограничено определенными структурами (строками, динмассивами, интерфейсами), в С++ - также можно работать и с пользовательскими структурами данных.
Так что гц может и нет, но автоматическое управление нужно.
А дальше оказываются нужны слабые ссылки (потому что мы начали легко и просто работать с любыми структурами, а в этих структурах есть куча ссылок на owner\parent\enemy_target, т.е. вверх и вбок по иерархии). И эти ссылки должны гарантированно не протухать при удалении. Ну и на этом этапе видимо бизнес решает что гц сделать проще и надежнее, как еще объяснить что практически все современные языки с гц вместо автоподсчета ссылок.

#35
12:47, 1 фев. 2021

Panzerschrek[CN]
> Там, где я обкладываюсь санитайзерами, Жабисты гоняют тесты.

жабисты не гоняют тесты для поиска мемори корапшен, их там нету никак
жабисты гоняют тесты для другого

#36
12:48, 1 фев. 2021

pahaa
> Нет. Это не ошибка компилятора. Это (совершенно внезапно) ожидаемое поведение.
Я ничего не понял. Поясни поподробнее, что там проихсодит, что ожидается и где компилятор лажает.

0iStalker
> > std::wstring
> > std::u16string
> > std::u32string
>
> Выпилить их нужно из стандарта, напрочь
wstring - точно выпилить. Как и недоразумение wchar_t. А вот чисто u16/u32 для каких-то целей можно оставить.

#37
12:50, 1 фев. 2021

exchg
> А что мешает делать вот так
останется еще выпилить memcpy, memset, и прочие функции работающие с указателями из стандартной библиотеки. Ну и из всех внешних библиотек тоже.
А тесты вполне могут иметь не 100%-е покрытие, так что это не спасет от редких граничных случаев которыми обязательно воспользуется хакер.

#38
(Правка: 13:07) 13:04, 1 фев. 2021

kipar
> останется еще выпилить memcpy, memset, и прочие функции работающие с
> указателями из стандартной библиотеки. Ну и из всех внешних библиотек тоже.
Удивительно, проблемой языка частью идеологию которого является расширение через библиотеки, являются библиотеки. Может в таком случае это проблема библиотек, а не языка?

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

> А тесты вполне могут иметь не 100%-е покрытие, так что это не спасет от редких
> граничных случаев которыми обязательно воспользуется хакер.
Могут и бывают, линкуй санитайзер в релиз. Используй gcov и длеай покрытие 100%. Пиши свою / бери чужую библиотеку с гард зонами. Тут нет универсального решения.

#39
13:06, 1 фев. 2021

0iStalker
>Есть понятие транспортной кодировки, которая должна быть всегда и везде utf8
Кому и зачем должна?

#40
13:08, 1 фев. 2021

Panzerschrek[CN]
>А вот чисто u16/u32 для каких-то целей можно оставить.
Нафиг не нужно, есть std::uint16_t, std::uint32_t, правда печально, что они не сильно std.

#41
13:09, 1 фев. 2021

exchg
> Могут и бывают, линкуй санитайзер в релиз. Пиши свою / бери чужую библиотеку с
> гард зонами. Тут нет универсального решения.
так в этом и проблема и об этом говорит ALX. Универсальное решение есть в других языках, а в Си его нет.

#42
13:12, 1 фев. 2021

kipar
> Как легко работать со строками в дельфи и какая боль с этим в Си.
Это - от ниосиляторства.
Конечно, если ставить вопрос о "строках вообще", на все случаи жизни, то, да в C все плохо. Но в каждом конкретном случае получается гораздо изящнее, чем с применением "тяжелой строковой артиллерии". Так, например, когда-то я для тренировки в Perl писал на нем интерпретатор Trac. Казалось бы, мощнейший аппарат регулярных выражений, заложенный в Perl, для задачи интерпретации строк - самое оно, но нет, оказалось все свелось к гораздо более простым операциям, но, зато, формат хранения строк перестал быть строковым.
Проблема только в том, что "современные программисты" не умеют вычислять символы (тяжелое наследие FORTRAN).

#43
(Правка: 13:20) 13:16, 1 фев. 2021

kipar
> Универсальное решение есть в других языках
И именно поэтому те языки не используют там где С/С++. А он говорит вот это:

=A=L=X=
> Только тем, что невозможно накосячить с heap corrupt и тебе в любом случае
> будет выкинуто исключение null pointer или index out of bounds и ты точно
> увидишь где проблема и в чём она сразу же по месту её возникновения. Только
> этим.

В Си/С++ это решается библиотеками. Т.е. тут его нету не столько потому, что его принципиально невозможно сделать, сколько тем что это не очень хорошее решение само по себе.

#44
13:22, 1 фев. 2021

nes
> Кому и зачем должна?

У нормальных разработчиков должна быть в архитектуре.

Страницы: 1 2 3 4 5149 Следующая »
ФлеймФорумПрограммирование