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

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

Страницы: 125 26 27 28149 Следующая »
#375
22:10, 11 фев. 2021

Delfigamer
> Да ладно уже, назовём вещи своими именами, ExceptT с дунотацией и Result с
> ?-оператором - это по сути checked exceptions и есть.

Нет. Принципиальная разница в том, что при `exception` происходит нарушение "control flow". Т.е. хз куда будет передано управление.

Delfigamer
> > Go/Rust style "panic"
> Мне кажется, OOM, SIGSEGV и Ctrl+C - это всё-таки отдельная категория фейлов

Использование зависит от конкретного случая. Когда мы делали конвертор файлов — `panic` бросался вообще на каждую ошибку, потому-что так проще. Когда делается автопилот — в нём совсем нет ни OOM, ни OutOfBounds, ни segmentation fault...

P.S. Сигналы — это вообще из другой оперы. Это когда нам "извне" говорят, что какая-то хрень происходит и не обязательно из-за ошибки.


#376
22:12, 11 фев. 2021

Вий
> решающих, как бы ещё навредить человечеству при помощи нового стандарта.
Нет. Просто, имея дело с мировым сообществом кодеров, неспособных ничего написать на C++, они придумали им занятие - изучать новые стандарты.

#377
22:25, 11 фев. 2021

Zegalur

Это не линейные типы — а простой enumeration. Можно поменять `datavtype` на `datatype` и ничего не поменяется. Проверку полноты pattern-matching умеют делать практически все современные языки.

#378
(Правка: 22:40) 22:39, 11 фев. 2021

nbkolchin
> Это не линейные типы
Это линейные типы.
> Можно поменять `datavtype` на `datatype` и ничего не поменяется.
Последний пример не даст ошибки компиляции.
Линейную переменную datavtype мы обязаны обработать, а datatype - не обязаны.
И дело не только в проверке полноты pattern-matching.

#379
(Правка: 0:36) 0:31, 12 фев. 2021

nbkolchin
> Нет. Принципиальная разница в том, что при `exception` происходит нарушение
> "control flow". Т.е. хз куда будет передано управление.
А если ты возвращаешь условный Err(NoParse), вообще-то, ты тоже не знаешь, куда потом вызыватель его передаст.
Так что нет, при одинаковой кривизне рук - разница исключительно косметическая. В Расте тоже можно поставить Box<dyn Error>, как и ExceptT SomeException в хаскеле, и все твои мечты про "кражу монитора инопланетянами мы обрабатываем немедленно и по месту" пойдут к инопланетянам на помойку.

nbkolchin
> Это не линейные типы — а простой enumeration. Можно поменять `datavtype` на
> `datatype` и ничего не поменяется. Проверку полноты pattern-matching умеют
> делать практически все современные языки.
Говоря образно, линейный тип - это когда у него нет автоматического деструктора, поэтому он не может теряться из области видимости в живом виде - можно либо передать его наружу, либо разложить ручками. Очень удобная штука, но её нигде нет, только по ночам снится. Жизнь - боль.

#380
(Правка: 8:13) 8:10, 12 фев. 2021

Кстати, вопрос к тем кто хорошо разобрался с try-with-resources в Java.
В офдоках и статьях на хабре не обозначен чётко один важный момент.
Предположим такой код:

try ( Some r = Some( ... ) )
{
    ...
}
catch ( Exception e )
{
    ...
}
Предположим, что код в try отработает без исключений, но при попытке автоматически сделать r.close() происходит исключение.
Приложенный catch будет его ловить или нет? По идее чтобы механизм работал слаженно согласно решаемой задаче он должен (и я пока считаю что это так и есть). Но чётко это нигде не проговаривается, поэтому имеется озабоченность... Есть опыт?

#381
8:47, 12 фев. 2021

Zegalur
> Последний пример не даст ошибки компиляции.

Принято. Я просмотрел последний пример.

Delfigamer
> В Расте тоже можно поставить Box<dyn Error>, как и ExceptT SomeException в
> хаскеле, и все твои мечты про "кражу монитора инопланетянами мы обрабатываем
> немедленно и по месту" пойдут к инопланетянам на помойку.

