Challenge: write a reference counted slice that works as much as possible like a built-in slice

[Stanislav Blinov]

On Thursday, 11 November 2021 at 09:15:54 UTC, Atila Neves wrote:

> I have not yet encountered...
> I think that...
> I don't think this is a problem.
> I wouldn't care about it either.
> Me, ~99.9% of the time. I definitely don't miss...

This all amounts to "I don't need it, therefore nobody should 
either". That's not a very good metric.

It's 2021. Your footnote on "nobody" simply does not apply. 
Everybody should be writing code designed to run on multiple 
processors simultaneously. Because that's what the machines are. 
A large portion of that "everybody" should be writing code where 
a large number of those processors are the GPU, or GPU(s), and 
I'm not even talking computer games. In either case, memory 
becomes key. Because, at least today, it's your slow resource 
(CPU) and also your somewhat limited resource (GPU).

> My algorithm:
> 1. Write code
> 2. Did I notice it being slow or too big? Go to 4.
> 3. Move on to the next task.
> 4. Profile and optimise, go to 2.

That's an interesting way of doing science. How would you notice 
anything without a baseline, which you haven't even set yet 
because you're not at (4)? You won't. You just wrote a slow piece 
of software and you don't even know it because you didn't look, 
because it didn't appear slow? Eh?

People after you, who use your software, maybe, MAYBE, would 
notice though (because they set the baseline from the start), but 
by that time it is too late, because your software is part of the 
OS or CRT or whatever other dependency the application must rely 
on, but you didn't care. Not because you didn't optimize. Just 
because you pessimized, and never bothered to look.

...and that is exactly why Visual Studio (a text editor) takes 10 
seconds to load a few small text files (whereas the compiler 
itself loads and compiles those same files in less than a 
second), Photoshop (an image editor) greets you with a nice 
splash screen (that contains an image) "almost" immediately, but 
lets you actually work on images only a dozen seconds later, 
Libre- (and any other) Office shows you a progress bar while it's 
"starting up", and so on and so forth... And then we have Andrei 
on stage lamenting on how awesome and lucrative it was to squeeze 
out that meager extra 1%...

> having to make things fit into 48k of RAM

??? You DO have to make things that fit into 32k, or 64k, or 
(insert your cache size here). Over time - modulated by the speed 
of that cache. Which means, you have to take care with how, and 
where, your data is laid out. Which, eventually, brings you back 
to how you allocate. Moreover, you DO have to make things that 
fit into a single cache line, or are bounded by the size of that 
cache line. Which, again, brings you back to how you allocate.

Nobody would do any of that for you. Malloc or new won't (well, 
malloc may try, but it'll inevitably fail). Vector and map won't. 
Unique, shared, and other ptrs won't.