Re: Why aren't overloaded nested functions allowed?
On Monday, 30 May 2016 at 23:17:15 UTC, pineapple wrote: On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote: From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale? I'm guessing it's related to - Unlike module level declarations, declarations within function scope are processed in order. And I'd suspect that the cleanest solution would be similar to the one given for interdependent functions: Declare the nested functions in a static nested struct instead. Ok, thanks.
Re: Why simple code using Rebindable doesn't compile ?
On Tuesday, 31 May 2016 at 05:31:59 UTC, chmike wrote: My conclusion is that rebindable is not a satisfying solution to have mutable references to immutable objects. I don't understand the rationale of these immutable references. It is too constraining. I still don't know why you're trying to use immutable. In the other thread you have listed you are trying to make a global singleton? You needed it mutable but marked immutable (for... some reason?) but all the methods won't change the contents or spirit of the object. I need to wrap my head around what you're trying to do before i can suggest anything else. Although making all members private and all functions as const would give you a mutable/unchanging object...
Re: Why simple code using Rebindable doesn't compile ?
On Monday, 30 May 2016 at 21:32:46 UTC, Alex Parrill wrote:
On Monday, 30 May 2016 at 10:09:19 UTC, chmike wrote:
Why can't info() return a Rebindable!(immutable(InfoImpl)) ?
What do you mean? `info` returns an `immutable(InfoImpl)`, not
a `Rebindable!(immutable(InfoImpl))`. Rebindable doesn't apply
itself to the return types of the methods of the return types
(there's no reason to).
I mean that if I change the return type of info() into
Rebindable!(immutable(infoImpl)) like this
Rebindable!(immutable(InfoImpl)) info() { ... return
rebindable(x);}
I get an error. I was explained privately that its because
Rebindable... Is an lvalue and not a type.
My conclusion is that rebindable is not a satisfying solution to
have mutable references to immutable objects.
I don't understand the rationale of these immutable references.
It is too constraining.
Re: Operator overloading through UFCS doesn't work
Here's one more vote for extending UFCS to operator overloading. Elie wrote that it's "a restriction that seems pointless and arbitrary"... which summarizes my own thoughts rather well, too. There are certainly concerning scenarios that can arise from making this change, but the correct way to approach this problem is not to tell the programmer "I won't let you use that tool, because if you mishandle it then you might find yourself in a nasty mess." That's what Java does - it treats the programmer like an idiot - and that's why it's so universally despised. It has consistently been my impression that this is very much not the sort of philosophy D follows. Anyway, D already provides the programmer with a wealth of tools which, if mishandled, can place them in a nasty mess. So I think this is a poor rationale for withholding from the programmer one more.
Re: Why aren't overloaded nested functions allowed?
On Monday, 30 May 2016 at 16:22:26 UTC, Max Samukha wrote: From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale? I'm guessing it's related to - Unlike module level declarations, declarations within function scope are processed in order. And I'd suspect that the cleanest solution would be similar to the one given for interdependent functions: Declare the nested functions in a static nested struct instead.
Re: Why do some T.init evaluate to true while others to false?
On Friday, 27 May 2016 at 15:49:16 UTC, ArturG wrote: On Friday, 27 May 2016 at 15:24:18 UTC, Adam D. Ruppe wrote: On Friday, 27 May 2016 at 15:19:50 UTC, ArturG wrote: yes but i have to check for that when some one does Why? This is no different than if they set any of the other four billion possible values. What do you mean? operation on float.nan gives you a float.nan so why does the shortcut evaluate to true and not false wouldnt that make more sense? NaN in IEEE 754 floating-point numbers (the floating-point number system most languages and processors use) is defined as a number with all exponent bits set and a non-zero mantissa. The mantissa value is the "NaN payload", and can be any value. `is` does a binary comparison on floating-point numbers, so NaNs with different payloads will not be considered equal, as you have found out with `float.init !is float.nan`.
Re: Why simple code using Rebindable doesn't compile ?
On Monday, 30 May 2016 at 10:09:19 UTC, chmike wrote:
This code compile, but array appending doesn't work
alias Rebindable!(immutable(InfoImpl)) Info;
class InfoImpl
{
void foo() {}
static immutable(InfoImpl) info()
{
__gshared immutable InfoImpl x = new immutable InfoImpl;
return x;
}
}
void main()
{
Info t = Info.info;
Info[] a;
//a ~= Info.info; <-- KO Compiler Error
a ~= rebindable(Info.info); // Ok
}
-
Why can't info() return a Rebindable!(immutable(InfoImpl)) ?
What do you mean? `info` returns an `immutable(InfoImpl)`, not a
`Rebindable!(immutable(InfoImpl))`. Rebindable doesn't apply
itself to the return types of the methods of the return types
(there's no reason to).
Re: D, GTK, Qt, wx,…
On Sunday, 29 May 2016 at 11:03:36 UTC, Russel Winder wrote: Is there even a wxD? Or perhaps there is an alternative that fits the bill of being production ready now, and either gives the same UI across all platforms or provides a platform UI with no change of source code, just a recompilation. There is DlangUI library. Gives same UI across all platforms, no source code change required, just recompilation. Widget set is not as full as in Qt or wx, but it's easy to extend, because DlangUI is not a binding, and written completely in D.
Re: Why do some T.init evaluate to true while others to false?
On Friday, 27 May 2016 at 14:48:59 UTC, Adam D. Ruppe wrote:
On Friday, 27 May 2016 at 14:43:47 UTC, ArturG wrote:
if(value is typeof(value).init) ...
that still requiers a special case for floating points, arrays
and optionally empty string literals.
Have you tried? That should work in all cases.
does this count?
struct Foo
{
int x;
float f;
}
void main()
{
Foo foo;
if(foo is typeof(foo).init) "A: does'nt work".writeln;
foo = Foo();
if(foo is typeof(foo).init) "B: works".writeln;
}
if you remove the float from the struct both cases work or if you
define the float inside the struct like this:
struct Foo
{
int x;
// float f = float.init; // does'nt work
float f = float.nan;
}
Re: String compare in words?
I didn't check assembly for '=='. What I have seen is that struct
comparison in dmd is implemented as byte per byte compare even if the
struct is 64bit long (e.g. Rebindable). I suppose dmd uses this
strategy because struct/array may not be 64bit aligned, or they could
have different alignment.
In order to use the suggested optimization we need a good planet
alignment. The effort to check that, or enforce it, is not worth the
benefit on average.
There could be a benefit in specific use cases where the alignment is
ensured.
I would be interested in such optimization with Rebindable. Can the 'is'
operator be overloaded ?
Le 30/05/2016 11:28, ag0aep6g via Digitalmars-d-learn a écrit :
On 05/29/2016 10:40 PM, qznc wrote:
bool string_cmp_opt(immutable(ubyte)[] x, immutable(ubyte)[] y) {
Having "string" in the function name may be a bit misleading. This
doesn't have any special functionality for text/characters/Unicode,
does it?
Should have const parameters, not immutable.
pragma(inline, false);
I think you have to put this pragma on the function signature, not in
the body. Also, why prevent inlining of the function?
if (x.length != y.length) return false;
int i=0;
int isn't large enough for array lengths.
// word-wise compare is faster than byte-wise
if (x.length > size_t.sizeof)
for (; i < x.length - size_t.sizeof; i+=size_t.sizeof) {
size_t* xw = cast(size_t*) &x[i];
size_t* yw = cast(size_t*) &x[i];
Typo: Should be `&y[i]` here.
if (*xw != *yw) return false;
}
// last sub-word part
for (; i < x.length; i+=1) {
if (x[i] != y[i]) // byte compare
return false;
}
return true;
}
Any comments or recommendations?
Did you benchmark this against the built-in `==`, with ldc or gdc?
If this is correct and faster than the built-in `==`, why isn't it the
built-in `==`?
--
Bien cordialement,
Ch.Meessen
Why aren't overloaded nested functions allowed?
From the spec (https://dlang.org/spec/function.html#nested): "Nested functions cannot be overloaded." Anybody knows what's the rationale?
Re: Operator overloading through UFCS doesn't work
On Sunday, 29 May 2016 at 07:18:10 UTC, Jonathan M Davis wrote: On Friday, May 27, 2016 09:08:20 Marc Schütz 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. Well, that begs the question: Why don't built-in types define `opBinary`? That's just another arbitrary irregularity, isn't it. It was never intended that any op* function be called by anyone except where the compiler lowers code to use them. They're for declaring overloaded operators on user-defined types so that those types can be used with those operators. If you're calling opBinary in your own code, you're doing it wrong. And it would be downright silly to then add opBinary to the built-in types. If I were to design my own language from scratch, that's actually how I would do it. All operators, even for built-in types, would just be syntax sugar for the method calls. The goal should be to minimize the difference between built-in and user-defined types as much as possible. Turtles all the way down... They don't need operator overloading. They already have the operators. Operators are supposed to be used as operators, not functions, and if there's any need to use them as functions, then there's something seriously wrong. And the fact that allowing free functions to overload operators via UFCS sends us into that territory just highlights the fact that they're a horrible idea. I'd say the fact that it doesn't work, and can't currently work for the reasons you described, points to an inconsistency in the language's design. It means that we have two largely overlapping concepts (builtin types and user defined types), where most language features work the same for both, but some don't. That's not the end of the world, of course, but still...
Re: String compare in words?
On Monday, 30 May 2016 at 09:28:29 UTC, ag0aep6g wrote:
On 05/29/2016 10:40 PM, qznc wrote:
bool string_cmp_opt(immutable(ubyte)[] x, immutable(ubyte)[]
y) {
Having "string" in the function name may be a bit misleading.
This doesn't have any special functionality for
text/characters/Unicode, does it?
Should have const parameters, not immutable.
pragma(inline, false);
I think you have to put this pragma on the function signature,
not in the body. Also, why prevent inlining of the function?
if (x.length != y.length) return false;
int i=0;
int isn't large enough for array lengths.
// word-wise compare is faster than byte-wise
if (x.length > size_t.sizeof)
for (; i < x.length - size_t.sizeof;
i+=size_t.sizeof) {
size_t* xw = cast(size_t*) &x[i];
size_t* yw = cast(size_t*) &x[i];
Typo: Should be `&y[i]` here.
if (*xw != *yw) return false;
}
// last sub-word part
for (; i < x.length; i+=1) {
if (x[i] != y[i]) // byte compare
return false;
}
return true;
}
Any comments or recommendations?
Did you benchmark this against the built-in `==`, with ldc or
gdc?
If this is correct and faster than the built-in `==`, why isn't
it the built-in `==`?
I too expected it to compile to a memcmp call, but according to
asm.dlang.org DMD with -O and -release, DMD compiles a == b to a
byte-wise compare.
I suppose for very tiny strings this is the fastest, but for
slightly larger strings, calling memcmp() would be faster. I
think inlining a string comparison is also not great for code
size. In the general case, for element types with trivial
equality, a call to memcmp() will always be preferable, right?
Re: How to hash any type to an integer?
On Sunday, 29 May 2016 at 16:26:58 UTC, Seb wrote: On Sunday, 29 May 2016 at 11:05:21 UTC, Gary Willoughby wrote: I'm currently implementing a hash map as an exercise and wondered if there is a built-in function I could use to hash keys effectively? What I'm looking for is a function that hashes any variable (of any type) to an integer. I've been looking at the `getHash` function of the `TypeInfo` class but that only seems to return the passed pointer. Any ideas? How about hashOf? https://dlang.org/phobos/object.html#.hashOf Awesome, thanks. Can't believe I missed that.
Re: Why simple code using Rebindable doesn't compile ?
This code compile, but array appending doesn't work
alias Rebindable!(immutable(InfoImpl)) Info;
class InfoImpl
{
void foo() {}
static immutable(InfoImpl) info()
{
__gshared immutable InfoImpl x = new immutable InfoImpl;
return x;
}
}
void main()
{
Info t = Info.info;
Info[] a;
//a ~= Info.info; <-- KO Compiler Error
a ~= rebindable(Info.info); // Ok
}
-
Why can't info() return a Rebindable!(immutable(InfoImpl)) ?
Re: String compare in words?
On 05/29/2016 10:40 PM, qznc wrote:
bool string_cmp_opt(immutable(ubyte)[] x, immutable(ubyte)[] y) {
Having "string" in the function name may be a bit misleading. This
doesn't have any special functionality for text/characters/Unicode, does it?
Should have const parameters, not immutable.
pragma(inline, false);
I think you have to put this pragma on the function signature, not in
the body. Also, why prevent inlining of the function?
if (x.length != y.length) return false;
int i=0;
int isn't large enough for array lengths.
// word-wise compare is faster than byte-wise
if (x.length > size_t.sizeof)
for (; i < x.length - size_t.sizeof; i+=size_t.sizeof) {
size_t* xw = cast(size_t*) &x[i];
size_t* yw = cast(size_t*) &x[i];
Typo: Should be `&y[i]` here.
if (*xw != *yw) return false;
}
// last sub-word part
for (; i < x.length; i+=1) {
if (x[i] != y[i]) // byte compare
return false;
}
return true;
}
Any comments or recommendations?
Did you benchmark this against the built-in `==`, with ldc or gdc?
If this is correct and faster than the built-in `==`, why isn't it the
built-in `==`?
Re: Why simple code using Rebindable doesn't compile ?
Oops, the duplicate alias instruction and main are copy past
error. It looks like the code was already too complex for me. ;)
Here is the code I tested
import std.typecons;
Rebindable!(immutable TestImpl) Test;
class TestImpl
{
void foo() {}
Test test() { __gshared x = new immutable TestImpl; return
rebindable(x); }
}
void main()
{
Test t = Test.test;
}
Why simple code using Rebindable doesn't compile ?
Hello,
here is a program stripped down to the minimum code that doesn't
compile
import std.typecons;
Rebindable!(immutable TestImpl) Test;
Rebindable!(immutable TestImpl) Test;
class TestImpl
{
void foo() {}
Test test() { __gshared x = new immutable TestImpl; return
rebindable(x); }
}
void main()
{
Test t = Test.test;
}
void main()
{
Test t = Test.test;
}
source/app.d(32,10): Error: circular reference to 'app.Test'
source/app.d(32,10): Error: Test is used as a type
/usr/include/dmd/phobos/std/typecons.d(1616,20): Error: template
instance std.traits.isDynamicArray!(immutable(TestImpl)) error
instantiating
source/app.d(27,1):instantiated from here:
Rebindable!(immutable(TestImpl))
/usr/include/dmd/phobos/std/typecons.d(1625,17): Error: mixin
std.typecons.RebindableCommon!(immutable(TestImpl), TestImpl,
Rebindable) does not match template declaration
RebindableCommon(T, U, alias This) if (is(T == class) || is(T ==
interface) || isAssociativeArray!T)
