C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Delete...why not a parameter by reference?!

From: organicoman <organicoman_at_[hidden]>
Date: Sun, 24 Aug 2025 21:43:25 +0100
> >> Anyone who is able to check their pointers before use, is equally able> >> to assign 0 to deleted pointers.> >> > {> > T* p = new T;> > Dll_fn_takes_by_Copy (p);> > delete p;> > }> >> > Show me how.>  >>  >> > Now you are being silly.> > 😂 ...no seriously...it is a honest question.> How can check if Dll_fn_takes_by_Copy assigned nullptr to the copy of p?> Making "delete p;" assign nullptr to "p" will not affect the /copy/ of "p" taken by the function. The ownership semantics implied by the name of your function and what you are trying to do with it - with standard "delete" or your suggested version - are so badly messed up that the code is beyond all hope and needs a redesign.That's an example chosen on purpose to illustrate the case, don't take it as a real world code.You have to use it to understand the following:"You are passing a copy of an owning pointer to an opaque function which has a bug."No change to the language, improvement or otherwise, can make nonsensical code suddenly work.> >> > But library implemented and low level will definitely use raw> > pointers....just show me how many std::vector implementation uses smart> > pointers for its internal data pointer.> >> > How standard library implementations are written is totally irrelevant.> > Very relevant...stl implementation are the goto to anyone who wants to > crank up his level of C++ expertise. Most students i see, copy the > standard implementation, even if they have the tools to do better.Real-world implementations of the C++ standard libraries would be an extraordinarily bad choice of example for anyone wanting to improve their C++ skills. Implementations are full of arcane coding that few people will ever want to see, along with lots of implementation-specific stuff, short-cuts, uses of poorly documented compiler extensions that exist solely for implementations of the library, and other non-portable and risky code that should never be copied elsewhere. Bits of it might be implemented in other languages (C or assembly), or at least other C++ standard versions. A great deal of the C++ standard library would be poor examples for modern C++ programming, precisely because it is /not/ modern C++ programming but has developed over the decades.For the most part, consider the standard library source code of your toolchain(s) as black boxes. Occasionally it might be interesting to peek inside for curiosity, but no more than that.Very good advice, but unfortunately no one will follow it.....remember hyram's law.

Received on 2025-08-24 20:43:33