I overloaded in the last post operator new and delete. Therefore, finding memory leaks and getting the first hint of the bad guys. My solution had two not-so-nice properties. With this post, I will overcome them.
What were the not-so-nice properties of my last post? At first, I got only a hint that my memory was lost; second, I had to prepare the whole bookkeeping of memory management at compile time. Those who want to know the details of these shortcomings should read the last post. But now the ugliness will go.
Who is the bad guy?
Particular tasks ask for special forces. So I have to use a small macro for debugging purposes.
I want to stress this point. I’m not a friend of macros.
Let’s have a look at the macro. #define new new(__FILE__, __LINE__)
The macro causes each new call will be mapped to the overloaded new call. This overloaded new call adds the name of the file and the line number, respectively. That’s exactly the information I need.
But what will happen if I use the macro in line 6?
The preprocessor substitutes all new calls. That shows precisely the modified main function.
Lines 2 and 12 show that the preprocessor substitutes the constants __FILE__ and __LINE__ in the macro. But how does the magic work? The header myNew4.hpp solves the riddle.
I implement in line 25 and 29 the special operators new and new that delegates their functionality to the helper function newImpl (lines 18 – 23). The function does two important jobs. At first, it displays to each new call the name of the source file and the line number (line 20); second, it keeps in the static array myAlloc track of each used memory address (line 21). This fits the behavior of the overloaded operator delete that sets all memory addresses to the null pointer nullptr (line 35). The memory addresses stand for the deallocated memory areas. In the end, the function getInfo displays the memory addresses that were not deallocated. You can directly see them together with the file name and line number.
Of course, I can directly apply the macro in the file myNew4.hpp. That was a lot of theory. What’s the output of the program?
The memory areas to the memory address 0x8c3010, 0x8c3090, and 0x8c3230 were not deallocated. The bad guys are the new calls in line 24 and line 14 (overloadNewAndDelete.hpp) and the new call in line 42 (myNew4.hpp).
Impressed? I assume, yes. But the presented technique has two drawbacks. One minor and one major.
- I have to overload the simple operator new and the operator new  for arrays. This, because of overloaded operator new, is not a fallback for the three remaining operators new.
- I can not use the particular operator new that returns in the error case a null pointer. Because it will be explicitly called by the operator new with the argument std::nothrow: int* myInt= new (std::nothrow) int(1998);
Now, I have to solve the first issue. I want to use for the array myAlloc, a data structure that manages its memory at run time. Therefore, it is not necessary anymore to eagerly allocate the memory at compile time.
All at run time
What was the reason that I couldn’t allocate memory in the operator new? The operator new was globally overloaded. Therefore, a call of new would end in a never-ending recursion. That will happen exactly if I use a container like std::vector that dynamically allocates its memory.
This restriction holds not anymore because I didn’t overload the global operator new. That is a fallback to the three remaining new operators. Thanks to the macro, my variant of operator new is used. Therefore, I can use std::vector in my operator new.
Exactly that can you see in my program.
I use in lines 13, 19, and 33 std::vector.
In the next post, I will have a closer look at std::allocator. In particular, I’m interested how memory requests can be mapped to particular memory areas.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, and Philipp Lenk.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.
|My special thanks to Embarcadero|
|My special thanks to PVS-Studio|
|My special thanks to Tipi.build|
|My special thanks to Take Up Code|
|My special thanks to SHAVEDYAKS|
I’m happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
- Embedded Programmierung mit modernem C++ 12.12.2023 – 14.12.2023 (Präsenzschulung, Termingarantie)
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ – The Core Language
- C++ – The Standard Library
- C++ – Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- Mail: schulung@ModernesCpp.de
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org
Modernes C++ Mentoring,