ARM: C++ exceptions - C/C++

>>> E>>>А зачем?
>>> A>>В смысле, зачем? Ты считаешь, что RAII — ненужная, бесполезная вещь? Объясни.
>>> E>Зачем лишаться RAII если не использовать исключения?
>>>
>>> Захват ресурсов происходит в конструкторе (= resource aquisition is initialization). Без исключений ты не можешь проделать это в конструкторе по очевидным причинам.
>
> S>Да ну. Проверок просто вставлять придется кучу, и все.
>
> В конструкторе? А иначе это не RAII.

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

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, Awaken, Вы писали:

E>>Хуже с операторами. Прийдётся какие-то невалидные состояния объектов заводить. Ну либо подход, который нравится мне использовать

A>поделись секретом

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

Ну а если что-то поломалось, то либо по длинному goto уходим на откат запроса, либо сэвимся и перезапускаемся (если на платформе это просто и быстро)

E>Соответсвенно где-то на уровне запросов делается регистрилка всего критического (файлов, например), а запрос обрабатывается на отдельно аллокаторе. >Соответсвенно, если всё удачно, то результат спасаем, неосвобождённые ещё критические ресурсы освобождаем, а промежуточные данные грохаем (можно прямо >всем аллокатором)

фактически это типа thread-local аллокатор.

Здравствуйте, Erop, Вы писали:

E>Вкраце схема предполагает, что исключения происходят редко. Типа в ошибочных ситуациях. Например в конце памяти.
E>Соответсвенно где-то на уровне запросов делается регистрилка всего критического (файлов, например), а запрос обрабатывается на отдельно аллокаторе. Соответсвенно, если всё удачно, то результат спасаем, неосвобождённые ещё критические ресурсы освобождаем, а промежуточные данные грохаем (можно прямо всем аллокатором)

Дааа. На что только люди не идут, дабы только не использовать исключения

[и оставаться по инструментальным средствам на уровне 60-ых годов прошлого века

]

R>Дааа. На что только люди не идут, дабы только не использовать исключения

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

Здравствуйте, Awaken, Вы писали:

A>фактически это типа thread-local аллокатор.
Ну такой подход позволяет сделать и это. Но он позволяет больше!

Здравствуйте, remark, Вы писали:

R>Дааа. На что только люди не идут, дабы только не использовать исключения

R>[и оставаться по инструментальным средствам на уровне 60-ых годов прошлого века

]

Это всё нужно не для того, чтобы "не использовать исключения", а для того, чтобы использоватьбыстрые аллокаторы.

На самомо деле не всё так плохо. Смотри. Есть thread-local указатель на текущий контекст запроса, где можно регить и разрегивать критические ресурсы. Соответсвенно их захват и освобождение происходит вполне так себе в рамках RAII, только кроме захвата производится ещё и регистрация ресурса в запросе.

Соответсвенно, если ты всё пишешь "честно" и зовёшь все деструкторы, то никаких проблем. Вс работает "и так". Ну а если ты таки что-то как-то грохаешь "всем скопом", то у тебя в запроме остаются зарегистрированные данные для освобождения критических ресурсов.

Пример. Вот надо тебе подобрать слова в кроссворд. Для этого тебе надо как-то хитро проитерировать словари, понастроить кучу вариантов, сожрать три вагона памяти, почти не освобождая её по ходу пьесы, и т. д. При этом троятся какие-то хмурые иразвесистые списки и деревья.
Потом тебе надо это всё хозяйство разрушить, правильно решить все вопросы владаения и т. д. и т. п.

А моя альтернатива проще и быстрее.

Ты всё это строишь на отдельном аллокаторе (который, если память реально отдавать надо редко, может ещё и быть очень быстрым и thread-local к тому же), потом копируешь полученный в результате кроссворд на другой аллокатор, а потом всё это прекрасное хозяйство просто выбрасываешь, а память освобождаешь прямо всем аллокатором. Совсем не тратя время на разрушение списков и счётчики умных указателей.

Этакий "GC для бедных"
Но есть две засады.
Засада 1.
Захват памяти, аллокированной на временном аллокаторе, статическими или просто долгоживущими объектами. Для решения этой проблемы желательна поддержка со стороны библиотеки контейнеров. Например, удобно пользоваться контейнерами, которые помнят, на каком аллокаторе они были созданы, и пользуются только им.

Засада 2.
Захват объектами, созданными на временном аллокаторе, каких-то критических ресурсов (память вне временного аллокатора, открытые файлы, временные файлы, объекты GDI и т. д.)
Эта засада решается описанной мной выше схемой с регистрилками.

