1.1, Аноним (-), 09:42, 27/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –19 +/– |
Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
| |
|
2.2, Анончик (?), 10:07, 27/03/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
А у них есть выбор?
| |
|
3.3, Аноним (-), 10:12, 27/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Удивляет даже, что это вообще упоминается в чейнджлоге новости. Каждый раз переизобретают колёса: в glib разве уже нет специальных функций вроде g_slice_alloc0? А тут это преподносится как инновационное супердостижение.
| |
|
4.8, 1 (??), 11:08, 27/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
про "переносимость" не дочитал ?
Где-то есть glibc, а где-то и нет.
| |
|
5.10, S.Atahl (?), 11:20, 27/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Берешь любой опенсорц-проект на си, заглядываешь в исходники -- нет-нет, да и там найдется своя собственная версия super_calloc. Где ж ваша хваленая стандартизация? И эти люди что-то там говорят про left-pad.
| |
|
6.20, Аноним (-), 16:25, 27/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> И эти люди что-то там говорят про left-pad.
Как будто мы этот super_calloc при каждой компиляции с левого сервака качаем.
| |
|
5.32, PereresusNeVlezaetBuggy (ok), 14:49, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> про "переносимость" не дочитал ?
> Где-то есть glibc, а где-то и нет.
Эм. glibc и glib — как бы разные вещи. Впрочем, обе по-любому не подходят из-за их лицензий...
| |
|
|
|
2.4, A.Stahl (ok), 10:53, 27/03/2017 [^] [^^] [^^^] [ответить]
| +9 +/– |
Шёл уже пятый десяток лет безуспешных попыток создать язык лучше Си...
| |
|
3.6, S.Atahl (?), 10:58, 27/03/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
А правда, что у вас там нет исключений, и вам приходится как обезьянам проверять ошибки непосредственно после вызова какой-либо функции?
| |
|
4.7, A.Stahl (ok), 11:00, 27/03/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
Да я и в плюсах не использую исключения -- уж очень у них некрасивый синтаксис на мой вкус.
| |
|
5.11, S.Atahl (?), 11:26, 27/03/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Да я и в плюсах не использую исключения -- уж очень у
> них некрасивый синтаксис на мой вкус.
В нормальных языках:
try {
return unsafe_op1(unsafe_op2(unsafe_op3()));
} catch (e) {
return fallback();
}
В няшной сишке (в режиме "никакого некрасивого синтаксиса"):
int result3;
int error3 = unsafe_op3(&result3);
if (error3) {
return fallback();
}
int result2;
int error2 = unsafe_op2(result3, &result2);
if (error2) {
return fallback();
}
int result1;
int error1 = unsafe_op1(result2, &result1);
if (error1) {
return fallback();
}
return result1;
| |
|
6.14, Mihail Zenkov (ok), 14:05, 27/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Для C скорее будет:
int result;
result = unsafe_op3();
if (errno)
return fallback();
result = unsafe_op2(result);
if (errno)
return fallback();
result = unsafe_op1(result);
if (errno)
return fallback();
return result;
или
int result;
unsafe_op3(&result);
if (errno)
return fallback();
unsafe_op2(&result);
if (errno)
return fallback();
unsafe_op1(&result);
if (errno)
return fallback();
return result;
Обычно приходится видеть что-то типа:
try {
int* array= new int[1000];
}
catch (exception& e) {
cout << "Standard exception: " << e.what() << endl;
return(-1);
}
return 0;
int* array = malloc(1000 * sizeof(int));
if (!array) {
printf("malloc failed\n");
return(-1);
}
return 0;
| |
|
7.15, S.Atahl (?), 14:18, 27/03/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
А errno что, глобальная переменная? Прямо как в старом добром QBASIC.
| |
|
6.19, Аноним (-), 16:21, 27/03/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
Во-первых, ЧИТАБЕЛЬНЫЙ вариант на Си выглядит как описано ниже, а не как у вас с кучей лишних строк, фигурных скобок где только возможно и лишних переменных типа error1:
int r1, r2, r3;
if (!unsafe_op3(&r3))
goto fallback;
if (!unsafe_op2(&r2, r3))
goto fallback;
if (!unsafe_op1(&r1, r2))
goto fallback;
return r1;
fallback:
return fallback();
Во-вторых, сказки не надо рассказывать, какие хорошие эти исключения. В этих ваших C++/Java/Python всё построено на объектах, и во-первых у вас в коде появится вызов конструктора для ваших unsafe_ (а в особо клинических случаях ещё и деструктор ручками вызывать придётся в каких-нибудь finally, при этом следя, чтобы вызывать деструкторы только для переменных, которые были инициализированы успешно), во-вторых если вы получаете исключение, то перед вызовом fallback вам ещё нужно какие-то ресурсы освободить.
Из-за всех этих сложностей 99% ошибок обрабатываются методом "пробрасываем исключение до main(), а там выводим стектрейс в лог и завершаем программу". К чести исключений скажу, что 99% ошибок и невозможно обработать в коде, и вывести ошибку в лог и завершиться - единственный возможный вариант, и механизм исключений оптимизирован именно для этих случаев.
Но в половине, если не больше, реальных приложений, использующих исключения, происходит что-то типа
try
{
file_stream fs;
fs.open();
fs.write();
fs.read();
fs.write();
fs.read();
fs.close();
}
catch (e)
{
// что будет если fs не был закрыт? да не может такого быть, я же написал fs.close() выше
return fallback();
}
Не верите мне - почитайте Спольски.
| |
|
7.24, Аноним (-), 23:59, 27/03/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> перед вызовом fallback вам ещё нужно какие-то ресурсы освободить
В C++, при всех его недостатках, эта проблема легко решается деструкторами (RAII и всё такое), вызов которых только для инициализированных объектов в порядке, обратном порядку их создания, обеспечивается компилятором. И не надо никаких жабских try-with-resources, питоновских "with", шарповских "using" и прочих подобных костылей, призванных компенсировать неопределённость/непредсказуемость момента и порядка уничтожения объектов.
> что будет если fs не был закрыт?
Если автор класса "file_stream" не совсем дурак, то деструктор закроет "fs" ещё до начала выполнения блока "catch" из-за выхода объекта из его области видимости. К.О.
| |
|
8.25, Аноним (-), 01:39, 28/03/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Главное, не забыть в деструкторе проверить uncaught_exception на случай, если ... текст свёрнут, показать | |
|
|
|
|
4.21, Аноним (-), 16:39, 27/03/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
> вам приходится как обезьянам проверять ошибки
Проверка ошибок - это вообще обезьянья работа. Но хипстерам не понять, за них ошибки пользователи ищут.
А ещё мы как обезьяны их обрабатываем - и не всегда завершением работы с выводом в лог стектрейса.
| |
4.36, Michael Shigorin (ok), 15:52, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> А правда, что у вас там нет исключений, и вам приходится как
> обезьянам проверять ошибки непосредственно после вызова какой-либо функции?
Вообще-то как обезъянам приходится жить Вам и подобным -- вместо делания чего-нить полезного шариться по вражеским форумам и адвокатить в пользу некрософта, по наблюдениям за всем свежеляпнутым с этого адреса. Так шта не проецируйте, лучше человеком наконец становитесь.
| |
|
|
2.13, YetAnotherOnanym (ok), 13:21, 27/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Сишники до сих пор копаются в своих alloc/calloc/malloc
Видишь alloc/calloc/malloc в компиляторе/интерпретаторе/виртмашине своего любимого языка? - Нет... - А они там есть!
| |
2.35, Michael Shigorin (ok), 15:46, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Шел 2017 год. Сишники до сих пор копаются в своих alloc/calloc/malloc.
Хозяйке на заметку: с этого же адреса будто по методичке "критиковали" (бездарно притом) ODF и адвокасили MSO, ну и баловались вещанием как бы в несколько ников хором.
Призовая ссылка: http://wiki.opennet.ru/MSSP
| |
|
1.23, Ilya Indigo (ok), 20:50, 27/03/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней и не сообщает о свежих версиях?
| |
|
2.34, PereresusNeVlezaetBuggy (ok), 14:56, 30/03/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Интересно, почему DistroWatch заклинило на версии 2.4.5 и он её считает последней
> и не сообщает о свежих версиях?
Потому что ему никто не помог, очевидно.
DistroWatch вообще не слишком точная площадка, но многие пользуются за неимением лучшего...
| |
|
|