Ну это вырожденный вариант. Из серии, что на любом языке можно написать гавнокод.

#382
10:35, 12 фев. 2021

=A=L=X=
В доках написано что если исключение будет брошено и из основной части, и из закрывающего блока, то будет обработано только первое, а второе спрятано с возможностью получения (в отличие от try-finally где наоборот будет спрятано первое). По-моему не было бы смысла писать об этом если бы второе подавлялось всегда, даже если первого нет. Ну и в stackoverflow явно говориться что будет ловить и то и то.
https://stackoverflow.com/questions/15895227/try-with-resources-m… ds-exceptions
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryR… rceClose.html

#383
11:05, 12 фев. 2021

kipar
> По-моему не было бы смысла писать об этом если бы второе подавлялось всегда,
> даже если первого нет.

Это не вызывало вопросов - это написано явно.

> Ну и в stackoverflow явно говориться что будет ловить и то и то.

Это хорошо.

#384
11:10, 12 фев. 2021

gudleifr
> Ведь функционал конструкции понятен.
Кроме понятности есть и другие критерии, которые тебе, с твоим опытом, не понять.

Delfigamer
> Мне кажется, OOM, SIGSEGV и Ctrl+C - это всё-таки отдельная категория фейлов
Настолько отдельная, что на них можно забить и не городить под них костылей в самих языках программирования.

return [](){};
> assert в какую категорию?
В ктатегорию отладочных проверок, туда-же, куда всякие санитайзеры.

gudleifr
> Как всегда - в обфускацию.

+ Показать

entryway
> nodiscard появился полторы недели назад. раньше как код писал?
Это, кстати, действительно, большая проблема C++. Как язык более-менее пригодный к удобной и безопасной разработке он появился после стандарта 2011-го года, а совсем нормальным стал к 2017-му стандарту.

Zefick
> if (r) {}
На code review за такое поругают.
К тому же можно добавить предупреждение компилятора на бессмысленный if.

> int* res
Сишное говно же, надо возврат значения вместо него использовать.

Delfigamer
> кражу монитора инопланетянами
Это аппаратная проблема, которую программа решать не должна.

#385
(Правка: 11:15) 11:14, 12 фев. 2021

Panzerschrek[CN]
> Как язык более-менее пригодный к удобной и безопасной разработке он появился
> после стандарта 2011-го года, а совсем нормальным стал к 2017-му стандарту.
Да, напишите на нем хоть что-нибудь!

Panzerschrek[CN]
> Это аппаратная проблема
А фон Нейман-то, дурак...

#386
(Правка: 13:17) 13:12, 12 фев. 2021

Panzerschrek[CN]
> На code review за такое поругают.
  Это был quick-fix. Естественно в рабочем коде будет что-то другое. Может быть там даже будет обработка каких-то ошибок, но никто не гарантирует, что будут обрабатыаться именно те ошибки, которые могут произойти и в полном объёме, о чём были пункты 2 и 3 выше.

#387
14:57, 12 фев. 2021

Panzerschrek[CN]
Сишное. Оно отлично работает и не вызывает проблем с производительностью, в отличии от возврата по значению, который часто неожиданно для авторов кода тормозит

#388
14:58, 12 фев. 2021

Zefick
Так пиши switch и обрабатывай все кейсы без default. Не нравится эстетически - твоя проблема.

#389
15:24, 12 фев. 2021

Вий
> Сишное.
> Оно отлично работает
"Си" и "хорошо работать" - понятия несовместимые.

> не вызывает проблем с производительностью, в отличии от возврата по значению
С разморозкой. С введением семантики перемещения в C++ проблем с возвратом по-значению нету. Ну а в каком-нибудь Rust так вообще, перемещение происходит автоматически, а если оно не переместилось само, то потребуется ручной вызов метода clone.

Страницы: 125 26 27 28149 Следующая »
ФлеймФорумПрограммирование