On Friday, 3 October 2014 at 09:24:30 UTC, Joseph Rushton
Wakeling wrote:
Won't that potentially fail based on the question of what the
input is? What if you're calling
Input has to be strictly pure. :)
On Friday, 3 October 2014 at 08:34:27 UTC, Ola Fosheim Grøstad
wrote:
Maybe you could do this as some kind of implicit range of
"formatting references" so that you can iterate over it in two
passes and save a heap allocation for situations where
traversal is cheap (fits in level 1 cache):
1.
On Friday, 3 October 2014 at 01:57:37 UTC, H. S. Teoh via
Digitalmars-d wrote:
The idea being that a call like `formattedWrite("%d", n)` is
far more
likely to be reused in other places in the program, than the
specific
format string "You have %d items in mailbox %s" and that
specific
combinatio
"H. S. Teoh via Digitalmars-d" wrote:
> On Sat, Sep 27, 2014 at 01:06:24PM +0200, Andrej Mitrovic via Digitalmars-d
> wrote:
>> On 9/27/14, H. S. Teoh via Digitalmars-d wrote:
>>> writefln!"...format string here"(... /* arguments here */);
>>
>> Mmm, I like this. It would be one of those ki
On Fri, Oct 03, 2014 at 12:04:23AM +, bearophile via Digitalmars-d wrote:
> H. S. Teoh:
>
> >So this new syntax can be implemented alongside the existing syntax
> >and people can gradually migrate over from purely-runtime format
> >strings to compile-time, statically-checked format strings.
>
H. S. Teoh:
So this new syntax can be implemented alongside the existing
syntax and people can gradually migrate over from
purely-runtime format strings to compile-time,
statically-checked format strings.
Very good.
D has a static type system, unlike Python/Ruby/etc but D printing
functions
" arguments but " ~ args.length.stringof ~
" are supplied");
// For now, we just forward it to the runtime format
implementation.
// The eventual goal is to only depend on formatting
On Thursday, 2 October 2014 at 20:42:16 UTC, Paulo Pinto wrote:
The Gc type is gone as of this week.
https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-09-30.md
Thanks, apparently they do it because they want to make a proper
tracing gc available later:
https://gi
eally solve the issues a @nogc version of D
should be able to deal with beyond having built-in unique_ptr
style semantics?
Or?
The Gc type is gone as of this week.
https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2014-09-30.md
counting.
The downgrade method can be used to create a non-owning Weak
pointer to the box. A Weak pointer can be upgraded to an Rc
pointer, but will return None if the value has already been
freed.»
So… they don't really solve the issues a @nogc version of D
should be able to deal with b
On Thursday, 2 October 2014 at 18:52:18 UTC, Paulo Pinto wrote:
Rust makes use of the type system and the borrow checker to
validate how the pointers are being used.
The usual errors when dealing with pointers are compile time
errors in Rust.
They constrain usage so that you cannot share mutab
On Thursday, 2 October 2014 at 13:29:58 UTC, Ola Fosheim Grøstad
wrote:
On Thursday, 2 October 2014 at 11:41:14 UTC, Jacob Carlborg
wrote:
I haven't really thought how it could be implemented but I was
hoping that the caller could magically decide the allocation
strategy instead of the callee.
On Thursday, 2 October 2014 at 11:41:14 UTC, Jacob Carlborg wrote:
I haven't really thought how it could be implemented but I was
hoping that the caller could magically decide the allocation
strategy instead of the callee. It looks like Rust is doing
something like that but I haven't looked at
On Wednesday, 1 October 2014 at 15:48:39 UTC, Oren Tirosh wrote:
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz
wrote:
(I'll try to make a sketch on how this can be implemented in
another post.)
Do elaborate!
Here's an example implementation of what I have in mind (totally
untes
On 02/10/14 11:41, "Ola Fosheim Grøstad"
" wrote:
That would be better, but how do you deal with "bar(foo())" ? Context
dependent instantiation is a semantic challenge when you also have
overloading, but I guess you can get somewhere if you make whole program
optimization mandatory and use a st
On Thursday, 2 October 2014 at 06:29:24 UTC, Jacob Carlborg wrote:
@gc a = foo(); // a contains an instance of Foo allocated with
the GC
@rc b = foo(); // b contains an instance of Foo allocated with
the RC allocator
That would be better, but how do you deal with "bar(foo())" ?
Context depend
On 01/10/14 19:25, Oren T wrote:
The idea is that the unique property is very short-lived: the caller
immediately assigns it to a pointer of the appropriate policy: either RC
or GC. This keeps the callee agnostic of the chosen policy and does not
require templating multiple versions of the code.
On 10/1/14, 1:56 PM, "Marc Schütz" " wrote:
On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu wrote:
On 10/1/14, 8:48 AM, Oren Tirosh wrote:
Bingo. Have some way to mark the function return type as a unique
pointer.
I'm skeptical about this approach (though clearly we need to
On 10/1/14, 10:51 AM, H. S. Teoh via Digitalmars-d wrote:
But Sean's idea only takes strings into account. Strings aren't the only
allocated resource Phobos needs to deal with. So extrapolating from that
idea, each memory management struct (or whatever other aggregate we end
up using), say call i
On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu
wrote:
On 10/1/14, 8:48 AM, Oren Tirosh wrote:
Bingo. Have some way to mark the function return type as a
unique
pointer.
I'm skeptical about this approach (though clearly we need to
explore it for e.g. passing ownership of da
On Wednesday, 1 October 2014 at 15:48:39 UTC, Oren Tirosh wrote:
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz
wrote:
One problem with actually implementing this is that using
reference counting as a memory management policy requires extra
space for the reference counter in the obj
On Wednesday, 1 October 2014 at 18:37:50 UTC, Sean Kelly wrote:
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
But Sean's idea only takes strings into account. Strings
aren't the only
allocated resource Phobos needs to deal with. So extrapolating
from that
i
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
But Sean's idea only takes strings into account. Strings aren't
the only
allocated resource Phobos needs to deal with. So extrapolating
from that
idea, each memory management struct (or whatever other
aggregate
compatibility).
This all... looks arcane. I'm not sure how it can even made to
work if user code just uses "auto". -- Andrei
At the moment, @nogc code can't call any function returning a
pointer. Under this scheme @nogc is allowed to call either code
that returns an explicitl
compatibility).
This all... looks arcane. I'm not sure how it can even made to
work if user code just uses "auto". -- Andrei
At the moment, @nogc code can't call any function returning a
pointer. Under this scheme @nogc is allowed to call either code
that returns an explicitly RC ty
On Wednesday, 1 October 2014 at 17:53:43 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu
via Digitalmars-d wrote:
On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
>29-Sep-2014 14:49, Andrei Alexandrescu пишет:
>>auto setExtension(MemoryManageme
On Wed, Oct 01, 2014 at 02:51:08AM -0700, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
> >29-Sep-2014 14:49, Andrei Alexandrescu пишет:
> >>auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2
> >>ext)
> >>if (...)
> >>{
> >> st
On 10/1/14, 10:25 AM, Oren T wrote:
The idea is that the unique property is very short-lived: the caller
immediately assigns it to a pointer of the appropriate policy: either RC
or GC. This keeps the callee agnostic of the chosen policy and does not
require templating multiple versions of the cod
On Wednesday, 1 October 2014 at 17:13:38 UTC, Andrei Alexandrescu
wrote:
On 10/1/14, 8:48 AM, Oren Tirosh wrote:
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz
wrote:
[...]
I'm convinced this isn't necessary. Let's take
`setExtension()` as an
example, standing in for any of a clas
On 10/1/14, 8:48 AM, Oren Tirosh wrote:
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote:
[...]
I'm convinced this isn't necessary. Let's take `setExtension()` as an
example, standing in for any of a class of similar functions. This
function allocates memory, returns it, and aba
On 10/1/14, 7:03 AM, Sean Kelly wrote:
So let the user supply a scratch buffer that will hold the result? With
the RC approach we're still allocating, they just aren't built-in
slices, correct?
Correct. -- Andrei
On 10/1/14, 6:52 AM, Sean Kelly wrote:
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Is this for exposition purposes or actually how you expect it to work?
That's pretty much what it would take. The key here is that RCString
i
Oren Tirosh:
Bingo. Have some way to mark the function return type as a
unique pointer. This does not imply full-fledged unique pointer
type support in the language
Let's have full-fledged memory zones tracking in the D type
system :-)
Bye,
bearophile
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote:
[...]
I'm convinced this isn't necessary. Let's take `setExtension()`
as an example, standing in for any of a class of similar
functions. This function allocates memory, returns it, and
abandons it; it gives up ownership of the
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Quite honestly, I can't imagine how I could write a template
function in D that needs to work with this approach.
You mean write a function that accepts a memory management
policy,
On Wednesday, 1 October 2014 at 08:55:55 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 9:10 AM, Sean Kelly wrote:
Is this for exposition purposes or actually how you expect it
to work?
That's pretty much what it would take. The key here is that
RCString is almost a drop-in replacement for str
On Wednesday, 1 October 2014 at 10:10:51 UTC, Robert burner
Schadek wrote:
lately when working on std.string I run into problems making
stuff nogc as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Also I would like a version of decode that takes the string not
as
On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote:
On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
Ideas, Suggestions ... ? any takers?
You can use .byDchar instead, which is nothrow @nogc.
Being forced out of using exception just to be able to have the
magic "@nogc
On Wednesday, 1 October 2014 at 10:51:25 UTC, Walter Bright wrote:
On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
Ideas, Suggestions ... ? any takers?
You can use .byDchar instead, which is nothrow @nogc.
thanks, I will try that.
On Wednesday, 1 October 2014 at 09:52:46 UTC, Andrei Alexandrescu
wrote:
On 9/30/14, 12:10 PM, "Marc Schütz" " wrote:
I would argue that GC is at its core _only_ a memory management
strategy. It just so happens that the one in D's runtime also
comes with
an allocator, with which it is tightly i
On 10/1/2014 3:10 AM, Robert burner Schadek wrote:
Ideas, Suggestions ... ? any takers?
You can use .byDchar instead, which is nothrow @nogc.
lately when working on std.string I run into problems making
stuff nogc as std.utf.decode is not nogc.
https://issues.dlang.org/show_bug.cgi?id=13458
Also I would like a version of decode that takes the string not
as ref.
Something like:
bool decode2(S,C)(S str, out C ret, out size_t
On 9/30/14, 10:46 PM, "Nordlöw" wrote:
On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu wrote:
Back when I've first introduced RCString I hinted that we have a
larger strategy in mind. Here it is.
Slightly related :)
https://github.com/D-Programming-Language/phobos/pull/2573
On 9/30/14, 6:53 PM, Manu via Digitalmars-d wrote:
I generally like the idea, but my immediate concern is that it implies
that every function that may deal with allocation is a template.
This interferes with C/C++ compatibility in a pretty big way. Or more
generally, the idea of a lib. Does this
On 9/30/14, 12:10 PM, "Marc Schütz" " wrote:
I would argue that GC is at its core _only_ a memory management
strategy. It just so happens that the one in D's runtime also comes with
an allocator, with which it is tightly integrated. In theory, a GC can
work with any (and multiple) allocators, and
On 9/30/14, 11:06 AM, Dmitry Olshansky wrote:
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2
ext)
if (...)
{
static if (mmp == gc) alias S = string;
else alias S = RCString;
S result;
...
return result
y new
functionality to Phobos.
Otherwise, you still have the situation where a given D
library doesn't allow the user to select a memory management scheme, and
internally calls Phobos functions with the default settings.
Correct.
So this
still doesn't solve the problem that tod
On 9/30/14, 9:49 AM, Johannes Pfau wrote:
I guess my point is that although RC is useful in some cases output
ranges / sink delegates / pre-allocated buffers are still necessary in
other cases and RC is not the solution for _everything_.
Agreed.
As Manu often pointed out sometimes you do not
On 9/30/14, 7:07 AM, John Colvin wrote:
Instead of adding a new template parameter to every function (which
won't necessarily play nicely with existing IFTI and variadic
templates), why not allow template modules?
Nice idea, but let's try and explore possibilities within the existing
rich lang
On 9/29/14, 1:07 PM, Uranuz wrote:
1. As far as I understand allocation and memory management of
entities like class (Object), dynamic arrays and associative
arrays is part of language/ runtime. What is proposed here is
*fix* to standart library. But that allocation and MM happening
via GC is not
On 9/29/14, 3:11 PM, Freddy wrote:
Internally we should have something like:
---
template String(MemoryManagementPolicy mmp=gc){
/++ ... +/
}
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1
path, R2 ext)
if (...)
{
auto result=String!mmp();
/++ +/
}
or may
On 9/30/14, 9:10 AM, Sean Kelly wrote:
On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu wrote:
The policy is a template parameter to functions in Phobos (and
elsewhere), and informs the functions e.g. what types to return.
Consider:
auto setExtension(MemoryManagementPolicy mmp
On 9/29/14, 11:44 AM, Shammah Chancellor wrote:
I don't like the idea of having to pass in template parameters
everywhere -- even for allocators. Is there some way we could have
"allocator contexts"?
E.G.
with( auto allocator = ReferencedCounted() )
{
auto foo = setExtension("hello", "tx
On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu
wrote:
Back when I've first introduced RCString I hinted that we have
a larger strategy in mind. Here it is.
Slightly related :)
https://github.com/D-Programming-Language/phobos/pull/2573
On 29 September 2014 20:49, Andrei Alexandrescu via Digitalmars-d
wrote:
> [...]
>
> Destroy!
>
> Andrei
I generally like the idea, but my immediate concern is that it implies
that every function that may deal with allocation is a template.
This interferes with C/C++ compatibility in a pretty big
On Wednesday, 1 October 2014 at 01:26:45 UTC, Manu via
Digitalmars-d wrote:
On 30 September 2014 08:04, Andrei Alexandrescu via
Digitalmars-d
wrote:
On 9/29/14, 10:16 AM, Paulo Pinto wrote:
Personally, I would go just for (b) with compiler support for
increment/decrement removal, as I think
On 30 September 2014 08:04, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 9/29/14, 10:16 AM, Paulo Pinto wrote:
>>
>> Personally, I would go just for (b) with compiler support for
>> increment/decrement removal, as I think it will be too complex having to
>> support everything and this will co
On Tuesday, 30 September 2014 at 12:32:08 UTC, Ola Fosheim
Grøstad wrote:
...basic building blocks such as intrinsics to build your own
RC with compiler support sounds like a more interesting option.
I agree.
On Tuesday, 30 September 2014 at 20:13:38 UTC, Paulo Pinto wrote:
Am 30.09.2014 14:55, schrieb "Ola Fosheim Grøstad"
":
On Tuesday, 30 September 2014 at 12:51:25 UTC, Paulo Pinto
wrote:
It works when two big ifs come together.
- inside the same scope (e.g. function level)
- when the referec
Am 30.09.2014 14:55, schrieb "Ola Fosheim Grøstad"
":
On Tuesday, 30 September 2014 at 12:51:25 UTC, Paulo Pinto wrote:
It works when two big ifs come together.
- inside the same scope (e.g. function level)
- when the referece is not shared between threads.
While it is of limited applicabil
On Tuesday, 30 September 2014 at 19:10:19 UTC, Marc Schütz wrote:
I'm convinced this isn't necessary. Let's take `setExtension()`
as an example, standing in for any of a class of similar
functions. This function allocates memory, returns it, and
abandons it; it gives up ownership of the memory.
s are nice to have and use, and I will
definitely follow up with std.allocator. However, std.allocator
is not the key to a @nogc Phobos.
Agreed.
Nor are ranges. There is an attitude that either output ranges,
or input ranges in conjunction with lazy computation, would
solve the issue o
29-Sep-2014 14:49, Andrei Alexandrescu пишет:
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1 path, R2 ext)
if (...)
{
static if (mmp == gc) alias S = string;
else alias S = RCString;
S result;
...
return result;
}
Incredible code bloat? Boilerplate in eac
API that might potentially use a Phobos
function. Otherwise, you still have the situation where a given D
library doesn't allow the user to select a memory management scheme, and
internally calls Phobos functions with the default settings. So this
still doesn't solve the problem that today,
On Tuesday, 30 September 2014 at 16:49:48 UTC, Johannes Pfau
wrote:
I guess my point is that although RC is useful in some cases
output
ranges / sink delegates / pre-allocated buffers are still
necessary in
other cases and RC is not the solution for _everything_.
Yes, I'm hoping this is an
Am Tue, 30 Sep 2014 05:29:55 -0700
schrieb Andrei Alexandrescu :
>
> > Another thought: if we use a template parameter, what's the story
> > for virtual functions (e.g. Object.toString)? They can't be
> > templated.
>
> Good point. We need to think about that.
>
Passing buffers or sink delegat
Am Tue, 30 Sep 2014 05:23:29 -0700
schrieb Andrei Alexandrescu :
> On 9/30/14, 1:34 AM, Johannes Pfau wrote:
> > So you propose RC + global/thread local allocators as the solution
> > for all memory related problems as 'memory management is not
> > allocation'. And you claim that using output rang
On Monday, 29 September 2014 at 10:49:53 UTC, Andrei Alexandrescu
wrote:
The policy is a template parameter to functions in Phobos (and
elsewhere), and informs the functions e.g. what types to
return. Consider:
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1
path, R2 ext)
if
On 9/30/14, 7:13 AM, "Marc Schütz" " wrote:
On Tuesday, 30 September 2014 at 14:05:43 UTC, Foo wrote:
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei
Alexandrescu wrote:
On 9/30/14, 6:38 AM, Foo wrote:
This won't work because the type of "string" is different for RC vs.
GC. -- Andrei
Bu
On 9/30/14, 7:05 AM, Foo wrote:
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei
Alexandrescu wrote:
On 9/30/14, 6:38 AM, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of "let the user pick", but I would use a global
variable:
On Tuesday, 30 September 2014 at 14:05:43 UTC, Foo wrote:
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei
Alexandrescu wrote:
On 9/30/14, 6:38 AM, Foo wrote:
This won't work because the type of "string" is different for
RC vs. GC. -- Andrei
But it would work for phobos functions without
ucing it to
either one is a mistake. In hindsight this looks rather obvious
but it has caused me and many people better than myself a lot
of headache.
That said allocators are nice to have and use, and I will
definitely follow up with std.allocator. However, std.allocator
is not the key to a
On Tuesday, 30 September 2014 at 13:59:23 UTC, Andrei
Alexandrescu wrote:
On 9/30/14, 6:38 AM, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of "let the user pick", but I would use a
global
variable:
enum MemoryManagementPoli
On 9/30/14, 6:38 AM, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of "let the user pick", but I would use a global
variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceManagementPolicy.gc,
rc =
On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau
wrote:
What if I don't want automated memory _management_? What if I
want a
function to use a stack buffer? Or if I want to free manually?
Agreed. This is the common case we need to solve for, but this is
memory allocation, not mana
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of "let the user pick", but I would use a
global variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceManagementPolicy.gc,
rc = ResourceManagementPolicy.rc,
On Tuesday, 30 September 2014 at 13:38:43 UTC, Foo wrote:
I hate the fact that this will produce template bloat for each
function/method.
I'm also in favor of "let the user pick", but I would use a
global variable:
enum MemoryManagementPolicy { gc, rc, mrc }
immutable
gc = ResourceMan
On Tuesday, 30 September 2014 at 12:51:25 UTC, Paulo Pinto wrote:
It works when two big ifs come together.
- inside the same scope (e.g. function level)
- when the referece is not shared between threads.
While it is of limited applicability, Objective-C (and
eventually Swift) codebases prov
Am Tue, 30 Sep 2014 10:47:54 +
schrieb "Vladimir Panteleev" :
> On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau
> wrote:
> > What if I don't want automated memory _management_? What if I
> > want a
> > function to use a stack buffer? Or if I want to free manually?
> >
> > If I w
On Tuesday, 30 September 2014 at 12:32:08 UTC, Ola Fosheim
Grøstad wrote:
On Tuesday, 30 September 2014 at 12:02:10 UTC, Johannes Pfau
wrote:
...
> Also the idea exposed in this thread that release()/retain()
> is
purely arithmetic and can be optimized as such is quite wrong.
retain() is con
ive to people who find
C++ lacking in elegance.
Actually, creating a phobos light with nothrow, nogc, a light
runtime and basic building blocks such as intrinsics to build
your own RC with compiler support sounds like a more interesting
option.
I am really not interested in library provided a
On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau
wrote:
What if I don't want automated memory _management_? What if I
want a
function to use a stack buffer? Or if I want to free manually?
If I want std.string.toStringz to put the result into a
temporary stack
buffer your solution d
On 9/30/14, 3:41 AM, Peter Alexander wrote:
On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau wrote:
What if I don't want automated memory _management_? What if I want a
function to use a stack buffer? Or if I want to free manually?
Agreed. This is the common case we need to solve f
Am Mon, 29 Sep 2014 15:04:03 -0700
schrieb Andrei Alexandrescu :
> On 9/29/14, 10:16 AM, Paulo Pinto wrote:
> > Personally, I would go just for (b) with compiler support for
> > increment/decrement removal, as I think it will be too complex having to
> > support everything and this will complicate
On 30/09/14 14:29, Andrei Alexandrescu wrote:
Good point. We need to think about that.
Weren't all methods in Object supposed to be lifted out from Object anyway?
--
/Jacob Carlborg
On 9/30/14, 1:34 AM, Johannes Pfau wrote:
So you propose RC + global/thread local allocators as the solution for
all memory related problems as 'memory management is not allocation'.
And you claim that using output ranges / providing buffers / allocators
is not an option because it only works in
On 9/30/14, 3:47 AM, Vladimir Panteleev wrote:
On Tuesday, 30 September 2014 at 08:34:26 UTC, Johannes Pfau wrote:
What if I don't want automated memory _management_? What if I want a
function to use a stack buffer? Or if I want to free manually?
If I want std.string.toStringz to put the result
Am Mon, 29 Sep 2014 15:11:26 -0700
schrieb Andrei Alexandrescu :
> On 9/29/14, 10:25 AM, Jacob Carlborg wrote:
> > How does allocators fit in this? Will it be an additional argument
> > to the function. Or a separate stack that one can push and pop
> > allocators to?
>
> There would be one alloca
e it looks like implementing struts for standard lib (which
is not broken yet ;) ) in order to compensate behaviour of
runtime lib.
This really hits the nail on the head, and I think your other
comments and questions are also quite insightful.
IMO the proposal that started this thread, @nogc, and -vgc a
that
problem. When a function is annotated with @nogc there's
sufficient info to chose the correct implementation without any
parameters, it's already known whether we are instantiated from a
@nogc block or not.
On 2014-09-29 22:15:33 +, Andrei Alexandrescu said:
On 9/29/14, 11:44 AM, Shammah Chancellor wrote:
I don't like the idea of having to pass in template parameters
everywhere -- even for allocators.
I agree.
Is there some way we could have
"allocator contexts"?
E.G.
with( auto allocato
On 9/29/14, 3:43 PM, Dicebot wrote:
On Monday, 29 September 2014 at 22:18:38 UTC, Andrei Alexandrescu wrote:
Passing arrays by reference is plenty adequate with all memory
management strategies. You'll need to wait and see how the proposal
changes that, but if you naysay, back it up.
Resisting
On Monday, 29 September 2014 at 22:18:38 UTC, Andrei Alexandrescu
wrote:
Passing arrays by reference is plenty adequate with all memory
management strategies. You'll need to wait and see how the
proposal changes that, but if you naysay, back it up.
Resisting to go on meaningless argument on ot
On 9/29/14, 11:44 AM, Shammah Chancellor wrote:
I don't like the idea of having to pass in template parameters
everywhere -- even for allocators.
I agree.
Is there some way we could have
"allocator contexts"?
E.G.
with( auto allocator = ReferencedCounted() )
Don't confuse memory allocatio
ight this looks rather obvious but it has caused me and many people better
than myself a lot of headache.
That said allocators are nice to have and use, and I will definitely follow up
with std.allocator. However, std.allocator is not the key to a @nogc Phobos.
Nor are ranges. There is an attit
On 9/29/14, 3:11 PM, Freddy wrote:
Internally we should have something like:
---
template String(MemoryManagementPolicy mmp=gc){
/++ ... +/
}
auto setExtension(MemoryManagementPolicy mmp = gc, R1, R2)(R1
path, R2 ext)
if (...)
{
auto result=String!mmp();
/++ +/
}
or may
ucing it to
either one is a mistake. In hindsight this looks rather obvious
but it has caused me and many people better than myself a lot
of headache.
That said allocators are nice to have and use, and I will
definitely follow up with std.allocator. However, std.allocator
is not the key to a
On 9/29/14, 10:25 AM, Jacob Carlborg wrote:
How does allocators fit in this? Will it be an additional argument to
the function. Or a separate stack that one can push and pop allocators to?
There would be one allocator per thread (changeable) deferring to a
global interlocked allocator. Most al
On 9/29/14, 10:16 AM, Paulo Pinto wrote:
Personally, I would go just for (b) with compiler support for
increment/decrement removal, as I think it will be too complex having to
support everything and this will complicate all libraries.
Compiler already knows (after inlining) that ++i and --i can
auto p1 = setExtension("hello", ".txt"); // fine, use gc
auto p2 = setExtension!gc("hello", ".txt"); // same
auto p3 = setExtension!rc("hello", ".txt"); // fine, use rc
So by default it's going to continue being business as usual,
but certain functions will allow passing in a (defaulted)
policy
801 - 900 of 1445 matches
Mail list logo
