If you make a friend only because you want to expose your private member to them, you may be a C++ programmer.
Retiring a favourite C++ joke
61–70 of 151 posts
Re: Retiring a favourite C++ joke
#62Re: Retiring a favourite C++ joke
#63Earlier quoted context omitted.
That modern pratice is more theory than practice, even on sample code from ISO C++ members.
No, it’s not just theory. Like anything in C++, codebases and their styles widely vary. But my comment holds true for the vast majority of developers I have worked with over the last decade. With the exception of the special “placement new“ operator, it is nearly obsolete to use new and delete.
I suggest browsing around code from Microsoft, Google, Apple,...
Plus there are those tons of enteprise code, hardly the "vast majority".
The only place I see modern C++ as advocated, it at C++ conference talks, and my own hobby coding.
Re: Retiring a favourite C++ joke
#64Hey, it actually works! int main() { int tobias[24] = {0,0,33}; delete(tobias+4); } Compile and run on Ubuntu 20.04 (may work on other Linuxes), no errors, no warnings, runs perfectly fine. Bonus fun: try printing out the address of `tobias` and `new int[6]` afterwards :)
I assume you have it on x86_64. I'm trying to make sense of that according to glibc implementation details[1] and Sys V/Itanium ABI. Default new and delete just use malloc/free. First 4 ints are interpreted as prev_size and size. prev_size is 0. 33 is 0b10001, size is 32 (bytes, so 8 ints), AMP is 0b001, so not in arena (default sbrk heap, I assume), not mmap'd, prev is used. I didn't follow how the internal bookkeep…
Essentially correct. 33 sets up the pointer to appear to glibc as if it were a small, “normal” 32-byte allocation. The default behavior for glibc free() with a small allocation size will be to put it into the thread cache (tcache), which makes it immediately available to be reused by the same thread.
Although you should obviously never write code like this by yourself, understanding weird details like this is very helpful when exploiting memory error bugs in software, as it lets you understand how precisely to subvert the memory allocator to give you access to desired parts of memory.
Re: Retiring a favourite C++ joke
#65Re: Retiring a favourite C++ joke
#66I was surprised to see it not mentioned in the post -- the most obvious reason this joke should be retired is not the reference to a television show but rather the modern practice of never using new or delete at all in C++ code. Modern C++ avoids these pitfalls and I think it's been 10 years since I've written the words the new or delete.
I frequently work with companies that have old, large codebases. A key requirement of the training in that environment is that attendees are able to read existing production code. In some cases that's over twenty years old and millions of lines of code. new/delete is just part of that reality. We teach them without encouraging their use.
Re: Retiring a favourite C++ joke
#67I was surprised to see it not mentioned in the post -- the most obvious reason this joke should be retired is not the reference to a television show but rather the modern practice of never using new or delete at all in C++ code. Modern C++ avoids these pitfalls and I think it's been 10 years since I've written the words the new or delete.
That modern pratice is more theory than practice, even on sample code from ISO C++ members.
I would argue it is not for me at least. In my 2 current C++ commercial products of fair size one has single explicit allocation, the other does not have any.
If I was writing for example libraries of custom high performance containers the situation would have been different but still highly localized. And it is sort of very specialized type of development anyways.
Re: Retiring a favourite C++ joke
#68I was surprised to see it not mentioned in the post -- the most obvious reason this joke should be retired is not the reference to a television show but rather the modern practice of never using new or delete at all in C++ code. Modern C++ avoids these pitfalls and I think it's been 10 years since I've written the words the new or delete.
> the modern practice of never using new or delete at all in C++ code
What? How do you (de)allocate memory without new and delete?
If the answer is "smart pointers" then why bother use C++ in the first place, just use Go or something.
Re: Retiring a favourite C++ joke
#69There's dozens of people who would get it... DOZENS!
Hey brother! I always love a good quote back. I've occasionally had a 'there are dozens of us' response in the training room or remote chat. Always makes me smile.
Re: Retiring a favourite C++ joke
#70My favorite C++ joke is: Have you heard about the new object-oriented version of COBOL? It’s called “ADD 1 TO COBOL”
My favorite, best told while among C programmers involuntarily debugging some gnarly C++ is, "Man, I swear, the dude that invented C++ doesn't know the difference between increment and excrement."