LINUX.ORG.RU

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

 , ,


0

3

Приветствую.

Понадобилось сделать небольшой проектик, в котором есть специфическое требование: сборка с флагами -fno-rtti, -fno-exceptions (gcc). В таком режиме бОльшая часть стандартной библиотеки превращается в тыкву. Вместе с тем, как мне кажется, если немного изменить интерфейс контейнеров, то их можно было бы использовать.

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

Не натыкался ли кто-нибудь на реализацию такой или похожей идеи? То есть: библиотеку контейнеров, которая по возможности копировала бы интерфейс стандартной, но при этом была пригодна для использования в режиме полного отсутствия механизма исключений.

★★

Ответ на: комментарий от uuwaan

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

ЗЫ а вообще это уже напоминает форменное дрочерство. Ибо в 99.99% программ std::bad_alloc приводит либо к завершению программы, либо к фатальной ошибке. И никто от этого не страдает.

asaw ★★★★★
()

компиль с флагами эксепшина и ртти, а дальше слинкуй статически с либой stdc++ и не парся

anonymous
()
Ответ на: комментарий от asaw

Ибо в 99.99% программ std::bad_alloc приводит либо к завершению программы, либо к фатальной ошибке. И никто от этого не страдает.

+100500 и более того до таких моментов редко доходит в любой из программы, а для говнокода и подавно такое сойдет

anonymous
()
Ответ на: комментарий от no-such-file

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

Разрешить только move-коструктор, остальные запретить. Инициализацию делать bool initialize(args...).

andreyu ★★★★★
()

а операции типа resize() сделать не void и кидающими исключения

Это вообще о чём? О выделении памяти? Потому что все остальные исключения и так опциональны.

Ну и ты готов (почти) везде обрабатывать нехватку памяти?

DarkEld3r ★★★★★
()

глянь http://ultimatepp.org/ у них есть альтернатива STL (правда незнаю что там с исключениями - просто лежит в закладках)

MKuznetsov ★★★★★
()
Ответ на: комментарий от DarkEld3r

О выделении памяти?

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

А в U++ вообще забили:

We decided to ignore possibility of «out-of-memory» exceptions and recovery. If U++ application goes out of memory, it simply prints the error message and terminates. Related issue - default and copy constructors are not allowed to throw exceptions in U++ (the common reason to throw exception here was out-of-memory condition).

uuwaan ★★
() автор топика
Ответ на: комментарий от uuwaan

И после каждого выделения отрабатываю нехватку, да.

Можешь описать логику подробнее? Просто любопытно где и для чего требуется что-то отличное от «попытаться освободить память или упасть».

DarkEld3r ★★★★★
()
Ответ на: комментарий от DarkEld3r

Есть система, скажем так, быстрого реагирования на определённые сигналы. Один поток постоянно слушает канал и пихает сообщения в очередь, второй поток работает с этими сообщениями. Проблемы две: 1) падать нельзя ну вообще; 2) всё это собирается на голом musl libc без стандартной библиотеки libstdc++ и без поддержки эксепшенов.

Из C++ только определения операторов new и delete через malloc/free и __cxa_pure_virtual (заглушка, куда попадаешь при вызове чистого виртуального метода). Всё остальное – стандартная библиотека C. Код – в стиле C с классами и шаблонами. Всё работало неплохо, но тут понадобилась более сложная обработка, чем была раньше. На обычном C++ с STL и контейнерами код получается простой и понятный. Проблема в том, что в процессе долгой работы память может задырявиться настолько, что очередной контейнер нужного размера будет не создать. Выход из самой ситуации несложен – можно прекратить забирать сообщения из очереди, выйти на уровень выше и зайти обратно, механизм RAII всё почистит. Проблема в том, что не используя исключения, стандартные контейнеры неспособны донести факт кончившейся памяти но нужного участка кода.

uuwaan ★★
() автор топика
Ответ на: комментарий от uuwaan

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

Прекрасно, значит резервируешь «нужный размер» заранее.

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