Ну а что касается "инструментальных средств 60-х годов прошлого века", то это ты наверное про С?

Здравствуйте, Awaken, Вы писали:

A>вот например такой случай: объект типа "композит", содержащий внутренние объекты.

А какие проблемы?

"Одинокий объект":

CFile myFile( getMyFileName() );
if( !myFile.IsOpened() )
    return ErrorStatus;

"Объект-композит":

class CMyFileWithLog {
public:
    CMyFileWithLog( std::string myFileName ) : file(myFileName ), logFile( myFileName + ".log" ) {}
    bool IsOpend() { return file.IsOpend() && logFile.IsOpend(); }
private:
    CFile file;
    CFile logFile;    
};
//-----------------------------
CMyFileWithLog myFile( getMyFileName() );
if( !myFile.IsOpened() )
    return ErrorStatus;

Здравствуйте, Awaken, Вы писали:

UN>>Использовать или не использовать — зависит от типа ARM. Я по жизни не люблю использовать исключения, по этому не стал бы их использовать в данном >случае.

A>нмв неиспользование исключений приводит к коду в стиле "Си с классами". фактически ты лишаешься RAII

RAII и исключения не зависят друг от друга.

Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, Erop, Вы писали:

E>>Здравствуйте, alexeiz, Вы писали:

E>>>>А зачем?
A>>>В смысле, зачем? Ты считаешь, что RAII — ненужная, бесполезная вещь? Объясни.
E>>Зачем лишаться RAII если не использовать исключения?

A>Захват ресурсов происходит в конструкторе (= resource aquisition is initialization). Без исключений ты не можешь проделать это в конструкторе по очевидным причинам.

Бред.

Здравствуйте, Erop, Вы писали:

E>Соответсвенно, если ты всё пишешь "честно" и зовёшь все деструкторы, то никаких проблем. Вс работает "и так". Ну а если ты таки что-то как-то грохаешь "всем скопом", то у тебя в запроме остаются зарегистрированные данные для освобождения критических ресурсов.

А зачем 2 механизма?
Каждый из них по отдельности может справляться.

Здравствуйте, Erop, Вы писали:

E>Здравствуйте, Awaken, Вы писали:

A>>вот например такой случай: объект типа "композит", содержащий внутренние объекты.

E>А какие проблемы?

E>"Одинокий объект":
E>

CFile myFile( getMyFileName() );
E>if( !myFile.IsOpened() )
E>    return ErrorStatus;

E>"Объект-композит":

class CMyFileWithLog {
E>public:
E>    CMyFileWithLog( std::string myFileName ) : file(myFileName ), logFile( myFileName + ".log" ) {}
E>    bool IsOpend() { return file.IsOpend() && logFile.IsOpend(); }
E>private:
E>    CFile file;
E>    CFile logFile;    
E>};
E>//-----------------------------
E>CMyFileWithLog myFile( getMyFileName() );
E>if( !myFile.IsOpened() )
E>    return ErrorStatus;

myFileName + ".log"

Здесь создается новая временная string. Допустим, не хватило памяти. Тогда что? Все равно файл попытается создаться. Да и вообще в copy-constructor'е myFileName уже может все свалиться. Тогда получится целая цепочка невалидных объектов. Соответственно возникает несколько проблем:

* Как мне узнать в конце концов первоначальную причину, по которой все свалилось, если невалидные объекты накапливаются как снежный ком?
* Перед каждой операцией с объектом нужно проверять его валидность. Вот мне в функцию пришел объект по константной ссылке, но я не могу быть уверен, что он валидный, потому что это мог быть времменный объект, который не смог создаться.
* Нет уверенности, что в какой-то точке программы все нужные объекты будут валидными.

Что-то мне это не нравится. Сдается, что здесь много подводных камней просто из-за того, что ожидаешь, что это будет работать как в RAII, и подловишься в один прекрасный момент на невалидном объекте.

Здравствуйте, Шахтер, Вы писали:

Ш>Здравствуйте, alexeiz, Вы писали:

A>>Здравствуйте, Erop, Вы писали:

E>>>Здравствуйте, alexeiz, Вы писали:

E>>>>>А зачем?
A>>>>В смысле, зачем? Ты считаешь, что RAII — ненужная, бесполезная вещь? Объясни.
E>>>Зачем лишаться RAII если не использовать исключения?

A>>Захват ресурсов происходит в конструкторе (= resource aquisition is initialization). Без исключений ты не можешь проделать это в конструкторе по очевидным причинам.

