Аналог стандартной библиотеки C++ для работы без исключений

STLport кажись умел такое.

оставить только конструктор

А если конструктор обломается выделить память, то он должен просто грохнуться?

В таком режиме бОльшая часть стандартной библиотеки превращается в тыкву.

Да ладно. Если пользовательский код не кидает исключений, то там мало что их кидает (по соотношению «сущности, которые делают throw»/«количество всех сущностей»).

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

А если конструктор обломается выделить память

Конструктор ПО УМОЛЧАНИЮ. Который без аргументов, который не выделяет память и не резервирует её.

Есть https://github.com/msharov/ustl

И, насколько я помню, это не единственная такая попытка. Вроде бы были еще реализации STL для embedded-разработки. Только вот забыл, как конкретный проект на эту тему назывался.

который не выделяет память и не резервирует её

А на себя ему ничего не надо? К тому же, bool resize(...) это конечно здорово, а вот как быть с простым v[100500]=42, тоже bool возвращать?

мало что их кидает

Назови, пожалуйста, хоть один контейнер кроме array, который можно использовать в условиях, когда у тебя нет bad_alloc.

Ну так пиши просто на С.

Как ты будешь возвращать ошибки при конструировании элементов? Предположим у тебя есть вектор, ты делаешь ему assign, память выделилась без проблем, где-то в середине копирование элемента обломилось.
1) Как ты вообще поймёшь, что оно обломилось?
2) Как ты прокинешь эту информацию наружу?

Там много таких моментов вылезает. В конце концов тебе придётся создавать свою объектную систему с жёстко фиксированными интерфейсами и прочими радостями. Оно точно стоит того?

Конструктор ПО УМОЛЧАНИЮ
который не выделяет память и не резервирует её.

странное у вас понимание конструктора по-умолчанию. вероятно имеется ввиду placement new?

Какое отношение placement new имеет к конструкторам по умолчанию?

Есть https://github.com/msharov/ustl

Спасибо, я её смотрел. Но она не спроектирована для работы без исключений. Там точно так же кидается bad_alloc и прочие исключения.

Сами контейнеры никаких исключений не кидают. В том числе и bad_alloc, его кидает аллокатор.

Я бы писал на strict подмножестве C++ — «C с классами» либо на С.

Тут я руководствуюсь следующими соображениями: 1) копирование POD-типа не обламывается никогда 2) если это мой нетривиальный класс, то я не буду делать ему нетривиальные operator= и конструктор копирования/перемещения в ситуации, когда у меня нет исключений, потому что нет способа вернуть ошибку

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

Я бы писал на подмножестве C++ «C с классами»

Шаблоны-то чем не угодили? Одно из основных преимуществ С++ над С.

Сами контейнеры никаких исключений не кидают. В том числе и bad_alloc, его кидает аллокатор.

Но они ЖДУТ, что аллокатор либо даст им указатель, либо возбудит исключение. Поэтому не получится написать небросающий аллокатор и подсунуть его под контейнер.

Т.е. вектор будет только для подов и встроенных типов? Можно конечно, но смысла большого не имеет.

Например, возьмём vector и пофантазируем: у него можно оставить только конструктор по-умолчанию, move-конструктор, а операции типа resize() сделать не void и кидающими исключения, а bool и возвращающими false.

Заменить все экзепшны жирным интом с состоянием и опрашивать по маске... и получить Си только с плюсами в названии.

vector<int> t(50);
if(t.exception & exception::bad_alloc) {
  ...
}

Насколько я помню, в libstdc++ все «try» и «catch» заменены на макросы, которые в случае отключения исключений ничего не делают.

Шаблоны-то чем не угодили? Одно из основных преимуществ С++ над С.

я их тоже имел ввиду.

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

Почему? Хранить там можно будет что хочется, просто вместо раздолбайского «а, ща этот вектор этому присвоим не глядя» будет более ответственное:

vector v2;

if (!v2.resize(v1.size())) {
 // ошибка
}

