You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: doc/reference.rst
+72
Original file line number
Diff line number
Diff line change
@@ -215,3 +215,75 @@ using FPSTR would become...
215
215
String response2;
216
216
response2 += FPSTR(HTTP);
217
217
}
218
+
219
+
C++
220
+
----
221
+
222
+
- About C++ exceptions, ``operator new``, and Exceptions menu option
223
+
224
+
The C++ standard says the following about the ``new`` operator behavior when encountering heap shortage (memory full):
225
+
226
+
- has to throw a ``std::bad_alloc`` C++ exception when they are enabled
227
+
228
+
- will ``abort()`` otherwise
229
+
230
+
There are several reasons for the first point above, among which are:
231
+
232
+
- guarantee that the return of new is never a ``nullptr``
233
+
234
+
- guarantee full construction of the top level object plus all member subobjects
235
+
236
+
- guarantee that any subobjects partially constructed get destroyed, and in the correct order, if oom is encountered midway through construction
237
+
238
+
When C++ exceptions are disabled, or when using ``new(nothrow)``, the above guarantees can't be upheld, so the second point (``abort()``) above is the only ``std::c++`` viable solution.
239
+
240
+
Historically in Arduino environments, ``new`` is overloaded to simply return the equivalent ``malloc()`` which in turn can return ``nullptr``.
241
+
242
+
This behavior is not C++ standard, and there is good reason for that: there are hidden and very bad side effects. The *class and member constructors are always called, even when memory is full* (``this == nullptr``).
243
+
In addition, the memory allocation for the top object could succeed, but allocation required for some member object could fail, leaving construction in an undefined state.
244
+
So the historical behavior of Ardudino's ``new``, when faced with insufficient memory, will lead to bad crashes sooner or later, sometimes unexplainable, generally due to memory corruption even when the returned value is checked and managed.
245
+
Luckily on esp8266, trying to update RAM near address 0 will immediately raise an hardware exception, unlike on other uC like avr on which that memory can be accessible.
246
+
247
+
As of core 2.6.0, there are 3 options: legacy (default) and two clear cases when ``new`` encounters oom:
248
+
249
+
- ``new`` returns ``nullptr``, with possible bad effects or immediate crash when constructors (called anyway) initialize members (exceptions are disabled in this case)
250
+
251
+
- C++ exceptions are disabled: ``new`` calls ``abort()`` and will "cleanly" crash, because there is no way to honor memory allocation or to recover gracefully.
252
+
253
+
- C++ exceptions are enabled: ``new`` throws a ``std::bad_alloc`` C++ exception, which can be caught and handled gracefully.
254
+
This assures correct behavior, including handling of all subobjects, which guarantees stability.
0 commit comments