Ш>Бред.

Когда нечего сказать, начинаешь хамить?

Здравствуйте, alexeiz, Вы писали:

A>Здесь создается новая временная string. Допустим, не хватило памяти. Тогда что? Все равно файл попытается создаться. Да и вообще в copy-constructor'е myFileName уже может все свалиться. Тогда получится целая цепочка невалидных объектов. Соответственно возникает несколько проблем:

Вообще-то это проблемы не RAII, а операторов и обработки ошибок.
Можно сделать, например, так.
1) Аллокировать подушку.
2) В случае конца памяти взвести флаг, что типа память кончилась, а подушку освободить.
3) Завести регистрилку ошибок. Куда их добавлять по мере появления, а потом всем кагалом обрабатывать, если что.
4) Когда обрабатываем ошибки -- тупо смотрим была ли использована подушка. Если была, пробуем аллокировать её заново. Если не можем -- то авост.
Можно иметь ещё одну "запасную" подушку, чтобы суметь сохранить работу пользователя и перезапуститься.

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

A>* Как мне узнать в конце концов первоначальную причину, по которой все свалилось, если невалидные объекты накапливаются как снежный ком?
A>* Перед каждой операцией с объектом нужно проверять его валидность. Вот мне в функцию пришел объект по константной ссылке, но я не могу быть уверен, что он валидный, потому что это мог быть времменный объект, который не смог создаться.
A>* Нет уверенности, что в какой-то точке программы все нужные объекты будут валидными.

смотри выше.

A>Что-то мне это не нравится. Сдается, что здесь много подводных камней просто из-за того, что ожидаешь, что это будет работать как в RAII, и подловишься в один прекрасный момент на невалидном объекте.

Всё-таки главная фишка RAII -- это освобождение ресурсов в деструкторе. Она остаётся доступной.
Мало того, остаётся доступным и захват объектов в конструкторах, если программа написана так, что провал захвата -- это ошибка. То есть написать так:

bool access_file( std::string name ) 
{
    try {
        CFile file( name );
    } catch( ... ) {
        return false;
    }
    return true;
}

не получится.

А написать так:

CEssentialData ReadMyApplicationsEssentialData()
{
    CEssentialDataPodArchive tmp;
    CFile file( GetReadMyApplicationsEssentialDataFileName() );
    file.ReadRecord( tmp );
    return CEssentialData( tmp );
}

Вполне получится.

И даже так, тоже получится:

bool access_file( std::string name ) 
{
    CFile file;
    return file.Open( name );
}

Так что кое-каrие ограничения в RAII конечно будут, но говорить о безусловном отказе, ИМХО, слишком круто.

Здравствуйте, remark, Вы писали:

R>А зачем 2 механизма?
R>Каждый из них по отдельности может справляться.

Затем, что в одних алгоритмах уобен один, а в других другой. А если у тебя часть запросов одного типа алгоритмы использует, а часть другого?

Кроме того, если ты заметил, то всё это требует поддержки в библиотеке в основном, и в RAII объектах, захватывающих критические ресурсы.
Кроме того, это доп. гарантия от их утечки. Так как на уровне запроса всегда можно проверить не утекло ли чего, и даже освободить, записав предупреждение в лог, например...

Так что один и тот же код в результате может работать и на платфороме с исключениями и на платформе без исключений и с такой политикой аллокации и с другой...
Изменения надо вносить в довольно незначительном перечне мест...

Здравствуйте, Erop, Вы писали:

E>смотри выше.

Я таким, как выше, страдать не буду. Лучше отказаться от конструкторов как таковых (кроме инициализирующих объект по-умолчанию). По крайней мере я видел и знаю, что без конструкторов и с Initialize() методом, можно писать надежный код. Примеров кода в таком стиле, как ты рассказываешь, я не встречал. Поэтому он у меня вызывает большие сомнения. Необходимость таких эзотерических методов обработки ошибок рассеять сомнения никак не помогает. Покажи мне пример реального кода. Мне очень интересно посмотреть, как это работает.

A>>Что-то мне это не нравится. Сдается, что здесь много подводных камней просто из-за того, что ожидаешь, что это будет работать как в RAII, и подловишься в один прекрасный момент на невалидном объекте.

E>Всё-таки главная фишка RAII -- это освобождение ресурсов в деструкторе. Она остаётся доступной.

Освобождение в деструкторе — это не главная фишка RAII. Это вообще не фишка RAII. Этот принцип был в языке задолго до того, как появилась идея RAII. Главная фишка — захват в конструкторе и гарантия, что если это не получилось, то объект не создастся, и таким образом не будет невалидных объектов.