Доносишь эту информацию с помощью кастомного аллокатора, отдав зарезервированную память.

asaw ★★★★★
()
Ответ на: комментарий от uuwaan

Есть система, скажем так, быстрого реагирования на определённые сигналы. Один поток постоянно слушает канал и пихает сообщения в очередь, второй поток работает с этими сообщениями. Проблемы две: 1) падать нельзя ну вообще; 2) всё это собирается на голом musl libc без стандартной библиотеки libstdc++ и без поддержки эксепшенов.

пишите критические вещи на чистом C. Спокойно разруливая память и время. С++ для другого.

MKuznetsov ★★★★★
()
Последнее исправление: MKuznetsov (всего исправлений: 1)
Ответ на: комментарий от uuwaan

вызывающе неверная информация :)

см 25.2.5 [alg.find] ходи как хочешь, но верни первый если есть

anonymous
()
Ответ на: комментарий от uuwaan

«Извиняй, хозяина, нету!»

а если libc хотя бы 5-летней давности взять?

anonymous
()

ты хочешь glib

/thread

anonymous
()
Ответ на: комментарий от uuwaan

Omg, сделай свой пул, что ты как маленький? Чуть-чуть память задефражилась, сразу какие-то эпичные костыли начал сочинять. Элджера что ли не читал?

anonymous
()
Ответ на: комментарий от uuwaan

мнени(e,я) коллег из gd http://www.gamedev.ru/flame/forum/?id=134087&page=57 http://www.gamedev.ru/flame/forum/?id=85560&page=64

Имхатеся, на основании своего опытa и вышeизложенного, custom memory allocator( and/or per class ?), placement_new и прочие радости...

И еще, можно глянуть опыт людей из gd по консолям( та жесткие TRC, TCR, no allocation per game frame, etc ): http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html http://ddima.livejournal.com был еще одни линк, но пpoфонарил..

anonymous
()

А какого-нибудь jemalloc'а будет не достаточно?

MadMax
()
Ответ на: комментарий от anonymous

Вот особенно Appendix_17 и Appendix_18

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html#Appendix_17

18 - Out of memory

EASTL does not solve the out-of-memory problem any differently than std STL (aside from it providing intrusive containers and fixed size containers). The std STL solution (exception handling) is supported by EASTL but is not favored and is usually disabled (see Appendix item 17).

Dealing with exception handling at the level of the container user is tedious and error-prone; dealing with it at the level of the allocator is easier for the user and is more reliable. Using exception handling to properly and safely deal with out-of-memory conditions is a daunting and tedious task, especially in an environment of custom allocators. This is not a criticism of C++ exception handling in general but rather is an observation about using it with STL containers.

asaw ★★★★★
()
Ответ на: комментарий от uuwaan

падать нельзя ну вообще
голом musl libc
через malloc/free
Код – в стиле C с классами и шаблонами
На обычном C++ с STL и контейнерами код получается простой и понятный.
Проблема в том, что в процессе долгой работы память может задырявиться настолько
механизм RAII всё почистит
стандартные контейнеры неспособны донести факт кончившейся памяти но нужного участка кода.
кончившейся памяти
памяти
malloc
контейнеры
C++ с STL

Не, я конечно знал, что «падать нельзя» - это куллстори школьников, но чтоб настолько. Каждое слово - взаимоисключающий параграф.

Особенно порадовало «кончившейся памяти + malloc» и «malloc + быстрого реагирования на определённые сигналы». Это просто уровень в районе днища галимого.

Ну и «musl libc» - типичная жертва пропаганды. Достаточно глянуть на их маллок, функции для работы со строками/памятью:

void *__malloc0(size_t n)
{
	void *p = malloc(n);
	if (p && !IS_MMAPPED(MEM_TO_CHUNK(p))) {
		size_t *z;
		n = (n + sizeof *z - 1)/sizeof *z;
		for (z=p; n; n--, z++) if (*z) *z=0;
	}
	return p;
}

if (*z) *z=0 просто нахрен оптимизация.

