On 1/3/12 11:34 AM, d coder wrote:
D's pass-down lambdas do not need memory allocation. As far as I
remember none of std.algorithm's use of lambda allocates memory.
On that front Andrei, did you get a chance to discuss my request to make
std.algorithm more usable with Walter?
http://
>
>
> D's pass-down lambdas do not need memory allocation. As far as I remember
> none of std.algorithm's use of lambda allocates memory.
>
>
On that front Andrei, did you get a chance to discuss my request to make
std.algorithm more usable with Walter?
http://www.digitalmars.com/webnews/newsgro
On Tue, 20 Dec 2011 12:11:27 -0800, Timon Gehr wrote:
On 12/20/2011 08:33 PM, Robert Jacques wrote:
On Mon, 19 Dec 2011 10:54:22 -0800, Timon Gehr wrote:
On 12/19/2011 07:50 PM, Vladimir Panteleev wrote:
On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
According to this wik
On 12/20/2011 08:33 PM, Robert Jacques wrote:
On Mon, 19 Dec 2011 10:54:22 -0800, Timon Gehr wrote:
On 12/19/2011 07:50 PM, Vladimir Panteleev wrote:
On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
According to this wikipedia page
http://en.wikipedia.org/wiki/Boehm_garbage_co
On Sun, 18 Dec 2011 15:28:16 -0800, Andrei Alexandrescu
wrote:
On 12/18/11 5:22 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu wrote:
On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandres
On Mon, 19 Dec 2011 10:54:22 -0800, Timon Gehr wrote:
On 12/19/2011 07:50 PM, Vladimir Panteleev wrote:
On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
According to this wikipedia page
http://en.wikipedia.org/wiki/Boehm_garbage_collector it is also the GC
that is used by D, wi
On Sun, 18 Dec 2011 15:29:23 -0800, Andrei Alexandrescu
wrote:
Unions will be conservative. The golden standard is that SafeD can't use
them or anything that forces conservative approaches.
Andrei
Is there a strong rational for a conservative approach to unions? Why not
simply set the GC p
On 12/20/11 11:41 AM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
2. Dynamic binding is a core concept of OOP. A language that does not
support dynamic
On 12/20/2011 06:41 PM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
2. Dynamic binding is a core concept of OOP. A language that does not
support dynami
Timon Gehr:
> What is to disagree with?
Sorry for my precedent answer, please ignore it, sometimes I have a too much
big mouth. I think discussions about definitions are not so interesting.
Bye,
bearophile
On Tuesday, December 20, 2011 17:58:30 Timon Gehr wrote:
> On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
> > On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
> >> 2. Dynamic binding is a core concept of OOP. A language that does not
> >> support dynamic binding does not support OOP. A pro
On 12/20/2011 05:36 PM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
2. Dynamic binding is a core concept of OOP. A language that does not
support dynamic binding does not support OOP. A program that does not
use dynamic binding is not object oriented. What is
On Tuesday, December 20, 2011 15:49:34 Timon Gehr wrote:
> 2. Dynamic binding is a core concept of OOP. A language that does not
> support dynamic binding does not support OOP. A program that does not
> use dynamic binding is not object oriented. What is to disagree with?
I don't agree with that e
On 12/20/2011 11:57 AM, bearophile wrote:
Timon Gehr:
If you don't need virtual functions, you should probably use
structs instead of classes. (you are not doing OOP anyway.)
I don't agree with both that statements.
Bye,
bearophile
1. He does not want type info. Structs don't have type inf
> The array concatenation requiring GC I get, but why does a
> delegate require it?
If you really want a stack allocated delegate, you could use something like:
import std.stdio, std.traits;
struct DelegateWrapper(alias fun, Args...)
{
Args args;
private auto f(ParameterTypeTuple!fun[Ar
On 12/20/11 7:41 AM, deadalnix wrote:
D's pass-down lambdas do not need memory allocation. As far as I
remember none of std.algorithm's use of lambda allocates memory.
Andrei
Is the compiler able to ensure that and do not allocate on the heap ?
Yes, to the best of my knowledge it's pretty mu
Le 20/12/2011 14:08, Andrei Alexandrescu a écrit :
On 12/20/11 5:56 AM, Froglegs wrote:
C++ "closures" do not allow you to maintain a reference to the context
after the function containing said context returns. Instead, C++
allows you to choose between copying the variables into the lambda
ins
D's pass-down lambdas do not need memory allocation. As far as
I remember none of std.algorithm's use of lambda allocates
memory.
Andrei
Oh cool, I like that
On 12/20/11 5:17 AM, Froglegs wrote:
The array concatenation requiring GC I get, but why does a delegate
require it?
This link says D allocates closures on the heap
http://en.wikipedia.org/wiki/Anonymous_function#D
I don't really get why, C++ lambda works well(aside from broken lack of
templat
On 12/20/11 5:56 AM, Froglegs wrote:
C++ "closures" do not allow you to maintain a reference to the context
after the function containing said context returns. Instead, C++
allows you to choose between copying the variables into the lambda
instance, or referencing them (the references may not "
Froglegs:
> Still it seems like a case of "you pay for what you don't use",
That's a design rule for C++, but D is a bit different :-)
Often in D there are ways to not pay what you don't use, but you have to ask
for them. If you don't ask for those ways, you usually need to pay a little,
and yo
C++ "closures" do not allow you to maintain a reference to the
context after the function containing said context returns.
Instead, C++ allows you to choose between copying the variables
into the lambda instance, or referencing them (the references
may not "escape"). The compiler may or may n
On Tuesday, 20 December 2011 at 11:17:32 UTC, Froglegs wrote:
The array concatenation requiring GC I get, but why does a
delegate require it?
This link says D allocates closures on the heap
http://en.wikipedia.org/wiki/Anonymous_function#D
I don't really get why, C++ lambda works well(aside f
On Tuesday, 20 December 2011 at 11:17:32 UTC, Froglegs wrote:
The class will still have a vptr. The vtable will contain only
the type info.
No way to disable type info(like in most C++ compilers you can
disable RTTI)? I get that GC might want it, but if I disable GC
why would I want type in
The class will still have a vptr. The vtable will contain only
the type info.
No way to disable type info(like in most C++ compilers you can
disable RTTI)? I get that GC might want it, but if I disable GC
why would I want type info?
I saw that D is planning to make the standard containers
Timon Gehr:
> If you don't need virtual functions, you should probably use
> structs instead of classes. (you are not doing OOP anyway.)
I don't agree with both that statements.
Bye,
bearophile
Froglegs:
> One thing I'm not sure about, D classes are virtual by default,
> but if you mark all functions as final does the class still
> contain a VFP or any other cruft?
Even D final classes, that do not have virtual methods, have a pointer to
virtual table. It's used to know what class
On 12/20/2011 11:48 AM, Jonathan M Davis wrote:
On Tuesday, December 20, 2011 11:21:41 Froglegs wrote:
I've only recently tried D out, but what I'd like to see..
-GC being truly optional
-being able to specify if the standard library should use GC or
not, perhaps with allocators
Some aspec
On 12/20/2011 11:21 AM, Froglegs wrote:
I've only recently tried D out, but what I'd like to see..
-GC being truly optional
-being able to specify if the standard library should use GC or not,
perhaps with allocators
-if D is going to have a GC, then a precise, compacting one would be
cool, but
On Tuesday, December 20, 2011 11:21:41 Froglegs wrote:
> I've only recently tried D out, but what I'd like to see..
>
> -GC being truly optional
> -being able to specify if the standard library should use GC or
> not, perhaps with allocators
Some aspects of D will _always_ require a GC or they
On Sun, 18 Dec 2011 04:09:21 +0400, Ruslan Mullakhmetov wrote:
> I want to ask you about D future, i mean next big iteration of D and
> propose some new feature, agent-based programming. Currently, after
> introducing C++11 i see the only advantages of D over C++11 except
> syntax sugare is gar
I've only recently tried D out, but what I'd like to see..
-GC being truly optional
-being able to specify if the standard library should use GC or
not, perhaps with allocators
-if D is going to have a GC, then a precise, compacting one would
be cool, but not if it gets in the way of making t
On 12/20/2011 07:01 AM, Ruslan Mullakhmetov wrote:
On 2011-12-19 11:52:25 +, Alex Rønne Petersen said:
On 18-12-2011 15:40, Somedude wrote:
Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
GC is just a mater of implementation. In presence of resources
implement
good GC algorithm offers
On 2011-12-19 11:52:25 +, Alex Rønne Petersen said:
On 18-12-2011 15:40, Somedude wrote:
Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
GC is just a mater of implementation. In presence of resources implement
good GC algorithm offers no difficulty.
Oh really ? Then please make us a
On 12/19/2011 07:50 PM, Vladimir Panteleev wrote:
On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
According to this wikipedia page
http://en.wikipedia.org/wiki/Boehm_garbage_collector it is also the GC
that is used by D, with some minor modifications of course.
I'm not sure if
On Monday, 19 December 2011 at 08:28:52 UTC, Adam Wilson wrote:
According to this wikipedia page
http://en.wikipedia.org/wiki/Boehm_garbage_collector it is also
the GC that is used by D, with some minor modifications of
course.
I'm not sure if that's true... I believe that they both use the
On 18-12-2011 15:40, Somedude wrote:
Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
GC is just a mater of implementation. In presence of resources implement
good GC algorithm offers no difficulty.
Oh really ? Then please make us a favor and write one for D. Also I'm
sure the C++ guys wil
On 12/19/2011 01:00 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 Dec
On 12/19/2011 05:23 AM, a wrote:
In case of passing GC memory to C functions, I would prefer to just
disallow the C code to capture the reference, and to disable GC while
the C function runs.
Wouldn't this be a problem with non concurrent GC? If you have multiple threads
that spend most of t
On Sun, 18 Dec 2011 23:29:38 -0800, Vladimir Panteleev
wrote:
On Monday, 19 December 2011 at 07:27:14 UTC, Adam Wilson wrote:
On Sun, 18 Dec 2011 23:19:41 -0800, Vladimir Panteleev
wrote:
On Monday, 19 December 2011 at 07:11:10 UTC, Adam Wilson wrote:
It seems to me that no one else is
On Sun, 18 Dec 2011 23:43:04 -0800, Jacob Carlborg wrote:
On 2011-12-19 00:19, Adam Wilson wrote:
On Sun, 18 Dec 2011 15:02:17 -0800, Timon Gehr
wrote:
On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu
wrote:
That is an i
On 2011-12-19 00:19, Adam Wilson wrote:
On Sun, 18 Dec 2011 15:02:17 -0800, Timon Gehr wrote:
On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 100% convinced
precise
On Monday, 19 December 2011 at 07:27:14 UTC, Adam Wilson wrote:
On Sun, 18 Dec 2011 23:19:41 -0800, Vladimir Panteleev
wrote:
On Monday, 19 December 2011 at 07:11:10 UTC, Adam Wilson wrote:
It seems to me that no one else is interested...
Not true :)
Hehe, I mean't outside the D communit
On Sun, 18 Dec 2011 23:19:41 -0800, Vladimir Panteleev
wrote:
On Monday, 19 December 2011 at 07:11:10 UTC, Adam Wilson wrote:
It seems to me that no one else is interested...
Not true :)
Hehe, I mean't outside the D community. I can think of five people off the
top of my head inside th
I think there is no need in language changes. Everythink can be
implemented via library.
What is needed:
- base agent class
- base behaviors
- runtime that provide ability to run independent agents even in
single-thread mode. Number of agents can be greater then number of
treads. so schedul
On Monday, 19 December 2011 at 07:11:10 UTC, Adam Wilson wrote:
It seems to me that no one else is interested...
Not true :)
On Sun, 18 Dec 2011 15:55:18 -0800, Vladimir Panteleev
wrote:
On Sunday, 18 December 2011 at 23:28:16 UTC, Andrei Alexandrescu wrote:
I'm not sure. I seem to recall discussions with pathological cases when
large regions of memory were scanned for no good reason.
We need to factor the freq
> In case of passing GC memory to C functions, I would prefer to just
> disallow the C code to capture the reference, and to disable GC while
> the C function runs.
Wouldn't this be a problem with non concurrent GC? If you have multiple threads
that spend most of the time in C function calls (
On Sunday, 18 December 2011 at 23:19:08 UTC, Adam Wilson wrote:
It seems to that we are really dancing around the potential
solution. A pluggable GC interface that allowed the developer
to choose the right GC for the task, or no GC at all. Imagine
if all the developer had to do is set a compile
On Sun, Dec 18, 2011 at 5:55 PM, Timon Gehr wrote:
> On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
>>
>> On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
>>>
>>> On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wr
On Monday, 19 December 2011 at 00:07:47 UTC, Timon Gehr wrote:
OK... but what about the "generational GC that uses a copying
collector
for the nursery"?
I am not sure I get the question. The D specification already
allows moving GC implementations. What is the issue you are
thinking about?
On 12/19/2011 01:00 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 Dec
On Sunday, 18 December 2011 at 23:55:17 UTC, Timon Gehr wrote:
On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr
wrote:
You a
On Sunday, 18 December 2011 at 23:28:16 UTC, Andrei Alexandrescu
wrote:
I'm not sure. I seem to recall discussions with pathological
cases when large regions of memory were scanned for no good
reason.
We need to factor the frequency of such cases, and their impact.
Also, a more precise GC isn
On 12/19/2011 12:45 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
You are right. I have had in mind a generational GC that uses a
copy
Le 19/12/2011 00:28, Andrei Alexandrescu a écrit :
> I ordered the GC book :o).
>
>
> Andrei
Also, at the risk of being redundant...
http://www.scribd.com/doc/26102695/Garbage-Collection-in-JVM
http://www.scribd.com/doc/59150636/C4-Continuously-Concurrent-Compacting-Collector
On Sunday, 18 December 2011 at 23:31:03 UTC, Timon Gehr wrote:
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
You are right. I have had in mind a generational GC that uses
a
copying collector for the nursery as this is what most
On 12/19/2011 12:24 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
You are right. I have had in mind a generational GC that uses a
copying collector for the nursery as this is what most
state-of-the-art VM GCs do.
...
We can change the way unions a
On 12/18/11 5:18 PM, Timon Gehr wrote:
On 12/19/2011 12:11 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
It is an unilateral improvement if both options are kept open. I don't
see a reason to cease support for the current GC model.
I believe that
On 12/18/11 5:22 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu wrote:
On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 10
On Sunday, 18 December 2011 at 23:18:22 UTC, Timon Gehr wrote:
You are right. I have had in mind a generational GC that uses a
copying collector for the nursery as this is what most
state-of-the-art VM GCs do.
...
We can change the way unions are layed out. The compiler can
mark GC memory pa
Vladimir Panteleev:
> Also, D can't have a completely precise GC as long as it has unions
Despite C/D unions are untagged, in many cases there is some kind of manually
managed tag (maybe stored elsewhere), or the programmer often knows (despite
being sometimes wrong) what type is present inside
On 12/19/2011 12:16 AM, Andrei Alexandrescu wrote:
On 12/18/11 5:11 PM, Vladimir Panteleev wrote:
Also, D can't have a completely precise
GC as long as it has unions and can pass managed memory to C code.
Also casts pointer <-> integrals.
Casting a pointer to GC memory to an integral results
On Sunday, 18 December 2011 at 23:13:03 UTC, Andrei Alexandrescu
wrote:
On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei
Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 100%
convinced
precise GC is the only way to go, a
On 12/18/11 5:11 PM, Vladimir Panteleev wrote:
Also, D can't have a completely precise
GC as long as it has unions and can pass managed memory to C code.
Also casts pointer <-> integrals.
These arguments don't blunt the desirability of precise GC.
Andrei
On 12/19/2011 12:11 AM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
It is an unilateral improvement if both options are kept open. I don't
see a reason to cease support for the current GC model.
I believe that currently the plan does not include pro
On Sun, 18 Dec 2011 15:02:17 -0800, Timon Gehr wrote:
On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 100% convinced
precise GC is the only way to go, and I think I'
On 12/18/11 4:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 100% convinced
precise GC is the only way to go, and I think I've convinced Walter to
a good extent as well.
Sacrificing
On Sunday, 18 December 2011 at 23:02:17 UTC, Timon Gehr wrote:
It is an unilateral improvement if both options are kept open.
I don't see a reason to cease support for the current GC model.
I believe that currently the plan does not include providing this
choice.
Furthermore, a generational
Vladimir Panteleev:
> Sacrificing something (performance, executable size) for
> something else is not an unilateral improvement.
I presume they will add a very easy way (like a compilation switch? No need to
modify druntime, or to recompile DMD, or to write your own GC) to switch back
to less
On 12/18/2011 11:53 PM, Vladimir Panteleev wrote:
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu wrote:
That is an interesting opportunity. At any rate, I am 100% convinced
precise GC is the only way to go, and I think I've convinced Walter to
a good extent as well.
Sacrifici
On Sunday, 18 December 2011 at 20:32:18 UTC, Andrei Alexandrescu
wrote:
That is an interesting opportunity. At any rate, I am 100%
convinced precise GC is the only way to go, and I think I've
convinced Walter to a good extent as well.
Sacrificing something (performance, executable size) for
s
On 12/18/11 3:07 PM, Timon Gehr wrote:
On 12/18/2011 11:51 AM, Ruslan Mullakhmetov wrote:
On 2011-12-18 00:56:33 +, Timon Gehr said:
C++11 does not change the relation between D and C++ a lot. Why do you
think it does?
Because it incorporates many features D declared to be unique to it
On 12/18/2011 11:51 AM, Ruslan Mullakhmetov wrote:
On 2011-12-18 00:56:33 +, Timon Gehr said:
C++11 does not change the relation between D and C++ a lot. Why do you
think it does?
Because it incorporates many features D declared to be unique to it
It does not, except for the most trivia
On 12/18/11 1:46 PM, jdrewsen wrote:
On Sunday, 18 December 2011 at 17:19:33 UTC, Andrei Alexandrescu wrote:
On 12/18/11 6:19 AM, Alex Rønne Petersen wrote:
On 18-12-2011 12:45, Somedude wrote:
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
I do not want to make a flame over D vs C++11.
On Sunday, 18 December 2011 at 17:19:33 UTC, Andrei Alexandrescu
wrote:
On 12/18/11 6:19 AM, Alex Rønne Petersen wrote:
On 18-12-2011 12:45, Somedude wrote:
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
I do not want to make a flame over D vs C++11.
Walter and I are both interested i
Yet, most high performance network elements from Ericson are running Erlang.
Able to process millions of phone calls per second.
What is D doing in real world?
This is the type of questions the community has to provide to naysayers.
--
Paulo
Somedude Wrote:
> Le 18/12/2011 12:13, Ruslan Mulla
On 12/18/11 6:19 AM, Alex Rønne Petersen wrote:
On 18-12-2011 12:45, Somedude wrote:
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
I do not want to make a flame over D vs C++11.
...
Once again, i'm not trying to make a holywar. I'm D lover myself. But a
lot of people do not consider this
On Sun, Dec 18, 2011 at 6:19 AM, Alex Rønne Petersen
wrote:
> On 18-12-2011 12:45, Somedude wrote:
>>
>> Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
>>>
>>> I do not want to make a flame over D vs C++11.
>>>
>>> ...
>>> Once again, i'm not trying to make a holywar. I'm D lover myself. But
Am 18.12.2011, 11:51 Uhr, schrieb Ruslan Mullakhmetov :
On 2011-12-18 00:56:33 +, Timon Gehr said:
C++11 does not change the relation between D and C++ a lot. Why do you
think it does?
Because it incorporates many features D declared to be unique to it over
C++ like
- thread local
Am 18.12.2011, 01:09 Uhr, schrieb Ruslan Mullakhmetov :
Hi all,
I want to ask you about D future, i mean next big iteration of D and
propose some new feature, agent-based programming. Currently, after
introducing C++11 i see the only advantages of D over C++11 except
syntax sugare is g
Le 18/12/2011 15:07, Ruslan Mullakhmetov a écrit :
>
> GC is just a mater of implementation. In presence of resources implement
> good GC algorithm offers no difficulty.
>
Oh really ? Then please make us a favor and write one for D. Also I'm
sure the C++ guys will be pleased to hear that it's su
Le 18/12/2011 13:19, Alex Rønne Petersen a écrit :
> On the other hand, Erlang's runtime is built around message-passing. >
I *extremely strongly doubt* that you can get similar performance out >
of message-passing in D
As I said inmy previous post, the kind of performance that Erlang has is
usefu
As far as I understand Erlang performance is reached by horizontal
scheduling (i'm not sure i used exact word) by which i mean that if you
have lack of performance you can buy new hardware nodes (servers) and
without any changes in code and even recompiling you can distribute
workload.
That i
On 18-12-2011 12:45, Somedude wrote:
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
I do not want to make a flame over D vs C++11.
...
Once again, i'm not trying to make a holywar. I'm D lover myself. But a
lot of people do not consider this benefits of D enough to shift to it
as for my
Le 18/12/2011 12:13, Ruslan Mullakhmetov a écrit :
> I do not want to make a flame over D vs C++11.
>
> ...
> Once again, i'm not trying to make a holywar. I'm D lover myself. But a
> lot of people do not consider this benefits of D enough to shift to it
> as for my opinion and experience.
>
>
It will be years before we seriously start looking at D3
Absolutely. Just wanted to share with my thoughts.
When i wrote to NG i do not intend to say "Let do it right know",
instead wanted to say "When D3 would be considered..."
Any good movement as i hope D is ought to have some global v
I do not want to make a flame over D vs C++11.
I answered else thread on some differences of C++11 vs D, but i agree
with you that i was a little bit in a hurry.
After rechecking i remembered constraints, static compilation (static
if), contract programming, functional programming. perhaps
On 2011-12-18 00:56:33 +, Timon Gehr said:
C++11 does not change the relation between D and C++ a lot. Why do you
think it does?
Because it incorporates many features D declared to be unique to it
over C++ like
- thread local variables
- explicit concurrency model
- type deduction
Le 18/12/11 02:53, Timon Gehr a écrit :
On 12/18/2011 02:42 AM, a wrote:
Ruslan Mullakhmetov Wrote:
Currently, after
introducing C++11 i see the only advantages of D over C++11 except
syntax sugare is garbage collector and modules.
So you are saying that sane templates, range based standard
On Sunday, December 18, 2011 04:09:21 Ruslan Mullakhmetov wrote:
> I want to ask you about D future
It will be years before we seriously start looking at D3, and while there are
ideas for what we might like to do with it, it's far too early to say what's
likely to happen with it. D2 needs to b
On 12/18/2011 02:42 AM, a wrote:
Ruslan Mullakhmetov Wrote:
Currently, after
introducing C++11 i see the only advantages of D over C++11 except
syntax sugare is garbage collector and modules.
So you are saying that sane templates, range based standard library and
concurrency improvements (t
Ruslan Mullakhmetov Wrote:
> Currently, after
> introducing C++11 i see the only advantages of D over C++11 except
> syntax sugare is garbage collector and modules.
So you are saying that sane templates, range based standard library and
concurrency improvements (thread local variables, immuta
On 12/18/2011 01:09 AM, Ruslan Mullakhmetov wrote:
Hi all,
I want to ask you about D future, i mean next big iteration of D and
propose some new feature, agent-based programming. Currently, after
introducing C++11 i see the only advantages of D over C++11 except
syntax sugare is garbage collecto
Hi all,
I want to ask you about D future, i mean next big iteration of D and
propose some new feature, agent-based programming. Currently, after
introducing C++11 i see the only advantages of D over C++11 except
syntax sugare is garbage collector and modules.
I recentrly attended student
95 matches
Mail list logo
