Re: Alias function with arguments
On Thursday, 11 July 2019 at 03:13:43 UTC, Jamie wrote:
Is it possible to alias a function and its arguments, but for
that function to only be evaluated when the alias is used? For
example
alias pragma(inline, true) inline
inline
void func(){}
What you're asking for is possible (see
https://run.dlang.io/is/2Lh4Dr for example).
However I don't believe the code sample you're showing is
possible, because aliases always evaluate to types or values and
you can't use either of those as a function attribute. Also
pragmas are not functions.
WeakRef implementation
Is this implementation of WeakRef correct? Is it portable? I
tested it and it seems to work, but I'm not real familiar with
the runtime or the GC. Also is there any way to convert this into
a struct instead of class? (Not possible this way due to frame
pointer for onDispose)
extern (C) void rt_attachDisposeEvent(Object, void
delegate(Object));
extern (C) void rt_detachDisposeEvent(Object, void
delegate(Object));
class WeakRef(T) if (is(T == class)) {
this(T element) {
address = *cast(size_t*) - offset;
rt_attachDisposeEvent(element, );
}
private extern (C) void onDispose(Object _) {
assert(_ is element);
address = 0 - offset;
}
alias element this;
inout(T) element() inout {
size_t result = address + offset;
return *cast(typeof(return)*)
}
private static immutable size_t offset = 16_785_407;
private size_t address;
}
auto weakRef(T)(T element) {
return new WeakRef!T(element);
}
Re: Can this recursive template type with named type parameters be simplified or improved?
On Sunday, 21 October 2018 at 21:23:35 UTC, aliak wrote: Hi, I'm playing around with a recursive template type that allows for named template parameters. The problem is that it requires a lot of repetition and becomes more error prone as the number of named arguments increase. So 1) Any ideas on how to make it less error prone? less repetition? a better way to do this? 2) Right now I can only have named optional parameters. Any ideas on how to make named required parameters (e.g. the first type parameter of Type). I don't know if this is at all helpful, but I spent an hour on it, so I'm going to share it: https://pastebin.com/cGZwc649 You can wrap it in a template if you want to retain the ability to pass arguments without names. Regards, Hakan
Re: Implicit conversion by return
On Wednesday, 8 August 2018 at 08:44:03 UTC, Alex wrote: return typeof(return)(5); Ah thanks, I was wondering if something like that exists. Still though, that's 16 extra characters that dont need to be there.
Implicit conversion by return
Given this:
struct Num
{
this(int a) {}
}
Is there any reason why this works:
Num n = 5;
but this doesnt:
Num funk()
{
return 5;
}
I understand that I can construct it explicitely, but that gets
annoying quickly, especially with templates.
Re: Can you tell if an template alias parameter is of a specific template?
I don't think you can distinguish between entities evaluated
through different templates. TemplateOf will paradoxically not
work on pure templates of the form "template X() {}" only things
like template functions and template structs. isSame, is, and
isInstanceOf will only work on the fully evaluated type or alias
(pred) not the template that was used to evaluate it.
If I understood your usecase correctly, you could do something
like this though:
https://run.dlang.io/is/VwZoAx
That is use an enum as a template parameter instead of wrapping
the predicate in a template.
Re: Where is TypeInfo_Class.m_init set
On Thursday, 2 August 2018 at 10:54:17 UTC, kinke wrote: Those 4 bytes for the struct is trailing padding, so that the struct is 16 bytes large, a multiple of its 8-bytes alignment (due to the pointer). Classes on the other hand aren't padded (they don't need to be, as there are no contiguous arrays of class instances, just class references). In this case, you could use `align(1) struct BazInitializer` to prevent the struct tail padding. Oh yeah, forgot about alignment. It's no use though. Unless I can get my hands on the internal "struct" type of Baz somehow, LDC is not gonna let me declare it: https://github.com/ldc-developers/ldc/blob/69104bdbf94713431cbc67151c1b34a6a5e0df34/gen/llvmhelpers.cpp#L1759
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 20:45:11 UTC, kinke wrote:
Sorry, scratch that, I forgot the `extern` before the dummy
global. After fixing that, I didn't quickly find a solution for
referencing the symbol in the .data.rel.ro section (LLVM asm,
e.g., `void* getInit() { return __asm!(void*)("movq
test.C.__init, %rax", "={rax}"); }` doesn't work either).
The compiler could emit the init symbol as regular global for
`-betterC` though.
---
This issue could also be tackled in the D ctor of the
extern(C++) class, by injecting the blit before the actual ctor
body. C++ code wouldn't have to take care about that D-interop
incompatibility anymore (independent of -betterC).
I looked into that approach a little and it was pretty
successful, at least for DMD:
https://run.dlang.io/is/KDHoI9
LDC complains about the type of initializer though:
onlineapp.d(22): Error: Global variable type does not match
previous declaration with same mangled name: _D5bclib3Baz6__initZ
onlineapp.d(22):Previous IR type: %bclib.Baz = type { [1
x i8*]*, i32 }
onlineapp.d(22):New IR type: %bclib.BazInitializer =
type { [1 x i8*]*, i32, [4 x i8] }
Any ideas on how to match the type exactly? I don't quite
understand why there are 4 bytes at the back of BazInitializer.
Re: pointer cast from const(Y) to immutable(void*)** is not supported at compile time
On Thursday, 2 August 2018 at 01:39:58 UTC, Nicholas Wilson wrote: https://issues.dlang.org/show_bug.cgi?id=19134 I wasn't quite sure whether it's a bug since it happens in both compilers. Thanks for opening the issue. As a workaround remove static, as that causes y to be initialised at compile time. I do want it at compiletime though. static here has nothing to do with static_cast in C++. The analogy to a static_cast would be const X x = new Y(); casting up the hierarchy, as opposed to dynamic casting down the hierarchy. Sorry, I actually meant a reinterpret_cast. I always get those mixed up. But now that I look at it again I don't see how that would help me, since my code isn't the one trying to to casting.
Re: pointer cast from const(Y) to immutable(void*)** is not supported at compile time
On Wednesday, 1 August 2018 at 16:25:28 UTC, Hakan Aras wrote: https://run.dlang.io/is/dSVruv Whoops, that was the wrong one. It's fixed now.
pointer cast from const(Y) to immutable(void*)** is not supported at compile time
Why does the following work in DMD 2.080 and LDC 1.10, but not in DMD 2.081 and LDC 1.11 beta: https://run.dlang.io/is/dSVruv And is there a way to enforce the cast like a static_cast in C++?
Re: Where is TypeInfo_Class.m_init set
On Tuesday, 31 July 2018 at 03:42:15 UTC, Mike Franklin wrote: 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 it yet. If you're trying to use `extern(C++)` classes with betterC, and the compiler is complaining about `TypeInfo` give me an example illustrating the problem, and I might be able to submit a fix to the compiler. Mike It's working fine so far. Only problem is that the class needs to be compiletime constructible to get the initializer.
Re: Where is TypeInfo_Class.m_init set
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.
Re: Where is TypeInfo_Class.m_init set
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 without tinkering with the compiler, but it doesn't seem to be the case.
Where is TypeInfo_Class.m_init set
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.
