Re: What's up with GDC?
Real professionals won't have difficulties to find binaries for ldc: https://github.com/ldc-developers/ldc/releases -- Bien cordialement, Ch.Meessen > Le 10 juin 2016 à 22:30, Joerg Joergonson via Digitalmars-d-learn > a écrit : > >> On Friday, 10 June 2016 at 19:51:19 UTC, Johan Engelen wrote: >>> On Friday, 10 June 2016 at 19:37:13 UTC, Joerg Joergonson wrote: >>> arm-linux-genuabi? arm-linux-gnueableihfqueridsofeyfh? >>> aifh-fkeif-f-fdsskjhfkjfafaa? >> >> Rofl! >> >>> and ldc requires building from sources(actually I didn't have too much >>> trouble with installing it but it doesn't work with my libs because of the >>> crappy coff issues that D has had since birth(it's like a tumor)). >> >> Why do you have to build from sources? Any details about the problems you >> see? >> >> Thanks, >> Johan > > Well, the post was a bit incoherent because getting all this stuff working > is. I was searching for ldc and ran across some web site that had only the > sources(same for gdc). > > The point of it all is that things seem to be a bit discombobulated and make > D look bad. Professions won't use D if it can't be used professionally(not > that I'm a pro, just saying). > > Why isn't there a proper binaries for ldc and gdc that work out of the box > like dmd? There used to be. What's up with all this arm-linux-genuabi crap? > When one opens up the archive all the files are named that way too. There is > no explanation of what that means. Did some kid write this stuff in his > basement or is this suppose to be serious? Do people think about the end user > when creating this stuff or is it just a eureka moment "Lightbulb: Lets > create some spaghetti!". > > I would have thought things would have gotten easier and more logical but > that doesn't seem to be the case. > >
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