E>Мало того, остаётся доступным и захват объектов в конструкторах, если программа написана так, что провал захвата -- это ошибка. То есть написать так:
E>

E>bool access_file( std::string name ) 
E>{
E>    try {
E>        CFile file( name );
E>    } catch( ... ) {
E>        return false;
E>    }
E>    return true;
E>}

не получится.

E>А написать так:

E>CEssentialData ReadMyApplicationsEssentialData()
E>{
E>    CEssentialDataPodArchive tmp;
E>    CFile file( GetReadMyApplicationsEssentialDataFileName() );
E>    file.ReadRecord( tmp );
E>    return CEssentialData( tmp );
E>}

Вполне получится.

Как же! Если честно, игнорирование всех исключительных ситуаций в этом коде приводит меня в ужас. Если даже коды ошибок куда-то и складываются, почему ты думаешь, что можно спокойно продолжать дальше работать? Объект file может и не создасться, но ты все равно вызываешь у него ReadRecord(). Какой это имеет смысл, и к чему это может привести? (Ну, допустим, к чему это может привести, я догадываюсь)

E>И даже так, тоже получится:

E>bool access_file( std::string name ) 
E>{
E>    CFile file;
E>    return file.Open( name );
E>}

E>Так что кое-каrие ограничения в RAII конечно будут, но говорить о безусловном отказе, ИМХО, слишком круто.

Отказ от RAII — это невозможность иметь конструкторов, гарантированно создающих валидный объект. Как я сказал и раньше, ты такую ситуацию все еще называешь RAII. Я — нет.

Здравствуйте, Аноним, Вы писали:

А>Тема использовать или не использовать много раз обсуждалась,
А>но теперь столкнулся с ней напрямую, и не знаю что делать.

А>Есть ARM и 64 Мб, надо выбрать использовать или не использовать
А>исключения, до написания основного кода,

А>какие бы вы выбрали тесты для этого будь у вас железка и кроскомпилятор
А>gcc 4.x для этого?

Провел первое тестирование, результаты не в пользу использования исключений:

без искльчений:

#include <cstdlib>
#include <cstdio>
#include <stdexcept>

#define length(arr) (sizeof(arr) / sizeof(arr[0]))

static unsigned int sum = 0;

static bool parse(int a)
{
    if (a < 0)
        return false;
    sum += a;

    return true;
}

int main()
{
    int a[100000];

    for (int i = 0; i< length(a); ++i)
        a[i] = i;

    a[length(a) / 2] = -1;
    a[(length(a) / 4) * 3] = -1;
    a[(length(a) / 6) * 5] = -1;
    a[(length(a) / 50) * 40] = -1;
    a[(length(a) / 1000) * 500] = -1;
    fprintf(stderr, "Inited\n");
    for (int i = 0; i< length(a); ++i) {
        if (!parse(a[i]))
            printf("Invalid value, i = %d\n", i);
    }
    printf("sum is: %u\n", sum);
    return EXIT_SUCCESS;
}

с исключениями:

#include <cstdlib>
#include <cstdio>
#include <stdexcept>

#define length(arr) (sizeof(arr) / sizeof(arr[0]))

static unsigned int sum = 0;

static void parse(int a)
{
    if (a < 0)
        throw std::runtime_error("Invalid value");
    sum += a;
}

int main()
{
    int a[100000];

    for (int i = 0; i< length(a); ++i)
        a[i] = i;

    a[length(a) / 2] = -1;
    a[(length(a) / 4) * 3] = -1;
    a[(length(a) / 6) * 5] = -1;
    a[(length(a) / 50) * 40] = -1;
    a[(length(a) / 1000) * 500] = -1;

    for (int i = 0; i< length(a); ++i) {
        try {
            parse(a[i]);
        } catch (const std::exception& e) {
            printf("Catch excepion, i = %d: %s\n",
                   i, e.what());
        }
    }
    printf("sum is: %u\n", sum);
    return EXIT_SUCCESS;
}

$ time ./exception
Catch excepion, i = 50000: Invalid value
Catch excepion, i = 75000: Invalid value
Catch excepion, i = 80000: Invalid value
Catch excepion, i = 83330: Invalid value
sum is: 704694374
real 0m 0.03s
user 0m 0.02s
sys 0m 0.02s

$./return_value
Inited
Invalid value, i = 50000
Invalid value, i = 75000
Invalid value, i = 80000
Invalid value, i = 83330
sum is: 704694374
real 0m 0.02s
user 0m 0.02s
sys 0m 0.01s

