Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 22:15:42 UTC, ag0aep6g wrote:
On 05/26/2016 11:13 PM, Era Scarecrow wrote:
void scan(ref Data[][] data, Condition cond) {
foreach(i; ...) {
if (cond)
data[i] ~= ...
}
}
Sorry, I'm still lost. Why can't you do whatever you're doing
in opOpAssign directly there, or in a free function? Does the
pseudo-array contain any additional data? Would a wrapper
around a built-in array not work?
Well a few things at work. First the array is originally a
static array, so I pass it as a slice; But if you pass it as a
slice you get the entire length, and modifying the length
requires either changing length or appending, both which may
cause allocation (something I want to avoid). By making my own
compatible structure I can manage the length and pointer directly
and precisely.
Second I would prefer the length to start at 0 and grow UP TO
the size of the static array. If it was just a single array this
wouldn't be an issue, but I'm working with a couple hundred of
these. Plus I don't want to add more data to the memory or
structure than necessary to treat it as an array after the fact.
I shouldn't have to.
Truthfully the same result can be done with shrinking it
afterwards, but I was trying to see if I could make it any faster
by managing the pointer and length directly and avoiding the
large temporaries. So far any speed gains are so minimal it's
worth dropping.
Oh, I see. Yeah, the answer is garbage. Seeing the spec section
that Adam D. Ruppe linked, the length field actually comes
first.
That CTFE errors out when you move the pointer to a variable
screams that something is wrong. The code seems to be seriously
misinterpreted in CTFE.
I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16081
Glad I found a bug! :) And all because [].ptr.offsetof wasn't an
option...
I just wanted to guarantee it was the correct order (in case it
gets changed in the future). But ultimately it isn't worth
pursuing.
Re: Testing array ptr for offset 0...
On 05/26/2016 11:13 PM, Era Scarecrow wrote:
By adding a struct overload for opOpAssign I can shrink it all down
to this, and avoid lengths entirely... As such internally the length
starts at 0, and checks are in place to ensure the bounds are never
exceeded.
void scan(ref Data[][] data, Condition cond) {
foreach(i; ...) {
if (cond)
data[i] ~= ...
}
}
Sorry, I'm still lost. Why can't you do whatever you're doing in
opOpAssign directly there, or in a free function? Does the pseudo-array
contain any additional data? Would a wrapper around a built-in array not
work?
[...]
The answer is wrong _because_ the code blows up. I inverted the check
to check if length is at offset 0 since (the length can only be 1 and a
better test), however it _still_ gives the wrong answer. Curiously CTFE
is fine with this casting as long as the pointer stays in that one spot.
Oh, I see. Yeah, the answer is garbage. Seeing the spec section that
Adam D. Ruppe linked, the length field actually comes first.
That CTFE errors out when you move the pointer to a variable screams
that something is wrong. The code seems to be seriously misinterpreted
in CTFE.
enum x = () {
size_t[] arr = [13];
return *(cast(size_t*) );
} ();
pragma(msg, x);
That prints "13LU". Apparently is mistaken for arr here.
I've filed an issue:
https://issues.dlang.org/show_bug.cgi?id=16081
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 20:46:31 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 20:25:43 UTC, Basile B. wrote: [...] I tried this with the gfm-package. I opened the dub.json file as a project and clicked 'Compilation'-> 'Compile Project' then it did its things: [...] gfm doesn't yield a .lib because of this: https://github.com/d-gamedev-team/gfm/blob/master/dub.json#L22 it should be "library" or staticLibrary or "sourceLibrary" thus it can't be registered. Bad luck here you've chosen the wrong stuff to test.
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 12:33:31 UTC, Adam D. Ruppe wrote: On Thursday, 26 May 2016 at 12:30:30 UTC, Alex Parrill wrote: The line "not having to make another array to keep track of lengths and then shorten them" is fairly vague. "Shortening" an array via slicing is basically free (it's just some integer arithmetic), but I'm not sure if that's what you meant. Indeed, creating a slice from a static array, another slice, or a pointer is free too... But managing the lengths separately and then re-slicing it afterwards is not free. It does have a low constant cost though; but can I remove that cost entirely (including the foreach loop overhead)? There's also the annoyance that on windows machines the stack size seems to be fairly small. Sometimes in my tests the program will crash before it starts because the requested size of a static array on the stack is too big. This means if I have a big stack allocation already, I want to try and avoid further allocations if I can avoid it. byte[1024*1024] buffer; //on my machine, it just crashes when this is allocated.
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 11:47:13 UTC, ag0aep6g wrote:
I don't follow. Why can't you use a built-in array? What can
you do with the stand-in that you can't do with the array
itself?
I can do the job with the built-in arrays, however the need for
another temporary array to keep track of lengths so I can slice
them after the fact is what i want to avoid. I'm also slicing
static arrays. I'm trying to see if this code would be more
efficient or not (if it is, it's not by much, which I'm sure has
to do with the cache more than anything else).
To do what I want currently it's something like...
enum Size = 1024, Other = 128;
Data[Size][Other] staticarray; //stack allocation
Data[][] sliced = staticarray[];
scan(sliced, condition);
void scan(ref Data[][] data, Condition cond) {
int lengths[Size];
foreach(i; ...) {
if (cond)
data[i][lengths[i]++] = ...
}
//cleanup/shrink
foreach(i, l; lengths)
data[i] = data[i][0 .. l];
}
By adding a struct overload for opOpAssign I can shrink it all
down to this, and avoid lengths entirely... As such internally
the length starts at 0, and checks are in place to ensure the
bounds are never exceeded.
void scan(ref Data[][] data, Condition cond) {
foreach(i; ...) {
if (cond)
data[i] ~= ...
}
}
Seems a bit back and forth, but as far as I can see it works as
you want. Why do you think the answer it gives is wrong? What
answer does it give you?
The answer is wrong _because_ the code blows up. I inverted the
check to check if length is at offset 0 since (the length can
only be 1 and a better test), however it _still_ gives the wrong
answer. Curiously CTFE is fine with this casting as long as the
pointer stays in that one spot.
template isArrayLengthOffsetZero() {
bool check() {
size_t[] arr = new size_t[1];
return *(cast(size_t*) ) == 1;
}
enum isArrayLengthOffsetZero = check(); //wrong answer
// enum isArrayLengthOffsetZero = !check(); //right answer but
logically wrong
}
//test struct
struct S(T) {
static if (isArrayLengthOffsetZero!()) {
size_t length;
T* ptr;
} else {
T* ptr;
size_t length;
}
this(T* p) { ptr = p; }
//opOpAssign
}
unittest {
import std.stdio;
//union to get our overlapping data types
union X { string str; S!(immutable char) s_str;}
X x;
x.s_str = S!(immutable char)("t".ptr); //only ptr assigned
//writeln(x.str); //blows up
writeln(x.str.length); //not 0...
assert(x.str.length == 0); //fails
}
Most likely the internal array structure CTFE uses for the array
is inverted, and if that's the case the proper answer to how to
get the simple offset of ptr (or length) is a mess.
Forcing the inverted answer works, but this is a lot of overhead
to try and make an algorithm faster. Speedups are minimal at
best, so I'm about ready to drop this line of thought.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 20:25:43 UTC, Basile B. wrote: But the procedure I described is very easy. you just have to clone, compile and click a button in the library manager. It's even better because you can choose which version to compile by "git checkout vx.x.x" while using the "DUB button" it's always the master version that get fetched (this is a limitation). I tried this with the gfm-package. I opened the dub.json file as a project and clicked 'Compilation'-> 'Compile Project' then it did its things: compiling C:\Users\stduser\Downloads\DUB\GFM\dub.json Fetching derelict-util 2.0.6 (getting selected version)... Placing derelict-util 2.0.6 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching derelict-gl3 1.0.18 (getting selected version)... Placing derelict-gl3 1.0.18 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching derelict-sdl2 1.9.7 (getting selected version)... Placing derelict-sdl2 1.9.7 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching derelict-assimp3 1.0.1 (getting selected version)... Placing derelict-assimp3 1.0.1 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching gfm 6.0.2 (getting selected version)... Placing gfm 6.0.2 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching derelict-fi 2.0.2 (getting selected version)... Placing derelict-fi 2.0.2 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Fetching colorize 1.0.5 (getting selected version)... Placing colorize 1.0.5 to C:\Users\Standardbenutzer\AppData\Roaming\dub\packages\... Performing "plain" build using C:\D\dmd2\windows\bin\dmd.exe for x86. derelict-util 2.0.6: building configuration "library"... derelict-assimp3 1.0.1: building configuration "library"... gfm:assimp 6.0.2: building configuration "library"... gfm:core 6.0.2: building configuration "library"... derelict-fi 2.0.2: building configuration "library"... gfm:freeimage 6.0.2: building configuration "library"... gfm:integers 6.0.2: building configuration "library"... colorize 1.0.5: building configuration "library"... gfm:logger 6.0.2: building configuration "library"... gfm:math 6.0.2: building configuration "library"... derelict-gl3 1.0.18: building configuration "library"... gfm:opengl 6.0.2: building configuration "library"... derelict-sdl2 1.9.7: building configuration "library"... gfm:sdl2 6.0.2: building configuration "library"... gfm_test ~master: building configuration "application"... C:\Users\stduser\Downloads\DUB\GFM\dub.json has been successfully compiled but if i go to 'Windows'->'Library Manager' the book icon is gray and not clickable. https://picload.org/image/rgcccpci/library_manager.png
Re: Operator overloading through UFCS doesn't work
On 25.05.2016 01:19, Elie Morisse wrote: On Saturday, 13 October 2012 at 22:58:56 UTC, Timon Gehr wrote: Afaik free-function operator overloads (but not in the context of UFCS) were considered and turned down because D did not want to get amidst discussions about adding Koenig lookup. UFCS does not do Koenig lookup. I don't get it, aren't the current symbol lookup rules enough to make free function operator overloads useful? To me it looks like they are. ... Yup. It could be argued that it is essentially a compiler bug. Sorry for digging up this thread, just getting irritated by a restriction that seems pointless and arbitrary. ... It is, but it has a few vocal proponents. Overloaded operators would suffer from the same potential abuses other methods are subjected to if UFCS was enabled, nothing more as far as I can see. You are perfectly right of course. It's painful for no benefit. (For example, there's no way to overload e.g. '+=' for classes in a way that reassigns the reference.)
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 19:07:42 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 17:25:25 UTC, Basile B. wrote: I'm on Windows now. I'm sorry but both packages were setup successfully. What you can do is the other way: - clone the git repos. - open the DUB json as project. - choose the right config in the inspector. - compile. - while the project for the lib to reg is still open, register in the library manager using the book-link icon. You have well version 2 update 5 ? Yes. So do you have any idea how i could get this to work? It would be nice to link libraries directly from the IDE but for the time being linking the project manually with the files on my harddrive is no problem. I'll release a hotfix tonight, so you'll be able to give Coedit another try if you're not already too much disapointed. But the procedure I described is very easy. you just have to clone, compile and click a button in the library manager. It's even better because you can choose which version to compile by "git checkout vx.x.x" while using the "DUB button" it's always the master version that get fetched (this is a limitation). One thing that's important to get (sorry if I heavily advertise Coedit...) is that the libman is a central component, everything rely on this (CE projects, ease of compilation of the "runnables", and super important: DCD). That's also why it's split from the project editors.
Re: Operator overloading through UFCS doesn't work
On Thursday, May 26, 2016 16:24:37 Elie Morisse via Digitalmars-d-learn wrote: > On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: > > The difference is that it's impossible to do > > 10.opBinary!"+"(15), so if you're forced to do > > foo.opBinary!"+"(bar) to get around a symbol conflict, it won't > > work with built-in types. > > Obviously operator overloading should be limited to class and > struct types, so that's not really relevant. It's completely relevent, because generic code is frequently going to operate on a variety of types - including both built-in types and user-defined types. If code is going to use +, then + must work. opBinary!"+" is simply not going to cut it. With UFCS, if there's a potential symbol conflict, then you can work around it - even in generic code. But with an overloaded operator, the operator must work as an operator, or generic code simply won't work. > > UFCS does not have that problem, because you're dealing with > > free functions and can choose to not use UFCS and provide the > > full import path or to alias the function, which you can't do > > with operators - particularly built-in operators. > > I still don't understand what you're getting at, unfortunately. You don't _have_ to use UFCS. You can call the function as a normal free function with the full import path. You can also alias the function to a different name and use that with UFCS or import the conflicting function with an alias so that it doesn't conflict. The overloaded operator, on the other hand, needs to work as on overloaded operator, and we can't just call an overloaded operator with its full import path or alias it when importing it, because it's an overloaded operator and not just a free function. We have ways to distinguish conflicting types with free functions, and we don't with operators, because operators were designed to be part of the type and not free functions. And syntactically, it really doesn't work to provide a way to distinguish between conflicting versions of an overloaded operator, because then you're no longer just using the operator and might as well just be using a function. But all I'm really doing here is saying the same thing multiple times in slightly different ways, so if you don't get it, I don't know how to explain it. > Thanks for taking the time to explain, although I still fail to > see a good justification for disabling UFCS for operators. I will > look for more discussions on the topic and if still no opposing > argument seems valid I might push the issue forward. You're going to need more than a good reason why it shouldn't be allowed. You're going to need a good reason why it should be, and I really don't think that you're going to have one good enough to get you anywhere with Walter. I'm fairly certain that there's a thread or two floating around somewhere in the main newsgroup where he's responded to the issue before though. - Jonathan M Davis
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:25:25 UTC, Basile B. wrote: I'm on Windows now. I'm sorry but both packages were setup successfully. What you can do is the other way: - clone the git repos. - open the DUB json as project. - choose the right config in the inspector. - compile. - while the project for the lib to reg is still open, register in the library manager using the book-link icon. You have well version 2 update 5 ? Yes. So do you have any idea how i could get this to work? It would be nice to link libraries directly from the IDE but for the time being linking the project manually with the files on my harddrive is no problem.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:09:03 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 17:06:03 UTC, Basile B. wrote: colorize works. You meant "serial-port" ? Well, i get the same message for both packages...Even though it creates a new folder with all the files in AppData\Roaming\dub\packages I confirm there is a bug. It's due to a DUB breaking change from 0.9.24-rc4 to 0.9.24. (everything is placed in a sub folder that has the same name of the package).
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:09:03 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 17:06:03 UTC, Basile B. wrote: colorize works. You meant "serial-port" ? Well, i get the same message for both packages...Even though it creates a new folder with all the files in AppData\Roaming\dub\packages I'm on Windows now. I'm sorry but both packages were setup successfully. What you can do is the other way: - clone the git repos. - open the DUB json as project. - choose the right config in the inspector. - compile. - while the project for the lib to reg is still open, register in the library manager using the book-link icon. You have well version 2 update 5 ?
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:09:03 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 17:06:03 UTC, Basile B. wrote: colorize works. You meant "serial-port" ? Well, i get the same message for both packages...Even though it creates a new folder with all the files in AppData\Roaming\dub\packages Can you create a GH issue ? I'll fix it ASAP. That's a desatrous bug. version 2 update 5 should have been the latest before monthes.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:06:03 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 17:02:06 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 16:53:42 UTC, Basile B. wrote: [...] Thanks, now i found it. If i try to add for example 'colorize' as a package i get: Fetching serial-port ~master... Placing serial-port ~master to C:\Users\luc\AppData\Roaming\dub\packages\... Neither a package description file, nor source/app.d was found in C:\Users\luc\AppData\Roaming\dub\packages\serial-port-master Please run DUB from the root directory of an existing package, or run "dub init --help" to get information on creating a new package. No valid root package found - aborting. error, failed to compile the package to register colorize works. You meant "serial-port" ? serial-port worked too here. I'm on linux (and CE is mostly developed on this platform) so it could be a bug (to verify).
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:06:03 UTC, Basile B. wrote: colorize works. You meant "serial-port" ? Well, i get the same message for both packages...Even though it creates a new folder with all the files in AppData\Roaming\dub\packages
Re: Easier way to add libraries to visual d?
On 26.05.2016 17:11, TheDGuy wrote: Hi, i use Visual D as a plugin for visual studio to create D applications. But what bothers me a bit is that i have to tell visual D the exact link to the .lib file for every lib i want to use in the project (!). So these are the steps i have to make to get an external lib working: 1. create a new folder in D:\dmd2\src\ with the name of the library 2. edit the 'sc.ini' file in D:\dmd2\windows\bin\ and add "-I%@P%\..\..\src\[foldername]" under '[Environment]' for every lib i want to use 3. add the .lib file to D:\dmd2\windows\lib 4. add the path to the lib in visual studio (project properties -> Linker -> General -> Library Files) Why do i have to do that? Why can i not just use one folder for the library files in visual d and the compiler searches the .lib files for each library which was imported into the project on its own? Is there an easier way to use libraries? You don't have to change anything in sc.ini. Just add the import path (the folder with the source files of your library) to "Project properties -> Compiler -> Additional import paths" and the full path to the .lib file to "Library Files". If it contains spaces, use quotes. If you want to use these libraries in multiple projects, you can also setup global search paths in "Tools -> Options -> Projects and Solutions -> Visual D Settings -> DMD directories".
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:02:06 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 16:53:42 UTC, Basile B. wrote: [...] Thanks, now i found it. If i try to add for example 'colorize' as a package i get: Fetching serial-port ~master... Placing serial-port ~master to C:\Users\luc\AppData\Roaming\dub\packages\... Neither a package description file, nor source/app.d was found in C:\Users\luc\AppData\Roaming\dub\packages\serial-port-master Please run DUB from the root directory of an existing package, or run "dub init --help" to get information on creating a new package. No valid root package found - aborting. error, failed to compile the package to register colorize works. You meant "serial-port" ?
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 16:53:42 UTC, Basile B. wrote: - Registering a dub package from online is in the "library manager" - The DUB project editor is a widget that's not docked by default, see in the menu "Windows", the item "Dub project editor". The Native project configuration and editor is for the native project format (which is another format than DUB, just like vsprojects are another format). Thanks, now i found it. If i try to add for example 'colorize' as a package i get: Fetching serial-port ~master... Placing serial-port ~master to C:\Users\luc\AppData\Roaming\dub\packages\... Neither a package description file, nor source/app.d was found in C:\Users\luc\AppData\Roaming\dub\packages\serial-port-master Please run DUB from the root directory of an existing package, or run "dub init --help" to get information on creating a new package. No valid root package found - aborting. error, failed to compile the package to register
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 17:02:06 UTC, TheDGuy wrote: Thanks, now i found it. If i try to add for example 'colorize' as a package i get: Fetching serial-port ~master... Placing serial-port ~master to C:\Users\luc\AppData\Roaming\dub\packages\... Neither a package description file, nor source/app.d was found in C:\Users\luc\AppData\Roaming\dub\packages\serial-port-master Please run DUB from the root directory of an existing package, or run "dub init --help" to get information on creating a new package. No valid root package found - aborting. error, failed to compile the package to register I mean 'serial-port', sry.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 16:53:42 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 16:21:30 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 16:01:22 UTC, Basile B. wrote: To register a DUB package, you can either fetch (DUB icon) or clone the repo, open the DUB JSON project, compile the right config, then in the libman there's a icon with a gray chain over a book. Click this icon and the library is registered. Where? I searched for 10 minutes and can't find any DUB button besides the dub project editor. If i create a new DUB project it looks like that everything is locked (for example native project configuration)? - Registering a dub package from online is in the "library manager" - The DUB project editor is a widget that's not docked by default, see in the menu "Windows", the item "Dub project editor". The Native project configuration and editor is for the native project format (which is another format than DUB, just like vsprojects are another format). By the way everything is explained in the wiki. If the browser didn't display the right anchor click F5. This happens because everything is in a big single page: https://github.com/BBasile/Coedit/wiki#library-manager-widget
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 16:21:30 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 16:01:22 UTC, Basile B. wrote: To register a DUB package, you can either fetch (DUB icon) or clone the repo, open the DUB JSON project, compile the right config, then in the libman there's a icon with a gray chain over a book. Click this icon and the library is registered. Where? I searched for 10 minutes and can't find any DUB button besides the dub project editor. If i create a new DUB project it looks like that everything is locked (for example native project configuration)? - Registering a dub package from online is in the "library manager" - The DUB project editor is a widget that's not docked by default, see in the menu "Windows", the item "Dub project editor". The Native project configuration and editor is for the native project format (which is another format than DUB, just like vsprojects are another format).
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:51:39 UTC, Basile B. wrote:
Oh, I'm so sorry ! I totally missed the point of the Q.
float.nan is not a "unique" value. Several values verify "nan"
(Look at std.math.isNan). So I suppose it's simpler to test
for nullity. Though with the sign there's also two possible
0...
void main(string[] args)
{
writeln(float.nan == float.init); // false
import std.math: isNaN;
writeln(isNaN(float.nan)); // true
writeln(isNaN(float.init)); //true
}
So the shortcut in the compiler might be more simple, there is
only a single test for "if(myFloat)"...
im just playing with this template[1] is there anything else i
missed? (if you dont mind)
it basically treats any T.init as false and skips the
function/delegate and just returns type.
[1] https://dpaste.dzfl.pl/d159d83e3167
Re: Operator overloading through UFCS doesn't work
On Thursday, 26 May 2016 at 06:23:17 UTC, Jonathan M Davis wrote: The difference is that it's impossible to do 10.opBinary!"+"(15), so if you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict, it won't work with built-in types. Obviously operator overloading should be limited to class and struct types, so that's not really relevant. UFCS does not have that problem, because you're dealing with free functions and can choose to not use UFCS and provide the full import path or to alias the function, which you can't do with operators - particularly built-in operators. I still don't understand what you're getting at, unfortunately. D was designed to be much cleaner with operator overloading than C++ is. It restricts what the definitions of the operators are so that you don't have to define as many of them to get the basic operations (e.g. opCmp for most of the comparison operators or op!"++" for both pre-increment and post-increment) and so that they aren't easily overloaded to do stuff that does not correspond to what that operator does for built-in types. D doesn't even use + for string concatenation, because Walter thought that that was operator abuse. Allowing arbitrary code to add overloaded operators to an existing type is not at all in line with that philosophy. Regardless, there really isn't much point in arguing this. If you want things to change, you're going to need to convince Walter, which I very much doubt is going to happen. - Jonathan M Davis Thanks for taking the time to explain, although I still fail to see a good justification for disabling UFCS for operators. I will look for more discussions on the topic and if still no opposing argument seems valid I might push the issue forward.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 16:01:22 UTC, Basile B. wrote: To register a DUB package, you can either fetch (DUB icon) or clone the repo, open the DUB JSON project, compile the right config, then in the libman there's a icon with a gray chain over a book. Click this icon and the library is registered. Where? I searched for 10 minutes and can't find any DUB button besides the dub project editor. If i create a new DUB project it looks like that everything is locked (for example native project configuration)?
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 15:41:45 UTC, TheDGuy wrote: On Thursday, 26 May 2016 at 15:21:40 UTC, Basile B. wrote: Use Coedit: the widget "library manager" allow to register libraries in a single click and then they are usable on the fly, in the projects or in a runnable modules, without specifying anything (except a (*) in a project setting called "libraryAliases". https://github.com/BBasile/Coedit/wiki#library-manager-widget It was especially designed because the other IDE suck a bit with static libraries. Thanks for the tip. I downloaded the version for windows from github and it works fine so far but if i want to "run compiled file" i get the message 'the executino of a runnable module has been implicitly aborted" even though i can run the .exe file manually without any errors. Do you know how i can run my app from out of coedit? Yes and no - CE Projects and DUB projects are always run outside (by deafault) - runnable modules can be run outside using: "Compile file and run outside". It's because runnable modules are different from projects. They are usually compiled so fast that you can recompile before each execution but you can open a GH issue and ask for a new action "run compiled file outside" (to split the action in two phases) When they are run inside, you can use the "Input process" widget to pass some input to the process that's hosted (see the "Windows" menu). To register a DUB package, you can either fetch (DUB icon) or clone the repo, open the DUB JSON project, compile the right config, then in the libman there's a icon with a gray chain over a book. Click this icon and the library is registered. Note that DUB projects are displayed in another widget that the one displayed by default at the right (see "DUB project editor") in the "Windows" menu.
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:48:18 UTC, Basile B. wrote:
On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote:
On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote:
float.init is not equal to 0.0f. In D FP points values are
initialized to nan (not a number).
By the way for strings it works, it's like the array case I
described in the first answer).
yes i guess i tested all/most types and know that float.init
is float.nan but why is nan true and not false?
Oh, I'm so sorry ! I totally missed the point of the Q.
float.nan is not a "unique" value. Several values verify "nan"
(Look at std.math.isNan). So I suppose it's simpler to test for
nullity. Though with the sign there's also two possible 0...
void main(string[] args)
{
writeln(float.nan == float.init); // false
import std.math: isNaN;
writeln(isNaN(float.nan)); // true
writeln(isNaN(float.init)); //true
}
So the shortcut in the compiler might be more simple, there is
only a single test for "if(myFloat)"...
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote: On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the first answer). yes i guess i tested all/most types and know that float.init is float.nan but why is nan true and not false? Oh, I'm so sorry ! I totally missed the point of the Q. float.nan is not a "unique" value. Several values verify "nan" (Look at std.math.isNan). So I suppose it's simpler to test for nullity. Though with the sign there's also two possible 0...
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:38:55 UTC, Basile B. wrote: because nan is not 0 and that the shortcut for float is if (fpValue) <=> if (fpValue != 0) if (!fpValue)<=> if (fpValue == 0) There's no relation between the initializer and the shortcut. It's not because for some values the shortcut matches to the initializer that it must always be the case...But I admit I don't know the exact rationale. Does anyone know ? Ok sorry for the noise and thanks anyway.
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 15:21:40 UTC, Basile B. wrote: Use Coedit: the widget "library manager" allow to register libraries in a single click and then they are usable on the fly, in the projects or in a runnable modules, without specifying anything (except a (*) in a project setting called "libraryAliases". https://github.com/BBasile/Coedit/wiki#library-manager-widget It was especially designed because the other IDE suck a bit with static libraries. Thanks for the tip. I downloaded the version for windows from github and it works fine so far but if i want to "run compiled file" i get the message 'the executino of a runnable module has been implicitly aborted" even though i can run the .exe file manually without any errors. Do you know how i can run my app from out of coedit?
Re: Why do some T.init evaluate to true while others to false?
On 05/26/2016 05:28 PM, ArturG wrote: On Thursday, 26 May 2016 at 15:25:26 UTC, ag0aep6g wrote: [...] What does it matter? You would have to create special cases for them. When? If you want to check if something is the .init value, compare against .init.
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:34:50 UTC, ArturG wrote: On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the first answer). yes i guess i tested all/most types and know that float.init is float.nan but why is nan true and not false? because nan is not 0 and that the shortcut for float is if (fpValue) <=> if (fpValue != 0) if (!fpValue)<=> if (fpValue == 0) There's no relation between the initializer and the shortcut. It's not because for some values the shortcut matches to the initializer that it must always be the case...But I admit I don't know the exact rationale. Does anyone know ?
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:29:52 UTC, Basile B. wrote: float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the first answer). yes i guess i tested all/most types and know that float.init is float.nan but why is nan true and not false?
Easier way to add libraries to visual d?
Hi, i use Visual D as a plugin for visual studio to create D applications. But what bothers me a bit is that i have to tell visual D the exact link to the .lib file for every lib i want to use in the project (!). So these are the steps i have to make to get an external lib working: 1. create a new folder in D:\dmd2\src\ with the name of the library 2. edit the 'sc.ini' file in D:\dmd2\windows\bin\ and add "-I%@P%\..\..\src\[foldername]" under '[Environment]' for every lib i want to use 3. add the .lib file to D:\dmd2\windows\lib 4. add the path to the lib in visual studio (project properties -> Linker -> General -> Library Files) Why do i have to do that? Why can i not just use one folder for the library files in visual d and the compiler searches the .lib files for each library which was imported into the project on its own? Is there an easier way to use libraries?
Re: Easier way to add libraries to visual d?
On Thursday, 26 May 2016 at 15:11:05 UTC, TheDGuy wrote: Hi, i use Visual D as a plugin for visual studio to create D applications. But what bothers me a bit is that i have to tell visual D the exact link to the .lib file for every lib i want to use in the project (!). So these are the steps i have to make to get an external lib working: 1. create a new folder in D:\dmd2\src\ with the name of the library 2. edit the 'sc.ini' file in D:\dmd2\windows\bin\ and add "-I%@P%\..\..\src\[foldername]" under '[Environment]' for every lib i want to use 3. add the .lib file to D:\dmd2\windows\lib 4. add the path to the lib in visual studio (project properties -> Linker -> General -> Library Files) Why do i have to do that? Why can i not just use one folder for the library files in visual d and the compiler searches the .lib files for each library which was imported into the project on its own? Is there an easier way to use libraries? Use Coedit: the widget "library manager" allow to register libraries in a single click and then they are usable on the fly, in the projects or in a runnable modules, without specifying anything (except a (*) in a project setting called "libraryAliases". https://github.com/BBasile/Coedit/wiki#library-manager-widget It was especially designed because the other IDE suck a bit with static libraries.
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:25:03 UTC, arturg wrote: On Thursday, 26 May 2016 at 15:15:57 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and "<=>" stands for "equivalence" I obviously meant: integral(*): if (i) <=> if (i != 0), "<>" is the Pascal operator for C's "!=" yes i know about most of those shortcuts its just float.init and char.init that work different then the other when you do this if(someType) // will be true for float and char while someType is T.init float.init is not equal to 0.0f. In D FP points values are initialized to nan (not a number). By the way for strings it works, it's like the array case I described in the first answer).
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:25:26 UTC, ag0aep6g wrote:
On 05/26/2016 04:03 PM, ArturG wrote:
for example:
if(any floatingpoint.init) will be true
if(any char.init) also true
if("") also true
while others are false e.g.
string s;
if(s) will be false
all others are also false or did i miss any?
What does it matter?
You would have to create special cases for them.
Re: Why do some T.init evaluate to true while others to false?
On 05/26/2016 04:03 PM, ArturG wrote:
for example:
if(any floatingpoint.init) will be true
if(any char.init) also true
if("") also true
while others are false e.g.
string s;
if(s) will be false
all others are also false or did i miss any?
What does it matter?
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:15:57 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and "<=>" stands for "equivalence" I obviously meant: integral(*): if (i) <=> if (i != 0), "<>" is the Pascal operator for C's "!=" yes i know about most of those shortcuts its just float.init and char.init that work different then the other when you do this if(someType) // will be true for float and char while someType is T.init
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:14:21 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and "<=>" stands for "equivalence" I obviously meant: integral(*): if (i) <=> if (i != 0), "<>" is the Pascal operator for C's "!="
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 15:11:50 UTC, Basile B. wrote: On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote: [...] [...] - integral(*): if (i) <=> if (i > 0) I obviously meant: - integral(*): if (i) <=> if (i <> 0) and "<=>" stands for "equivalence"
Re: Why do some T.init evaluate to true while others to false?
On Thursday, 26 May 2016 at 14:03:16 UTC, ArturG wrote:
for example:
if(any floatingpoint.init) will be true
if(any char.init) also true
if("") also true
while others are false e.g.
string s;
if(s) will be false
all others are also false or did i miss any?
It's a shortcut that works for certain type and that means:
- pointers: if (ptr) <=> if (ptr != null)
- pointers: if (!ptr) <=> if (ptr == null)
- integral(*): if (i) <=> if (i > 0)
- integral: if (!i) <=> if (i == 0)
- classes: if (c) <=> if (c !is null)
- classes: if (!c)<=> if (c is null)
(*) integral: generally speaking so: byte, ubyte, short, ushort,
int, uint, long, ulong, char, wchar, dchar and also, very special
case, structs with an alias this to one of this integral type.
for array this works and this tests the (.ptr) member but most of
the people here (incl. me) would recommand rather to always do:
"if (arr.length)"
because in some cases "if (arr)" will yield "true" even if the
length is equal to 0.
Re: Effect of declaring a class immutable ?
On Thursday, 26 May 2016 at 14:12:23 UTC, chmike wrote:
I couldn't find any information about this on the dlang web
site.
What is the effect adding the immutable attribute to a class
like this
immutable class MyClass { ... }
The compiler doesn't complain.
Will it add the immutable attribute to all members ?
Since immutable is transitive everything in your class will be.
So basically the only thing you can do is
- create a new immutable(MyClass)
- sets the instances variables in the ctor.
- calls the method (which can't do anything on the variables).
And that's all, e.g:
immutable class Foo
{
int i;
this(int i){this.i = i;}
void method(){}
}
void main()
{
immutable(Foo) foo = new immutable(Foo)(1);
//foo.i = 8; // not possible since i is immutable
Foo foo1 = cast(Foo) foo; // cast away immutable from the
type.
//foo1.method; // not pissible since method is immutable
}
So it's more or less useless, unless you want to wrap some
variables in a class to simplify completion in the IDE or
whatever other reasons.
_
By the way the doc for "immutable class Stuff" is here:
https://dlang.org/spec/const3.html#immutable_type, it's a type
constructor. "immutable" is fully part of the type.
Re: Effect of declaring a class immutable ?
On Thursday, May 26, 2016 14:12:23 chmike via Digitalmars-d-learn wrote:
> I couldn't find any information about this on the dlang web site.
>
> What is the effect adding the immutable attribute to a class like
> this
>
> immutable class MyClass { ... }
>
> The compiler doesn't complain.
> Will it add the immutable attribute to all members ?
If you put any attribute on a class that's not specifically for a class
(like abstract or final), then it will mark all of its members with that
attribute, which is almost never what you want. It's equivalent to doing
something like
immutable
{
class MyClass
{
}
}
or
class MyClass
{
immutable:
}
- Jonathan M Davis
Re: Effect of declaring a class immutable ?
On Thursday, 26 May 2016 at 14:12:23 UTC, chmike wrote:
I couldn't find any information about this on the dlang web
site.
What is the effect adding the immutable attribute to a class
like this
immutable class MyClass { ... }
The compiler doesn't complain.
Will it add the immutable attribute to all members ?
auto mc = new MyClass;
typeof(mc.someFieldOrFun).stringof.writeln; says yes
and if you define opCall you need to use
auto mc = new immutable MyClass;
Runtime.loadLibrary linker errors
Hi, Whenever I try to compile code that relies on Runtime.loadLibrary, I get a linker error during compilation. ``` Undefined symbols for architecture x86_64: "_rt_loadLibrary", referenced from: _D4core7runtime7Runtime17__T11loadLibraryZ11loadLibraryFxAaZPv in ll_test.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) --- errorlevel 1 ``` I'm using dmd 2.071 and ldc 0.17 on OS X. I've seen comments and some indications in the source that this function isn't available on OS X, but it's not entirely clear (forum threads are old, and the source in runtime is a bit over my head.) If this code won't compile on OS X, is there an alternative? Thanks, -c.
Effect of declaring a class immutable ?
I couldn't find any information about this on the dlang web site.
What is the effect adding the immutable attribute to a class like
this
immutable class MyClass { ... }
The compiler doesn't complain.
Will it add the immutable attribute to all members ?
Why do some T.init evaluate to true while others to false?
for example:
if(any floatingpoint.init) will be true
if(any char.init) also true
if("") also true
while others are false e.g.
string s;
if(s) will be false
all others are also false or did i miss any?
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 07:51:46 UTC, Era Scarecrow wrote: If the ptr is at offset 0, we declare it first, otherwise second, simple... Except this fails since "no property 'offsetof' for type 'void*'". SO... I make a template to test for it instead. Built-in arrays are kinda magical and thus their members aren't ordinary members you can inspect like that. return *(cast(size_t*) ) != 1; And I'm pretty sure that cast is illegal in CTFE. Perhaps the bug here is that dmd isn't throwing an error when it is supposed to... The value being compared gives 0 when I try it, which wouldn't make sense for either .length or .ptr. Am i going about this the wrong way? I don't think there's a need for a test because the ABI spec says length is always defined to be at offset zero anyway: http://dlang.org/spec/abi.html#arrays If you want to test it, a runtime assert would probably be enough, at least then it won't do the wrong thing and your message can tell the user to recompile. Runtime assert is prolly better anyway just in case ctfe disagrees with the execution platform.
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 12:30:30 UTC, Alex Parrill wrote: The line "not having to make another array to keep track of lengths and then shorten them" is fairly vague. "Shortening" an array via slicing is basically free (it's just some integer arithmetic), but I'm not sure if that's what you meant. Indeed, creating a slice from a static array, another slice, or a pointer is free too...
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 07:51:46 UTC, Era Scarecrow wrote: ... This smells like an XY problem [0]. Why exactly do you need the internal layout of the array structure? The line "not having to make another array to keep track of lengths and then shorten them" is fairly vague. "Shortening" an array via slicing is basically free (it's just some integer arithmetic), but I'm not sure if that's what you meant. [0]: http://meta.stackexchange.com/questions/66377/what-is-the-xy-problem
Re: Testing array ptr for offset 0...
On 05/26/2016 09:51 AM, Era Scarecrow wrote:
So I'm experimenting and want to override how arrays are managed for a
short duration, this is for optimization of not having to make another
array to keep track of lengths and then shorten them when i can in fact
just manage it myself *very* briefly.
So, I need to make sure the structure is compatible with the built-in
array structure (since the remainder of the calls are via normal
convention and no allocation/resizing is done except by progressively
smaller slices, so it should be compatible as long as it's a valid
pointer).
I don't follow. Why can't you use a built-in array? What can you do with
the stand-in that you can't do with the array itself?
[...]
template isArrayPtrOffsetZero() {
auto check() {
static assert([].sizeof == (size_t.sizeof*2));
size_t[] arr = new size_t[1]; //length == 1.
return *(cast(size_t*) ) != 1;
}
enum isArrayPtrOffsetZero = check();
}
[...]
Except this blows up and always gives the wrong answer... ==1 length
test reverses it but is now the wrong test, and changing it to
isArrayLengthOffsetZero will in turn give the wrong answer again...
Here's how I understand that code:
isArrayPtrOffsetZero is supposed to check if the offset of ptr is 0. You
do that by setting the length of some array to 1, and then checking if
the first half of the array structure is not 1. If it's 1, then length's
offset is 0, so ptr's offset can't be 0. If it's not 1, then length's
offset isn't 0, so ptr's offset must be 0.
Seems a bit back and forth, but as far as I can see it works as you
want. Why do you think the answer it gives is wrong? What answer does it
give you?
Re: full copies on assignment
On Wednesday, 25 May 2016 at 15:44:34 UTC, Marc Schütz wrote:
On Tuesday, 24 May 2016 at 20:58:11 UTC, John Nixon wrote:
On Tuesday, 24 May 2016 at 15:17:37 UTC, Adam D. Ruppe wrote:
On Tuesday, 24 May 2016 at 14:29:53 UTC, John Nixon wrote:
Or add an explicit constructor:
struct CS {
// ...
this(const CS rhs) { this = rhs; }
Unfortunately this results in "Error: cannot implicitly convert
expression (rhs) of type const(CS) to CS'.
Re: Testing array ptr for offset 0...
On Thursday, 26 May 2016 at 09:16:48 UTC, Kagamin wrote:
try this:
struct X
{
byte[] data;
alias data this;
}
This doesn't help me with what I want, and effectively does
nothing as far as I can tell. Although testing is showing
managing the pointer & length directly is a little slower for
whatever reason.
Re: Testing array ptr for offset 0...
try this:
struct X
{
byte[] data;
alias data this;
}
Re: What's wrong with my usage of std.algorithm.map in this code example?
On Wednesday, 25 May 2016 at 19:07:32 UTC, Era Scarecrow wrote:
On Wednesday, 25 May 2016 at 13:27:28 UTC, Chris wrote:
Why can the tuple be iterated with foreach, as in my quick
fix, and indexed with tuple[0..], but is not accepted as a
range? What are the differences? Is there a way to rangify a
tuple?
The tuple is identified/used at compile-time, as such it's a
compiler primitive and not a range. Foreach in this case will
unroll the loop regardless how it looks. So...
test(Args...)(Args args) {
...
foreach (const ref i; items)
itemstrings ~= i.to!string;
Will become: (const and ref are pointless in this example,
unless the args are referenced)
test(int arg1, int arg2, int arg3, int arg4) {
...
itemstrings ~= arg1.to!string;
itemstrings ~= arg2.to!string;
itemstrings ~= arg3.to!string;
itemstrings ~= arg4.to!string;
Trying to use map on it was literally expanding the entire
input to map.
Ah, I didn't know that it was just unrolled. That makes sense, of
course.
[snip]
Testing array ptr for offset 0...
So I'm experimenting and want to override how arrays are managed
for a short duration, this is for optimization of not having to
make another array to keep track of lengths and then shorten them
when i can in fact just manage it myself *very* briefly.
So, I need to make sure the structure is compatible with the
built-in array structure (since the remainder of the calls are
via normal convention and no allocation/resizing is done except
by progressively smaller slices, so it should be compatible as
long as it's a valid pointer).
But i seem to have an issue trying to test if ptr is at offset 0
or not. Having the wrong order would be catastrophic, and if the
source changes (for whatever reason) i don't want to have to fix
it.
So... the obvious test: static if ([].ptr.offsetof == 0)
If the ptr is at offset 0, we declare it first, otherwise
second, simple... Except this fails since "no property 'offsetof'
for type 'void*'". SO... I make a template to test for it instead.
template isArrayPtrOffsetZero() {
auto check() {
static assert([].sizeof == (size_t.sizeof*2));
size_t[] arr = new size_t[1]; //length == 1.
return *(cast(size_t*) ) != 1;
}
enum isArrayPtrOffsetZero = check();
}
struct X {
static if (isArrayPtrOffsetZero!()) {
int* ptr;
size_t length;
} else { ... }
}
Except this blows up and always gives the wrong answer... ==1
length test reverses it but is now the wrong test, and changing
it to isArrayLengthOffsetZero will in turn give the wrong answer
again...
Am i going about this the wrong way?
Re: import in mixin template
On Thursday, 26 May 2016 at 05:47:36 UTC, Era Scarecrow wrote:
On Thursday, 26 May 2016 at 05:20:25 UTC, vitus wrote:
Why 'alias wln1 = writeln;' doesnt't work but 'alias wln2 =
std.stdio.writeln;' work when import is not static? Why
'wln2("test");' work but 'std.stdio.writeln("test");' doesn't?
(changing import to static import doesn't change anything)
The import seems to be localized to just the mixin & the
template. Makes sense since you don't want to be cluttering the
namespace with other imports.
The only thing you haven't shown is that the 'alias m' is
identified and accessible. Adding it in the compiler doesn't
complain; Only line 11 (alias wln1) complains for me DMD w32
v2.071.0.
But why is 'std.stdio.writeln' accessible from CLASS but writeln
no? Both are imported in MIXIN.
and:
mixin template MIXIN(){
import std.stdio;
}
class CLASS{
mixin MIXIN;
void test(){
alias wln = std.stdio.writeln; //OK
wln("test"); //OK
std.stdio.writeln("test"); //Error: Deprecation: module
std.stdio is not accessible here, perhaps add 'static import
std.stdio;'
}
}
Why is possible create alias to function 'std.stdio.writeln' but
cannot by called as a function directly?
Re: Operator overloading through UFCS doesn't work
On Wednesday, May 25, 2016 23:31:18 Elie Morisse via Digitalmars-d-learn
wrote:
> On Wednesday, 25 May 2016 at 21:50:06 UTC, Jonathan M Davis wrote:
> > It's not an overloaded operator anymore at that point, and that
> > definitely fails to work for generic code, since not all
> > operators are overloaded operators. Free functions don't have
> > that problem.
>
> Sorry to reiterate the previous post but is that really the case?
>
>void FuncTemplate(...)(...) {
> X.FreeFunc(Y);
>}
>
>import ModuleA; // contains FreeFunc
>import ModuleB; // contains a conflicting FreeFunc overload
>
>FuncTemplate!()(); // fails
>
> Where is the difference with writing generic code with operators
> (overloaded or not)?
The difference is that it's impossible to do 10.opBinary!"+"(15), so if
you're forced to do foo.opBinary!"+"(bar) to get around a symbol conflict,
it won't work with built-in types. UFCS does not have that problem, because
you're dealing with free functions and can choose to not use UFCS and
provide the full import path or to alias the function, which you can't do
with operators - particularly built-in operators.
D was designed to be much cleaner with operator overloading than C++ is. It
restricts what the definitions of the operators are so that you don't have
to define as many of them to get the basic operations (e.g. opCmp for most
of the comparison operators or op!"++" for both pre-increment and
post-increment) and so that they aren't easily overloaded to do stuff that
does not correspond to what that operator does for built-in types. D doesn't
even use + for string concatenation, because Walter thought that that was
operator abuse. Allowing arbitrary code to add overloaded operators to an
existing type is not at all in line with that philosophy.
Regardless, there really isn't much point in arguing this. If you want
things to change, you're going to need to convince Walter, which I very much
doubt is going to happen.
- Jonathan M Davis