auto elem = find_if_not(v1.begin(), v1.end(), v2.begin(), nonTrivialCopyOk);
if (elem != v1.end()) {
// копирование не выполнено, elem указывает на сбойнувший элемент
}

Т.е. в самом векторе ты продолжишь копирование даже если несколько элементов отвалились? Ну, можно наверное.

find_if_not останавливается сразу как только предикат станет false. Я либо успешно скопирую весь вектор, либо у меня будет частично заполненный вектор с хорошими копиями и указатель на элемент, который вызвал ошибку копирования. Ни о каком ихом продолжении работы речи не идёт, и копирование идёт вообще вне класса вектора, на моей стороне, где я контролирую процесс.

А что ты будешь делать с методом .at()? Вектор любит out_of_range кидать.

Моя твоя не понимай. Во-первых, у тебя какая-то своя особая версия find_if_not, неизвестная науке. Может, ты имеешь в виду copy_if? Но он не так работает. Короче, разверни мысль.

Буду работать в стиле C, через operator[], а at() выкину из класса. Невозможно, не имея исключений, воссоздать интерфейс стандартной библиотеки. Но можно сделать его очень похожим, что, на мой взгляд, будет плюсом.

Смотрим здесь. Раздел «Possible implementation». Там приведён код:

template<class InputIt, class UnaryPredicate>
InputIt find_if_not(InputIt first, InputIt last, UnaryPredicate q)
{
    for (; first != last; ++first) {
        if (!q(*first)) {
            return first;
        }
    }
    return last;
}

Как мы видим, алгоритм идёт строго от начала к концу, сразу останавливаясь по предикату. Важно отметить, что стандарт C++ в части алгоритмов ОБЯЗЫВАЕТ реализацию библиотеки вести себя так же, как эталонная. Опимизируй что хочешь как хочешь, но изволь всё же идти слева направо и останавливаться сразу.

Go on: detail the standard library support for -fno-exceptions.

In sum, valid C++ code with exception handling is transformed into a dialect without exception handling. In detailed steps: all use of the C++ keywords try, catch, and throw in the standard library have been permanently replaced with the pre-processor controlled equivalents spelled __try, __catch, and __throw_exception_again. They are defined as follows.

#if __cpp_exceptions
# define __try      try
# define __catch(X) catch(X)
# define __throw_exception_again throw
#else
# define __try      if (true)
# define __catch(X) if (false)
# define __throw_exception_again
#endif

In addition, for every object derived from class exception, there exists a corresponding function with C language linkage. An example:

#if __cpp_exceptions
  void __throw_bad_exception(void)
  { throw bad_exception(); }
#else
  void __throw_bad_exception(void)
  { abort(); }
#endif

The last language feature needing to be transformed by -fno-exceptions is treatment of exception specifications on member functions. Fortunately, the compiler deals with this by ignoring exception specifications and so no alternate source markup is needed.

By using this combination of language re-specification by the compiler, and the pre-processor tricks and the functional indirection layer for thrown exception objects by the library, libstdc++ files can be compiled with -fno-exceptions.

User code that uses C++ keywords like throw, try, and catch will produce errors even if the user code has included libstdc++ headers and is using constructs like basic_iostream. Even though the standard library has been transformed, user code may need modification. User code that attempts or expects to do error checking on standard library components compiled with exception handling disabled should be evaluated and potentially made conditional.

https://gcc.gnu.org/onlinedocs/libstdc /manual/using_exceptions.html

Что сказать-то хотел?

Что вот «решение» твоей задачи... при помощи пары костыликов.

operator[] вызывает at и потому выбрасывает тот же экзепшн.

Что libstdc++ и так спроектирована так, чтобы работать с -fno-exceptions.

Нет. Их потому и два метода, что один проверяет и кидается, а второй не проверяет ничего. Если operator[] кидает исключение, это значит, что реализация библиотеки не соответствует стандарту.

