Re: Preffered way of writing variadic templated functions in 2.079
On Thursday, March 08, 2018 08:36:09 Nordlöw via Digitalmars-d-learn wrote:
> Is using
>
> https://dlang.org/changelog/2.079.0.html#default_after_variadic
>
> for instance as
>
> void show(Args...)(Args args,
> string file = __FILE__,
> uint line = __LINE__,
> string fun = __FUNCTION__)
> if (Args.length >= 1)
> {
> ...
> }
>
> preferred over previous usage
>
> template show(Args...)
> if (Args.length >= 1)
> {
> void show(string file = __FILE__,
>uint line = __LINE__,
>string fun = __FUNCTION__)
> {
> ...
> }
> }
>
> or are the two version equally good in terms of run-time,
> compile-time and (lack of) template symbol bloatedness?
>
> See also
>
> https://github.com/nordlow/phobos-next/blob/master/src/dbgio.d#L53
Well, the first one works with IFTI, whereas the second one does not,
because the template arguments are not use in the function. So, you can just
call the first one, whereas the second one will have to be explicitly
instantiated in order to be called. And the second one has no runtime
arguments corresponding to the template arguments, meaning that the two
examples are really quite different. If what you meant was really
template show(Args...)
if (Args.length >= 1)
{
void show(Args args,
string file = __FILE__,
uint line = __LINE__,
string fun = __FUNCTION__)
{
...
}
}
then that's basically identical to the first template, because that's what
the first template gets lowered to. Directly templatizing a function or type
is just a shortcut.
The big thing that you want to avoid doing is having the file and line
number be template arguments rather than function arguments, because then
you get a different template instantiation for each combination of file and
line number, meaning that in practice, you're going to get a different
instantiation of the function template every time you call it, which is
definitely not good. However, now that it's been fixed so that you can have
default arguments after a variadic template argument, there's really no need
to do that, whereas previously, stuff like std.logger pretty much had to.
- Jonathan M Davis
Preffered way of writing variadic templated functions in 2.079
Is using
https://dlang.org/changelog/2.079.0.html#default_after_variadic
for instance as
void show(Args...)(Args args,
string file = __FILE__,
uint line = __LINE__,
string fun = __FUNCTION__)
if (Args.length >= 1)
{
...
}
preferred over previous usage
template show(Args...)
if (Args.length >= 1)
{
void show(string file = __FILE__,
uint line = __LINE__,
string fun = __FUNCTION__)
{
...
}
}
or are the two version equally good in terms of run-time,
compile-time and (lack of) template symbol bloatedness?
See also
https://github.com/nordlow/phobos-next/blob/master/src/dbgio.d#L53
Re: Can't "is null" an interface?!?! Incompatible types???
On Thursday, 8 March 2018 at 08:04:54 UTC, Nick Sabalausky (Abscissa) wrote: Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to work on run.dlang.io). But it does seem to work for me if I use 'v0.8.3-alpha.1'. I wonder what could have changed to result in this? It's a struct in "v0.8.3-rc.1" [1]. In "v0.8.3-rc.1" the new vibe-core package is the default configuration. [1] https://github.com/vibe-d/vibe-core/blob/master/source/vibe/core/net.d#L467 -- /Jacob Carlborg
Re: Can't "is null" an interface?!?! Incompatible types???
On 03/08/2018 01:13 AM, Nicholas Wilson wrote:
That does seem odd.
---
/+dub.sdl:
dependency "vibe-d" version="~>0.8.3-alpha.1"
+/
import vibe.core.net;
import std.stdio;
TCPConnection mySocket;
void main() {
auto b = mySocket is null;
writeln(b);
}
---
works fine on run.dlang.io
Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to
work on run.dlang.io). But it does seem to work for me if I use
'v0.8.3-alpha.1'.
I wonder what could have changed to result in this?
Re: Can't "is null" an interface?!?! Incompatible types???
On 03/08/2018 03:04 AM, Nick Sabalausky (Abscissa) wrote: Interesting. I was using vibe.d 'v0.8.3-rc.1' (which doesn't appear to work on run.dlang.io). But it does seem to work for me if I use 'v0.8.3-alpha.1'. I wonder what could have changed to result in this? https://github.com/vibe-d/vibe.d/issues/2108
Re: Elegant way to use dynamic bindings
On Friday, 9 February 2018 at 20:19:33 UTC, Dennis wrote:
I'd still like to find a nice way to generate the boilerplate
code for dynamic loading, if I come up with something I'll post
it here.
So I ended up using an import library for a while, but I then
wanted to get the handle of the DLL, which I don't know how to do
with an import library. I also didn't like the non-customizable
Windows pop-ups that appear when the libraries can't be found so
I finally wrote some mixin code to generate the boilerplate for
dynamic loading:
https://gist.github.com/dkorpel/3bf108ca48cb43bdbe3cc8bf30405b4d
Now you only need to declare the functions in a Struct:
```
struct FunctionsInMyDLL {
int getVersion();
string getName();
// more functions
}
```
And the templates do the rest. :)
Re: docs/definition: !object
On 3/8/18 1:00 AM, Nick Sabalausky (Abscissa) wrote: On 03/08/2018 12:05 AM, ketmar wrote: Nick Sabalausky (Abscissa) wrote: I'm having trouble finding the documentation for what exactly the unary "not" operator does when applied to a class/interface object. Does this documentation exist somewhere? I know at least part of it involves "is null", but I seem to remember hearing there was more to it than just that. https://dlang.org/spec/operatoroverloading.html#boolean_operators "Class references are converted to bool by checking to see if the class reference is null or not." Ah, thanks. But are we CERTAIN that's all there is to it? I have a non-reduced situation right now where outputting the address of a class reveals a non-null address, and yet assert(!!theObjectInQuestion) is failing. (this is occurring during stack unwinding, if that makes a difference) One thing to keep in mind, assert(someObject) does more than just check if it's not null, it also runs the object's invariant to see if it's valid. I'm not sure about assert(!!someObject), probably this is just checking for non-null, but I'm not sure if the compiler folds this into assert(someObject) (which would be a bug, but may explain things). To be more pedantic, I'd recommend assert(someObject !is null) -Steve
Re: Generic test bit function (core.bitop)
On Wednesday, 7 March 2018 at 13:26:06 UTC, Alex wrote: From this point of view, size_t is not fixed, but capable to point to any place in memory. Therefore, pointer of any type have by definition exactly the defined size of size_t. Thank you,I thougth that pointer aliasing wasn't allowed.
Re: VsCode tutorial
On Wednesday, 7 March 2018 at 21:39:09 UTC, Apocalypto wrote: Are there any tutorials about D in vscode? Which are the minimal plugins to install to have code completion, syntax highlighting and code formatting? Are there any app templates that i can invoke to not start every project from scratch? How can I debug my app? See: https://marketplace.visualstudio.com/items?itemName=webfreak.code-d It also comes with lots of templates.
Re: how do I pass this callback?
On Thursday, 8 March 2018 at 17:06:05 UTC, Marc wrote: How do I define the callback so that it can be used in RegisterWaitForSingleObject()? I've tried pass as argument: myFunc myFunc.ptr none worked. Here's my code: [...] Function call: [...] Error: [...] Solved! I shall rather use extern (Windows) not extern(C): extern (Windows) void OnExited(void* context, BOOLEAN isTimeOut);
how do I pass this callback?
How do I define the callback so that it can be used in RegisterWaitForSingleObject()? I've tried pass as argument: myFunc myFunc.ptr none worked. Here's my code: extern (C) void OnExited(void* context, BOOLEAN isTimeOut); extern(Windows): BOOL RegisterWaitForSingleObject( PHANDLE phNewWaitObject, HANDLE hObject, WAITORTIMERCALLBACK Callback, PVOID Context, ULONG dwMilliseconds, ULONG dwFlags ); Function call: RegisterWaitForSingleObject(, hProcess, , NULL, INFINITE, WT_EXECUTEONLYONCE); Error: function a.RegisterWaitForSingleObject(void** phNewWaitObject, void* hObject, extern (Windows) void function(void*, bool) Callback, void* Context, uint dwMilliseconds, uint dwFlags) is not callable using argument types (void**, void*, extern (C) void function(void* context, bool isTimeOut), typeof(null), uint, uint) a.d(38):cannot pass argument & OnExited of type extern (C) void function(void* context, bool isTimeOut) to parameter extern (Windows) void function(void*, bool) Callback
Re: dub / win 64 / unresolved externals from run-time lib?
On Thursday, 8 March 2018 at 17:03:18 UTC, Robert M. Münch wrote: Using Dub and pretty simple setup, that links in 3 C/C++ static libraries, I get these linker errors: libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp_fmodf referenced in function "void __cdecl YGRoundToPixelGrid(struct YGNode * const,float,float,float)" (?YGRoundToPixelGrid@@YAXQEAUYGNode@@MMM@Z) libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp__CrtDbgReportW referenced in function "void * __cdecl std::_Allocate_manually_vector_alignedstd::_Default_allocate_traits>(unsigned __int64)" (??$_Allocate_manually_vector_aligned@U_Default_allocate_traits@std@@@std@@YAPEAX_K@Z) The first I don't understand as it should be in some run-time libraries. The second indicates a problem with debug / non-debug runtime libraries. However, I would expect that the correct run-time libraries are used. I'm building my code with just: dub build --arch=x86_64 Any idea? By the looks of it, the C(++) libs have been compiled with /MDd (debug DLL version of MSVC runtime libs), while DMD and LDC default to the static (release) libs, i.e., /MT. The according switch for DMD/LDC is `-mscrtlib` IIRC.
dub / win 64 / unresolved externals from run-time lib?
Using Dub and pretty simple setup, that links in 3 C/C++ static libraries, I get these linker errors: libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp_fmodf referenced in function "void __cdecl YGRoundToPixelGrid(struct YGNode * const,float,float,float)" (?YGRoundToPixelGrid@@YAXQEAUYGNode@@MMM@Z) libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp__CrtDbgReportW referenced in function "void * __cdecl std::_Allocate_manually_vector_alignedstd::_Default_allocate_traits>(unsigned __int64)" (??$_Allocate_manually_vector_aligned@U_Default_allocate_traits@std@@@std@@YAPEAX_K@Z) The first I don't understand as it should be in some run-time libraries. The second indicates a problem with debug / non-debug runtime libraries. However, I would expect that the correct run-time libraries are used. I'm building my code with just: dub build --arch=x86_64 Any idea? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: dub / win 64 / unresolved externals from run-time lib?
On 2018-03-08 17:24:32 +, kinke said: On Thursday, 8 March 2018 at 17:03:18 UTC, Robert M. Münch wrote: Using Dub and pretty simple setup, that links in 3 C/C++ static libraries, I get these linker errors: libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp_fmodf referenced in function "void __cdecl YGRoundToPixelGrid(struct YGNode * const,float,float,float)" (?YGRoundToPixelGrid@@YAXQEAUYGNode@@MMM@Z) libyogacore.lib(Yoga.obj) : error LNK2019: unresolved external symbol __imp__CrtDbgReportW referenced in function "void * __cdecl std::_Allocate_manually_vector_alignedstd::_Default_allocate_traits>(unsigned __int64)" (??$_Allocate_manually_vector_aligned@U_Default_allocate_traits@std@@@std@@YAPEAX_K@Z) The first I don't understand as it should be in some run-time libraries. The second indicates a problem with debug / non-debug runtime libraries. However, I would expect that the correct run-time libraries are used. I'm building my code with just: dub build --arch=x86_64 Any idea? By the looks of it, the C(++) libs have been compiled with /MDd (debug DLL version of MSVC runtime libs), Hi, that's correct. while DMD and LDC default to the static (release) libs, i.e., /MT. Interesting... this little but important detail is not very well document. The only reference I found is [1] but nothing in the official compiler documentation page. The according switch for DMD/LDC is `-mscrtlib` IIRC. Yes, it is. Seems there is no difference between multi-threaded and non-multi-threaded. Thanks, that worked. [1] https://dlang.org/changelog/2.073.0.html#mscrtlib-option -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: extern (c) struct ?
On 2018-03-08 16:03:57 +, Adam D. Ruppe said: How are you accessing it? If it is by pointer only passing it to methods, you can simply: struct my_cpp_struct; and define functions: extern(C) void foo(my_cpp_struct* arg); Hi, :-/ seems I was a bit confused by all the backs and forth on my side. Yes, this will of course work and is sufficient to move on. And the defined functions can be aliased, right? then just declare functions you need and always use as opaque pointer. When running in the VisualD environment in debugging mode, I can't dive into the my_cpp_struct. Seems the debugger doesn't uncover opaque pointers. Or do I need to tell it somehow about it? -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: docs/definition: !object
On 03/08/2018 05:31 AM, Steven Schveighoffer wrote: On 3/8/18 1:00 AM, Nick Sabalausky (Abscissa) wrote: But are we CERTAIN that's all there is to it? I have a non-reduced situation right now where outputting the address of a class reveals a non-null address, and yet assert(!!theObjectInQuestion) is failing. (this is occurring during stack unwinding, if that makes a difference) Turns out it wasn't a class at all: As Jacob pointed out in my other thread, it *used* to be a class/interface in a previous lib version (vibe's TCPConnection) but got changed to a struct without my noticing. Hence the seemingly weird behaviours. One thing to keep in mind, assert(someObject) does more than just check if it's not null, it also runs the object's invariant to see if it's valid. Ahh, right! *That's* the part I knew I'd heard about and was trying to remember.
Re: Generic Property Implementation
On Friday, 9 March 2018 at 01:22:15 UTC, Mike Franklin wrote: I would like to know if this can be improved to support the following: * binary assignment operators (e.g. +=) * unary assignment operators (e.g. ++) * @safe, @nogc, and -betterC compatible * at least as good code generation as that proposed in the DIP when optimizations are enabled. * And should be scalable to data that isn't addressable (e.g. bitfields). See https://issues.dlang.org/show_bug.cgi?id=16187
does the shared keyword work with mutable structs?
I read where shared classes have not been implemented yet. So I'm
using
just a struct e below: But the output below is showing that
sharing is
not happening between Struct in main() and the various spawned
threads.
I'm I doing something wrong?
creating queue in EventBuffer constructor
eventBuffer.enter = 1
eventBuffer.leave = 0
eB.enter = 0
eB.enter = 0
eB.leave = 0
eB.leave = 0
eB.enter = 0
eB.leave = 0
void producer(in ref shared(EventBuffer) eB, shared(Lock) lock)
{
writeln("eB.enter = ", eB.enter);
writeln("eB.leave = ", eB.leave);
Event event;
foreach(i; 0..7)
{
synchronized(lock)
{
event.keyPressed = i;
eB.enterOrLeaveQueue(Direction.Entering, event);
}
}
}
void main()
{
shared(Lock) lock = new shared(Lock)();
shared(EventBuffer) eventBuffer = EventBuffer(50);
writeln("eventBuffer.enter = ", eventBuffer.enter);
writeln("eventBuffer.leave = ", eventBuffer.leave);
foreach(i; 0..3)
{
spawn(, eventBuffer, lock);
}
}
Re: Generic Property Implementation
On Tuesday, 20 February 2018 at 14:34:53 UTC, bauss wrote: Would there be a reason why this wouldn't be a good implementation? If so what and how could it be improved? Are there flaws in an implementation like this? [... snip ...] I am very interested in this as a potential alternative to the binary assignment operators for properties DIP (https://github.com/JinShil/DIPs/blob/master/DIPs/DIP1xxx-mvf.md) I would like to know if this can be improved to support the following: * binary assignment operators (e.g. +=) * unary assignment operators (e.g. ++) * @safe, @nogc, and -betterC compatible * at least as good code generation as that proposed in the DIP when optimizations are enabled. D has the philosophy that the language should strive to provide composable primitives, and delegate syntactic sugar to libraries. I like that philosophy and I think it would prevent an expense of limited resources if we could find a good library implementation for this. Mike
Re: extern (c) struct ?
On Thursday, 8 March 2018 at 15:51:53 UTC, Robert M. Münch wrote: I have a pretty complex struct with C++ typed private members etc. in it which I want to use from D. How are you accessing it? If it is by pointer only passing it to methods, you can simply: struct my_cpp_struct; and define functions: extern(C) void foo(my_cpp_struct* arg); then just declare functions you need and always use as opaque pointer.
extern (c) struct ?
I have a pretty complex struct with C++ typed private members etc. in it which I want to use from D. Obviously I don't want to/can't rebuild the struct definiton in D and I don't need access to all the members just some simple C API ones are enough. How can I get access to this struct from D? I mean something like: alias my_d_struct = extern(c) my_cpp_struct; -- Robert M. Münch http://www.saphirion.com smarter | better | faster
Re: Thread Function does not executes
On Tuesday, 6 March 2018 at 09:01:55 UTC, Vino wrote: On Monday, 5 March 2018 at 13:50:28 UTC, Vino wrote: [...] Hi All, On further analysis, as to why the function deleteAgedDir is not getting executed, found that if this function finds a folder to be deleted then it should delete the folder(rmdirRecurse(dirname)), but in this case it does not delete the folder if it finds so the return of this function is empty, if there are no file to be deleted then this function works perfectly but if there is any folder preset to be deleted this that folder is not getting deleted, so i am suspecting that the issue is with the function rmdirRecurse is not working as expected on Windows 2007, so request your help on this please. From, Vino.B Hi All, If I compile the program with 32bit(without passing -64m) then everything is working as expected. So can any one explain why the program(rmdirRecurse) does not work when compiled with 64 bit. From, Vino.B
