refInt = ref int: how to achieve this? or is this a bug?

[mw]

On Thursday, 18 June 2020 at 02:22:55 UTC, Stanislav Blinov wrote:
> On Thursday, 18 June 2020 at 01:21:52 UTC, mw wrote:

> queue.push(new Object); // receiver may get garbage reference
> queue.push(FatStruct()); // temporary is gone after push() 
> queue.push(createStuff!options()); // yeah, createStuff is

Can all of these be rewritten as:

dSideRefHolderVar = dSideWhateverStuff();
queue.push(dSideRefHolderVar);

?

To use that C lib, then have to live with its constraints. I have 
no intention to wrap that library to work universally in the D 
world. If dpp can provide a thin oo wrapper automatically, I 
don’t even want to write this one.


> You're absolutely correct, C is C, and D is D, and type system

I’m glad you recognize this:-)

> exists for a reason, yet you're trying to circumvent it, and 
> don't like it when the language fights back.

This is not true: the compiler silently throw away ref from the 
alias without issuing an error; if it did, I would be more sure 
it’s a feature rather than bug, given the current semantics. Then 
I will try to find other way to make it work.


> Like I originally remarked, if you *want* to be escaping 
> pointers, then escape pointers, and state as much in your 
> interface. That will simplify it (the interface), and leave 
> your users (i.e. "the programmers") with no illusions as to 
> what's going on.

That’s right: The library user have to know how the original 
library works in order to use the wrapper. Maybe I haven’t 
mentioned this:

“To make those initial values valid (which is to say, visible) 
upon other logical cores, threads on those cores need to issue 
the define


https://www.liblfds.org/mediawiki/index.php?title=r7.1.1:Define_LFDS711_MISC_MAKE_VALID_ON_CURRENT_LOGICAL_CORE_INITS_COMPLETED_BEFORE_NOW_ON_ANY_OTHER_LOGICAL_CORE

”

It’s ugly macro of that C lib need to be called, but need to live 
with it.

And even laughable this:

The LFDS711_QUEUE_BMM_QUERY_GET_POTENTIALLY_INACCURATE_COUNT 
query is not guaranteed to be accurate. Where enqueue and dequeue 
operations are not guaranteed to be visible by the time the 
function calls return, similarly, it may be that a count will 
during its operation not see an element which has been enqueued, 
or see that an element has been dequeued. In general however it 
should be bang on; it's just it's not guaranteed.

https://www.liblfds.org/mediawiki/index.php?title=r7.1.1:Function_lfds711_queue_bmm_query#Notes


Yet, this library is the best time tested open source library on 
the internet. I have no interest to re-invent the wheels, or make 
the wrapper universal.

Because it’s much better than the ~4x times slower fewly-used D 
queues I have found.