и
$ls -lh exception return_value
-rwxr-xr-x 1 root root 85.7k Jan 1 00:18 exception
-rwxr-xr-x 1 root root 63.8k Jan 1 00:18 return_value

как видите на довольно большое количество килобайт больше.

выбран именно такой тест, потому что на арме будет крутиться
24/7 сервис, обрабатывающий результаты измерений,
при сбое он должен записать ошибку в лог и продолжить работу.

какие-нибудь предложение по изменению тестов?

Здравствуйте, Аноним, Вы писали:

А>какие-нибудь предложение по изменению тестов?
1) Всё-таки надо измерять время работы кода в случае, когда исключений не происходит. Так как исключения -- это тки сбой. Нештатная ситуация.
2) Про размер тоже неплохо бы понять. Это RT на 20 кило подрос, или это код такой пухлый выходит (я думаю, что RT)

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

Это ИМХО и если время позволяет, в смысле есть время перезапустить сервис. Правда можно иметь "сервис про запас" и перезапускать основной в как-нибудь в фоне.

Мало того, я бы ещё и по таймеру перезапускал тоже. Ну просто так, на всякий случай

Здравствуйте, alexeiz, Вы писали:

A>Здравствуйте, Шахтер, Вы писали:

Ш>>Здравствуйте, alexeiz, Вы писали:

A>>>Здравствуйте, Erop, Вы писали:

E>>>>Здравствуйте, alexeiz, Вы писали:

E>>>>>>А зачем?
A>>>>>В смысле, зачем? Ты считаешь, что RAII — ненужная, бесполезная вещь? Объясни.
E>>>>Зачем лишаться RAII если не использовать исключения?

A>>>Захват ресурсов происходит в конструкторе (= resource aquisition is initialization). Без исключений ты не можешь проделать это в конструкторе по очевидным причинам.

Ш>>Бред.

A>Когда нечего сказать, начинаешь хамить?

Бред он и есть бред.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Тема использовать или не использовать много раз обсуждалась,
А>>но теперь столкнулся с ней напрямую, и не знаю что делать.

А>>Есть ARM и 64 Мб, надо выбрать использовать или не использовать
А>>исключения, до написания основного кода,

А>>какие бы вы выбрали тесты для этого будь у вас железка и кроскомпилятор
А>>gcc 4.x для этого?

А>Провел первое тестирование, результаты не в пользу использования исключений:

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

А>с исключениями:

А>

А>#include <cstdlib>
А>#include <cstdio>
А>#include <stdexcept>

А>#define length(arr) (sizeof(arr) / sizeof(arr[0]))

А>static unsigned int sum = 0;

А>static void parse(int a)
А>{
А>    if (a < 0)
А>        throw std::runtime_error("Invalid value");
А>    sum += a;
А>}

А>int main()
А>{
А>    int a[100000];

А>    for (int i = 0; i< length(a); ++i)
А>        a[i] = i;

А>    a[length(a) / 2] = -1;
А>    a[(length(a) / 4) * 3] = -1;
А>    a[(length(a) / 6) * 5] = -1;
А>    a[(length(a) / 50) * 40] = -1;
А>    a[(length(a) / 1000) * 500] = -1;
А>
А>
А>  int i;
А>
А>try 
А>   {
А>    for (i = 0; i< length(a); ++i) 
А>       {
А>        parse(a[i]);
А>       } 
А>   } 
А>catch (const std::exception& e) 
А>  {
А>   printf("Catch excepion, i = %d: %s\n",
А>                   i, e.what());
А>   return EXIT_FAILURE; 
А>  }
А>
А>  printf("sum is: %u\n", sum);
А>  return EXIT_SUCCESS;
А>}

А>

	От:	Sergey
	Дата:	29.08.07 10:38
	Оценка:

	От:	Erop
	Дата:	29.08.07 16:33
	Оценка:

	От:	Awaken
	Дата:	29.08.07 17:21
	Оценка:

От:	remark	http://www.1024cores.net/
Дата:	29.08.07 17:24
Оценка:

	От:	Awaken
	Дата:	29.08.07 17:26
	Оценка:

	От:	alexeiz
	Дата:	30.08.07 05:26
	Оценка:

	От:	alexeiz
	Дата:	30.08.07 05:27
	Оценка:

	От:	alexeiz
	Дата:	30.08.07 07:27
	Оценка:

	От:	Аноним
	Дата:	30.08.07 13:41
	Оценка: