Joseph Rushton Wakeling:

What really matters to me is stuff like Sample and Cover, where we can readily expect that they may be called in inner loops of the program, and so having lots of allocations via "new" would be a big problem. So, it follows that the current helper functions (sample, cover, etc.) need to be rewritten at some point with this in mind.

I think @nogc is a good improvement for D, despite Walter and other people (and I think Don) were very sceptical about it, because it's like a new lens that allows me to see important things about my code that I wasn't able to see before. Phobos has to be modified in many places to allow both usage patterns for people that want to write short clean code (that allocates automatically and lets the GC free), and performance-conscious people that need to avoid most or all heap allocations. What's unfortunate is that the @nogc attribute was not present for lot of time of development of Phobos, so several Phobos things now need to be modified and some old APIs could give problems. std.random2 should offers ways to be used as much as possible from @nogc code, see below.


It's not a problem I propose to solve for the 1.0.0 release, but it is a problem that needs addressing in the long run.

Even if the 1.0.0 release of std.random2 is not much @nogc, in my opinion it needs to have an API designed to allow it to be retrofitted cleanly and nicely for @nogc usages too.


do you have any ideas or suggestions for how to address the requirement for RNGs and related functionality to be reference types, together with the wish to support @nogc ... ? Preferably in a way that avoids the user having to explicitly indicate destruction?

If you are not using the GC, and you don't want to indicate destruction, you have to use RAII and perhaps RefCounted. You can allocate on the C heap manually, or on the stack, or you can allocate on the stack or C heap using one of Andrei's future allocators.

Bye,
bearophile
  • Re: hap.random: a new r... Joseph Rushton Wakeling via Digitalmars-d-announce
    • Re: hap.random: a ... Nick Sabalausky via Digitalmars-d-announce
      • Re: hap.random... Joseph Rushton Wakeling via Digitalmars-d-announce
        • Re: hap.ra... bearophile via Digitalmars-d-announce
          • Re: ha... Dicebot via Digitalmars-d-announce
            • R... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Dicebot via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
          • Re: ha... Joseph Rushton Wakeling via Digitalmars-d-announce
            • R... bearophile via Digitalmars-d-announce
              • ... Joseph Rushton Wakeling via Digitalmars-d-announce
    • Re: hap.random: a ... Chris Cain via Digitalmars-d-announce

Reply via email to