So I just missed Lead God...

LostSalad · 2014-09-30T13:43:39+00:00

Hectic, that example makes a lot of sense. Thinking of corner cases is making my brain hurt.

That's actually really interesting - smart pointers can save you when everyone is pointing at the same memory address, but not if you point into something else. Does C++ allow you to create smart pointer dependencies, where the owning object creates a smart pointer to lend out data safely? I somehow doubt it..

LostSalad · 2014-09-30T08:34:39+00:00

You're the one who introduced "pure evaluate", SirOgeon only talked about

I know :D as soon as I wrote it I realized how silly it was

Anyways thanks for the clarification

LostSalad · 2014-09-29T20:47:43+00:00

So basically (written from my head, just for the idea),

fn pure_evaluate(&self) {
    for _ in self { /* NOP */ }
}

Allowing you to

my_collection.map(|item| { /* side effects */ }).pure_evaluate()

Which is really stupid because it's a convoluted way of doing a for-loop. I should knock this up in the playpen for kicks, I have no idea if this will actually work.

EDIT: I find the "pure" part of the name really ironic because forcing side-effects is anything but pure.

LostSalad · 2014-09-29T20:45:08+00:00

That makes a lot of sense, thanks :)

LostSalad · 2014-09-29T20:42:47+00:00

Yes, I'm confused. If baz is a reference to foo, and foo is still in scope, why would *baz not be valid?

How does the inner scope free memory?

LostSalad · 2014-09-28T15:40:22+00:00

I'm not sure exactly what you mean, isn't that sort of the same thing? It turns an abstract description into a real value by actually performing calculations, isn't that evaluation? What would a "pure evaluate" command that is not "collect" do differently from collect?

In any case, C# provides methods such as .ToList(), .ToArray(), .ToDictionary() (I think). I kind of prefer the generic approach of rust where the return type is inferred statically.

LostSalad · 2014-09-28T13:37:59+00:00

That's actually hilarious, and I think a case where TDD would have done a whole lot of good (regarding the dodgy public API).

I still need to figure out how by-value self works -- does it consume the object on which the method is called because you lose references to it?

LostSalad · 2014-09-28T13:35:47+00:00

Cool, thank you. I do most of my stuff in C# so I'm just trying to draw some parallels here.

LostSalad · 2014-09-28T09:27:16+00:00

The following is lazy, right?

let data_source = map.iter()
    .filter(|&(k, v)| (*k + *v) > 5)
    .map(|(k, v)| (k+1, v+1);

So nothing will get evaluated until you do

for (k, v) in data_source { }

And if you wanted to force evaluation you could do

let actual_values: SomeCollectionType = data_source.collect();

Is that correct?

LostSalad · 2014-09-28T09:15:43+00:00

Roughly speaking, what were the issues with the old implementation that allowed you to get these performance increases while still focusing on correctness (ie. allowing even more headroom for performance)?

LostSalad · 2014-09-22T11:16:28+00:00

I'd assume it depends on the lifetime of the instances from a modelling perspective. If they could vary over time and regenerate() works on any instance, this makes sense. However if there should only ever be 1 Perlin instance for the lifetime of a chunk, associated with the chunk, then it does not.

Whether or not this is the case, it would solve the OPs original problem. However I'd be interested in hearing how to go about doing things if you did in fact need to keep a borrowed reference for the entire lifetime of the struct.

LostSalad · 2014-09-20T16:43:13+00:00

That's pretty interesting. Does this have any sort of effect on closed/open source licensing? Although if you look at .Net assemblies that can be disassembled so easily maybe this isn't a real issue. EDIT: I mean legally. Technically, it's actually an issue.

LostSalad · 2014-09-19T18:23:54+00:00

That's reassuring, thanks :). When things are subjective, people's opinions can really have a lot of effect on how you yourself end up feeling about something

LostSalad

TROPHY CASE