On Thursday, 21 July 2016 at 13:13:39 UTC, Claude wrote:
On Thursday, 21 July 2016 at 10:30:55 UTC, Andrea Fontana wrote:
On Thursday, 21 July 2016 at 09:59:53 UTC, Claude wrote:
I can build a "Hello world" program on ARM GNU/Linux, with
druntime and phobos.
I'll write a doc page about that.
On Thursday, 28 July 2016 at 21:02:59 UTC, John Carter wrote:
On Thursday, 28 July 2016 at 15:48:58 UTC, Seb wrote:
[...]
Eh. I hoped that somewhere in that explosion of discussion on
the topic the problem had been solved and I had just missed it
and merely had to use that.
Also this idea
Can one add code that executes before the GC and any memory is
normally allocated(even static) and after all of it was suppose
to be released?
A sort of static this for the whole app. I would like to monitor
the memory of the app to make sure that the total memory before
and after is equal. I
On Sunday, 31 July 2016 at 22:45:16 UTC, Stefan Koch wrote:
On Sunday, 31 July 2016 at 22:38:59 UTC, Seb wrote:
Consider this short program:
void main()
{
alias S = float;
S s1 = 0x1.24c92ep+5;
S s2 = -0x1.1c71c8p+0;
[...]
It's an anoying feature.
The reason this is not implement
On Monday, 1 August 2016 at 08:53:30 UTC, Kagamin wrote:
A bug.
... which should be filled at Bugzilla and/or fixed. Thanks! :)
On Sunday, 31 July 2016 at 18:15:49 UTC, Gorge Jingale wrote:
On Sunday, 31 July 2016 at 10:11:46 UTC, LaTeigne wrote:
On Saturday, 30 July 2016 at 12:24:55 UTC, ketmar wrote:
On Saturday, 30 July 2016 at 12:18:08 UTC, LaTeigne wrote:
it you think that you know the things better than somebody
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer
wrote:
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple
pointer, right?
Or I am missing something here?
You want opAssign, not opOpAssign. opOpAssign is for things
like +=.
Your code h
On Monday, 1 August 2016 at 16:21:16 UTC, Mike Parker wrote:
On Monday, 1 August 2016 at 16:18:32 UTC, Patric wrote:
But still.
If it was the case of "+=" wasn´t wrong to call the dtor since
is a ref var?
No. It was working as expected. You never implemented opAssign,
so default assignment
On Monday, 1 August 2016 at 16:18:32 UTC, Patric wrote:
But still.
If it was the case of "+=" wasn´t wrong to call the dtor since
is a ref var?
No. It was working as expected. You never implemented opAssign,
so default assignment was being used. There was no ref variable.
On Monday, 1 August 2016 at 16:17:02 UTC, Patric wrote:
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer
wrote:
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple
pointer, right?
Or I am missing something here?
You want opAssign, not opO
On Monday, 1 August 2016 at 16:14:31 UTC, Patric wrote:
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer
wrote:
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple
pointer, right?
Or I am missing something here?
You want opAssign, not opO
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer
wrote:
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple
pointer, right?
Or I am missing something here?
You want opAssign, not opOpAssign. opOpAssign is for things
like +=.
Your code h
On Monday, 1 August 2016 at 16:05:51 UTC, Steven Schveighoffer
wrote:
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple
pointer, right?
Or I am missing something here?
You want opAssign, not opOpAssign. opOpAssign is for things
like +=.
Your code h
On Monday, 1 August 2016 at 15:51:58 UTC, Jonathan M Davis wrote:
On Monday, August 01, 2016 15:25:59 Alex via
Digitalmars-d-learn wrote:
On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis
wrote:
> If you want a template constraint that checks that a type
> works with the index operator
On 8/1/16 12:01 PM, Patric wrote:
I expected nothing to happen because "ref" its a simple pointer, right?
Or I am missing something here?
You want opAssign, not opOpAssign. opOpAssign is for things like +=.
Your code had me worried for a while :)
-Steve
struct Test{
int x;
this(int v){
x = v;
writeln(x.to!string ~ " Created");
}
~this(){
writeln(x.to!string ~ " Destroyed");
}
void opOpAssign(string op, Type)(ref Type s){
x = s.x;
On Monday, August 01, 2016 15:25:59 Alex via Digitalmars-d-learn wrote:
> On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis wrote:
> > If you want a template constraint that checks that a type works
> > with the index operator on a type, and you're not restricting
> > it to something like
On Monday, 1 August 2016 at 15:06:54 UTC, Jonathan M Davis wrote:
If you want a template constraint that checks that a type works
with the index operator on a type, and you're not restricting
it to something like size_t, then you're just going to have to
check whether the expression is going
On Monday, August 01, 2016 14:46:03 Alex via Digitalmars-d-learn wrote:
> On Monday, 1 August 2016 at 13:52:56 UTC, Jonathan M Davis wrote:
> > An array does not implement RandomAccessFinite, which is an
> > interface that you created. So, a function that takes a
> > RandomAccessFinite is not going
On Monday, 1 August 2016 at 13:52:56 UTC, Jonathan M Davis wrote:
An array does not implement RandomAccessFinite, which is an
interface that you created. So, a function that takes a
RandomAccessFinite is not going to accept an array. A dynamic
array will match isRandomAccessRange, but that has
On Monday, August 01, 2016 11:06:54 Alex via Digitalmars-d-learn wrote:
> Hi everybody,
> I have a question and a half on templates and ranges, this time.
> Say, I have two functions:
>
> auto f1(T, S)(T t, S s) if(isIntegral!T && isRandomAccessRange!S)
> {
> return s[t];
> }
>
> auto f2(T, S)
On Monday, 1 August 2016 at 10:35:29 UTC, pineapple wrote:
Every hashing function will produce collisions.
Not totally true: when the hash map content is static (i.e known
at compile time) there are probabilities that a perfect hashing
function exists. But these kind of functions are a bit sp
Hi everybody,
I have a question and a half on templates and ranges, this time.
Say, I have two functions:
auto f1(T, S)(T t, S s) if(isIntegral!T && isRandomAccessRange!S)
{
return s[t];
}
auto f2(T, S)(T t, RandomAccessFinite!S raf) if(isIntegral!T)
{
return raf[t];
}
and a
class myCla
On Sunday, 31 July 2016 at 18:57:50 UTC, Jack Stouffer wrote:
Next question: what's the fastest hashing implementation that
will provide the least collisions? Is there a hash
implementation that's perfered for AAs?
There's no hashing function that would be specifically better for
associative
On Saturday, 30 July 2016 at 12:54:32 UTC, Basile B. wrote:
func is a pointer to a function but FunctionTypeOf extracts the
target type.
So the correct assertion is
static assert(is(FunctionTypeOf!func* == typeof(func)));
I can't believe that it worked for delegates because the same
happe
A bug.
26 matches
Mail list logo
