On 3/3/21 1:37 PM, Jack wrote:
the one that the compiler defaults to when you don't provide one?
There's no default opCmp.
For opEquals, it's a memberwise comparison.
-Steve
the one that the compiler defaults to when you don't provide one?
On 11/19/20 6:12 AM, Steven Schveighoffer wrote:
On 11/18/20 6:06 PM, ag0aep6g wrote:
int opCmp(S other)
{
import std.typecons: tuple;
return tuple(this.tupleof).opCmp(tuple(other.tupleof));
}
Ah, excellent solution! I hadn't thought of that.
-Steve
On 11/18/20 6:06 PM, ag0aep6g wrote:
On Wednesday, 18 November 2020 at 22:29:17 UTC, Steven Schveighoffer wrote:
How do I do something really simple for opCmp? I tried this it didn't
work:
return this == other ? 0 :
this.tupleof < other.tupleof ? -1 : 1;
std.typecons.Tuple has opCmp.
opCmp. While this is
useful for the compiler, there's no default I know of that is an easy
one-liner.
Here's a stab at a totally generic version that I haven't unit tested at
all, except to verify that it works for your example struct S:
auto cmp(T, U)(auto ref T lhs, auto ref U rhs
On Wednesday, 18 November 2020 at 22:29:17 UTC, Steven
Schveighoffer wrote:
How do I do something really simple for opCmp? I tried this it
didn't work:
return this == other ? 0 :
this.tupleof < other.tupleof ? -1 : 1;
std.typecons.Tuple has opCmp. So this works:
int opCmp(S ot
On Wednesday, 18 November 2020 at 22:29:17 UTC, Steven
Schveighoffer wrote:
I have a struct like this:
struct S
{
int x;
int y;
}
and I want a default comparison. The problem is, that
comparison doesn't have a default, and requires I implement
opCmp. While this is useful
I have a struct like this:
struct S
{
int x;
int y;
}
and I want a default comparison. The problem is, that comparison doesn't
have a default, and requires I implement opCmp. While this is useful for
the compiler, there's no default I know of that is an easy one-liner.
The truth
On Friday, December 6, 2019 12:03:45 AM MST berni44 via Digitalmars-d-learn
wrote:
> In std.typecons, in Tuple there are two opCmp functions, that are
> almost identical; they only differ by one being const and the
> other not:
>
> int opCmp(R)(R rhs)
> if (a
On Friday, 6 December 2019 at 07:03:45 UTC, berni44 wrote:
In std.typecons, in Tuple there are two opCmp functions, that
are almost identical; they only differ by one being const and
the other not:
int opCmp(R)(R rhs)
if (areCompatibleTuples!(typeof(this), R
a template this parameter [1] to have a new copy of
opCmp generated for each qualified version of Tuple it's called
with:
int opCmp(R, this This)(R rhs) const
if (areCompatibleTuples!(typeof(this), R, "<"))
{
...
}
This may lead to binary bloat, though, since you can pote
In std.typecons, in Tuple there are two opCmp functions, that are
almost identical; they only differ by one being const and the
other not:
int opCmp(R)(R rhs)
if (areCompatibleTuples!(typeof(this), R, "<"))
{
static foreach (i; 0 ..
values are sufficiently
larger than that hard-coded value.
I think feqrel() will be useful there:
https://dlang.org/phobos/std_math.html#.feqrel
Ali
I'd do something like that (disclaimer - from memory):
```
int opCmp( T rhs ) const {
auto diff = curVal - rhs;
auto epsilon
-coded value.
I think feqrel() will be useful there:
https://dlang.org/phobos/std_math.html#.feqrel
Ali
I'd do something like that (disclaimer - from memory):
```
int opCmp( T rhs ) const {
auto diff = curVal - rhs;
auto epsilon = max(curVal.epsilon, rhs.e
On 12/24/2017 02:10 AM, kerdemdemir wrote:
> if ( fabs(diff) < 0.0001 )
I can't answer your question but I know that the comparison above is
wrong because it can be meaningful only if the values are sufficiently
larger than that hard-coded value.
I think feqrel() will be
In documentation and forums I found some example for overloading
opCmp for int values. But I couldn't see any examples for double
values.
That is what I come up with my own:
struct AdjustableVal ( T = double )
{
this ( T initVal )
{
curVal = initVal
On Tuesday, 13 June 2017 at 16:49:14 UTC, H. S. Teoh wrote:
On Tue, Jun 13, 2017 at 10:51:40AM -0400, Steven Schveighoffer
via Digitalmars-d-learn wrote: [...]
I think Andrei has a nice way to do opCmp for integers that's
a simple subtraction and negation or something like
s about the subject. I have to sit down and
write it down.
I agree. It's a thing also that can be optimized in unintuitive
ways. I think Andrei has a nice way to do opCmp for integers
that's a simple subtraction and negation or something like that.
I observed that compiler optimizers are prett
On Tue, Jun 13, 2017 at 10:51:40AM -0400, Steven Schveighoffer via
Digitalmars-d-learn wrote:
[...]
> I think Andrei has a nice way to do opCmp for integers that's a simple
> subtraction and negation or something like that.
[...]
In theory, cmp(int x, int y) can be implemented simply as
On 6/11/17 11:24 AM, Honey wrote:
On Friday, 9 June 2017 at 17:50:28 UTC, Honey wrote:
Looking at the implementation of Tuple.opCmp, I'm not sure I'd bet on
existence of opCmp for fundamental types:
int opCmp(R)(R rhs)
if (areCompatibleTuples!(typeof(this), R
On Sunday, 11 June 2017 at 15:40:42 UTC, Honey wrote:
On Sunday, 11 June 2017 at 15:24:30 UTC, Honey wrote:
Doesn't it make sense to introduce another overload of cmp
similar to Steve's doCmp [2] right at that spot?
Moreover, it seems that std.algorithm.cmp should employ three
way comparison
On Sunday, 11 June 2017 at 15:24:30 UTC, Honey wrote:
Doesn't it make sense to introduce another overload of cmp
similar to Steve's doCmp [2] right at that spot?
Moreover, it seems that std.algorithm.cmp should employ three way
comparison as well. The current implementation
int cmp(alias
On Friday, 9 June 2017 at 17:50:28 UTC, Honey wrote:
Looking at the implementation of Tuple.opCmp, I'm not sure I'd
bet on existence of opCmp for fundamental types:
int opCmp(R)(R rhs)
if (areCompatibleTuples!(typeof(this), R, "<"))
{
forea
On Friday, 9 June 2017 at 17:28:18 UTC, Steven Schveighoffer
wrote:
This is why I think such a function should exist in
Phobos/druntime. I'm not 100% sure it doesn't already, but I
couldn't find one...
Looking at the implementation of Tuple.opCmp, I'm not sure I'd
bet on existence of opCmp
On 6/9/17 11:33 AM, Honey wrote:
Hi Steve!
On Friday, 9 June 2017 at 15:12:42 UTC, Steven Schveighoffer wrote:
If I were to write it, it would be something like:
int doCmp(T)(auto ref T t1, auto ref T t2)
{
static if(is(typeof(t1.opCmp(t2
return t1.opCmp(t2);
else
I re-read thoroughly and got it)
09.06.2017 18:12, Steven Schveighoffer пишет:
int doCmp(T)(auto ref T t1, auto ref T t2)
{
static if(is(typeof(t1.opCmp(t2
return t1.opCmp(t2);
else
{
if(t1 < t2) return -1;
else if(t1 > t2) return 1;
return 0;
}
}
Isn't it enough to use just
owever, this is less performant if the
type defines opCmp (you are calling it twice).
Calling opCmp twice on the same data is exactly what I tried to
avoid.
There really ought to be an opCmp for any type, which does the
best thing available. I'm not sure if it exists.
I agree it should
On 6/9/17 10:53 AM, Honey wrote:
Hi everyone!
Given
struct Pair(T, U = T)
{
T f;
U s;
}
what is the intended way to genrically implement opCmp for this struct?
The naive approach
struct Pair(T, U = T)
{
// [...]
int opCmp(const Pair r) const
{
immutable c = f.opCmp(r.f
Hi everyone!
Given
struct Pair(T, U = T)
{
T f;
U s;
}
what is the intended way to genrically implement opCmp for this
struct?
The naive approach
struct Pair(T, U = T)
{
// [...]
int opCmp(const Pair r) const
{
immutable c = f.opCmp(r.f);
return c != 0 ? c : s.opCmp(r.s
On 07.11.2015 16:59, anonymous wrote:
Wat. It even compiles with @safe. That's not good.
Filed an issue:
https://issues.dlang.org/show_bug.cgi?id=15315
On Saturday, 7 November 2015 at 14:36:25 UTC, Mike Parker wrote:
So my general question is: why immutable variables shouldn't
be able to be moved (inside an array)?
To be pedantic, sort isn't actually moving anything. It's
reassigning elements, i.e. a[1] = a[2]. The immutable member
makes
On Saturday, 7 November 2015 at 00:19:56 UTC, Ali Çehreli wrote:
Continuing from your hint: So, opCmp works but it is sort()
that cannot move objects of ku around because of that immutable
variable.
So my general question is: why immutable variables shouldn't be
able to be moved (inside
On Saturday, 7 November 2015 at 11:48:56 UTC, Alex wrote:
So my general question is: why immutable variables shouldn't be
able to be moved (inside an array)?
To be pedantic, sort isn't actually moving anything. It's
reassigning elements, i.e. a[1] = a[2]. The immutable member
makes it
Ok, ok... I see the direction, but I still miss something:
From the point of view of "Programming in D", chapter 33.3,
"Immutability of the slice vs the elements":
I don't want to have an immutable slice but immutable elements.
And your answers imply that sorting not only modify the slice
, here when
sort() will have to move it'll move the reference:
---
import std.stdio;
import std.algorithm;
struct ku
{
immutable int id;
alias id this;
this(int i)
{
id = i;
}
int opCmp(ref const ku rhs) const
On Saturday, 7 November 2015 at 10:24:03 UTC, BBaz wrote:
void main()
{
ku*[] tt = [new ku(2),new ku(1)];
sort(tt);
}
Don't really like this ;) not because
writeln(tt);
doesn't work any more, but because I have to think about where to
use pointers and where not...
Ok... found the solution. The technical at least.
import std.algorithm;
import std.range;
void main(){
ku[] tt = [ku(2), ku(1)];
//writeln(tt);
auto index3 = new size_t[tt.length];
makeIndex!("a.id < b.id")(tt, index3);
auto ind = indexed(tt, index3);
Found something useful, here:
http://dlang.org/phobos/std_algorithm_sorting.html#makeIndex
with that I can achieve the following
void main(){
ku[] tt = [ku(2), ku(1)];
//writeln(tt);
auto index3 = new size_t[tt.length];
makeIndex!("a.id < b.id")(tt, index3);
On 07.11.2015 15:36, Mike Parker wrote:
It's actually possible to use move one instance
into another, though:
void main() {
import std.algorithm : move;
ku k1 = ku(1);
ku k2 = ku(2);
k2.move(k1);
assert(k1.id == 2);
}
Wat. It even compiles with @safe. That's not good.
On Friday, 6 November 2015 at 22:55:15 UTC, Alex wrote:
Ok... the question is not silly any more...
without 'immutable' it works. So, what am I missing?
sorry, again a forum bug that stripped my answer:
sort() fails because in the template constraint
`hasAssignableElements` fails.
On Friday, 6 November 2015 at 22:55:15 UTC, Alex wrote:
Ok... the question is not silly any more...
without 'immutable' it works. So, what am I missing?
sort() fails because in the template constraint
`hasAssignableElements
On 11/06/2015 02:54 PM, Alex wrote:
> I'm sure I'm doing a silly mistake somewhere, but why this doesn't work?
> import std.stdio;
> import std.algorithm;
>
> struct ku
> {
> immutable int id;
> alias id this;
>
> this(int i)
> {
>
I'm sure I'm doing a silly mistake somewhere, but why this
doesn't work?
import std.stdio;
import std.algorithm;
struct ku
{
immutable int id;
alias id this;
this(int i)
{
id = i;
}
int opCmp(ref const ku rhs
Ok... the question is not silly any more...
without 'immutable' it works. So, what am I missing?
On 3/2/15 8:52 AM, Nordlöw wrote:
On Friday, 27 February 2015 at 15:00:35 UTC, Steven Schveighoffer wrote:
Hm... what about:
return count rhs.count ? -1 : count rhs.count ? 1 : rank
rhs.rank ? -1 : rank rhs.rank;
Is this more efficient than my version?
You said more compact, not more
On Friday, 27 February 2015 at 15:00:35 UTC, Steven Schveighoffer
wrote:
Hm... what about:
return count rhs.count ? -1 : count rhs.count ? 1 : rank
rhs.rank ? -1 : rank rhs.rank;
Is this more efficient than my version?
On Friday, 27 February 2015 at 11:04:51 UTC, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in
the following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum
strength
On 2/27/15 6:04 AM, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in the
following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum strength)
auto opCmp(const Hit rhs
On 02/27/2015 03:04 AM, Nordlöw wrote:
Is there a more compact way to describe the opCmp function in the
following struct
Please see:
http://forum.dlang.org/thread/lnr99a$vvd$1...@digitalmars.com#post-lnr99a:24vvd:241:40digitalmars.com
Ali
Is there a more compact way to describe the opCmp function in the
following struct
struct Hit
{
size_t count; // number of walkers that found this node
NWeight rank; // rank (either minimum distance or maximum
strength)
auto opCmp(const Hit rhs) const
I need to compare to DateTime. I looked at docs and found opCmp
for DateTime type.
The problem is that I can't understand how to use it.
http://dlang.org/phobos/std_datetime.html#DateTime
opCmp(in DateTime rhs);
what is rhs?
I am trying to do something like this:
if( DateTime.opCmp(dtindb
+ n.days solved my problem.
On Sunday, 1 February 2015 at 15:04:39 UTC, Suliman wrote:
I need to compare to DateTime. I looked at docs and found opCmp
for DateTime type.
The problem is that I can't understand how to use it.
http://dlang.org/phobos/std_datetime.html#DateTime
opCmp(in DateTime rhs);
what is rhs?
I am
On 2015-02-01 at 16:04, Suliman wrote:
opCmp(in DateTime rhs);
what is rhs?
RHS is probably short of right hand side, ie. the argument on the right side of
the operator in a binary operator expression. In `a b` it would be b.
I am trying to do something like this:
if( DateTime.opCmp
Thanks! Could anybody say how can I use roll if I need to date to
date.
For example I need to plus:
DateTime currentdt = cast(DateTime)(Clock.currTime());
with another DateTime var foo.
On Sunday, February 01, 2015 19:22:40 Suliman via Digitalmars-d-learn wrote:
+ n.days solved my problem.
Roll is specifically for cases where you want one of the fields to increase
or decrease without affecting the others (e.g. if you had a spin control in
your GUI with a DateTime backing it and
Alexandr Druzhinin:
http://dpaste.dzfl.pl/f7364d416cb2
Error appeared when I defined opCmp and now I can't understand
what's the reason of the error. Why does tween need access to
unittest?
Try to use static struct instead of a struct.
Bye,
bearophile
/ 3.0, 0));
}
opEquals/onHash/opCmp are minefields. I don't know why the D
compiler doesn't add a large amount of errors and warnings to
turns this minefield in something a bit safer.
Also use std.math.feqrel to compare floating point values.
Bye,
bearophile
09.04.2014 13:45, bearophile пишет:
Alexandr Druzhinin:
http://dpaste.dzfl.pl/f7364d416cb2
Error appeared when I defined opCmp and now I can't understand what's
the reason of the error. Why does tween need access to unittest?
Try to use static struct instead of a struct.
Bye,
bearophile
);
assert(tween(p2d0, p2d1, 1 / 3.0) == Point2D(1 / 3.0, 0));
}
opEquals/onHash/opCmp are minefields. I don't know why the D compiler
doesn't add a large amount of errors and warnings to turns this
minefield in something a bit safer.
It would be very nice.
Also use std.math.feqrel to compare
Alexandr Druzhinin:
Thank you! It works. But where can I read about this issue?
Reading about this issue is not good. What you can read about
is how unittests are implemented in D (as functions) and what's
the difference between static structs and nonstatic ones when
they are defined
09.04.2014 14:13, bearophile пишет:
Reading about this issue is not good. What you can read about is how
unittests are implemented in D (as functions) and what's the difference
between static structs and nonstatic ones when they are defined inside a
function.
Bye,
bearophile
I guess I should
Alexandr Druzhinin:
I guess I should read how tepmlates work.
No templates are involved in this code.
Bye,
bearophile
09.04.2014 15:19, bearophile пишет:
Alexandr Druzhinin:
I guess I should read how tepmlates work.
No templates are involved in this code.
Bye,
bearophile
I mean that nested struct Point2D has additional pointer to frame and
when compiler tries to instantiate template function 'tweet' it
To make a struct a valid key type, do I need to implement both
opCmp and opEquals or just one or the other? It says on the page
about associative arrays: The implementation may use either
opEquals or opCmp or both. Does that mean it uses whichever one
is user-defined (or both if they're both
On Thursday, April 03, 2014 07:10:06 dnspies wrote:
To make a struct a valid key type, do I need to implement both
opCmp and opEquals or just one or the other? It says on the page
about associative arrays: The implementation may use either
opEquals or opCmp or both. Does that mean it uses
On Thursday, 3 April 2014 at 10:15:46 UTC, Jonathan M Davis wrote:
_Any_ type which overloads both opEquals and opCmp and does not
make them
match exactly is just plain broken.
I disagree:
If a.opEquals(b) is true, then a.opCmp(b) must be 0.
If a.opCmp(b) is non-zero, then a.opEquals(b
On Thursday, 3 April 2014 at 10:42:33 UTC, monarch_dodra wrote:
A correctly implemented AA would use opCmp to store objects in
each bucket in cases of hash collisions, but still use opEqual
in case of equivalence.
I would add to that, try to use opCmp if it is available. It
should
On Thursday, 3 April 2014 at 10:42:33 UTC, monarch_dodra wrote:
On Thursday, 3 April 2014 at 10:15:46 UTC, Jonathan M Davis
wrote:
_Any_ type which overloads both opEquals and opCmp and does
not make them
match exactly is just plain broken.
I disagree:
If a.opEquals(b) is true
On Thu, 03 Apr 2014 06:42:32 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Thursday, 3 April 2014 at 10:15:46 UTC, Jonathan M Davis wrote:
_Any_ type which overloads both opEquals and opCmp and does not make
them
match exactly is just plain broken.
I disagree:
If a.opEquals(b
On Thursday, 3 April 2014 at 16:47:05 UTC, Steven Schveighoffer
wrote:
On Thu, 03 Apr 2014 06:42:32 -0400, monarch_dodra
monarchdo...@gmail.com wrote:
On Thursday, 3 April 2014 at 10:15:46 UTC, Jonathan M Davis
wrote:
_Any_ type which overloads both opEquals and opCmp and does
not make them
On Thu, 03 Apr 2014 14:45:40 -0400, monarch_dodra monarchdo...@gmail.com
wrote:
On Thursday, 3 April 2014 at 16:47:05 UTC, Steven Schveighoffer wrote:
This can lead to false positives if opCmp(x, y) == 0 is assumed to mean
equal.
An example: if you used RBTree to store 2d points
Hello,
The call signature for opCmp in a struct is:
struct S {
int opCmp(ref const S s) const { ... }
}
int opCmp(ref const S s) const { return _val - s._val; }
This works fine if _val is 'int'. However, if _val is 'long' then
subtracting 2 longs may not result in an int - and therefore I
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise?
No, this is fine.
On 02/16/2014 04:13 PM, Timon Gehr wrote:
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that I should
be aware of? Is there any reason that doing this may be not be wise
:
struct Foo {
int x, y;
string s;
int opCmp(in ref Foo r) {
return cmpBuilder(x, r.x, y.abs, r.y.abs, s, r.s);
}
}
Is this worth adding to Phobos?
Bye,
bearophile
, that are seen as pairs. Usage example:
struct Foo {
int x, y;
string s;
int opCmp(in ref Foo r) {
return cmpBuilder(x, r.x, y.abs, r.y.abs, s, r.s);
}
}
Is this worth adding to Phobos?
Bye,
bearophile
IMO no (lots of repetition), but forwarding opCmp is:
struct Foo{
int
On Sunday, 16 February 2014 at 15:19:08 UTC, Timon Gehr wrote:
On 02/16/2014 04:13 PM, Timon Gehr wrote:
On 02/16/2014 02:59 PM, Saurabh Das wrote:
This does compile and run correctly, but are there any hidden
assumptions or requirements on the return value of opCmp that
I should
be aware
I'm trying to experiment a bit around the iota function.
If I try to impose the following constraits:
auto my_iota(B, E)(B begin, E end)
if (is (typeof(++begin)) is (typeof(begin end))) {}
Everything works as it should, but according to D Templates: A
Tutorial book, you should not use
fails to compile for both integers and my defined types.
I read the D Templates: A Tutorial book and as far as I can tell
++B.init and B.init E.init doesn't look too much wrong, but I've not
seen any constraint of this kind in phobos (using variables instead of
types) so I was wondering if
On Friday, 20 December 2013 at 15:38:56 UTC, Francesco Cattoglio
wrote:
I'm trying to experiment a bit around the iota function.
If I try to impose the following constraits:
Everything works as it should, but according to D Templates: A
Tutorial book, you should not use arguments in
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot cleaner.
On Friday, 20 December 2013 at 16:40:23 UTC, monarch_dodra wrote:
Everything works as it should, but according to D Templates:
A Tutorial book, you should not use arguments in constraints.
That's news to me.
It seems strange to me too, but: page 69 on the PDF:
Do not use argument in your
On Friday, 20 December 2013 at 17:18:01 UTC, Timon Gehr wrote:
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which
you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I find the latter cleaner: its intent is more apparent. I use
is(typeof()) only for really testing for type
On Fri, Dec 20, 2013 at 6:31 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
On Friday, 20 December 2013 at 16:40:23 UTC, monarch_dodra wrote:
Everything works as it should, but according to D Templates: A Tutorial
book, you should not use arguments in constraints.
That's news
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud
wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I find the latter cleaner: its intent is more
On Friday, 20 December 2013 at 17:18:01 UTC, Timon Gehr wrote:
On 12/20/2013 05:40 PM, monarch_dodra wrote:
That's normal, because T.init is not an lvalue.
If you need an lvalue, we have `std.traits.lvalueOf!T` which
you
can use.
is(typeof((T v){ /+ use v +/ }))
I think this is a lot
On 12/20/2013 09:42 PM, monarch_dodra wrote:
On Friday, 20 December 2013 at 17:48:03 UTC, Philippe Sigaud wrote:
On Fri, Dec 20, 2013 at 6:33 PM, Francesco Cattoglio
francesco.cattog...@gmail.com wrote:
Is there any difference between is(typeof(somecode)) and
__traits(compiles, somecode)?
I
On 12/20/2013 10:57 PM, Timon Gehr wrote:
Most non-trivial templates that use is(typeof(...)) in the constraint
can be broken. (In the sense that it is possible to instantiate them
even though their body does not compile.)
Actually, it seems that the behaviour of DMD has changed in this
On Friday, 20 December 2013 at 20:42:13 UTC, monarch_dodra wrote:
AFAIK, there is no real difference, but is(typeof()) is more
idiomatic in phobos.
Most uses of `is(typeof())` were written before the `compiles`
trait was introduced. Add the cargo cult to that, and it's no
wonder that Phobos
On 11/13/2013 07:46 PM, Charles Hixson wrote:
On 11/12/2013 04:47 PM, bearophile wrote:
Charles Hixson:
I had tried return bytes.cmp(b.bytes); , but it didn't occur to me
that the error meant I should have used a copy? Does this syntax
mean that what's being compared is a dynamic array
On 11/12/2013 04:47 PM, bearophile wrote:
Charles Hixson:
I had tried return bytes.cmp(b.bytes); , but it didn't occur to me
that the error meant I should have used a copy? Does this syntax
mean that what's being compared is a dynamic array copy of the
original static array?
They are not
Is there any better way to write the method than:
(cmp doesn't seem to work, and byte arrays don't have an opCmp method.)
int opCmp(ref const B24 b) const
{for(int i = 0;i 24;i++)
{if(bytes[i] b.bytes[i])return-1;
if(bytes[i] b.bytes[i
On 11/12/2013 01:06 PM, Charles Hixson wrote:
Is there any better way to write the method than:
(cmp doesn't seem to work, and byte arrays don't have an opCmp method.)
int opCmp(ref const B24 b) const
{for(int i = 0;i 24;i++)
{if(bytes[i] b.bytes[i])return
Ali Çehreli:
int opCmp(ref const B24 b) const
{
return bytes[].cmp(b.bytes[]);
Few months ago I have written a small rant about that. That
little [] at the end of those arrays is not innocuous, it
essentially throws away a very precious compile-time amount of
information
On 11/12/2013 01:38 PM, Ali Çehreli wrote:
On 11/12/2013 01:06 PM, Charles Hixson wrote:
Is there any better way to write the method than:
(cmp doesn't seem to work, and byte arrays don't have an opCmp method.)
int opCmp(ref const B24 b) const
{for(int i = 0;i 24;i
Charles Hixson:
I had tried return bytes.cmp(b.bytes); , but it didn't occur
to me that the error meant I should have used a copy? Does
this syntax mean that what's being compared is a dynamic array
copy of the original static array?
They are not copies, just slices. In case of doubts take
Hi, I tried to compare two sets by opCmp, but I couldn't get
correct outputs.
Does anyone help me?
I have same sets of set S1 = [1,2,3] and S2 = [1,2,3].
Output of S1S2 should be false because S1 is not a proper subset.
However, S1=S2 should be true because S1 is a subset of S1.
I can't
1 - 100 of 151 matches
Mail list logo
