Jak zapewnić odporność na brak pamięci przy wyłączonych wyjątkach C++ (VS2010)?

Question

Pracuję nad dynamicznie połączoną biblioteką (DLL) o krytycznym działaniu, która również powinna mieć stosunkowo mały rozmiar binarny. Ponieważ nie jawnie rzuca żadnych wyjątków, chciałbym wyłączyć obsługę wyjątków w ogóle. Jest jednak jeden wyjątek (niezamierzony kalambur): kiedy zabraknie pamięci (OOM), muszę zgłosić kod błędu do aplikacji, aby miał szansę poradzić sobie z wdziękiem. Baza kodu jest zbyt duża, aby sprawdzić każdą alokację indywidualnie i propagować błąd oraz zawiera zewnętrzny kod, którego nie powinienem dotykać. Dlatego chciałbym przechwycić wyjątki OOM w wyeksportowanych funkcjach moich bibliotek DLL.

Szybki test pokazuje, że po wyłączeniu wyjątków C++ w Visual C++ 2010 (tj. Flagi nie/EHa,/EHsc lub/EHs), nadal przeskakuje do bloku catch (std :: bad_alloc &) przy przydzielaniu zbyt dużej ilości pamięci .

Wygląda na to, że działa zgodnie z oczekiwaniami. Jednak otrzymuję następujące ostrzeżenie na poziomie 1: "Używany program obsługi wyjątków C4530: C++, ale semantykę odwijania nie włączono." Określ/EHsc ". MSDN twierdzi, że "obiekt z automatycznym przechowywaniem w ramce, między funkcją wykonującą rzut i funkcją rzucającą rzut, nie zostanie zniszczony".

Dokładnie, co bym tu stracił? W porządku jest pozostawienie rzeczy w stanie niezdefiniowanym, o ile wszystko, co zostało utworzone przez bibliotekę, może zostać usunięte, a aplikacja może zacząć od początku (jeśli tak wybierze). Czy istnieje duże ryzyko wycieku pamięci, której nie można odzyskać?

Czy biblioteki DLL używają oddzielnej puli pamięci? A jeśli tak, czy mogę go usunąć bez konieczności usuwania aplikacji z biblioteki DLL? Mogę z łatwością sprawić, że moja biblioteka zignoruje jakiekolwiek dalsze (wyeksportowane) wywołania funkcji, dopóki aplikacja nie wykona reinicjalizacji.

Dzięki za porady.

Answer 1

Kilka eliminacje:

ja nie wiem, czy rzuca wyjątek bez obsługi wyjątków włączona jest niezdefiniowane zachowanie lub nie w normie, ale nie są z pewnością dostanie stos wywołań odwijania/spalające z obiektami na stosie.

Jeśli piszesz kod w stylu C++ za pomocą RAII dla muteksów, plików, pamięci itd., To bardzo zła rzecz.

Przechodząc następnie, i zakładając, że kod jest zasadniczo kod C-style:

1) Jeśli statycznie łączenie do biblioteki C Runtime, Twój DLL nie będą dzielić sterty z głównym aplikacji. Rozładowanie biblioteki DLL powinno zwolnić wyciek pamięci - ale ponownie należy zadbać o inne zasoby.

2) Jeśli dynamicznie łączysz się z środowiskiem wykonawczym C (dość powszechnym), to dzielisz stertę. Będziesz musiał mieć sposób ręcznego zwolnienia dowolnej pamięci przydzielonej z biblioteki DLL.

Posiadanie siebie zbytnio zaśmiecone problemami związanymi z biblioteką DLL, poleciłbym szybką analizę porównawczą, aby sprawdzić, za co płacisz, jeśli chodzi o włączanie wyjątków. W zależności od platformy i kompilatora wyjątki niekasowane mogą mieć bardzo niewielki wpływ na wydajność.