On 2015-09-21 06:22, Paul O'Neil wrote:
As the title says, cpp_binder is a tool that generates C++ bindings. It
reads C++ headers and produces a D file filled with "extern(C++)"
declarations. It can translate a bunch of cool, small examples, but is
not close to being ready for prime-time. It
On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote:
I hope that this post will spur discussion / decisions / action
binding C++ libraries into D. I think the language
capabilities (e.g. extern(C++, namespace)) get really far and
that the next big push needs to be on binding real
On Tuesday, 22 September 2015 at 00:31:45 UTC, Paul O'Neil wrote:
While D and C++ const don't quite share semantics, they're
petty close and they mangle the same way. I do what ZombieDev
has in the table.
Going from const to mutable like that breaks the type system...
On Tuesday, 22 September 2015 at 02:15:51 UTC, jmh530 wrote:
Interesting. Not to resurrect the older D vs. Rust thread, but
I have heard it that it can be painful to do some things in
Rust. D often has the ability to do unsafe things, like disable
the GC. I was looking at how Rust has raw
> I read your reasons why you're not using DStep. But I still think it's a
> shame that you chose to create a new tool instead of contributing to DStep.
>
> That's the unfortunate issue with the D community. Everyone is creating
> their on projects instead of working together. That's why the
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it would be possible to
create a system where the created objects know their own life
spans and destroy themselves, once they are no
On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it would be possible
to create a system where the created objects
On Tue, Sep 15, 2015 at 7:37 PM, Meta via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Monday, 14 September 2015 at 21:05:42 UTC, Martin Nowak wrote:
>
>> The second beta for the 2.068.2 point release fixes an regression with
>> destroy that could result in a memory
On Wednesday, 16 September 2015 at 03:20:28 UTC, SimonN wrote:
Yes, the 0.4.x version works with my examples perfectly. Thanks
for adding const support!
(I haven't tested yet every combination of const/mutable
Enumap, const/mutable foraech-value, and direct/ref
foreach-value. My examples are
On 2015-09-19 17:56:21 +, thedeemon said:
If we carefully use addRoot() and addRange() for data directly pointing
to GC heap I think we don't need to let GC scan everything that can
lead to this data. This is error-prone in general, of course.
Well, that's a different name for malloc &
On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
So I'm not completely nuts! Good to know. :) I wonder, if
something like this is feasible in D.
I am too. I'm toying with some ideas, but I think it would work
mostly for shorter programs. Then again, I'm mostly interested in
shorter
On Monday, 21 September 2015 at 10:25:05 UTC, Chris wrote:
On Monday, 21 September 2015 at 10:18:17 UTC, Ola Fosheim
Grøstad wrote:
On Monday, 21 September 2015 at 09:58:31 UTC, Chris wrote:
I sometimes wonder - and please forgive me my ignorance,
because I'm not a GC expert at all - if it
On Monday, 21 September 2015 at 19:32:23 UTC, Ola Fosheim Grøstad
wrote:
If the compiler can prove that two pointers point to
non-overlapping memory regions then the compiler can optimize
better. This is one of the reasons why Fortran compilers
managed to do better than C for a long time.
On 09/21/2015 12:01 PM, Ola Fosheim Grøstad wrote:
> On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
>> I guess that the only thing that doesn't map directly to D is &&. The
>> others look on the D side like this:
>> C++ -> D
>> T* -> T*
>> T& -> ref T
>> const T*
How come it crashes a lot ?
> Glancing quickly at the source, it looks like it is using clang as a
> source of C++ truth.
It's crashing a lot because I make some incorrect assumptions about
what's in the AST and not everything is handled. Getting templates
right is hard, and cpp_binder doesn't
On 09/21/2015 05:29 AM, Jacob Carlborg wrote:
> On 2015-09-21 06:22, Paul O'Neil wrote:
>
>> I've written more about cpp_binder and my experiences at
>> http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.
>
> About the plugin architecture. I tried modifying DMD to run DStep to
On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
I guess that the only thing that doesn't map directly to D is
&&. The others look on the D side like this:
C++ -> D
T* -> T*
T& -> ref T
const T* -> const T*
const T& -> const ref T
I don't think D const and C++
On 09/19/2015 07:51 PM, Vladimir Panteleev wrote:
What would DMD identify itself as then, if a version is not specified on
make's command line?
It could use the output of `git describe`.
That would probably be better anyway, because non-release builds would
properly identify themselves as
On Monday, 21 September 2015 at 13:23:21 UTC, Rory McGuire wrote:
That takes forever on 2.068.0 as well. Even as:
import std.range;
uint[ushort.max] inst;
alias InstElem = ElementType!(typeof(inst));
even weirder (to me at least) its related to the number of
items in "inst". uint[1] is quick.
On Monday, 21 September 2015 at 09:59:44 UTC, ZombineDev wrote:
On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
[...]
Another option is to introduce a special built-in function like
std::move that just selects the rvalue overload. This would
require a language change, but
On Sunday, 20 September 2015 at 19:36:13 UTC, Sönke Ludwig wrote:
Getting close to the 1.0.0 milestone, this release implements
all of the major missing features except for a reviewed/cleaned
up D API. The most important changes in this release are:
clip
Download:
On Monday, 21 September 2015 at 14:30:19 UTC, Chris wrote:
What's the current state of D's GC. Will std.allocator improve
things eventually?
I don't understand the point of std.allocator.
AFAIK the current GC has very limited compiler support. A smart
compiler could move allocations to the
On Monday, 21 September 2015 at 12:04:11 UTC, Ola Fosheim Grøstad
wrote:
That is most likely even more work than creating a language
solution?
What's the current state of D's GC. Will std.allocator improve
things eventually?
On Monday, 21 September 2015 at 07:45:48 UTC, Ola Fosheim Grøstad
wrote:
On Monday, 21 September 2015 at 04:22:30 UTC, Paul O'Neil wrote:
I hope that this post will spur discussion / decisions /
action binding C++ libraries into D. I think the language
capabilities (e.g. extern(C++,
On Friday, 18 September 2015 at 19:26:27 UTC, Rory wrote:
The new GC in Go 1.5 seems interesting. What they say about is
certainly interesting.
http://blog.golang.org/go15gc
"To create a garbage collector for the next decade, we turned
to an algorithm from decades ago. Go's new garbage
On Monday, 21 September 2015 at 09:45:01 UTC, ZombineDev wrote:
[...]
Another option is to introduce a special built-in function like
std::move that just selects the rvalue overload. This would
require a language change, but would save us from adding && type
qualifiers (which is a far more
On Monday, 21 September 2015 at 18:28:19 UTC, jmh530 wrote:
My understanding is that the key benefit of Rust's system is
that compile time checks don't have the runtime costs of smart
pointers.
+ aliasing information.
If the compiler can prove that two pointers point to
non-overlapping
On Monday, 21 September 2015 at 11:01:27 UTC, ZombineDev wrote:
There's also a simple thing called smart pointers which do this
with RAII, copy and move semantics. Smart pointers manage the
lifetime of the object they point to automatically. You just
need to make sure that you access the
With Andrei working more on D maybe he will find time to document how the
compiler works better so more of us can contribute.
On Mon, Sep 21, 2015 at 4:23 AM, deadalnix via Digitalmars-d-announce <
digitalmars-d-announce@puremagic.com> wrote:
> On Sunday, 20 September 2015 at 23:43:29 UTC, Jack
On Sunday, 20 September 2015 at 23:43:29 UTC, Jack Stouffer wrote:
On Sunday, 20 September 2015 at 22:41:46 UTC, deadalnix wrote:
That's just bad excuses.
Excuses? Sure. Bad excuses? Not nearly. The other things I
listed are much more important (IMO) than making the GC faster.
The most
On 2015-09-21 06:22, Paul O'Neil wrote:
I've written more about cpp_binder and my experiences at
http://www.todayman.net/cpp_binder-pre-announcement-and-status.html.
About the plugin architecture. I tried modifying DMD to run DStep to
automatically generate bindings and use them directly. I
31 matches
Mail list logo
