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

innuendo
> не понял, шот ты имел ввиду?

Лёгкость разработки обеспечивается не только языком, но и фреймворками и инструментариями.

Panzerschrek[CN]
> Более того, ослаблена и проблема порчи стека.
Есть стек, но есть и куча. std::vector не избавлен от проблем по хипу. Я лично совсем недавно ловил такие траблы из-за того бардака что развёлся вокруг std::string.
Если кто не знал существуют следующие "стандартные" типы строк в STL:
std::string,
std::wstring
std::u16string
std::u32string
Так вот wstring в винде - это 16-битные чары, а в линупсе - 32-битные. Именно поэтому чтобы различать ввели u16/u32.
Ну и конечно я на это напоролся когда реализовывал сетевое взаимодействие между Window и Android.
Несмотря на то что как трушный сишник использовал std::wstring. Ну и получил heap corrupt как нефиг делать.
Благо быстро локализовал, т.к. побитые символы сразу бросались в глаза.

=A=L=X=
>Несмотря на то что как трушный сишник использовал std::wstring. Ну и получил heap corrupt как нефиг делать.
Ну так нефиг работать с сырыми указателями.

nes
> Ну так нефиг работать с сырыми указателями.

Данные по сети. Как мне еще с ними работать в С++?
В Java как раз всё заворачивается в получение массивов и всякие методы у строк типа fromArray( byte[], encoding ). Да. Как раз круто, что там сразу идёт анальное огораживание от возможности попортить хоть хип хоть стек. Именно это и сабж, а не подчистка мусора.

Да нет проблем у C++ с фичами, только синтаксис скатывается в полный треш, потому что трусы из комитета боятся добавлять новые ключевые слова.

=A=L=X=
>Данные по сети. Как мне еще с ними работать в С++?
Как с очередью байт, не?

Вий
Трусы из комитета боятся деприкейтить, в этом их проблема.

Panzerschrek[CN]
> плюсовик тупо заиспользует std::vector, и сделает ему resize.

ооооо... нету на тебя конзольных перцов

innuendo
А шо там на конзоли не завели вехтир?

nes
ты у них сам спроси

innuendo
Не имею знакомых.

nes
https://gamedev.ru/code/forum/?id=257154&page=2
вот тут один

Panzerschrek[CN]
> Отчасти это лечится написанием тестов и прогоном их под всякими детекторами
> (valgrind, например).

говоришь шо нету разницы между скоростю разработки между явой и сипипи ?

nes
> И как там у свифта дела с кроссплатформенностью?
Кроссплатформенно можно писать на плюсах, свифт не нужен. На обж-ц только обёртки. При чём в последнее время обёртки всё чаще вызов функций со стороны свифта осуществляют. Если ябл всё же решат сделать нормальный инструмент для создания мостика напрямую, минуя обж-ц - будет хорошо.

nes
> вроде без ауторелиз пула будет утечка памяти, не
Ты для проекта указываешь тип управления памятью. При чём этот переключатель зашит внутрь реализации указателей. В проектах с автоматическим управлением авторелиз писать вообще нельзя. Да и авторелиз - он уже сам по себе АВТОрелиз, так что даже в этом случае указатели автоматические. Просто это не те автоматические указатели, к которым все привыкли.

Panzerschrek[CN]
> Расскажи мне, как ты умудрился такое сделать
Специально даже репу завёл для демонстрации. Стек точно повреждается при использовании MSVC2017 и не повреждается при использовании clang или gcc. На остальных компиляторах не проверял. Если подскажешь санитайзер, который найдёт такое - буду только рад.

pahaa
> Стек точно повреждается при использовании MSVC2017
Похоже на ошибку компилятора. Да, такое бывает.

innuendo
> говоришь шо нету разницы между скоростю разработки между явой и сипипи ?
Нету. Там, где я обкладываюсь санитайзерами, Жабисты гоняют тесты.

=A=L=X=
> Является ли менеджмент памяти главной проблемой C?
Нет. Это не проблема, это решение.

=A=L=X=
> Является ли менеджмент памяти главной проблемой C++?
Да. Потому, что в C++, начиная с некоторых пор, все - проблема.

=A=L=X=
> На мой взгляд это [проблема] выход за пределы массива.
Это тоже удобное системное решение. Без него даже printf бы не работал.