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

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

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

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

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

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

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

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

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

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

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

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

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

А в 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ты хочешь glib

/thread

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

мнени(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фонарил..

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

Вот особенно 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.

падать нельзя ну вообще
голом 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;
}

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

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

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

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

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

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

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

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

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

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

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

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

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

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

современные malloc-и не фрагментируют :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

современные malloc-и не фрагментируют :)

А какой жопой это могут делать «не современные маллоки»?