On Thursday, 10 July 2014 at 22:31:55 UTC, Vlad Levenfeld wrote:
On Thursday, 10 July 2014 at 22:28:46 UTC, H. S. Teoh via
Digitalmars-d wrote:
std.array.appender?
I tried it, it was much better than the default append but
still several times slower than a manually overload.
There's also
Thanks Mike... Looking into that.
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
+ If not, can it be disabled entirely/completely?
Adrian,
Sorry for the late reply. You may be interested in this article
on the wiki (http://wiki.dlang.org/Memory_Management). It talks
about different methods one can use to avoid th
** manually overloaded opOpAssign'
(hit send too fast)
On Thursday, 10 July 2014 at 22:28:46 UTC, H. S. Teoh via
Digitalmars-d wrote:
std.array.appender?
I tried it, it was much better than the default append but still
several times slower than a manually overload.
On Thu, Jul 10, 2014 at 10:20:41PM +, Vlad Levenfeld via Digitalmars-d
wrote:
> I haven't managed to read through these last few pages but I just wanted to
> chime with my noob opinion re: D slices, templates, GC and manual
> allocation, for whatever its worth:
>
> Although I tend to just let
I haven't managed to read through these last few pages but I just
wanted to chime with my noob opinion re: D slices, templates, GC
and manual allocation, for whatever its worth:
Although I tend to just let the GC do its thing most of the time,
I've found spots where I needed manual allocation
On Thu, Jul 10, 2014 at 07:57:55PM +, deadalnix via Digitalmars-d wrote:
[...]
> Actually, I think we can do better than Java, because we have
> type qualifiers and less indirection. That isn't unseen: OCaml's
> GC is more performant than Java's. We certainly do not have the
> resources java ha
On Thursday, 10 July 2014 at 20:18:23 UTC, Araq wrote:
No, you don't. No distinction between GC'ed and non GC'ed
pointers,
This is true.
interior pointers are everywhere,
This however, I don't think is a problem. It can make a
non-precise GC more unreliable, but otherwise?
sharing GC'ed
Araq:
casting to const/immutable might be officially undefined but in
practice abounds so you better don't take advantage of that,
Do you have evidence of this? It's not just "officially
undefined", it's practically undefined, dmd gives all kind of
wrong results if you cast away const/immuta
On Thursday, 10 July 2014 at 19:57:56 UTC, deadalnix wrote:
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:
Adrian:
As for your second question (i.e. how good the GC needs to be
for me), I would probably be satisfied with a GC that matches
the Java one
This will not happen even
Am 10.07.2014 21:57, schrieb deadalnix:
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:
Adrian:
As for your second question (i.e. how good the GC needs to be for
me), I would probably be satisfied with a GC that matches the Java one
This will not happen even in one hundred years
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:
Adrian:
As for your second question (i.e. how good the GC needs to be
for me), I would probably be satisfied with a GC that matches
the Java one
This will not happen even in one hundred years. So if that's
what you want, you will
On Wednesday, 9 July 2014 at 13:01:36 UTC, bearophile wrote:
The huge amount of work done on the OracleVM GC that is not
easy to match.
D need for low-level code (currently user code can't tell the
GC what are the current actual contents of a union, this
includes Algebraic), D desire to interfa
Marc Schütz:
Uhmm... what makes you think so?
The huge amount of work done on the OracleVM GC that is not easy
to match.
D need for low-level code (currently user code can't tell the GC
what are the current actual contents of a union, this includes
Algebraic), D desire to interface efficien
On Wednesday, 9 July 2014 at 11:44:31 UTC, Marc Schütz wrote:
This will not happen even in one hundred years. So if that's
what you want, you will never be satisfied by D GC.
Uhmm... what makes you think so?
Good question actually...
On Wednesday, 9 July 2014 at 11:21:13 UTC, bearophile wrote:
Adrian:
As for your second question (i.e. how good the GC needs to be
for me), I would probably be satisfied with a GC that matches
the Java one
This will not happen even in one hundred years. So if that's
what you want, you will
Adrian:
As for your second question (i.e. how good the GC needs to be
for me), I would probably be satisfied with a GC that matches
the Java one
This will not happen even in one hundred years. So if that's what
you want, you will never be satisfied by D GC.
Bye,
bearophile
Have you written enough D code where you have seen the current
GC is not good enough for you? How much good has to be the D GC
for you to use it?
Bye,
bearophile
Hi,
As I said at the start, I have been away a while but I wrote a
fair amount of code in D about a year ago to test the waters.
Adrian:
for if the GC is stumbling block for some people (such as
myself), an inefficient/weak one does not help in convincing GC
sceptics to accept it.
...
is there a comprehensive and precise set of instructions
available that one could follow in order to write D programs
entirely devoid o
Hi folks,
Thank you all for your very informative answers - much
appreciated.
Great to see such an active community there.
To summarise what you said:
+ No, the GC can't be taken out, but with careful attention one
can - relatively easily - bypass it. This can come at a price of
some great
On Tuesday, 8 July 2014 at 16:55:54 UTC, bearophile wrote:
D is in beta release, so that pull request has to wait for
2.067+.
We use release branches now. There is no reason for development
activity to decline during the beta period – other than people
being busy with addressing beta tester f
Meta:
https://github.com/D-Programming-Language/dmd/pull/3615
D is in beta release, so that pull request has to wait for 2.067+.
Bye,
bearophile
On Tuesday, 8 July 2014 at 12:24:32 UTC, John Colvin wrote:
There was talk of something like immutable(char)[$] =
"héllo͂"; working, but I don't know where that went.
https://github.com/D-Programming-Language/dmd/pull/3615
On Tuesday, 8 July 2014 at 11:31:49 UTC, Oluca wrote:
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer
int[10] a = [0,1,2,3,4,5,6,7,8,9]; //a static array, on the
stack
auto s = a[]; //a normal slice, backed by stack memory*
auto s1 = a[3 .. 5]; //ditto
I see. Thanks for the examples. What about strings? Do they
depend on GC?
They are just slices / arrays.
On Tuesday, 8 July 2014 at 11:26:55 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any ot
On Tuesday, 8 July 2014 at 11:22:42 UTC, John Colvin wrote:
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using
"impressive
features" of the language.
What do CTFE, mixins, Ds pow
On Tuesday, 8 July 2014 at 06:23:13 UTC, Jeremy DeHaan wrote:
I remember that slices was one thing you would no longer have
if you disable the GC, but I can't think of any others.
You can definitely use slices without the GC and they are still
awesome without the GC.
What you cannot do is cre
On Tuesday, 8 July 2014 at 10:25:17 UTC, Oluca wrote:
- You can't use slices. You can't make use of most of the
Standard Library functionality.
You just cannot append to them.
- It matters, because you can't manually manage life-time of
the objects. See, you have to keep a reference to a C-
On Tuesday, 8 July 2014 at 10:07:18 UTC, Tobias Pankrath wrote:
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using
"impressive
features" of the language.
What do CTFE, mixins, Ds powerful template mechanism, immutable
+
slices, sane op
On Tuesday, 8 July 2014 at 09:57:15 UTC, Oluca wrote:
- No, it can't be disabled if you want to keep using "impressive
features" of the language.
What do CTFE, mixins, Ds powerful template mechanism, immutable +
slices, sane operator overloading, opDispatch, alias this and
UFCS, RAII + scope st
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
Hi all,
I know there's been quite some discussion about the GC in D,
but I've been busy doing other things and haven't been
following that closely.
So I'd appreciate it if someone could fill me in about
proceedings/decisions in this reg
Marc Schütz:
There might also be other changes necessary, some kind of
ownership tracking / borrowing for example, to make this safe.
(Manual memory management without help from the language can
easily lead to all kinds of bugs.)
In the end Bartoz could be right.
Bye,
bearophile
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
+ Has the GC been dropped?
No, and no matter what exactly will be done, it surely will
always stay at least as an option, and most probably will be
enabled by default.
+ If not, can it be disabled entirely/completely?
This is alre
On Tuesday, 8 July 2014 at 03:37:51 UTC, Adrian wrote:
+ Has the GC been dropped?
Nope, still there and probably always will be. I think I read on
the forums that people are working on a better/more precise GC
though. From what I understand the current one could stand a lot
of improvement.
Hi all,
I know there's been quite some discussion about the GC in D, but
I've been busy doing other things and haven't been following that
closely.
So I'd appreciate it if someone could fill me in about
proceedings/decisions in this regard...
+ Has the GC been dropped?
+ If not, can it b
38 matches
Mail list logo