Т.е. очередное поделие С/С++ экспертов.

Судя по коду и уровню этих днищ - они ваяли своё говно тупо по мануалам от глибц.

lock_bin(j);
		c = mal.bins[j].head;
		if (c != BIN_TO_CHUNK(j)) {
			if (!pretrim(c, n, i, j)) unbin(c, j);
			unlock_bin(j);
			break;
		}
		unlock_bin(j);
char *__strchrnul(const char *s, int c)
{
	size_t *w, k;

	c = (unsigned char)c;
	if (!c) return (char *)s + strlen(s);

	for (; (uintptr_t)s % ALIGN; s++)
		if (!*s || *(unsigned char *)s == c) return (char *)s;
	k = ONES * c;
	for (w = (void *)s; !HASZERO(*w) && !HASZERO(*w^k); w++);
	for (s = (void *)w; *s && *(unsigned char *)s != c; s++);
	return (char *)s;
}

А уж эти мемкопи, эти мемсеты от школьников. Теперь ясно почему мемсет не заюзался - он просто говно.

Почему этот мемкопи до сих пор не в ядре. Вот бы пацаны обрадовались.

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

anonymous
()

А ещё это так мило, когда нули начитавшись моих объяснений, обосравшись в спорах со мною начинают их повторять и при этом нести херню, ибо даже не понимают о чем кукарекают.

anonymous
()
Ответ на: комментарий от uuwaan

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

В результате у тебя память будет «в дырочку»
память
«в дырочку»

Да тут явный анскилл. Иди перечитай макулатуру, только на этот раз не ту, которую ты в мусорном баке нашёл за 90-й год из серии «для чайников».

А у тебя нет нигде непрерывного блока размером в мегабайт.

Я тебя удивлю, но у тебя итак нет ни одного «непрерывного блока размеров в мегабайт». Об этом ты узнаешь из макулатуры.

И тут-то и malloc и operator new и скажут тебе: «Извиняй, хозяина, нету!». А так-то свободная память есть, чо.

А потом ты так же узнаешь, почему «malloc и operator new» никакого отношения к памяти не имеют. И почему то, что ты тут высрал - фиеричная херня.

А так да - за партой, за которой ты пишешь свою лабу - такая пурга прокатит.

anonymous
()
Ответ на: комментарий от anonymous

Какого буя ты тут на всех ярлыки развешиваешь, царек упоротый? Выучил десяток умных слов и круче всех теперь? Тебе кто-то сказал что у опа есть MMU? И даже если есть, оно дефрагментирует только до страницы, а внутри страницы изволь рулить сам.

anonymous
()
Ответ на: комментарий от anonymous

Какого буя ты тут на всех ярлыки развешиваешь, царек упоротый?

Ну ты мне покажи того, на кого этот ярлык не работает. Ну и где я что «развешивал»?

Выучил десяток умных слов и круче всех теперь?

Дело всё в том, что а) я не использую «умных слов» - это для нулей. И что самое главное - почему же ты их не выучил?

Тебе кто-то сказал что у опа есть MMU?

Логика. Ничего, без мму не существует. Иди почитай хоть названия сайта, а потом погугли по ключевому слову.

Да ладно, оставим линукс - просто тотальная нулёвость + сеть + треды + маллок + с++ - это уже 100% признак не то, что мму, а х86.

И даже если есть

И даже если ты попытаешься что-то «умное» мне написать, даже если ты сотню раз попытаешься меня поймать - не получиться, будешь всегда в говне.

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

оно дефрагментирует только до страницы

И опять же куллстори от многоуважаемого эксперта. Никакой «дефрагментации» и «фрагментации» памяти в юзерпейсе нет - есть только в мифологии нулей и их высерав.

Да и «нигде» нет.

а внутри страницы изволь рулить сам.

Ничего меньше страницы не существует, кроме как в мифологии нулей и их высерах. Ни фрагментации, ни рулёжки, ни памяти.

Это всё происходит в твоих убогих фантазиях.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.