On Friday, 15 July 2016 at 19:20:52 UTC, Jacob Carlborg wrote:
Yes. Just as it's possible to call C function from D, it's
possible to implement functions in D that can be called from C.
This compatibility applies C++ and Objective-C as well.
So, it applies to member functions too (for C++)?
On Friday, 15 July 2016 at 23:07:20 UTC, Andrey wrote:
Hi guys!
Can any one tell me - how to pass an array of int's in to the
template struct at compile-time, and how to use int there?
Like this: https://dpaste.dzfl.pl/844057da81e9 ?
Hi guys!
Can any one tell me - how to pass an array of int's in to the
template struct at compile-time, and how to use int there?
I'm wondering how I can use the output of __traits(getOverloads,
a, "name"). The example in the doc uses direct indexing (like
__traits(getOverloads, a, "name")[0](param)) and it works. But
I'm struggling with iterating through the result or storing the
resulting tuple into a local var.
On Friday, 15 July 2016 at 17:41:21 UTC, Michael Coulombe wrote:
Your issue is this line:
alias boxAR(A) = Box!(A, R);
This means that A must be a type, but you are trying to
instantiate it with lambdas. If you switch to:
alias boxAR(alias A) = Box!(A, R);
But now you are back to the
On 2016-07-15 19:52, cy wrote:
I would never (ever) do this myself, but trying to understand dmd, the
code is absolutely packed with things like this:
extern(C++) class Package : ScopeDSymbol
{
...
override const(char)* kind() const
{
return "package";
}
...
override final
I would never (ever) do this myself, but trying to understand
dmd, the code is absolutely packed with things like this:
extern(C++) class Package : ScopeDSymbol
{
...
override const(char)* kind() const
{
return "package";
}
...
override final inout(Package) isPackage() inout
{
On Friday, 15 July 2016 at 17:00:09 UTC, jmh530 wrote:
I was working with the lightweight wrapper and it seemed to
work for simple stuff, but then I started getting a bunch of
errors when I tried to integrate it in to my project.
Below is the stripped down version of what I've been working
On Monday, 20 June 2016 at 16:39:54 UTC, Marc Schütz wrote:
Untested:
Seems to only work if A and B are both defined in the same file
as Foos (defeating the purpose). Putting A and B in a.d and b.d
respectively gives me these errors:
a.d(2): Error: undefined identifier 'Foos'
a.d(2):
On Saturday, 9 July 2016 at 05:40:10 UTC, ag0aep6g wrote:
On 07/09/2016 12:33 AM, jmh530 wrote:
I'm trying to create a tuple of variadic length containing
structs with
mixed types. So for instance, given
struct Foo(T, U)
{
T x;
U y;
}
I want to create something like
Use an intermediate class:
abstract class OtherObject1(S) : AbstractObject!S
{
abstract void Foo(int a, int b);
class OtherObject(S, bool R) : OtherObject1!S
{
int x;
override void Foo(int a, int b)
On Friday, 15 July 2016 at 15:04:22 UTC, Devin Hill wrote:
to the condition. It works pretty well! Granted, it doesn't
allow for calling it in two ways like a variadic version would
have:
foo(1, 2, 3) // works with this setup
foo([1, 2, 3]) // doesn't, but would only be occasionally
abstract class AbstractObject(S)
if (IsSomeString!S)
{
}
class OtherObject(S, bool R) : AbstractObject!S
{
int x;
void Foo(int a, int b)
{
x = a + b;
static if (R) // error
{
// more codes .
}
}
}
class OtherObjects(S) :
Hi Claude!
On Friday, 15 July 2016 at 14:09:40 UTC, Claude wrote:
Hello,
I would like to cross-compile a D program from a x86 machine to
an ARM target.
[...]
So I'm a bit confused of what the current state of LDC+ARM is.
For example, is the run-time fully ported on ARM/Linux?
LDC is fully
On Friday, 15 July 2016 at 15:02:15 UTC, Radu wrote:
Hi,
LDC on Linux ARM is fairly complete. I think it is a fully
supported platform (all tests are passing). Check in
https://wiki.dlang.org/Compilers the LDC column.
This is the close for a tutorial for cross-compiling
On 07/15/2016 02:51 PM, maik klein wrote:
Thanks I didn't know that you could have type qualifiers inside
templates, D still surprises me sometimes.
Qualifiers are part of the type. So wherever you can have a type, you
can have a qualified type.
I don't think it is practical to call move
On Friday, 15 July 2016 at 05:23:15 UTC, Basile B. wrote:
even better:
template sameType(T...)
{
import std.meta;
static if (!T.length)
enum sameType = false;
else
enum sameType = NoDuplicates!T.length == 1;
}
Yeah, that's basically what I ended up doing, but
On Friday, 15 July 2016 at 14:09:40 UTC, Claude wrote:
Hello,
I would like to cross-compile a D program from a x86 machine to
an ARM target.
I work on GNU/Linux Ubuntu 64-bit.
I have an ARM gcc toolchain, which I can use to make programs
on an ARM Cortex-A9 architecture running a Linux
Hello,
I would like to cross-compile a D program from a x86 machine to
an ARM target.
I work on GNU/Linux Ubuntu 64-bit.
I have an ARM gcc toolchain, which I can use to make programs on
an ARM Cortex-A9 architecture running a Linux kernel 3.4.11+.
I managed to build and install LLVM 3.8.1
On Friday, 15 July 2016 at 12:05:47 UTC, ag0aep6g wrote:
On 07/15/2016 10:29 AM, maik klein wrote:
[...]
Sure. Just instantiate Rc with a const/immutable T. I.e., write
`Rc!(const int)` instead of `const Rc!int`. Or with auto and
makeRc: `auto rc = makeRc(immutable int(5));`.
[...]
On Friday, 15 July 2016 at 11:36:27 UTC, ag0aep6g wrote:
On 07/15/2016 10:11 AM, nik wrote:
[...]
[...]
[...]
void is somewhat special. It can't be used to declare variables
or as a parameter type. So you'll have to approach this a bit
differently. You also can't have a struct constructor
On 07/15/2016 10:29 AM, maik klein wrote:
There are two things that bothered me for quite some time
Interior immutability:
Consider a something like this
https://dpaste.dzfl.pl/fa5be84d26bc
The implementation is totally wrong and it doesn't make sense, but it
shows that Rc can not be
On 07/15/2016 04:16 PM, Jerry wrote:
> Unittests have to be inside a module to be run on DMD atleast.
> So putting module foo at top should fix it.
Strange. Still not getting picked up.
$ dmd --version
DMD64 D Compiler v2.071.0
Copyright (c) 1999-2015 by Digital Mars written by
On 2016-07-15 04:17, dan wrote:
Thanks Jacob!
I was unaware of Orange.
Available on Dub now as well: https://code.dlang.org/packages/orange
--
/Jacob Carlborg
Unittests have to be inside a module to be run on DMD atleast.
So putting module foo at top should fix it.
On 07/15/2016 12:54 PM, dom wrote:
i just had a scenario like the one below. when calling .array on the
filterresult dmd goes nuts because of the init() function in Players.
Renaming to initialize() solved the problem.
Solution: As .init is used for struct initialization and such
On 07/15/2016 10:11 AM, nik wrote:
One thing I cant figure out/don't know if is possible is to have a type
that takes "void" (see last unittest)
[...]
Result type:
struct Result(T, E)
{
this(inout T result) inout
{
_result = result;
_is_result = true;
}
The test I have in 'app.d' don't get picked up by 'dub test' in a
freshly created project by 'dub init'.
$ dub test
Generating test runner configuration '__test__library__' for
'library' (library).
Performing "unittest" build using dmd for x86_64.
dplay ~master: building
On Friday, 15 July 2016 at 08:11:13 UTC, nik wrote:
//unittest
//{
// auto result_1 = Result!(void, string)(void);
// auto result_2 = Result!(void, string)(void);
// assert(result_1.is_result);
// assert(result_1 == result_2);
//}
You wanted to handle the void case?
i just had a scenario like the one below. when calling .array on
the filterresult dmd goes nuts because of the init() function in
Players. Renaming to initialize() solved the problem.
Solution: As .init is used for struct initialization and such
(https://dlang.org/spec/property.html#init) i
On Wednesday, 13 July 2016 at 02:20:58 UTC, anonymous wrote:
On Tuesday, 12 July 2016 at 14:04:55 UTC, Seb wrote:
D is entirely driven by highly motivated volunteers. (this
will change soon with the new D foundation)
With the fundation, volunteers wont be highly motivated
anymore. Fundations
Just as a follow-up, I think it's looking more and more like a
compiler bug. It works properly both with gdc and ldmd2. Should I
make a bug report about that?
There are two things that bothered me for quite some time
Interior immutability:
Consider a something like this
https://dpaste.dzfl.pl/fa5be84d26bc
The implementation is totally wrong and it doesn't make sense,
but it shows that Rc can not be const/immutable because at least
"dup" needs to
Hi all,
I've been using D for a week now to compare it to Rust as a
replacement to C++.
One thing I miss from Rust is
https://doc.rust-lang.org/std/result/ and its companion
https://doc.rust-lang.org/std/macro.try!.html
They make for some nice syntax so I had a go at recreating them
in D
34 matches
Mail list logo
