On 24/08/2025 22:43, organicoman wrote:
>
> 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."
>

Please understand the purpose of this mailing list - it is for
discussing proposals for changes and additions to the C++ standards. It
is all about making C++ better for /real world/ code. Nobody here cares
about intentionally buggy code, or purely hypothetical examples far
removed from what any programmer would write. They care even less about
hypothetical nonsense code that doesn't even have any connection to what
you are talking about - since the external function takes a /copy/ of
"p", it is irrelevant what happens to "p" after the function is called.

If you want to persuade anyone that you have a good idea, find some
examples of /realistic/ code that you can write in two versions - one
without your idea, and one in a C++ that incorporates your idea.
Explain how the second version is simpler to write, more efficient, more
flexible, has lower risk of bugs, or is in some way significantly better
than the former version. Explain why this needs a change to the C++
standard, and can't be handled by improvements to existing tools.

If you can't do that - and so far, you have not been able to - then why
do we still have this thread? It is fine to have a discussion about an
idea, then realise it is not actually as great as you first thought.
That's why we have discussion lists and other such forums. But you also
have to reach a point where you understand that your idea is going
nowhere - it is time to take a step back, and rethink things.

>>>> 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.
>

I have never heard of anyone suggesting that real-world C++ standard
library implementations are a good tool for learning, or that anyone
actually looks at them. Most people who take a casual glance at the
code for major C++ standard library implementations run away screaming.
(My apologies - and undying respect - to Jonathan and any others on this
list who write and maintain these implementations.)