Re: C++ interface vs D and com
On Wednesday, 13 July 2016 at 02:49:54 UTC, Adam Sansier wrote:
On Wednesday, 13 July 2016 at 02:34:14 UTC, Mike Parker wrote:
What happens when you declare an interface that extends from
IUnknown (and not extern(C++)), then cast the pointer returned
from the COM API? It should just work without needing to muck
around with the vtable.
That was what I tried first, It didn't work. I don't know what
the problem though. I either get an access violation or the
functions don't do anything.
Perhaps you forgot to call CoInitialize{Ex}?
I think it's more complex because without extern(C++) the
vtable is in a different place than expected(it's offset by 1),
so simple casting does not work.
"A COM interface differs from a regular interface in that there
is no object.Interface entry in vtbl[0]; the entries vtbl[0..$]
are all the virtual function pointers, in the order that they
were declared. This matches the COM object layout used by
Windows.
A C++ interface differs from a regular interface in that it
matches the layout of a C++ class using single inheritance on
the target machine. "
You don't need extern(C++) for COM interfaces. There are several
declared in the Windows bindings that each inherit from IUnknown
and there's no extern(C++) in sight (they existed long before C++
support did). Here's a working example using one of them,
IShellLinkW, declared in core.sys.windows.shlobj.
```
import core.sys.windows.windows,
core.sys.windows.shlobj,
core.sys.windows.com;
pragma(lib, "Ole32");
void main()
{
IShellLinkW iface;
auto shellLinkCLSID = CLSID_ShellLink;
auto shellLinkIID = IID_IShellLinkW;
CoInitialize(null);
scope(exit)CoUninitialize();
auto hr = CoCreateInstance(
,
null,
CLSCTX_INPROC_SERVER,
,
cast(void**)
);
if(SUCCEEDED(hr)) {
import std.stdio : writeln;
writeln("Got it!");
iface.Release();
}
else throw new Exception("Failed to create IShellLink
instance");
}
```
There's a minor annoyance here in that the IID constants are all
declared in the Windows bindings as manifest constants, which is
normally the smart thing to do with constants. However, they're
intended to be used as lvalues with the COM API, so I had to save
them off in local variables in order to take their addresses. You
can do whatever you want with your own declarations, of course.
Re: adding toString to struct
On Wednesday, 13 July 2016 at 02:29:12 UTC, Jesse Phillips wrote: On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: windows libs have a lot of structs and it would be nice to have the ability to convert them to a string to see them in the debugger(e.g., CLSID). Is there a way to do this? I've tried to pull out the code from the libs but it if a total clusterfuck. std.conv.to will print a structure with field values, not sure if that helps you if you're using a debugger. No, Visual D doesn't seem to use it either. I can, of course, create code... but that's a hassle.
Re: C++ interface vs D and com
On Wednesday, 13 July 2016 at 02:34:14 UTC, Mike Parker wrote: On Tuesday, 12 July 2016 at 23:55:55 UTC, Adam Sansier wrote: Ok, Another hack: iInterface x; void** y = cast(void**) *y = malloc(iInterface.sizeof); x.__vptr = cast(immutable(void*)*)(*ptr); x.func(); works. x is the object of type iInterface. It has no object associated with it, basically create one using malloc and set it's vtable. this avoids the need to create the class. What happens when you declare an interface that extends from IUnknown (and not extern(C++)), then cast the pointer returned from the COM API? It should just work without needing to muck around with the vtable. That was what I tried first, It didn't work. I don't know what the problem though. I either get an access violation or the functions don't do anything. I think it's more complex because without extern(C++) the vtable is in a different place than expected(it's offset by 1), so simple casting does not work. "A COM interface differs from a regular interface in that there is no object.Interface entry in vtbl[0]; the entries vtbl[0..$] are all the virtual function pointers, in the order that they were declared. This matches the COM object layout used by Windows. A C++ interface differs from a regular interface in that it matches the layout of a C++ class using single inheritance on the target machine. "
Re: C++ interface vs D and com
On Wednesday, 13 July 2016 at 02:25:35 UTC, Jesse Phillips wrote: On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: So, com throughs me a interface ptr and I need to map it to an interface. When I do, I get an access violation. I have an (com) ptr and an interface. How do I link them up so I can call the functions? I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. This is still true in extern(C++) D, right? The calling convention is thiscall. https://dlang.org/spec/cpp_interface.html I'm not the best person to answer your questions here, but if you're working with COM you do not want to declare them as extern(C++). D supported COM long before it did direct C++ interfacing. You can look at how Juno interfaces with Windows COM objects: https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/source/juno/xml/msxml.d#L226 You'll notice that it inherits from IDispatch instead of IUnknown, Juno defines that interface. https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/source/juno/com/core.d#L2063 Juno tries to make it easier to write and interface with COM, but I've only been keeping it compiling and haven't gotten to writing my own stuff (I've run into issues with manifest files an such). It would be awesome if you found it useful and could improve on the experience. https://github.com/JesseKPhillips/Juno-Windows-Class-Library/wiki I think you would have to explain to me why it would be worth switching. At least in my case it is already working and seems to be much easier than a quick casual glance at juno. I don't need a full blown COM lib at this point though and maybe it only works for my use case(Where CoCreateInstance returns the interface ptr directly and no need to query). I think extern(C++) is necessary because of the calling convention. I could be wrong. extern(Windows) definitely doesn't work. Why the methods I'm using might seem a bit hackish, they are working and is rather simple(a few lines of code), it might not be robust though. Maybe you could write up a little more on the juno readme.markdown file to explain it's purpose and capabilities. It seems like it provides server capabilities, which at don't need at the moment(maybe later), and seems quite large. My com code is basically about 10 lines total + the interface. If you can convince me to try it out, I might... but doing com isn't my primary goal here and I seem to have finished up what I was trying to achieve(my use case is probably relatively simple though). Last thing I want to do is get bogged down in this stuff, which feels clumsy and not well documented(Both the D and C sides)
Re: core.stdc.config
On Thursday, 30 January 2014 at 03:28:57 UTC, Craig Dillabaugh wrote: So, there is a module core.stdc.config (referenced here): http://dlang.org/interfaceToC.html That is presumably part of the D Standard library. I am curious to know why no mention of this library is included at: http://dlang.org/phobos/index.html Is it not part of Phobos? Are there standard modules in D that are not included in Phobos? If so, where would one find the list of these modules. I knew there was (or used to be) a module that defines D types of size equal to the standard C types, but I wasn't finding it, and I thought I was going mad. I guess it's just not documented -- not even listed in the documentation tree!
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 23:55:55 UTC, Adam Sansier wrote: Ok, Another hack: iInterface x; void** y = cast(void**) *y = malloc(iInterface.sizeof); x.__vptr = cast(immutable(void*)*)(*ptr); x.func(); works. x is the object of type iInterface. It has no object associated with it, basically create one using malloc and set it's vtable. this avoids the need to create the class. What happens when you declare an interface that extends from IUnknown (and not extern(C++)), then cast the pointer returned from the COM API? It should just work without needing to muck around with the vtable.
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: So, com throughs me a interface ptr and I need to map it to an interface. When I do, I get an access violation. I have an (com) ptr and an interface. How do I link them up so I can call the functions? I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. This is still true in extern(C++) D, right? The calling convention is thiscall. https://dlang.org/spec/cpp_interface.html I'm not the best person to answer your questions here, but if you're working with COM you do not want to declare them as extern(C++). D supported COM long before it did direct C++ interfacing. You can look at how Juno interfaces with Windows COM objects: https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/source/juno/xml/msxml.d#L226 You'll notice that it inherits from IDispatch instead of IUnknown, Juno defines that interface. https://github.com/JesseKPhillips/Juno-Windows-Class-Library/blob/master/source/juno/com/core.d#L2063 Juno tries to make it easier to write and interface with COM, but I've only been keeping it compiling and haven't gotten to writing my own stuff (I've run into issues with manifest files an such). It would be awesome if you found it useful and could improve on the experience. https://github.com/JesseKPhillips/Juno-Windows-Class-Library/wiki
Re: adding toString to struct
On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: windows libs have a lot of structs and it would be nice to have the ability to convert them to a string to see them in the debugger(e.g., CLSID). Is there a way to do this? I've tried to pull out the code from the libs but it if a total clusterfuck. std.conv.to will print a structure with field values, not sure if that helps you if you're using a debugger.
Re: how to mark an extern function @nogc?
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 are real motivation-killers.
Re: How to open file with exclusive lock?
On 07/12/2016 03:54 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Tue, Jul 12, 2016 at 03:40:36PM -0700, Charles Hixson via Digitalmars-d-learn wrote: [...] OK. It's not possible without OS support. Agreed. And I don't want to get into C calls, but rather to use the mechanisms that D provides. And this *probably* won't cause any problems. But how should I tell D that that's the way I want to access to work? It's not clear to me that locking beyond the current EOF is valid, or whether it will decide that it needs to reserve the space before I use it (in which case locking from 0->ulong.max bytes is a bad idea, and would totally fill my hard disk). Here's another approach. Since it's almost a given that we're talking about cooperating processes sharing an advisory lock here (since a global mandatory file lock seems to have poor support, at least on Posix), we don't *have* to lock the actual bytes we're writing to. We can simply reserve a couple of bytes (perhaps even just one byte) at the beginning of the file, and agree among all processes that we will always try to acquire lock on that byte before writing to (the rest of) the file. Essentially it would serve as a file equivalent of a mutex. Then wrap all your file primitives in a little wrapper that acquires this mutex before performing file I/O, have your program only do I/O through this wrapper, and you're all set. (IIRC, this is how the SQLite3 library implements database read/write locks. Each sqlite3 database file has a few bytes, IIRC 6 bytes, at a known file offset, that it uses to control various levels of access to the database. Depending on which level of locking was needed, it would acquire a lock on one or more of these bytes, before accessing the rest of the file. It doesn't actually acquire a lock on the bytes being read / modified.) T That's probably the most viable approach. It does mean there's a lag between file open and file lock (unless I was to mess around with concurrency locks), but it's quite unlikely that anyone else will access the file while I have it open. (Well, possibly baloo or nepomuk or some such, but that's probably harmless.)
Re: I can has @nogc and throw Exceptions?
On Friday, 13 February 2015 at 21:08:58 UTC, Marc Schütz wrote:
On Friday, 13 February 2015 at 19:09:43 UTC, Tobias Pankrath
wrote:
1. Throw preallocated exceptions is the way to go
... and because noone has yet shown an explicit example:
void myThrowingNogcFunc() @nogc {
static const exc = new Exception("something went
wrong");
throw exc;
}
As long as you don't need to pass a runtime argument to the
constructor, there's no need for emplace acrobatics.
Why not? If the argument is static? (A string literal, surely
this shouldn't be a problem and usually what is used?)
void myThrowingNogcFunc(string s)() @nogc
{
static const exc = new Exception(s);
throw exc;
}
?
I too am looking for nogc exceptions.
How about simply setting aside a 100kb of memory as a pool for
exceptions. Seems like a lot but still under 640kb, hell, even
1MB would still be tiny.
After all, it's not like exceptions are common or happen in
complex ways.
Does anyone have a proper solution to this problem? I'd like nogc
exception handling with run-time generated args.
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 22:55:05 UTC, Adam Sansier wrote: So, the problem now, is how to take the interface, which is simple, no implementation, and either create the implementation or create a sort of simple empty proxy that can be used to instantiate the interface? I mean automatically of course. I believe D already has some library solution for this but haven't looked them up yet. Ok, Another hack: iInterface x; void** y = cast(void**) *y = malloc(iInterface.sizeof); x.__vptr = cast(immutable(void*)*)(*ptr); x.func(); works. x is the object of type iInterface. It has no object associated with it, basically create one using malloc and set it's vtable. this avoids the need to create the class.
Re: how to mark an extern function @nogc?
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) I for one welcome our new D Foundation overlords.
Re: How to open file with exclusive lock?
On Tue, Jul 12, 2016 at 03:40:36PM -0700, Charles Hixson via Digitalmars-d-learn wrote: [...] > OK. It's not possible without OS support. Agreed. And I don't want > to get into C calls, but rather to use the mechanisms that D provides. > And this *probably* won't cause any problems. But how should I tell D > that that's the way I want to access to work? It's not clear to me > that locking beyond the current EOF is valid, or whether it will > decide that it needs to reserve the space before I use it (in which > case locking from 0->ulong.max bytes is a bad idea, and would totally > fill my hard disk). Here's another approach. Since it's almost a given that we're talking about cooperating processes sharing an advisory lock here (since a global mandatory file lock seems to have poor support, at least on Posix), we don't *have* to lock the actual bytes we're writing to. We can simply reserve a couple of bytes (perhaps even just one byte) at the beginning of the file, and agree among all processes that we will always try to acquire lock on that byte before writing to (the rest of) the file. Essentially it would serve as a file equivalent of a mutex. Then wrap all your file primitives in a little wrapper that acquires this mutex before performing file I/O, have your program only do I/O through this wrapper, and you're all set. (IIRC, this is how the SQLite3 library implements database read/write locks. Each sqlite3 database file has a few bytes, IIRC 6 bytes, at a known file offset, that it uses to control various levels of access to the database. Depending on which level of locking was needed, it would acquire a lock on one or more of these bytes, before accessing the rest of the file. It doesn't actually acquire a lock on the bytes being read / modified.) T -- If you're not part of the solution, you're part of the precipitate.
Re: C++ interface vs D and com
So, the problem now, is how to take the interface, which is simple, no implementation, and either create the implementation or create a sort of simple empty proxy that can be used to instantiate the interface? I mean automatically of course. I believe D already has some library solution for this but haven't looked them up yet.
Re: How to open file with exclusive lock?
On 07/12/2016 12:05 PM, H. S. Teoh via Digitalmars-d-learn wrote: On Tue, Jul 12, 2016 at 11:54:18AM -0700, Charles Hixson via Digitalmars-d-learn wrote: I want to open a file with an exclusive lock. It would be important that no other thread be able to access the file in write mode, and desirable that no other thread be able to access the file in read mode. (Ditto for other processes.) stdio.file.lock (or is it stdio.file.File.lock?) seems to demand a range of chunks to lock, but the file is not fixed in length. Is it appropriate to just specify the maximum possible number of bytes (i.e. ulong.max)? Whether this is even possible depends on your OS. I don't know of any cross-platform way of file-locking that is guaranteed to work everywhere. In Posix there's fcntl(F_RDLCK / F_WRLCK), which I believe is the underlying OS call for File.lock. However, this is only an *advisory* lock, i.e., any other processes accessing the file must also call flock(), otherwise none of its protections apply. It only works between cooperating processes. Linux does have a mandatory locking feature, but it requires the kernel to be specially configured for it, and the filesystem must also support it (and must be mounted with the correct options). Unfortunately it's Linux-specific and probably won't work for any other OS. Windows may have some file-locking mechanism that does what you want, but I'm not familiar with the intricacies of how it works. T OK. It's not possible without OS support. Agreed. And I don't want to get into C calls, but rather to use the mechanisms that D provides. And this *probably* won't cause any problems. But how should I tell D that that's the way I want to access to work? It's not clear to me that locking beyond the current EOF is valid, or whether it will decide that it needs to reserve the space before I use it (in which case locking from 0->ulong.max bytes is a bad idea, and would totally fill my hard disk).
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 21:21:04 UTC, Adam Sansier wrote: On Tuesday, 12 July 2016 at 15:12:21 UTC, Lodovico Giaretta wrote: I'm not an expert in this field, but did you read this[1]? [1] https://dlang.org/spec/interface.html#com-interfaces Yes, of course... Well, I asked because you say you marked your interfaces as extern(C++), which is *not* what the spec says you should do. Of course, because you didn't give us much infos on what's not working, we have to guess and point you to some generic resources. Did you read the wiki entry[1], and had a look to some source code[2]? It may be useful to understand if it's a simple mistake on your side or some more deep issue. [1] https://wiki.dlang.org/COM_Programming [2] https://github.com/dlang/druntime/blob/master/src/core/sys/windows/com.d
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 15:13:02 UTC, Adam D. Ruppe wrote: On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. If it is a COM interface, you should make it a COM interface by inheriting from IUnknown. http://dlang.org/spec/interface.html#com-interfaces Obviously... doesn't help. There is some weirdness with the vtable. In the C++ version it is a simple list of void*'s starting at offset 0. In the D version I haven't figured out what is going on yet. Might just be a simple mistake on my part but something seems aloof. I will continue to work on it, it is difficult without being able to really see what is going on through proper debugging support though and not knowing how D does things differently than C++ under the hood.
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 15:12:21 UTC, Lodovico Giaretta wrote: On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: So, com throughs me a interface ptr and I need to map it to an interface. When I do, I get an access violation. I have an (com) ptr and an interface. How do I link them up so I can call the functions? I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. This is still true in extern(C++) D, right? The calling convention is thiscall. https://dlang.org/spec/cpp_interface.html I'm not an expert in this field, but did you read this[1]? [1] https://dlang.org/spec/interface.html#com-interfaces Yes, of course...
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 18:52:08 UTC, Meta wrote:
On Tuesday, 12 July 2016 at 04:23:07 UTC, Adam Sansier wrote:
Now, I could simply make Do a template method but then this
prevents it being a virtual function.
void Do(T)(T name) if (is(T == string) || is(T == int))
{
Init_Data();
static if (is(T == string))
{
...Get index from name
}
}
You could always use std.variant.algebraic which implements
runtime polymorphism:
import std.algebraic;
alias intOrString = Algebraic!(int, string);
void Do(intOrString indexOrName)
{
Init_Data();
int index = indexOrName.visit!(
(int i) => i,
(string s) => getIndexByName(s),
);
}
I thought about this, but kinda hacky. Because I'm using wstring
I would basically have to do:
alias intOrString = Algebraic!(int, string, wstring);
void Do(intOrString indexOrName)
{
Init_Data();
int index = indexOrName.visit!(
(int i) => i,
(string s) => getIndexByName(to!wstring(s)),
(wstring s) => getIndexByName(s),
);
}
It's not terrible, but not better than using templates, which
would be more performant.
void Do(T arg) if (is(arg == string) || is(arg == int) || is(arg
== wstring)
{
int i = 0;
Init_Data();
static if (is(arg == string) || is(arg == wstring))
{
wstring s;
static if (is(arg == string))
s = to!wstring(arg);
else
s = arg;
// Find i for string
i = Findi(arg);
} else
i = arg;
}
It's not very elegant either but basically works and solves the
problem... and also does it in one function. It's probably as
close as one can get in D to what I want, I'm hoping someone find
a better way.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 17:17:31 UTC, Kagamin wrote:
On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote:
Doesn't matter, it's not what I asked.
Yeah, I'm not confident I understood your problem right. You
can try to describe your problem better.
Criteria:
1. At most 2 one parameter functions be used, one that takes an
int and the other a wstring.
2. They must be overloadable and allow for a literal string type
to be passed for the wstring function. This prevents basic
templates and variant techniques.
3. No duplication of code.
4. The wstring function only exists to find the index for the
argument passed. It cannot do this without the int function being
called first, as it initializes or gets data that cannot be done
more than once. This forces some type of "break" in the flow of
the int function.
suppose you have two functions and only two functions.
void Do(int i)
{
// stuff 1
// stuff 2 (uses i)
}
void Do(wstring s)
{
// stuff 1
// converts s to i, the same i that is used in Do(int)
// stuff 2 (uses i)
}
Obviously stuff 1 and stuff 2 are duplicates. stuff 1 does not
not use i or s. stuff 2 does not use s.
The question is how to optimally, in terms of code duplication,
reduce Do(string) so it does no extra work.
There are ways, obviously. But to satisfy the complete criteria
is the hard part.
I could probably use some goto statements and asm to accomplish
this, but probably quite a bit of work and tricky
void Do(wstring s)
{
// get i from s (a simple search), no big deal, a comment
suffices
// create function call to (setup stack, modify first stack
parameter, which is i, to use our new i
goto Doi;
}
void Do(int i)
{
// stuff 1
label Doi;
// stuff 2
}
The goto bypasses stuff1 in Do(int), and sets up i with the new
value. This method would work but is a hack, not portable, etc.
It is essentially the same idea as the yield I proposed, but less
robust. A yield and continue construct would hide all the details
and do something similar.
Again, this isn't about how to accomplish some goal, but how to
accomplish it given the criteria/restraints proposed. It's a no
brainier to do without the constraints.
Re: How to open file with exclusive lock?
On Tue, Jul 12, 2016 at 11:54:18AM -0700, Charles Hixson via Digitalmars-d-learn wrote: > I want to open a file with an exclusive lock. It would be important > that no other thread be able to access the file in write mode, and > desirable that no other thread be able to access the file in read > mode. (Ditto for other processes.) > > stdio.file.lock (or is it stdio.file.File.lock?) seems to demand a > range of chunks to lock, but the file is not fixed in length. Is it > appropriate to just specify the maximum possible number of bytes (i.e. > ulong.max)? Whether this is even possible depends on your OS. I don't know of any cross-platform way of file-locking that is guaranteed to work everywhere. In Posix there's fcntl(F_RDLCK / F_WRLCK), which I believe is the underlying OS call for File.lock. However, this is only an *advisory* lock, i.e., any other processes accessing the file must also call flock(), otherwise none of its protections apply. It only works between cooperating processes. Linux does have a mandatory locking feature, but it requires the kernel to be specially configured for it, and the filesystem must also support it (and must be mounted with the correct options). Unfortunately it's Linux-specific and probably won't work for any other OS. Windows may have some file-locking mechanism that does what you want, but I'm not familiar with the intricacies of how it works. T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Re: How to open file with exclusive lock?
On Tuesday, 12 July 2016 at 18:54:18 UTC, Charles Hixson wrote: I want to open a file with an exclusive lock. It would be important that no other thread be able to access the file in write mode, and desirable that no other thread be able to access the file in read mode. (Ditto for other processes.) stdio.file.lock (or is it stdio.file.File.lock?) seems to demand a range of chunks to lock, but the file is not fixed in length. Is it appropriate to just specify the maximum possible number of bytes (i.e. ulong.max)? From the lock[1] description: If both start and length are zero, the entire file is locked. [1] https://dlang.org/phobos/std_stdio.html#.File.lock
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 18:52:08 UTC, Meta wrote:
On Tuesday, 12 July 2016 at 04:23:07 UTC, Adam Sansier wrote:
Now, I could simply make Do a template method but then this
prevents it being a virtual function.
void Do(T)(T name) if (is(T == string) || is(T == int))
{
Init_Data();
static if (is(T == string))
{
...Get index from name
}
}
You could always use std.variant.algebraic which implements
runtime polymorphism:
import std.algebraic;
Should be `import std.variant`.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 04:23:07 UTC, Adam Sansier wrote:
Now, I could simply make Do a template method but then this
prevents it being a virtual function.
void Do(T)(T name) if (is(T == string) || is(T == int))
{
Init_Data();
static if (is(T == string))
{
...Get index from name
}
}
You could always use std.variant.algebraic which implements
runtime polymorphism:
import std.algebraic;
alias intOrString = Algebraic!(int, string);
void Do(intOrString indexOrName)
{
Init_Data();
int index = indexOrName.visit!(
(int i) => i,
(string s) => getIndexByName(s),
);
}
How to open file with exclusive lock?
I want to open a file with an exclusive lock. It would be important that no other thread be able to access the file in write mode, and desirable that no other thread be able to access the file in read mode. (Ditto for other processes.) stdio.file.lock (or is it stdio.file.File.lock?) seems to demand a range of chunks to lock, but the file is not fixed in length. Is it appropriate to just specify the maximum possible number of bytes (i.e. ulong.max)?
Re: How can you call a stored function in an AA with proper number of arguments converted to the proper type?
On Tuesday, 12 July 2016 at 08:34:03 UTC, Kagamin wrote:
Store a wrapper instead of the actual function:
void wrapper(alias F)(string[] args)
{
(convert args to F arguments) and invoke
}
cmd.func = !someFunc;
string[] args;
cmd.func(args);
Thanks that is clever. Never would have thought of that. Thanks a
lot!
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote: Doesn't matter, it's not what I asked. Yeah, I'm not confident I understood your problem right. You can try to describe your problem better.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 16:42:52 UTC, Lodovico Giaretta wrote: On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote: Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers. Every language has its own ways of solving various problems. We are giving you solutions in D. If you don't want solutions in D, then what do you want? It's pointless
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 16:27:52 UTC, Adam Sansier wrote: On Tuesday, 12 July 2016 at 13:54:16 UTC, Lodovico Giaretta Also note that yield semantics as available in various languages is much different from what you are proposing here. Not really. Yield is usually a break in flow, regardless just because it's applied to fibers doesn't mean it's *much* different. It's the same basic concept. Across various programming languages, yield has two very different meanings and aims: 1) to achieve cooperative multitasking (as in D fibers); but you are not doing cooperative multitasking; 2) for generator functions (like in Python); but you don't have a function that generates multiple values. Also note that in both cases the yielding does not depend on some syntax used at call site. So, by any PL meaning of yield, yield is not what you need to solve your problem.
Re: Where does one post a proposal for a language change?
On Tuesday, 12 July 2016 at 16:45:18 UTC, DLearner wrote: General/Issues/or... P.R. to this repository: https://github.com/dlang/DIPs
Where does one post a proposal for a language change?
General/Issues/or...
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 16:30:05 UTC, Adam Sansier wrote: Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers. Every language has its own ways of solving various problems. We are giving you solutions in D. If you don't want solutions in D, then what do you want?
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 16:03:15 UTC, Kagamin wrote: On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote: I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat. It's a normal use case for private functions: the public function prepares object state and delegates to the private function that does the logic. Doesn't matter, it's not what I asked. Trying to provide answers to a question that wasn't asked and was clearly stated I wasn't interested in those types of answers.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 13:54:16 UTC, Lodovico Giaretta wrote:
On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
Extract functions for shared parts:
void Do(string name)
{
DoStuff();
int i = find(name);
DoStuffWithIndex(i);
}
void Do(int name)
{
DoStuff();
DoStuffWithIndex(i);
}
I don't like it, creates an extra function for no apparent
reason except to get around the problem of not having a yield
type of semantic. Again, I wasn't asking for any ol' solution,
there are many ways to skin this cat.
It is usually considered a good thing to break big functions
into smaller ones; this allows for easier code reading, better
maintainability and easier reuse.
Doesn't matter, that isn't what I asked.
Also note that yield semantics as available in various
languages is much different from what you are proposing here.
Not really. Yield is usually a break in flow, regardless just
because it's applied to fibers doesn't mean it's *much*
different. It's the same basic concept.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote: I don't like it, creates an extra function for no apparent reason except to get around the problem of not having a yield type of semantic. Again, I wasn't asking for any ol' solution, there are many ways to skin this cat. It's a normal use case for private functions: the public function prepares object state and delegates to the private function that does the logic.
Re: adding toString to struct
On Tuesday, 12 July 2016 at 14:51:43 UTC, Adam Sansier wrote: On Tuesday, 12 July 2016 at 14:27:49 UTC, Adam D. Ruppe wrote: On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: Is there a way to do this? write a new function that prints them and call that This doesn't work to display them in visual D though. Requires a lot of hoops just to see a stupid string of the data. OutputDebugString works in Visual Studio, so might work in Visual D as well.
Re: [OT] Re: how to mark an extern function @nogc?
On Tuesday, 12 July 2016 at 14:42:23 UTC, ag0aep6g wrote: On 07/12/2016 04:04 PM, Seb wrote: D is entirely driven by highly motivated volunteers. (this will change soon with the new D foundation) Does the foundation have plans to hire programmers? That's news to me. At the DConf16 Andrei announced in his keynote that he is in the progress of finding sponsors and has already made quite some progress (he mentioned 500K non-Zimbabwean dollars [1]), but also noticed that he still needs to built a roadmap & agenda on how to most effectively invest this money. I haven't heard much since, but I hope that once the D Foundation got an official non-profit status (according to the vision this is planned to happen in this August), we might hear more. Apart from that the D foundation currently already "hires" four programmers as part of the GSoC program ;-) [1] http://forum.dlang.org/post/qaskprdxmshpabara...@forum.dlang.org
Re: structure alignment
On Tuesday, 12 July 2016 at 15:08:29 UTC, Adam D. Ruppe wrote:
On Tuesday, 12 July 2016 at 14:54:25 UTC, Adam Sansier wrote:
Um, because that's the way they were defined! So your telling
me that D is going to make me mark every member align(n) when
C++ has a global pragma align that does it for all in the
scope?
This is trivial, just add it to the bindings.
:s/struct \(.*\) {/struct \1 {\ralign(1):
It's not trivial, a global modifier similar to pragma(align(n))
would be trivial.
Your method makes many assumptions that may not hold. What if the
struct is templated(possible), what if it has comments after
struct and before {, etc? It's a hack that is not a solution. The
proper solution is to have a way to properly specify that a
struct has all members aligned without having to specify it on
all members or per struct.
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. If it is a COM interface, you should make it a COM interface by inheriting from IUnknown. http://dlang.org/spec/interface.html#com-interfaces
Re: C++ interface vs D and com
On Tuesday, 12 July 2016 at 15:09:26 UTC, Adam Sansier wrote: So, com throughs me a interface ptr and I need to map it to an interface. When I do, I get an access violation. I have an (com) ptr and an interface. How do I link them up so I can call the functions? I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. This is still true in extern(C++) D, right? The calling convention is thiscall. https://dlang.org/spec/cpp_interface.html I'm not an expert in this field, but did you read this[1]? [1] https://dlang.org/spec/interface.html#com-interfaces
C++ interface vs D and com
So, com throughs me a interface ptr and I need to map it to an interface. When I do, I get an access violation. I have an (com) ptr and an interface. How do I link them up so I can call the functions? I marked the interface extern(C++) so it's a C++ style interface. The first field of a COM object is a pointer to its vtable. This is still true in extern(C++) D, right? The calling convention is thiscall. https://dlang.org/spec/cpp_interface.html
Re: structure alignment
On Tuesday, 12 July 2016 at 14:54:25 UTC, Adam Sansier wrote:
Um, because that's the way they were defined! So your telling
me that D is going to make me mark every member align(n) when
C++ has a global pragma align that does it for all in the scope?
This is trivial, just add it to the bindings.
:s/struct \(.*\) {/struct \1 {\ralign(1):
Re: structure alignment
On Tuesday, 12 July 2016 at 14:26:54 UTC, Adam D. Ruppe wrote:
On Tuesday, 12 July 2016 at 00:20:31 UTC, Adam Sansier wrote:
I need to align every member of every struct in a module. I
can't simply add align(n) inside every struct because that
seems ridiculous.
Why are these structs needing the alignment?
Because god said so.. I can't change it, not everything is in my
control.
From what I've read, align(n){ struct x; } only aligns the
struct itself, is this true?
Right. To align the members, you put align(x) on the individual
members (or align(x): at the top of the struct to apply to all
of them)
Is there a way to set global alignment for members per module
or per scope?
no
Um, because that's the way they were defined! So your telling me
that D is going to make me mark every member align(n) when C++
has a global pragma align that does it for all in the scope? I
thought D was better than C++?
Re: adding toString to struct
On Tuesday, 12 July 2016 at 14:27:49 UTC, Adam D. Ruppe wrote: On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: Is there a way to do this? write a new function that prints them and call that This doesn't work to display them in visual D though. Requires a lot of hoops just to see a stupid string of the data.
[OT] Re: how to mark an extern function @nogc?
On 07/12/2016 04:04 PM, Seb wrote: D is entirely driven by highly motivated volunteers. (this will change soon with the new D foundation) Does the foundation have plans to hire programmers? That's news to me.
Re: adding toString to struct
On Tuesday, 12 July 2016 at 05:16:30 UTC, Adam Sansier wrote: Is there a way to do this? write a new function that prints them and call that
Re: structure alignment
On Tuesday, 12 July 2016 at 00:20:31 UTC, Adam Sansier wrote:
I need to align every member of every struct in a module. I
can't simply add align(n) inside every struct because that
seems ridiculous.
Why are these structs needing the alignment?
From what I've read, align(n){ struct x; } only aligns the
struct itself, is this true?
Right. To align the members, you put align(x) on the individual
members (or align(x): at the top of the struct to apply to all of
them)
Is there a way to set global alignment for members per module
or per scope?
no
Re: how to mark an extern function @nogc?
On Tuesday, 12 July 2016 at 00:17:32 UTC, Adam Sansier wrote: On Monday, 11 July 2016 at 15:54:02 UTC, Seb wrote: On Monday, 11 July 2016 at 01:59:51 UTC, Adam Sansier wrote: On Monday, 11 July 2016 at 01:58:23 UTC, Adam Sansier wrote: I'm using some win functions that don't use the gc and are not marked, specifically CLSIDFromString that I imported myself(it's not marked nogc in objbase). I went ahead and copied the import and added nogc. Shouldn't someone add that to objbase? Why don't you fork it & add it yourself? Otherwise to quote Walter: "a bug only exists if it's on Bugzilla [issues.dlang.org]" ;-) If this is a bug then there are some serious issues with D's protocol of updating code. How can entire modules be missed? It seems the maintainers of D's library code do not actually use most of the features then? D needs a real code test suite to keep stuff like this from happening, not individual users from the outside to keep it in shape which makes me feel like a guinea pig. I won't stick around too long if that's the case. Well the code quality standards are actually quite high for D (and the test suites are there), but the problem that you discovered here is that most modules have been written before the moderately new @nogc keyword has been introduced. Phobos alone has > 100K LoC, so it just takes a bit of time until new features are propagated through the entire codebase and help is appreciated there because D is entirely driven by highly motivated volunteers. (this will change soon with the new D foundation) That being said (1) there are currently between 2-5 PRs per day to add more annotations to Phobos, (2) most code in Phobos is templated and thus the compiler can automatically infer attributes.
Re: Associative Array c'tor
On Tuesday, 12 July 2016 at 13:56:49 UTC, cym13 wrote: I'm with Steven here, that's definitely too surprising, initialization should not be linked to clear in any way. feel free to change/improve it. for me it is logical, but i'm often found that i am the only one who agrees with my logic. ;-)
Re: Associative Array c'tor
On Tuesday, 12 July 2016 at 13:01:20 UTC, ketmar wrote: On Tuesday, 12 July 2016 at 12:34:40 UTC, Steven Schveighoffer wrote: There was a suggestion to make .clear (a relatively new feature) actually preallocate if it's currently null, but I didn't want to do allocating in that method (too surprising). I do think it would be nice to have an initializer function that simply allocates the impl. q patch[1]. it adds template arg to `.clear`, so no code breakage here (old `clear` is still not allocate, but `.clear!true` will). [1] https://issues.dlang.org/show_bug.cgi?id=16269 I'm with Steven here, that's definitely too surprising, initialization should not be linked to clear in any way.
Re: Passing ranges around
On Tue, Jul 12, 2016 at 06:37:35AM +, Mike Parker via Digitalmars-d-learn
wrote:
> On Tuesday, 12 July 2016 at 03:57:09 UTC, Bahman Movaqar wrote:
> > What should be signature of `foo` in the following piece of code?
> >
> > auto foo(range r) {
> > // do something with the `r`
> > }
> >
> > void main() {
> > foo([1,2,3].map!(x => x*x));
> > }
> >
> >
>
> auto foo(R)(R r) { ... }
Better yet:
import std.range.primitives;
auto foo(R)(R r) if (isInputRange!R) { ... }
This is to ensure R is actually a range, so that, for example, foo(123)
will be rejected at compile-time.
T
--
"A man's wife has more power over him than the state has." -- Ralph Emerson
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 13:44:02 UTC, Adam Sansier wrote:
On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
Extract functions for shared parts:
void Do(string name)
{
DoStuff();
int i = find(name);
DoStuffWithIndex(i);
}
void Do(int name)
{
DoStuff();
DoStuffWithIndex(i);
}
I don't like it, creates an extra function for no apparent
reason except to get around the problem of not having a yield
type of semantic. Again, I wasn't asking for any ol' solution,
there are many ways to skin this cat.
It is usually considered a good thing to break big functions into
smaller ones; this allows for easier code reading, better
maintainability and easier reuse.
Also note that yield semantics as available in various languages
is much different from what you are proposing here.
Re: Simple overloading without complications
On Tuesday, 12 July 2016 at 08:52:26 UTC, Kagamin wrote:
Extract functions for shared parts:
void Do(string name)
{
DoStuff();
int i = find(name);
DoStuffWithIndex(i);
}
void Do(int name)
{
DoStuff();
DoStuffWithIndex(i);
}
I don't like it, creates an extra function for no apparent reason
except to get around the problem of not having a yield type of
semantic. Again, I wasn't asking for any ol' solution, there are
many ways to skin this cat.
Re: Associative Array c'tor
On Tuesday, 12 July 2016 at 12:34:40 UTC, Steven Schveighoffer wrote: There was a suggestion to make .clear (a relatively new feature) actually preallocate if it's currently null, but I didn't want to do allocating in that method (too surprising). I do think it would be nice to have an initializer function that simply allocates the impl. q patch[1]. it adds template arg to `.clear`, so no code breakage here (old `clear` is still not allocate, but `.clear!true` will). [1] https://issues.dlang.org/show_bug.cgi?id=16269
Re: Associative Array c'tor
On 7/12/16 5:42 AM, ketmar wrote: On Tuesday, 12 July 2016 at 03:38:44 UTC, Bahman Movaqar wrote: Now I understand. This is tricky --could introduce hard to find bugs. Is there anyway to make sure it doesn't happen? Such as giving the AA a default empty value on the declaration line --like `string[int] a = []`? no. the only thing you can do is to add something to aa and immediately `.clear` There was a suggestion to make .clear (a relatively new feature) actually preallocate if it's currently null, but I didn't want to do allocating in that method (too surprising). I do think it would be nice to have an initializer function that simply allocates the impl. Anyone want to do a PR? basically (strawman name): int[int] aa; aa.initialize; // still has 0 elements, but no longer null. I'm not sure you could make a static initializer method, since AA's are special builtin types. Relative modules needed to be changed are object.d and src/rt/aaA.d -Steve
Re: Is this a bug ?
On 7/12/16 1:31 AM, Chang Long wrote:
On Tuesday, 12 July 2016 at 04:38:42 UTC, Chang Long wrote:
test.d
=
template newType(size_t N){
class NewType
{
enum Type = N ;
}
}
just find it should be this:
template newType(size_t N){
class NewType
{
enum Type = N ;
}
alias newType = NewType;
}
Just some advice: Name your template NewType, or the class newType, and
then it will work.
-Steve
Re: sorting std.container
On 7/12/16 1:05 AM, WhatMeWorry wrote: On Monday, 11 July 2016 at 19:07:51 UTC, ketmar wrote: list slices are not random-access ranges, thus they can't be sorted in-place (this is what std.algorithm.sort does). so the only way is to convert list to array, sort it, and make a list from sorted array. probably not something you want. ;-) this is common for any "traditional" linked list implementation: random access is very costly, thus even if it is implemented, it's better to not use it. SList and DList are "traditional" lists without any fancy algorithms inside (like finger trees or skip lists). you may want to use arrays instead (it is often more efficient anyway, especially if you don't need to insert elements in the middle of the array), or associative arrays. If I may deviate from the discussion a bit,are there any real world scenarios where the SList and DList (that is, "traditional" linked lists) is superior to fixed, dynamic or associative arrays? IMO, singly linked lists are almost always better as home-grown types. This is because there is too much overhead for a generic "list", and it almost never does everything you need it to. Just about the only real good use for a generic singly-linked list is a stack, though arrays can cover that. Where singly-linked lists may be better is if you are moving pre-allocated nodes onto the stack and don't want to allocate space for them (or change their address). Again, a home-grown version will do better here too. A dual-linked list, on the other hand, is not as easy to write, and functions well as a generic container. With O(1) front/back insertion and O(1) front/back removal, it makes a great base for a FIFO queue. -Steve
Re: Docs for `Group` type
On 07/12/2016 04:21 PM, Edwin van Leeuwen wrote: > On Tuesday, 12 July 2016 at 11:40:48 UTC, Bahman Movaqar wrote: >> On 07/12/2016 01:01 PM, Mike Parker wrote: >>> Do you have some sample code that shows the error? >> >> Yes. I'm working on Stockman[1] a playground to learn D. >> In file `etl.d`, line 110 [2], if I change the line to >> auto refInvoice = group[1].takeOne(); >> the file will not compile. I have attached the compile error to this >> message. >> >> Thanks, > > What does group.writeln; output? That should give you a good sense of > what is going on. That's a good trick to know. Thanks. -- Bahman
Re: Docs for `Group` type
On 07/12/2016 04:23 PM, ag0aep6g wrote: > On 07/12/2016 01:40 PM, Bahman Movaqar wrote: >> Yes. I'm working on Stockman[1] a playground to learn D. >> In file `etl.d`, line 110 [2], if I change the line to >> auto refInvoice = group[1].takeOne(); >> the file will not compile. I have attached the compile error to this >> message. > > Do you also add the import of takeOne? takeOne is not a range primitive, > but a function that works on ranges. Need to import it in order to use it. Stupid me! Thanks :-) -- Bahman
Re: aspects on methods?
On Tuesday, 12 July 2016 at 11:26:20 UTC, jj75607 wrote: you can't. there is no AST macros in D, so you can't rewrite parsed source.
Re: Docs for `Group` type
On 07/12/2016 01:40 PM, Bahman Movaqar wrote: Yes. I'm working on Stockman[1] a playground to learn D. In file `etl.d`, line 110 [2], if I change the line to auto refInvoice = group[1].takeOne(); the file will not compile. I have attached the compile error to this message. Do you also add the import of takeOne? takeOne is not a range primitive, but a function that works on ranges. Need to import it in order to use it.
Re: Docs for `Group` type
On Tuesday, 12 July 2016 at 11:40:48 UTC, Bahman Movaqar wrote: On 07/12/2016 01:01 PM, Mike Parker wrote: Do you have some sample code that shows the error? Yes. I'm working on Stockman[1] a playground to learn D. In file `etl.d`, line 110 [2], if I change the line to auto refInvoice = group[1].takeOne(); the file will not compile. I have attached the compile error to this message. Thanks, What does group.writeln; output? That should give you a good sense of what is going on.
Re: Docs for `Group` type
On 07/12/2016 01:01 PM, Mike Parker wrote: > Do you have some sample code that shows the error? Yes. I'm working on Stockman[1] a playground to learn D. In file `etl.d`, line 110 [2], if I change the line to auto refInvoice = group[1].takeOne(); the file will not compile. I have attached the compile error to this message. Thanks, -- Bahman [1] https://github.com/bahmanm/stockman-d [2] https://github.com/bahmanm/stockman-d/blob/master/source/etl.d#L110 Performing "debug" build using dmd for x86_64. stockman-d ~master: building configuration "application"... source/etl.d(110,33): Error: no property 'takeOne' for type 'ChunkByChunkImpl!(__lambda9, MapResult!(__lambda3, ByLine!(char, char)))' /home/bahman/Programs/D/dmd-2.071.0/linux/bin64/../../src/phobos/std/algorithm/iteration.d(480,16):instantiated from here: MapResult!(__funcliteral3, ChunkByImpl!(__lambda2, MapResult!(__lambda3, ByLine!(char, char source/etl.d(108,44):instantiated from here: map!(ChunkByImpl!(__lambda2, MapResult!(__lambda3, ByLine!(char, char source/etl.d(32,26):instantiated from here: combineOneLiners!(MapResult!(__lambda3, ByLine!(char, char))) dmd failed with exit code 1.
Re: aspects on methods?
On Tuesday, 12 July 2016 at 11:26:20 UTC, jj75607 wrote:
I want to use aspect-like annotations to transform
@Lockable
class Abc
{
@sync
void f() {
writeln("f");
}
@shared
void g() {
writeln("g");
}
}
to something like:
class Abc
{
shared(ReadWriteMutex) _lock123;
this()
{
_lock123 = cast(shared)(new ReadWriteMutex());
}
void f() {
synchronized((cast()_lock123).writer) {
writeln("f");
}
}
void g() {
synchronized((cast()_lock123).reader) {
writeln("g");
}
}
}
How can I do that?
I don't think UDAs can be used that way in D, but I'm not an
expert.
When I want to achieve something similar to this kind of
rewriting, I usually use a mix of template mixins[1] and string
mixins[2,3].
[1] https://dlang.org/spec/template-mixin.html
[2] https://dlang.org/spec/statement.html#MixinStatement
[3] https://dlang.org/mixin.html
aspects on methods?
I want to use aspect-like annotations to transform
@Lockable
class Abc
{
@sync
void f() {
writeln("f");
}
@shared
void g() {
writeln("g");
}
}
to something like:
class Abc
{
shared(ReadWriteMutex) _lock123;
this()
{
_lock123 = cast(shared)(new ReadWriteMutex());
}
void f() {
synchronized((cast()_lock123).writer) {
writeln("f");
}
}
void g() {
synchronized((cast()_lock123).reader) {
writeln("g");
}
}
}
How can I do that?
Re: local const functions - bug ?
On Sunday, 10 July 2016 at 07:20:29 UTC, Meta wrote: On Friday, 8 July 2016 at 09:01:10 UTC, Marc Schütz wrote: `foo()` is effectively a delegate, therefore `const` applies to the context. AFAIK const on a function can only ever refer to the `this` pointer, but there is no `this` pointer. To the `this` pointer, or the context, in case of delegates. Here, `foo()` is a nested function that accesses a variable in the outer scope. This qualifies it as a delegate [1]: "When comparing with nested functions, the function form is analogous to static or non-nested functions, and the delegate form is analogous to non-static nested functions. In other words, a delegate literal can access stack variables in its enclosing function, a function literal cannot." [1] https://dlang.org/spec/expression.html#FunctionLiteral
Re: @safe fun alayws call @system function?
On Tuesday, 12 July 2016 at 09:17:37 UTC, ag0aep6g wrote: On 07/12/2016 11:09 AM, Dsby wrote: How can i call @system function in a @safe function? You can't. You can mark the @safe function @trusted [1] instead. @trusted functions are considered memory-safe by the compiler and can be called from @safe code, but they can use @system features and call @system functions. A @trusted function must still be memory-safe, and the compiler cannot check that it is, so you as the programmer take on the responsibility to ensure that the function is in fact memory-safe. Be very careful with @trusted and make sure you know exactly what you're doing. A bad @trusted function compromises the whole call chain. [1] https://dlang.org/spec/function.html#trusted-functions Thanks!
Re: Associative Array c'tor
On Tuesday, 12 July 2016 at 03:38:44 UTC, Bahman Movaqar wrote: Now I understand. This is tricky --could introduce hard to find bugs. Is there anyway to make sure it doesn't happen? Such as giving the AA a default empty value on the declaration line --like `string[int] a = []`? no. the only thing you can do is to add something to aa and immediately `.clear`
Re: @safe fun alayws call @system function?
On 07/12/2016 11:09 AM, Dsby wrote: How can i call @system function in a @safe function? You can't. You can mark the @safe function @trusted [1] instead. @trusted functions are considered memory-safe by the compiler and can be called from @safe code, but they can use @system features and call @system functions. A @trusted function must still be memory-safe, and the compiler cannot check that it is, so you as the programmer take on the responsibility to ensure that the function is in fact memory-safe. Be very careful with @trusted and make sure you know exactly what you're doing. A bad @trusted function compromises the whole call chain. [1] https://dlang.org/spec/function.html#trusted-functions
@safe fun alayws call @system function?
How can i call @system function in a @safe function?
Re: Simple overloading without complications
Extract functions for shared parts:
void Do(string name)
{
DoStuff();
int i = find(name);
DoStuffWithIndex(i);
}
void Do(int name)
{
DoStuff();
DoStuffWithIndex(i);
}
Re: How can you call a stored function in an AA with proper number of arguments converted to the proper type?
Store a wrapper instead of the actual function:
void wrapper(alias F)(string[] args)
{
(convert args to F arguments) and invoke
}
cmd.func = !someFunc;
string[] args;
cmd.func(args);
Re: Passing ranges around
On Tuesday, 12 July 2016 at 07:50:34 UTC, Bahman Movaqar wrote:
On 07/12/2016 11:07 AM, Mike Parker wrote:
auto foo(R)(R r) { ... }
That did it. Thanks.
Out of curiosity, does the same pattern apply to functions
which take
`tuple`s as input arguments?
It's just a function template. It's what you use whenever you
need to deal with generic types.
https://dlang.org/spec/template.html
Re: Docs for `Group` type
On Tuesday, 12 July 2016 at 08:03:53 UTC, Bahman Movaqar wrote: On 07/12/2016 11:06 AM, Mike Parker wrote: The 'Group' type is an implementation detail -- a type used internally -- that you aren't supposed to care about. All you need to care about is that it's a range. The documentation for chunkBy [1] explains what the return type is. [1] https://dlang.org/phobos/std_algorithm_iteration.html#.chunkBy Thanks. Now since I can't do `takeOne` on `Group`[1], exactly what kind of range is `Group`? [1] Error: no property 'takeOne' for type 'Group' When you downloaded DMD, you also received the source to Phobos, so you can see for yourself. The only Group type I see the chunkBy implementations is at [1] (the link to the github viewer probably won't point to the same place for long, but you should be looking in the the version of ChunkByImpl for forward ranges). It's a forward range. Do you have some sample code that shows the error? [1] https://github.com/dlang/phobos/blob/master/std/algorithm/iteration.d#L1608
Re: Docs for `Group` type
On 07/12/2016 11:06 AM, Mike Parker wrote: > The 'Group' type is an implementation detail -- a type used internally > -- that you aren't supposed to care about. All you need to care about is > that it's a range. The documentation for chunkBy [1] explains what the > return type is. > > [1] https://dlang.org/phobos/std_algorithm_iteration.html#.chunkBy Thanks. Now since I can't do `takeOne` on `Group`[1], exactly what kind of range is `Group`? [1] Error: no property 'takeOne' for type 'Group' -- Bahman
Re: Passing ranges around
On 07/12/2016 11:07 AM, Mike Parker wrote:
> auto foo(R)(R r) { ... }
That did it. Thanks.
Out of curiosity, does the same pattern apply to functions which take
`tuple`s as input arguments?
--
Bahman
Re: Passing ranges around
On Tuesday, 12 July 2016 at 03:57:09 UTC, Bahman Movaqar wrote:
What should be signature of `foo` in the following piece of
code?
auto foo(range r) {
// do something with the `r`
}
void main() {
foo([1,2,3].map!(x => x*x));
}
auto foo(R)(R r) { ... }
Re: Docs for `Group` type
On Tuesday, 12 July 2016 at 04:25:26 UTC, Bahman Movaqar wrote: When using `chunkBy` (unary pred) the result is a list of tuples. Each tuple holds a key and a `Group` which belong to that key. Where can I find the docs for this `Group` type (I have already tried searching library on dlang.org)? Thanks, The 'Group' type is an implementation detail -- a type used internally -- that you aren't supposed to care about. All you need to care about is that it's a range. The documentation for chunkBy [1] explains what the return type is. [1] https://dlang.org/phobos/std_algorithm_iteration.html#.chunkBy