Оттуда следует, что при -fno-exceptions конструкции кода, которые отвечают за исключения, меняются на подпорки, чтобы этот код скомпилировался. Оттуда НЕ следует, что контейнеры и другие классы стандартной библиотеки в отсутствие исключений начинают вести себя по-другому, адаптируясь к ситуации. Там просто при возникновении исключения абортируется вся программа целиком. Как говорится, нет человека – нет проблемы.

Только эта функция принимает 3 аргумента, а у тебя 4.

Это я просто отвлёкся и ошибся в коде. Спасибо что заметил.

auto elem = find_if_not(v1.begin(), v1.end(), nonTrivialCopy(v2));
if (elem != v1.end()) {
// копирование не выполнено, elem указывает на сбойнувший элемент
}

А nonTrivialCopy – это соответственно функтор, который знает о v2 и копирует перебираемые элементы из v1.

Оттуда НЕ следует, что контейнеры и другие классы стандартной библиотеки в отсутствие исключений начинают вести себя по-другому, адаптируясь к ситуации.

Тебе нужны гарантии того, что стандартная библиотека при этом остается 100% рабочей или что? Вот в следующем абзаце про ограничения:

Some issues remain with this approach (see bugzilla entry 25191). Code paths are not equivalent, in particular catch blocks are not evaluated. Also problematic are throw expressions expecting a user-defined throw handler. Known problem areas in the standard library include using an instance of basic_istream with exceptions set to specific ios_base::iostate conditions, or cascading catch blocks that dispatch error handling or recovery efforts based on the type of exception object thrown.

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

Назови, пожалуйста, хоть один контейнер кроме array, который можно использовать в условиях, когда у тебя нет bad_alloc.

Любой контейнер. У тебя для этого есть 2 возможности: 1. Использовать свои аллокаторы; 2. Переопределить операторы new и delete: http://en.cppreference.com/w/cpp/memory/new/operator_new Делай их такими, чтоб они сообщали об ошибках как тебе нужно. Какие проблемы?

Даже вот ещё есть возможность использовать http://en.cppreference.com/w/cpp/memory/new/set_new_handler

Так что управление памятью - это вообще не проблема.

Расскажи, как будешь переопределять. На случай, если ты не совсем понимаешь о чём говоришь, поясню: вышележащий контейнер ждёт от тебя ТОЛЬКО валидный указатель на память, вернуть NULL ты не можешь, бросить исключение ты не можешь, убить всю программу целиком тоже не можешь. С set_new_handler то же самое. В случае отказа выделения памяти хэндлер может только либо кинуть исключение, либо убить программу целиком.

убить всю программу целиком тоже не можешь

Конечно не можешь, во всяких линуксах к тебе еще раньше придет белая лисичка дядя OOM Killer и прибьет ее сам.

К сожалению, «всякими линуксами» разработка ПО не ограничивается.

в условиях небольшого проектика, бед аллоками и нулевыми указателями от malloc можно принебречь на линкусах, тем более если за ранее известно сколько памяти будет потреблять софт, вообще дожить до момента когда линукс тебе вернет НУЛЛ в malloc, это мало вероятно, либо должен был зачетный говнокод что бы сожрать абсолютно всю память и своп

Нет, не только. Можно ещё долго работать, создавать всякие объектики, удалять их. В результате у тебя память будет «в дырочку», и тут ты просишь ну скажем мегабайт. А у тебя нет нигде непрерывного блока размером в мегабайт. И тут-то и malloc и operator new и скажут тебе: «Извиняй, хозяина, нету!». А так-то свободная память есть, чо.

вернуть NULL ты не можешь, бросить исключение ты не можешь, убить всю программу целиком тоже не можешь.

Убить программу целиком ты можешь всегда.

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

new_handler может поскрести по сусекам. И вот как раз с помошью этого и можно выкрутиться.

И вот как раз с помошью этого и можно выкрутиться.

Можно ПОПЫТАТЬСЯ выкрутиться. Может, найдёшь сколько нужно, а может нет. И вот эта ветка с обломом возвращает нас к исходному вопросу.