On 18-Aug-2015 07:45, Rikki Cattermole wrote:
What I don't like:
- Does not allow for calling the constructor on the type should it have one

Hm it depends - one thing is that after mmaping a file the type may already be constructed, if it wasn't then emplacement should be the right thing to do. That is there should be a default/string value.

- Does not map to std.mmfile in any way

Which is a good thing. std.mmfile is crappy 8 year old ported crap.

- No way to say an offset in the file to

That may be useful.

> - You implement basically everything in std.mmfile all over again

Low-level API might be in order but it's not std.mmfile which is not low-level enough. Separating out a set of portable mmaping primitives would be awesome.

What I don't like is perpetual being a class - too bad as it won't honor scoping and destructor may or may not be called. Just make it a struct.

Also type should be Perputal, then perpetual is helper function that creates it then by means of IFTI type may be deduced. I suggest the following API:

// all parameters after file are either T itself
auto p = perpetual("file-name", 42);// would deduce T=int

// or args to T:
struct RGB{ int r,g,b; }
// if not in file use RGB(1,2,3)
auto p = perpetual!RGB("file-name", 1, 2, 3);

Dmitry Olshansky

Reply via email to