On Wednesday, 9 March 2016 at 22:54:13 UTC, bigsandwich wrote:
Yes, I do. std::function<> uses type erasure to store a
"function". If its small enough, its stored internally,
otherwise it goes on the heap.
Yes, I believe that is said to be the common implementation, but
people also claim it
On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/),
which I assume has been ported to D2, porting it to Windows or
whatever else remains to be done and then addin
On Tuesday, 8 March 2016 at 18:01:25 UTC, Lodovico Giaretta wrote:
- one accepting InputRanges, that can work with almost any data
source and does not require the entire input to be available at
the same time; it's cons are that it must allocate lots of
small strings (one for each token) and gr
On Thursday, 10 March 2016 at 11:12:47 UTC, thedeemon wrote:
On Thursday, 10 March 2016 at 05:01:37 UTC, Joakim wrote:
Perhaps someone could build off of Sociomantic's concurrent GC
(https://www.sociomantic.com/blog/2013/06/porting-cdgc-to-d2/), which I assume has been ported to D2, porting it t
On 3/8/16 10:04 PM, Jack Stouffer wrote:
On Wednesday, 9 March 2016 at 01:18:26 UTC, maik klein wrote:
Direct link: https://maikklein.github.io/post/CppAndD/
Reddit link:
https://www.reddit.com/r/programming/comments/49lna6/a_comparison_between_c_and_d/
If you spot any mistakes, please let me
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.
I agree. A first step would be easy to do with std.allocator's
thread-loca
On 3/9/16 7:40 PM, Jack Stouffer wrote:
On Wednesday, 9 March 2016 at 12:58:24 UTC, Andrei Alexandrescu wrote:
Folks, I've been a tad scarce in the past month or so. This is because
I've been working on a paper submission, which turned out to be a
major and extremely captivating effort. Can't sh
On Thursday, 10 March 2016 at 15:25:54 UTC, Andrei Alexandrescu
wrote:
It's done and with a nice accompanying article too, I just need
to allocate the time to push it into Phobos. -- Andrei
You could just push it to dub in the meantime so people can play
with it.
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it
lock-free.
Currently, GC lock cause some serious performance penalties for
multithreaded code when frequent allocations take place.
I
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu
wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it
lock-free.
Currently, GC lock cause some serious performance penalties
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei Alexandrescu wrote:
On 3/9/16 10:40 PM, NX wrote:
I think the best possible improvement for GC is making it lock-f
I've made a few updates based on some of the feedback in this
thread.
- execute() renamed to query()
- query with input binds directly from connection
- query() returns result for chaining
The design is still early stage. I've got a growing list of
design options which I'll bring into discuss
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan
wrote:
On Thursday, 10 March 2016 at 15:24:48 UTC, Andrei
Alexandrescu wrote:
On 3/9/16 10:40 PM, NX wrote:
Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59 UTC, Jeremy DeHaan wrote:
On Thursday, 10 March 2016 at 15:24:4
On Tuesday, 8 March 2016 at 20:32:02 UTC, Idan Arye wrote:
Declaring the named arguments variadically will be done by
adding `...` after a struct argument:
struct Options{int x; int y=1; int z=2;}
auto fun(Options options ...)
We'll need a syntax for specifying the arguments - but that
On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
The compiler should detect that this call is ambiguous and
would not allow it.
It's a potentially significant amount of work to determine that
the expression is ambiguous, or to
On Monday, 7 March 2016 at 18:21:24 UTC, Meta wrote:
On Monday, 7 March 2016 at 10:40:15 UTC, ZombineDev wrote:
Which I don't think will cause ambiguity with delegates:
auto tuple3 = { getInt() }; tuple
auto tuple3 = { getInt(); }; lambda
Unfortunately this will not work. There was a tuple pro
On Thursday, 10 March 2016 at 18:49:28 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 19:39 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 17:46:15 UTC, Daniel Kozak wrote:
Dne 10.3.2016 v 18:15 ZombineDev via Digitalmars-d napsal(a):
On Thursday, 10 March 2016 at 16:46:59
I am very new to D so I apologize if I'm very uninformed. I'm
learning D by porting a big (awful) c++ project to D so that I
may take advantage of all the lovely testing and QA features. I
am currently moving a class over that I have which represents a 2
float vector and I've run into a problem
Don't forget to mention all the "software engineering" principles
that can be taught using D too including:
Design by Contract
Literate programming (embedded documentation)
and to tool that come "standard" in the language such as
Coverage
Profiling
Hi,
I tried posting this to the Phobos list but it failed!
I've been writing a tool that requires me to demangle D mangled
names. To check it I've been running the tool on its self
including its mangled names (that I get from the profiler). I've
discovered that std.demangle.demangle() canno
On Thursday, 10 March 2016 at 21:07:09 UTC, FatalCatharsis wrote:
I am very new to D so I apologize if I'm very uninformed. I'm
learning D by porting a big (awful) c++ project to D so that I
may take advantage of all the lovely testing and QA features. I
am currently moving a class over that I
On Thursday, 10 March 2016 at 22:04:24 UTC, Xinok wrote:
I'm not sure how the compilers translate the contracts into
code, but it's definitely feasible. Code of the form:
auto foo()
in{ ... }
out(result){ ... }
body{ ... }
Could simply be rewritten as:
Not quite because con
On Thursday, 10 March 2016 at 22:39:54 UTC, Adam D. Ruppe wrote:
Contracts are most interesting in the case of inheritance and
keeping variables between them isn't going to be easy.
IMHO, at this point, inheritance is the only reason they're worth
having in the language. Without inheritance, i
On Thursday, 10 March 2016 at 21:54:33 UTC, Andrew wrote:
Don't forget to mention all the "software engineering"
principles that can be taught using D too including:
Design by Contract
Literate programming (embedded documentation)
and to tool that come "standard" in the language such as
Cover
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis
wrote:
IMHO, at this point, inheritance is the only reason they're
worth
having in the language. [snip]
I created a simple example to understand your point about
contracts only really mattering for inheritance, but my example
is g
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis
wrote:
I don't think that out contracts are worth much anyway, since
in almost all cases, unit tests do that job already, and it's
usually much easier to write test that specific input gives
specific output than it is to have a genera
Surely a language such as Java is much better for things like
design by contract through JML? It may not be built-in such as
D's `in` and `out` blocks, but there is tool-support for both
runtime and static checking, and JML can also describe things
such as class invariants.
One of awful thing
On Sunday, 6 March 2016 at 07:38:01 UTC, Ali Çehreli wrote:
What are the points that you would stress? I am thinking that
they would be interested more in whether D is better as a
teaching tool. Do you agree?
Ali
I think the D std.parallelism library would be a nicer starting
point than usi
On Thursday, 10 March 2016 at 23:47:55 UTC, Andrew wrote:
One of awful things about programming in many languages is that
there's a gazillion tools you need to tack-on before you can do
any engineering. In C++ that includes Doxygen for
documentation, C++Unit for unit tests, gprof, gcov, valgri
On Thursday, 10 March 2016 at 23:31:14 UTC, jmh530 wrote:
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis
wrote:
IMHO, at this point, inheritance is the only reason they're
worth
having in the language. [snip]
I created a simple example to understand your point about
contracts
On Thursday, 10 March 2016 at 23:31:22 UTC, FatalCatharsis wrote:
On Thursday, 10 March 2016 at 22:57:41 UTC, Jonathan M Davis
wrote:
If/Once we get more features in the compiler which take
advantage of contracts, then I'll likely change my tune on
that one, but for now, IMHO, they're really on
On Friday, 11 March 2016 at 00:07:45 UTC, Jonathan M Davis wrote:
You're not using in or out contracts here at all, so so of
course, you're not going to see how in/out contracts work with
inheritance in this example. To quote
http://dlang.org/spec/contracts.html:
Sigh...my point was that
On Friday, 11 March 2016 at 01:04:05 UTC, jmh530 wrote:
On Friday, 11 March 2016 at 00:07:45 UTC, Jonathan M Davis
wrote:
You're not using in or out contracts here at all, so so of
course, you're not going to see how in/out contracts work with
inheritance in this example. To quote
http://dla
On Friday, 11 March 2016 at 01:45:36 UTC, Jonathan M Davis wrote:
Sure, but if you're not using in/out contracts with a class,
you're not going to see how they interact with inheritance. To
mimic what they do, you'd have to duplicate the base class
contracts in the derived class and make sure
On Friday, 11 March 2016 at 04:17:51 UTC, jmh530 wrote:
On Friday, 11 March 2016 at 01:45:36 UTC, Jonathan M Davis
wrote:
Sure, but if you're not using in/out contracts with a class,
you're not going to see how they interact with inheritance. To
mimic what they do, you'd have to duplicate the
On Thu, 10 Mar 2016 19:01:53 +, ZombineDev wrote:
> On Monday, 7 March 2016 at 19:06:54 UTC, Chris Wright wrote:
>> On Mon, 07 Mar 2016 11:06:13 +, ZombineDev wrote:
>>> The compiler should detect that this call is ambiguous and would not
>>> allow it.
>>
>> It's a potentially significant
37 matches
Mail list logo
