On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer
wrote:
Sorry, I had this wrong. The [] on the left hand side is
actually part of the []= operator. But on the right hand side,
it simply is a [] operator, not tied to the =. I erroneously
thought the arr[] = ... syntax was specia
On Wednesday, 16 April 2014 at 03:26:24 UTC, Meta wrote:
This would go fairly well with Andrei's idea of passing true or
false to an attribute to enable or disable it.
@gc(false) void fun() {}
I don't like this because it's hard to read. It's a bad idea.
Never use booleans in interfaces lik
On Tuesday, 15 April 2014 at 15:59:31 UTC, Steven Schveighoffer
wrote:
Requiring it simply adds unneeded hoops through which you must
jump, the left hand side denotes the operation, the right hand
side does not
Unfortunately, this particular operation is denoted by both sides.
Note -- it woul
On Tuesday, 15 April 2014 at 23:54:24 UTC, Matej Nanut via
Digitalmars-d wrote:
This shouldn't be a problem if you plonk @nogc: at the top of
your own file, as it won't compile anymore if you try to call
@gc functions.
It is a problem if you are allowed to override @nogc with @gc,
which is wh
On Wednesday, 16 April 2014 at 08:46:56 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 15 April 2014 at 23:54:24 UTC, Matej Nanut via
Digitalmars-d wrote:
This shouldn't be a problem if you plonk @nogc: at the top of
your own file, as it won't compile anymore if you try to call
@gc functions.
It
On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
I don't believe users hesitant to use D will suddenly come to D
now that there is a @nogc attribute. I also don't believe they
want to avoid the GC, even if they say they do. I believe what
they really want is to have an alternative to
On Wednesday, 16 April 2014 at 09:03:22 UTC, JN wrote:
I'd have to agree. I doubt @nogc will change anything, people
will just start complaining about limitations of @nogc (no
array concat, having to use own libraries which may be
incompatible with phobos). The complaints mostly come from the
On Monday, April 14, 2014 20:47:06 Brad Roberts via Digitalmars-d wrote:
> Another flurry of bounces floated through today (which I handled by removing
> the suspensions, again). The only practical choice is a fairly intrusive
> one. I've enabled the from_is_list option, meaning that the 'from'
Thank you, I'm all set now.
On Wednesday, 16 April 2014 at 00:51:37 UTC, Brad Roberts via
Digitalmars-d wrote:
I've kicked things a little, but need to figure out better why
it didn't go out on it's own.
On 4/15/14, 5:26 PM, Kevin Lamonte via Digitalmars-d wrote:
I am trying to reset my passw
JN:
I doubt @nogc will change anything, people will just start
complaining about limitations of @nogc
Having a way to say "this piece of program doesn't cause heap
activity" is quite useful for certain piece of code. It makes a
difference in both performance and safety.
But not being able to
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Walter, the DIP has a funny creation date.
On Wed, Apr 16, 2014 at 01:58:32AM -0700, Jonathan M Davis via Digitalmars-d
wrote:
> On Monday, April 14, 2014 20:47:06 Brad Roberts via Digitalmars-d wrote:
> > Another flurry of bounces floated through today (which I handled by
> > removing the suspensions, again). The only practical choice is
On Wednesday, 16 April 2014 at 09:17:48 UTC, Ola Fosheim Grøstad
wrote:
On Wednesday, 16 April 2014 at 09:03:22 UTC, JN wrote:
I'd have to agree. I doubt @nogc will change anything, people
will just start complaining about limitations of @nogc (no
array concat, having to use own libraries which
On Wednesday, 16 April 2014 at 06:59:30 UTC, Steve Teale wrote:
On Tuesday, 15 April 2014 at 16:02:33 UTC, Steven Schveighoffer
wrote:
Sorry, I had this wrong. The [] on the left hand side is
actually part of the []= operator. But on the right hand side,
it simply is a [] operator, not tied t
On 16 April 2014 19:03, JN via Digitalmars-d wrote:
> On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
>
>> I don't believe users hesitant to use D will suddenly come to D now that
>> there is a @nogc attribute. I also don't believe they want to avoid the
>> GC, even if they say they do.
On Tuesday, 15 April 2014 at 23:26:18 UTC, Marco Leise wrote:
Am Tue, 15 Apr 2014 22:38:48 +
schrieb "Jeroen Bollen" :
Does anyone know of any (preferably complete) XCB bindings for
D?
2 of the 2 people I know who looked into this decided that D
bindings for C bindings for X is a silly ex
On Wednesday, 16 April 2014 at 12:24:18 UTC, Jeroen Bollen wrote:
Surely people must have communicated with X in other ways than
the xlib in D?
I thought about doing XCB a few times but I keep going back to
xlib because it really isn't that bad.
On 4/16/14, Jonathan M Davis via Digitalmars-d
wrote:
> Yikes. This is making it much harder to read what comes from who what with
> "via Digitalmars-d" tacked onto the end of everyone's name.
Also, it's broken for some emails. For example this dforum post by
Ola: http://forum.dlang.org/post/twzy
On Tuesday, 15 April 2014 at 11:04:42 UTC, Daniel Murphy wrote:
"Manu via Digitalmars-d" wrote in
message
news:mailman.9.1397553786.2763.digitalmar...@puremagic.com...
Huh? Do methods work now? Since when?
Since I needed them for DDMD.
Is this[1] then out of date and I can interface wit
is there? if so, where is it? Also, I see dmd is written in C++
but still uses C style to do stuff eg, printf() instead of cout.
Is this why C++ libraries can increase a lot size (and
performance?) of executable which current style don't?
"asman" wrote in message news:maojdlxhbwuhxqrmv...@forum.dlang.org...
is there? if so, where is it? Also, I see dmd is written in C++ but still
uses C style to do stuff eg, printf() instead of cout. Is this why C++
libraries can increase a lot size (and performance?) of executable which
curre
On Wednesday, 16 April 2014 at 11:51:07 UTC, Manu via
Digitalmars-d wrote:
On 16 April 2014 19:03, JN via Digitalmars-d
wrote:
On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
I don't believe users hesitant to use D will suddenly come to
D now that
there is a @nogc attribute. I also
When looking at the success of Go it seems to me that it is
caused to a large extend by the kind of multi-threading Go offers
which is something like "spawn as many thousand threads as you
like".
Being able to spawn as many thousand threads as needed without
caring about it seems to be an imp
V Wed, 16 Apr 2014 13:32:45 +
asman via Digitalmars-d napsáno:
> is there? if so, where is it?
http://dlang.org/dstyle.html
V Wed, 16 Apr 2014 13:32:45 +
asman via Digitalmars-d napsáno:
> is there? if so, where is it?
sorry I post coding styles for D not for dmd
"Moritz Maxeiner" wrote in message
news:kvzwlecwougswrqka...@forum.dlang.org...
Is this[1] then out of date and I can interface with non-virtual methods?
Because that's what your post seems to imply (unless I misunderstood).
[1] http://dlang.org/cpp_interface.html
Yes. The best place to l
On 4/16/14, 2:03 AM, JN wrote:
On Wednesday, 16 April 2014 at 01:57:29 UTC, Mike wrote:
I don't believe users hesitant to use D will suddenly come to D now
that there is a @nogc attribute. I also don't believe they want to
avoid the GC, even if they say they do. I believe what they really
want
Am 16.04.2014 15:59, schrieb Bienlein:
When looking at the success of Go it seems to me that it is caused to a
large extend by the kind of multi-threading Go offers which is something
like "spawn as many thousand threads as you like".
Being able to spawn as many thousand threads as needed withou
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d.
It achieves exactly that - right now! Integration with
std.concurrency would be great, but at least for now it has an
API compatible replacement that can be merged la
Am 16.04.2014 16:16, schrieb Bienlein:
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d. It
achieves exactly that - right now! Integration with std.concurrency
would be great, but at least for now it has an API compat
"DanielKozákvia Digitalmars-d" wrote in message
news:mailman.99.1397656987.2763.digitalmar...@puremagic.com...
sorry I post coding styles for D not for dmd
They are similar.
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:
I still don't understand what you mean by "distributed".
Spawning 50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
On Wednesday, 16 April 2014 at 14:16:30 UTC, Bienlein wrote:
On Wednesday, 16 April 2014 at 14:06:13 UTC, Sönke Ludwig wrote:
I agree, but I also wonder why you still keep ignoring vibe.d.
It achieves exactly that - right now! Integration with
std.concurrency would be great, but at least for n
On Wednesday, 16 April 2014 at 14:00:24 UTC, Daniel Murphy wrote:
"Moritz Maxeiner" wrote in message
news:kvzwlecwougswrqka...@forum.dlang.org...
Is this[1] then out of date and I can interface with
non-virtual methods? Because that's what your post seems to
imply (unless I misunderstood).
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Good start.
However, what is still an open issue is that @nogc can be stopped
by allocations in another thread. We nee
Am 16.04.2014 16:43, schrieb Bienlein:
On Wednesday, 16 April 2014 at 14:21:03 UTC, Sönke Ludwig wrote:
I still don't understand what you mean by "distributed". Spawning
50.000 tasks:
import vibe.core.core;
import std.stdio;
void main()
{
foreach (i; 0 .. 50_000)
On Wednesday, 16 April 2014 at 10:13:06 UTC, bearophile wrote:
JN:
I doubt @nogc will change anything, people will just start
complaining about limitations of @nogc
Having a way to say "this piece of program doesn't cause heap
activity" is quite useful for certain piece of code. It makes a
On Saturday, 14 December 2013 at 15:16:50 UTC, Jacob Carlborg
wrote:
On 2013-12-14 15:53, Steven Schveighoffer wrote:
I realize this is really old, and I sort of dropped off the D
cliff
because all of a sudden I had 0 extra time.
But I am going to get back into working on this (if it's still
What about namespaces?
I often see, that D developers say something like "remove
allocations from std lib", and it seems, that the main reason to
do it is eliminate gc calls.
What about the idea, that local objects do not use gc at all?
Maby, all temporary variables can be destroyed just like in C++,
when out of scope w
This is one of the things the `scope` storage class on local
variables can do, but since it isn't implemented properly, it is
not memory safe and thus its usage is deprecated.
I really really really want to see scope be fully implemented,
including not allowing a reference to the variable to e
On Wednesday, 16 April 2014 at 16:51:57 UTC, Adam D. Ruppe wrote:
This is one of the things the `scope` storage class on local
variables can do, but since it isn't implemented properly, it
is not memory safe and thus its usage is deprecated.
I really really really want to see scope be fully im
Construction and Initialisation
===
As previously discussed, it's annoying having the conflation of
construction and initialisation. It leads to two options:
1) construction is initialisation. This is nasty for some ranges
where the range is truly destructive, amon
"Moritz Maxeiner" wrote in message
news:nadswyordzxwa...@forum.dlang.org...
That sounds very cool, I've had a look at [1] and [2], which seem to be
the two files with the new C++ class interfacing. As far as I could tell,
you need to create any instances of C++ classes with C++ code / you
"monnoroch" wrote in message news:kqjrnqecnfejmiwnk...@forum.dlang.org...
What about namespaces?
Zero support currently.
On Wednesday, 16 April 2014 at 17:14:55 UTC, John Colvin wrote:
I would love to have a "scope" that works properly, with or
without blade-guards to stop me chopping off my hands when the
function returns.
The blade guards are the important part though: if you just want
the allocation pattern,
On Tuesday, 15 April 2014 at 21:41:37 UTC, Brad Anderson wrote:
Yes, please. Too few of the attributes have inverse attributes.
Being able to stick your defaults up at the top of your module
and then overriding them only when needed would be very nice
and make the code a lot more tidy.
I act
On Wednesday, 16 April 2014 at 17:16:07 UTC, Daniel Murphy wrote:
If you are using 'new' in C++ it will not use D's GC heap,
unless you overrode the global 'new' operator or something.
Which, if you did, would enable you to use C++ classes from D
somewhat transparently, no?
Am 16.04.2014 18:51, schrieb Adam D. Ruppe:
This is one of the things the `scope` storage class on local variables
can do, but since it isn't implemented properly, it is not memory safe
and thus its usage is deprecated.
I really really really want to see scope be fully implemented, including
not
On Wednesday, 16 April 2014 at 17:22:02 UTC, Gary Willoughby
wrote:
On Tuesday, 15 April 2014 at 21:41:37 UTC, Brad Anderson wrote:
Yes, please. Too few of the attributes have inverse attributes.
Being able to stick your defaults up at the top of your module
and then overriding them only when
On 4/16/2014 2:03 AM, JN wrote:
I'd have to agree. I doubt @nogc will change anything, people will just start
complaining about limitations of @nogc (no array concat, having to use own
libraries which may be incompatible with phobos). The complaints mostly come
from the fact that D wants to offer
On 4/16/2014 4:50 AM, Manu via Digitalmars-d wrote:
I am convinced that ARC would be acceptable,
ARC has very serious problems with bloat and performance.
Every time a copy is made of a pointer, the ref count must be dealt with,
engendering bloat and slowdown. C++ deals with this by providing
On 4/16/2014 8:01 AM, qznc wrote:
However, what is still an open issue is that @nogc can be stopped by allocations
in another thread. We need threads which are not affected by stop-the-world. As
far as I know, creating threads via pthreads C API directly achieves that, but
integration with @nogc
On 4/16/2014 1:49 AM, "Ola Fosheim Grøstad"
" wrote:
Btw, I think you should add @noalloc also which prevents both new and malloc. It
would be useful for real time callbacks, interrupt handlers etc.
Not practical. malloc() is only one way of allocating memory - user defined
custom allocators a
On Wednesday, 16 April 2014 at 17:39:32 UTC, Walter Bright wrote:
Not practical. malloc() is only one way of allocating memory -
user defined custom allocators are commonplace.
What I want is a __trait that scans for all call expressions in a
particular function and returns all those functions
Walter Bright:
Not practical. malloc() is only one way of allocating memory -
user defined custom allocators are commonplace.
OK, then I'll have to close my ER about @noheap.
Bye,
bearophile
On Wed, 2014-04-16 at 13:59 +, Bienlein via Digitalmars-d wrote:
> When looking at the success of Go it seems to me that it is
> caused to a large extend by the kind of multi-threading Go offers
> which is something like "spawn as many thousand threads as you
> like".
A critically important
On Wed, 2014-04-16 at 16:06 +0200, Sönke Ludwig via Digitalmars-d wrote:
[…]
>
> I agree, but I also wonder why you still keep ignoring vibe.d. It
> achieves exactly that - right now! Integration with std.concurrency
> would be great, but at least for now it has an API compatible
> replacement
TL;DR
Here is some under documented, incomplete and untested code.
CAVEAT IMPLEMENTOR: some details have been omitted to keep things brief!
struct someRange
{
ulong seq;
bool fresh = true;
long line;
dchar front;
// and lets just pretend that there is
On Monday, 17 March 2014 at 17:39:41 UTC, Denis Shelomovskij
wrote:
Multidimensional arrays indexing and slicing syntax is finally
added [1] (thanks to Kenji Hara). So it was a good cause to
update my multidimensional arrays library implementation and
add support for the new syntax. So here we
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Some initial thoughts:
* Is it perhaps too early to introduce this? We don't have
allocators yet, so it can be quite h
Peter Alexander:
* Does @nogc => nothrow? If I'm not mistaken, throw must
through a GC-allocated Throwable.
* If the above is true, does that mean exceptions cannot be
used at all in @nogc code?
This should work:
void foo() @nogc nothrow {
static const err = new Error("error");
thr
Stefan Frijters:
First of all, thank you very much for making such nice
additions to D available for general use. I finally got around
to giving this a spin.
Recently I've shown a possible usage example of the
multidimensional arrays indexing and slicing syntax:
http://forum.dlang.org/threa
This make me proud of being an engineer:
http://www.wimp.com/powerquadcopters/
I wonder what type system they used when modelling the algorithms
;)
Excuse me for posting this a bit of topic...I just had to share
this experience with you all brilliant people.
Le 16/04/2014 00:38, Jeroen Bollen a écrit :
Does anyone know of any (preferably complete) XCB bindings for D?
You can take a look to my bindings :
https://github.com/D-Quick/XCB
As I don't use them for the moment I am not sure there is no mistake in
it, but it sure that it can be build witho
On Wednesday, 16 April 2014 at 19:53:01 UTC, bearophile wrote:
Peter Alexander:
* Does @nogc => nothrow? If I'm not mistaken, throw must
through a GC-allocated Throwable.
* If the above is true, does that mean exceptions cannot be
used at all in @nogc code?
This should work:
void foo() @n
On Wednesday, 16 April 2014 at 20:04:38 UTC, Nordlöw wrote:
This make me proud of being an engineer:
http://www.wimp.com/powerquadcopters/
I wonder what type system they used when modelling the
algorithms ;)
Excuse me for posting this a bit of topic...I just had to share
this experience wit
In a library I was writing I was in need of the following:
Write code that takes a function pointer/delegate and an array of
strings that calls the function by parsing each string into the
given functions arguments. And if the function has a return
value, the code will also return the functio
On Wednesday, 16 April 2014 at 19:44:19 UTC, Peter Alexander
wrote:
On Tuesday, 15 April 2014 at 17:01:38 UTC, Walter Bright wrote:
http://wiki.dlang.org/DIP60
Start on implementation:
https://github.com/D-Programming-Language/dmd/pull/3455
Some initial thoughts:
* Is it perhaps too early t
On Wednesday, 16 April 2014 at 20:29:17 UTC, bearophile wrote:
Peter Alexander:
(I assume that nothrow isn't meant to be there?)
In D nothrow functions can throw errors.
Of course, ignore me :-)
You could do something like this:
void foo() @nogc
{
static err = new Error();
if (bad
Peter Alexander:
err.setError("badthing happened");
And that is usually written:
err.msg = "badthing happened";
Bye,
bearophile
Peter Alexander:
(I assume that nothrow isn't meant to be there?)
In D nothrow functions can throw errors.
You could do something like this:
void foo() @nogc
{
static err = new Error();
if (badthing)
{
err.setError("badthing happened");
throw err;
}
}
To b
Well, most of the new games (Unity3D) are done in C# nowadays
and people live with it even though game development is one of
the biggest C++ loving and GC hating crowd there is.
Unity3D the engine is written primarily in C++, not C#.
The Unity editor and gameplay code is written in C# because
On 4/16/2014 12:44 PM, Peter Alexander wrote:
* Is it perhaps too early to introduce this? We don't have allocators yet, so it
can be quite hard to avoid the GC in some situations.
Not that hard.
* Many Phobos functions use 'text' and 'format' in asserts. What should be done
about those?
Re
On Wednesday, 16 April 2014 at 17:39:32 UTC, Walter Bright wrote:
Not practical. malloc() is only one way of allocating memory -
user defined custom allocators are commonplace.
Not sure why this is not practical. If the custom allocators are
in D then you should be able to track all the way do
Am 16.04.2014 22:49, schrieb froglegs:
Well, most of the new games (Unity3D) are done in C# nowadays and
people live with it even though game development is one of the biggest
C++ loving and GC hating crowd there is.
Unity3D the engine is written primarily in C++, not C#.
The Unity editor an
On 04/16/2014 10:10 PM, Peter Alexander wrote:
However, that raises a second question: since err is allocated when a
new thread is created, does that mean @nogc functions cannot create
threads in the presence of such static initialisation?
This does not allocate on the GC heap.
I am really looking forward to .NET Native becoming widespread.
Then this type of comparisons (C# vs C++) will be quite
different.
I don't think it will make a major difference. Taking a GC based
language and giving it a native compiler doesn't automatically
make it performance competiti
On 4/16/2014 2:14 PM, "Ola Fosheim Grøstad"
" wrote:
If the custom allocators are in D then you
should be able to track all the way down to malloc.
malloc is hardly the only storage allocator.
On Wed, 16 Apr 2014 04:50:51 -0700, Manu via Digitalmars-d
wrote:
I am convinced that ARC would be acceptable, and I've never heard anyone
suggest any proposal/fantasy/imaginary GC implementation that would be
acceptable...
In complete absence of a path towards an acceptable GC implementation
On Wednesday, 16 April 2014 at 22:34:35 UTC, Walter Bright wrote:
malloc is hardly the only storage allocator.
Except for syscalls such as brk/sbrk, which ones are you thinking
of?
On 4/16/2014 3:45 PM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 16 April 2014 at 22:34:35 UTC, Walter Bright wrote:
malloc is hardly the only storage allocator.
Except for syscalls such as brk/sbrk, which ones are you thinking of?
I've written several myself that do not use malloc. Even t
On 4/16/2014 3:42 PM, Adam Wilson wrote:
ARC may in fact be the most advantageous for a specific use case, but that in no
way means that all use cases will see a performance improvement, and in all
likelihood, may see a decrease in performance.
Right on. Pervasive ARC is very costly, meaning th
Walter Bright:
malloc is hardly the only problem people will encounter with
realtime callbacks. You'll want to avoid disk I/O, network
access, etc., too.
It seems a good idea to offer a way to extend the type system
with new semantically meaningful annotations in user code. (Koka
language do
On Wednesday, 16 April 2014 at 15:32:05 UTC, sclytrack wrote:
What about adding custom annotations that don't do any checking
by
itself. Like when @nogc doesn't actually verify that the
~ is not used for strings.
void hello() require(@nogc)
{
}
Just a verification by the compiler that you use
On 2014-04-16 23:20:07 +, Walter Bright said:
On 4/16/2014 3:42 PM, Adam Wilson wrote:
ARC may in fact be the most advantageous for a specific use case, but
that in no
way means that all use cases will see a performance improvement, and in all
likelihood, may see a decrease in performance
On 4/16/2014 5:06 PM, Michel Fortin wrote:
It's not just ARC. As far as I know, most GC algorithms require some action to
be taken when changing the value of a pointer. If you're seeing this as
unnecessary bloat, then there's not much hope in a better GC for D either.
Yeah, those are called wri
"John Colvin" wrote in message news:qbwxwxekffpegmbck...@forum.dlang.org...
Which, if you did, would enable you to use C++ classes from D somewhat
transparently, no?
Potentially, yes. You'd need to be very careful that there was always a
gc-visible reference to the class to keep it alive, s
On Wednesday, 16 April 2014 at 22:42:23 UTC, Adam Wilson wrote:
Long story short, Tracing vs. Ref-counting are algorithmic
duals and therefore do not significantly differ. My read of the
article is that all the different GC styles are doing is
pushing the cost somewhere else.
All memory mana
On 17 April 2014 03:37, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 4/16/2014 4:50 AM, Manu via Digitalmars-d wrote:
>
>> I am convinced that ARC would be acceptable,
>>
>
> ARC has very serious problems with bloat and performance.
>
This is the first I've heard of
On 17 April 2014 08:42, Adam Wilson via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On Wed, 16 Apr 2014 04:50:51 -0700, Manu via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
> I am convinced that ARC would be acceptable, and I've never heard anyone
>>
>> suggest any proposal/
On 17 April 2014 09:20, Walter Bright via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 4/16/2014 3:42 PM, Adam Wilson wrote:
>
>> ARC may in fact be the most advantageous for a specific use case, but
>> that in no
>> way means that all use cases will see a performance improvement, and
On 17 April 2014 10:06, Michel Fortin via Digitalmars-d <
digitalmars-d@puremagic.com> wrote:
> On 2014-04-16 23:20:07 +, Walter Bright
> said:
>
> On 4/16/2014 3:42 PM, Adam Wilson wrote:
>>
>>> ARC may in fact be the most advantageous for a specific use case, but
>>> that in no
>>> way mea
On Wednesday, 16 April 2014 at 23:14:27 UTC, Walter Bright wrote:
On 4/16/2014 3:45 PM, "Ola Fosheim Grøstad" I've written
several myself that do not use malloc.
If it is shared or can call brk() it should be annotated.
Even the Linux kernel does not use malloc. Windows offers many
ways to al
On Thursday, 17 April 2014 at 03:14:21 UTC, Manu via
Digitalmars-d wrote:
Obviously, a critical part of ARC is the compilers ability to
reduce
redundant inc/dec sequences.
You need whole program opimization to do this well. Which I am
strongly in favour of, btw.
I've never heard of Obj-C us
It occurs to me that a central issue regarding the memory management
debate, and a major limiting factor with respect to options, is the fact
that, currently, it's impossible to tell a raw pointer apart from a gc
pointer.
Is this is a problem worth solving? And would it be as big an enabler to
add
96 matches
Mail list logo
