On Monday, 30 July 2018 at 22:40:21 UTC, Hakan Aras wrote:
I'm trying to use extern(C++) classes with -betterC and I would
like to initialize their members properly.
I would also like to be able to use `extern(C++)` classes without
the runtime, but I haven't been able to allocate any time to
If anyone stumbles upon this thread and wants to do the same
thing, this article has some solutions:
https://theartofmachinery.com/2018/05/27/cpp_classes_in_betterc.html
Not perfect, but at least it's a start.
On Tuesday, 31 July 2018 at 00:29:45 UTC, Mike Franklin wrote:
I don't think it is set in druntime, but rather directly
emitted to the binary by the compiler as part of the object
code generation. I'm not sure if this is right, but check
That makes sense. I was hoping it would be possible
On Tuesday, 31 July 2018 at 00:29:45 UTC, Mike Franklin wrote:
I'm not sure if this is right, but check
https://github.com/dlang/dmd/blob/792fe5379af310cbd9348eca910cd5f8889d57ac/src/dmd/toobj.d#L368
Actually, this looks more like what you're looking for:
On Monday, 30 July 2018 at 22:40:21 UTC, Hakan Aras wrote:
Sorry if this is the wrong category.
Where in the druntime is m_init of TypeInfo_Class set? I'm
trying to use extern(C++) classes with -betterC and I would
like to initialize their members properly.
I don't think it is set in
On Monday, 30 July 2018 at 20:54:28 UTC, Simen Kjærås wrote:
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type
unless B specifically disables certain features, but it seems
weird
Sorry if this is the wrong category.
Where in the druntime is m_init of TypeInfo_Class set? I'm trying
to use extern(C++) classes with -betterC and I would like to
initialize their members properly.
On Monday, 30 July 2018 at 22:22:39 UTC, solidstate1991 wrote:
I need this to port a C++ code to D (a compression algorithm
known as LZHAM), and the easiest way to deal with it would be
that. The ADLER32 and CRC32 algorithms had to be ditched, and
while I could rewrite the former to make sense
I need this to port a C++ code to D (a compression algorithm
known as LZHAM), and the easiest way to deal with it would be
that. The ADLER32 and CRC32 algorithms had to be ditched, and
while I could rewrite the former to make sense (used some form of
"vectorization") I would like to use the
On 07/30/2018 10:40 AM, realhet wrote:
Hello,
I've already found out how to create an array with uninitialized
elements, but what I'm looking for is a way to append 16 uninitialized
ushorts to it and after I will it directly from 2 SSE registers.
The approximate array length is known at the
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type
unless B specifically disables certain features, but it seems
weird that disabling one opAssign disables all of them inside
the
On Monday, 30 July 2018 at 20:38:33 UTC, aliak wrote:
On Monday, 30 July 2018 at 20:20:15 UTC, Alex wrote:
On Monday, 30 July 2018 at 19:33:45 UTC, aliak wrote:
On Monday, 30 July 2018 at 18:47:06 UTC, Alex wrote:
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
[...]
What happens if
On Monday, 30 July 2018 at 20:20:15 UTC, Alex wrote:
On Monday, 30 July 2018 at 19:33:45 UTC, aliak wrote:
On Monday, 30 July 2018 at 18:47:06 UTC, Alex wrote:
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
[...]
What happens if you omit the @disable line?
Compiles ok then.
So...
On Monday, 30 July 2018 at 19:33:45 UTC, aliak wrote:
On Monday, 30 July 2018 at 18:47:06 UTC, Alex wrote:
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
[...]
What happens if you omit the @disable line?
Compiles ok then.
So... is this a valid workaround? ;)
On Monday, 30 July 2018 at 18:47:06 UTC, Alex wrote:
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type
unless B specifically disables certain features, but it seems
weird that
On 7/30/18 1:40 PM, realhet wrote:
Hello,
I've already found out how to create an array with uninitialized
elements, but what I'm looking for is a way to append 16 uninitialized
ushorts to it and after I will it directly from 2 SSE registers.
The approximate array length is known at the
On Monday, 30 July 2018 at 18:30:16 UTC, aliak wrote:
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type
unless B specifically disables certain features, but it seems
weird that disabling one opAssign disables all of them inside
the
Is this a bug?
If not is there a workaround?
I would like for the alias this to function as a normal A type
unless B specifically disables certain features, but it seems
weird that disabling one opAssign disables all of them inside the
aliases type but not in the aliasing type?
struct A {
Hello,
I've already found out how to create an array with uninitialized
elements, but what I'm looking for is a way to append 16
uninitialized ushorts to it and after I will it directly from 2
SSE registers.
The approximate array length is known at the start so I could be
able to do this
On Monday, 30 July 2018 at 10:23:06 UTC, CC wrote:
With "targetPath", it sounds like I'd need to modify a file
(DUB's .json file) that's in the source tree to indicate where
some(?)/all(?) of the files resulting from the build would be
stored.
Yes.
But it sounds like I'm maybe fighting
Not a question.
I came up with a nice and simple way to apply operations on an
arbitrary number of members of unknown type of a set of objects
of unknown type. This without having to reimplement these
operations for each class that needs to support the operation(s).
All this without
On Monday, 30 July 2018 at 01:50:23 UTC, CC wrote:
[...]
My usual modus operandi is:
1. check out the project into some directory "foo".
2. create another directory "foo.build", somewhere outside of
"foo".
3. "cd foo.build"
4. Run some configuration script/file located in "foo", to
generate
On Thursday, 26 July 2018 at 16:52:31 UTC, Ali Çehreli wrote:
[snip]
It doesn't but the scope itself is legal in a nested scope; so,
'const' should not remove the scope either.
> It works at the
> global level just fine.
It must be because one cannot introduce a nested scope at the
global
On Monday, 30 July 2018 at 07:34:04 UTC, Alex wrote:
I've started playing with "dub", and it *seems* to assume that
you want the files generated during the build process to
reside directly inside your checked-out source tree.
Is that true? And if so, am I fighting dub's design by
attempting
On Sunday, 29 July 2018 at 23:03:27 UTC, Johannes Loher wrote:
Yeah, I know that it possible to implement the template like
this, but that is not the point here. I would like to know why
it does not work the way I described it. To me it seems very
strange, that `S : T` has different semantics
On Monday, 30 July 2018 at 01:50:23 UTC, CC wrote:
Before starting with D programming, most of my projects have
configured their build systems with Autotools or CMake, and git
for source control.
With those systems, it's usually considered best practice to
store all files generated during
26 matches
Mail list logo
