On 03/13/2014 07:40 PM, Vladimir Panteleev wrote:
Looks like most of these are on compiler bugs.
The only Phobos one is the std.getopt one, however its situation is
two abandoned patches and no clear goal as to what constitutes a
change worthy of marking the issue as fixed and paying out the
On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:
El 11/04/14 12:10, Walter Bright ha escrit:
but hey, now we have D.
Yeah, I like D far better than Java.
+1000
So do I. But for Java there is Hibernate, Hadoop, Cassandra, DI,
JSF, JMS, JTA, SOAP, REST, vert.x, Quartz, web
I moved the auto-tester to another host and domain name today. It now lives at:
https://auto-tester.puremagic.com/
There's a redirect in place from the old location. There's a reasonable chance I've forgotten to
update something somewhere. If you stumble across anything broken, please
On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote:
On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:
El 11/04/14 12:10, Walter Bright ha escrit:
but hey, now we have D.
Yeah, I like D far better than Java.
+1000
So do I. But for Java there is Hibernate, Hadoop,
Am 16.04.2014 11:05, schrieb Chris:
On Wednesday, 16 April 2014 at 08:21:37 UTC, Bienlein wrote:
On Tuesday, 15 April 2014 at 19:19:00 UTC, Jordi Sayol wrote:
El 11/04/14 12:10, Walter Bright ha escrit:
but hey, now we have D.
Yeah, I like D far better than Java.
+1000
So do I. But for
On Tuesday, 8 April 2014 at 21:44:24 UTC, Andrei Alexandrescu
wrote:
http://www.reddit.com/r/programming/comments/22jwcu/how_i_came_to_write_d/
Thanks, this was a fun read! :-)
I use vibe.d for a small server side application. It's quite
fast, although we haven't tested it on a larger scale yet. On
the downside, vibe.d's API is not quite intuitive, so it takes
a while to get used to it. But that might be down to the fact
that it's not easy to write an intuitive API
You may be on to something here.
On Tuesday, 15 April 2014 at 22:27:53 UTC, John Carter wrote:
I was contemplating why languages explode on to the scene or
not, and often
it comes down to a so called Killer App.
For Ruby, it was Rails.
The ability to construct optimally fast typesafe tuples
On 04/16/2014 01:55 PM, justme wrote:
You may be on to something here.
Maybe I should create a wanted feature list and get started. Any feature
you would like to see?
Can you give a concrete example of what features would be
easier if it was built-in?
My point is that multi-threading/concurrency should be very
simple. Go has channels and goroutines and that's it. That does
not make concurrency simple, but a lot simpler than when using
locks, semaphores,
On Wednesday, 16 April 2014 at 13:06:56 UTC, Bienlein wrote:
Can you give a concrete example of what features would be
easier if it was built-in?
My point is that multi-threading/concurrency should be very
simple. Go has channels and goroutines and that's it. That does
not make concurrency
On Wednesday, 16 April 2014 at 13:42:26 UTC, Chris wrote:
Maybe we should spawn a new thread for this discussion. I'm
sure this is of interest for everyone on this forum.
All right, here we go:
On 4/16/14, 1:47 AM, Brad Roberts wrote:
I moved the auto-tester to another host and domain name today. It now
lives at:
https://auto-tester.puremagic.com/
I hate to ask this just after a change already, but... how about moving
it to auto-tester.dlang.org? -- Andrei
On 4/16/14, 7:12 AM, Andrei Alexandrescu wrote:
On 4/16/14, 1:47 AM, Brad Roberts wrote:
I moved the auto-tester to another host and domain name today. It now
lives at:
https://auto-tester.puremagic.com/
I hate to ask this just after a change already, but... how about moving it to
I guess the place I'd start is with what CJ Date has been saying about
Tutorial D and how much you can rephrase into D.
In someways it's a very orthogonal concept, we tend to think of databases
as places where we store data.
What Date is saying is, no, they are collections of predicates and an
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if you are
thinking about new major features ?
On Wednesday, 16 April 2014 at 22:45:45 UTC, Adam Wilson wrote:
On Fri, 04 Apr 2014 07:35:18 -0700, Alexander Bothe
i...@alexanderbothe.com wrote:
On Monday, 31 March 2014 at 21:41:26 UTC, Théo Bueno wrote:
Mono-D seems pretty complete to me now, I was wondering if
you are thinking about new
On 4/15/14, 12:18 PM, Dicebot wrote:
On Tuesday, 15 April 2014 at 19:12:30 UTC, Steven Schveighoffer wrote:
int isthisok(int x, int y) @nogc
{
// need scratch space
int[] buf = new int[x * y];
scope(exit) GC.free(buf.ptr);
// perform some algorithm using buf
...
//
return
I am Eng. (Electrical Engineer) Fernando Parillo of University of
Cassino, Italy, author of several papers about sfloat24 math
library. I conceived this library, in the early of 2007 and this
library worked in stable manner in the middle of 2010, date of
publication of the first paper
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
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
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
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
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.
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
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 a
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
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
On 16 April 2014 19:03, JN via Digitalmars-d digitalmars-d@puremagic.comwrote:
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
On Tuesday, 15 April 2014 at 23:26:18 UTC, Marco Leise wrote:
Am Tue, 15 Apr 2014 22:38:48 +
schrieb Jeroen Bollen jbin...@gmail.com:
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
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
digitalmars-d@puremagic.com 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:
On Tuesday, 15 April 2014 at 11:04:42 UTC, Daniel Murphy wrote:
Manu via Digitalmars-d digitalmars-d@puremagic.com 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
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
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
digitalmars-d@puremagic.comwrote:
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
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
V Wed, 16 Apr 2014 13:32:45 +
asman via Digitalmars-d digitalmars-d@puremagic.com 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 digitalmars-d@puremagic.com 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
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
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 without
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
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
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
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
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
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
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
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,
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
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
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
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
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
ola.fosheim.grostad+dl...@gmail.com 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 -
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
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 that
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
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);
throw
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:
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
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()
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
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
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
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
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 be
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#
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?
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
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
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
On 4/16/2014 2:14 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com 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
digitalmars-d@puremagic.com 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
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?
1 - 100 of 157 matches
Mail list logo
