On Saturday, 26 October 2013 at 16:01:18 UTC, Joseph Rushton Wakeling wrote:
> On 25/10/13 20:41, Namespace wrote:
>> Did you mean to get rid of built-in arrays / kill int[] and replace it with
>> Array!T?
>
> Array!T is problematic as things stand -- e.g. you can't foreach over one.  So, forgetting syntax preferences, there needs to be some work on containers before they can "just work" like the builtins.
>
> If it's possible, I'd rather see the converse -- that code that assumes the GC will "just work" with other allocation strategies, so one can use the builtins without worrying.  But am I being naively hopeful in seeking that? :-)

I would never vote to replace the built-in arrays with something ugly as Array!T.
If D would switch to Array!T and Map!(T, U) it would be the same hell as with C++. But I hope allocators enable the possibility that built-in arrays could use other memory mangaement besides the GC. That would be awesome.

On Saturday, 26 October 2013 at 16:10:46 UTC, Dmitry Olshansky wrote:
> 26-Oct-2013 20:01, Joseph Rushton Wakeling пишет:
>> On 25/10/13 20:41, Namespace wrote:
>>> Did you mean to get rid of built-in arrays / kill int[] and replace it
>>> with
>>> Array!T?
>>
>> Array!T is problematic as things stand -- e.g. you can't foreach over
>> one.
>
> Sure you can. Try it and rejoice:
>
> void main()
> {
>     import std.container, std.stdio;
>     Array!int a = make!(Array!int)(1,2,3,4);
>     //the rule is: if a can be sliced then slice it and use that slice
>     foreach(v; a)
>     {
>         writeln(v);
>     }
> }
>

The fact that foreach with a ref item or foreach with an index doesn't work makes using them a lot more of a hassle than built-in arrays though.

    void main()
    {
        import std.container, std.stdio;
        Array!int a = make!(Array!int)(1,2,3,4);
        foreach(ref v; a)
        {
            v *= v; // no effect on a
        }

        writeln(a[]); // [1, 2, 3, 4]

        foreach(v, i; a) // Error: cannot infer argument types
        {
            a[i] *= v;
        }
    }

On 10/25/13 7:23 AM, Manu wrote:
> 3. FreeList has some options; minSize, maxSize, maxNodes. When I'm using
> a freelist, the most important option to me is to be able to allocate
> new nodes in batches.

Pushed new version with batchSize parameter, defaulted to 8.

Andrei

On 10/26/13 5:23 AM, Johannes Pfau wrote:
> Some small nitpicks:
> * byAllocation is not accessible from outside std.allocator

Fixed.

> * Is it intentional that AllocatorWithStats can't log the
>    __FUNCTION__ / __PRETTY_FUNCTION__ ?

Just an omission, good idea! Fixed. Let's just record __FUNCTION__.

> * The documentation for byAllocation should probably state that it only
>    lists 'alive' allocations and that this is especially useful for
>    finding memory leaks.

Fixed.

> And one bigger problem: CAllocatorImpl doesn't work well with
> AllocatorWithStats.
>
> AllocatorWithStats special members (byAllocation, etc) are not
> directly accessible. Although we can access them by using .impl it'd be
> nice to have a special AllocatorWithStats class which directly exposes
> those members.

That shouldn't be a problem - just downcast to CAllocatorImpl!AllocatorWithStats and you got access.

> The second problem is that the logged file/line is always in
> std.allocator.d. It's probably not easy to get this working in all
> cases (especially regarding polymorphism).

Uhm, that /is/ a problem.


Andrei

On 10/25/13 12:19 PM, Dmitry Olshansky wrote:
> - I don't like the name CAllocator. Whatever that C stands for it's
> ambiguous (Class, Cee, Caramel?).

Class. Better names welcome.

> - It may be only me but I _think_ it could be more useful to have a few
> specific interfaces then 1 fat CAllocator. I've come to dislike
> fat-interfaces with isSupported kludges but that's IMHO.

Yah it's a good idea. I'll think of it.

> - I see that shrink primitive didn't make it... Well, on the upside the
> primitives count is really low.

Yah. "Getting away with as little as you can" is my mantra :o).

> - In description of chooseAtRuntime:
> HeapBlock!chooseAtRuntime  --> HeapBlock!(Allocator, chooseAtRuntime)

Fixed and pushed.

https://github.com/andralex/phobos/blob/allocator/std/allocator.d


Andrei

On Saturday, 26 October 2013 at 15:00:12 UTC, Andrei Alexandrescu wrote:

> I think it's a commonly-used convention.

Is this something that comes from C++ which doesn't have explicit abstract classes and interfaces in the same sense that D, Java and C# does?

I dislike this as much as I dislike adding or appending m_ or _ for instance variables.

--
/Jacob Carlborg

On Sunday, 27 October 2013 at 06:15:52 UTC, Andrei Alexandrescu wrote:

> Class. Better names welcome.

Allocator. Or we could call CAllocator AllocatorBase and call CAllocatorImpl Allocator. It depends on which of these two classes is most likely to be used in API's. I think the one most likely to be used should be called Allocator.

Other names could be DynamicAllocator or RuntimeAllocator.

--
/Jacob Carlborg

On Sunday, 27 October 2013 at 06:15:52 UTC, Andrei Alexandrescu wrote:
> On 10/25/13 12:19 PM, Dmitry Olshansky wrote:
>> - I don't like the name CAllocator. Whatever that C stands for it's
>> ambiguous (Class, Cee, Caramel?).
>
> Class. Better names welcome.

I think DynamicAllocator would be a better name than CAllocator, but regardless, I think they're both pretty bad. However, I think it's indicative of a deeper problem with the interface chosen here: CAllocator is probably a kind of god object.

Like Dmitry, I think using `interface`s (maybe `wrap` can be leveraged for the adaptation role[1]) is an approach worth investigating. It lets the library statically enforce that it gets the functionality it needs as opposed to having to raise a runtime error, while still allowing the caller to implement that functionality dynamically (urgh, reaching for words!).

[1] Assuming `wrap` works on structs.

On 2013-10-26 17:01, Andrei Alexandrescu wrote:

> I think it's a commonly-used convention.

Any book, covering the topic, will say that mangling types in names is bad practice.

We don't use this naming convention anywhere in Phobos.

-- 
/Jacob Carlborg

On 10/26/13 8:00 AM, Andrei Alexandrescu wrote:
> 3. Mallocator could also implement these on Posix:
> http://man7.org/linux/man-pages/man3/posix_memalign.3.html. However,
> Windows requires a specific call for deallocating aligned memory. To
> accommodate both portably, we leave Mallocator as is and create
> AlignedMallocator that uses the _aligned_* family on Windows and the
> respective functions on Posix. On Windows, allocate() requests would
> pass a default of platformSize (i.e. 16 I suspect) to _aligned_malloc.

Just implemented AlignedMallocator and pushed.

http://erdani.com/d/phobos-prerelease/std_allocator.html#.AlignedMallocator

Untested on Windows.


Andrei