Function overload with template alias error
Hi,
I'm trying to write a template function which takes a templated alias to
another type:
struct test(T)
{
}
template aliasT(T)
{
alias test!(T) aliasT;
}
void foo(T)(test!T t) { // works
}
void foo2(T)(aliasT!T t) { // doesn't work
}
int main(string[] args)
{
test!(int) t;
aliasT!(int) t2;
foo(t);
foo2(t2); // error
return 0;
}
When foo2(t2) is called which takes an alias to test!T as argument I get
the following error from dmd:
*(21): Error: template variant.foo2(T) does not match any function
template declaration
*(21): Error: template variant.foo2(T) cannot deduce template function
from argument types !()(test!(int))
I thought that aliasT!T and test!T have the same internal types and the
compiler would be able deduce the template parameters. Am I missing
something or is this a bug in DMD? This is a reduced test case from a
piece of code where I tried to write an templated overload to
std.variant.Algebraic.
Thanks,
André
Re: Reading about D: few questions
On 12/24/2011 02:02 AM, Jonathan M Davis wrote: The core problem for a number of these situations is how types are handled with regards to expressions. In an expression such as char[] arr = s ~ '.'; the type of the value being assigned is determined _before_ the assignment is done. So, even though in theory the compiler could make it work, it doesn't, because by the time it's looking at the type being assigned to, it's too late. There would need to be a fundamental change in how the language functions in order to fix issues like this. Examples of resolved issues like this: int[] foo()pure; immutable(int)[] x = foo; pure can do it when it can not because it's able to look at what the return type is and changing the result of the expression accordingly but because it has guarantees which make it so that it knows that the return value could be converted to any level of constness and still be valid. The types used in the expressions internally are generally irrelevant. So, while I completely agree that it would be an improvement if the compiler did a better job with implicit conversion when it could theoretically be done, I'm not sure how much of that we're actually going to end up seeing simply because of how the language and type system works in terms of the order of evaluation. - Jonathan M Davis I don't think this is very hard to get working.
Re: Catching signals with D
@Heywood Floyd: that works, but what exactly am I permitted to use inside the handler, as I assume it's a C function? This might be a useless question as non-atomic operations touching global data aren't supposed to be in signal handlers, but I'm still interested to know. @Alex Rønne Petersen: what exactly is https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/signal.d? I don't see it mentioned anywhere on dlang.org? :/ I'm still new to all this stuff. When programming in C, everything I ever needed was in the default repositories of my Linux distribution, so I neved needed to worry about anything. :) Thanks, Matej
Re: Reading about D: few questions
23.12.2011 22:51, bearophile пишет: ++a[] works, but a[]++ doesn't. Already known compiler bug. Is it a joke? Array expression in D are for performance reasons to generate x2-x100 faster code without any compiler optimisations. Link to one of these epic comments (even x100 more epic because of '%' use instead of 'x###'): https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 But `a[]++` should store a copy of `a`, increment elements and return stored copy. It is hidden GC allocation. We already have a silent allocation in closures, but here a _really large_ peace of data can be allocated. Yes, this allocation sometimes can be optimized out but not always. IMHO, D should not have `a[]++` operator.
Re: Reading about D: few questions
On 24.12.2011 19:01, Denis Shelomovskij wrote: 23.12.2011 22:51, bearophile пишет: ++a[] works, but a[]++ doesn't. Already known compiler bug. Is it a joke? Array expression in D are for performance reasons to generate x2-x100 faster code without any compiler optimisations. Link to one of these epic comments (even x100 more epic because of '%' use instead of 'x###'): https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 But `a[]++` should store a copy of `a`, increment elements and return stored copy. It is hidden GC allocation. We already have a silent allocation in closures, but here a _really large_ peace of data can be allocated. Yes, this allocation sometimes can be optimized out but not always. IMHO, D should not have `a[]++` operator. Why should it store a copy? o_O I also don't see any allocations in the code on the URL above.
Arrray sizeof
snippet: int[] arr1 = [1,2,3,4,5]; int[5] arr2 = [1,2,3,4,5]; writeln(arr1.sizeof); writeln(arr2.sizeof); Output: 8 20 0 is ok to me but why 8??
Re: Arrray sizeof
On 24.12.2011 18:46, RenatoL wrote: snippet: int[] arr1 = [1,2,3,4,5]; int[5] arr2 = [1,2,3,4,5]; writeln(arr1.sizeof); writeln(arr2.sizeof); Output: 8 20 0 is ok to me but why 8?? 8 is the size of the int[] type, which contains two pointers (or a pointer and a size). To get 20, you can use: arr1[0].sizeof * arr1.length
Re: Catching signals with D
On Sat, Dec 24, 2011 at 7:37 AM, Matej Nanut matejna...@gmail.com wrote: @Heywood Floyd: that works, but what exactly am I permitted to use inside the handler, as I assume it's a C function? This might be a useless question as non-atomic operations touching global data aren't supposed to be in signal handlers, but I'm still interested to know. @Alex Rønne Petersen: what exactly is https://github.com/D-Programming-Language/druntime/blob/master/src/core/sys/posix/signal.d? I don't see it mentioned anywhere on dlang.org? :/ I'm still new to all this stuff. When programming in C, everything I ever needed was in the default repositories of my Linux distribution, so I neved needed to worry about anything. :) That module is part of druntime, and you can import it with import core.sys.posix.signal; The documentation isn't on dlang.org, probably because dlang.org doesn't contain the documentation for OS-specific modules (it's hard to generate the documentation for those when you're not on the same OS).
Re: Reading about D: few questions
Denis Shelomovskij: IMHO, D should not have `a[]++` operator. I see, and sorry. (Those percentage comments are relative to tests done on large arrays, so they are silly.) Bye, bearophile
Re: Reading about D: few questions
2011/12/24 Mr. Anonymous mailnew4s...@gmail.com: On 24.12.2011 19:01, Denis Shelomovskij wrote: 23.12.2011 22:51, bearophile пишет: ++a[] works, but a[]++ doesn't. Already known compiler bug. Is it a joke? Array expression in D are for performance reasons to generate x2-x100 faster code without any compiler optimisations. Link to one of these epic comments (even x100 more epic because of '%' use instead of 'x###'): https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 But `a[]++` should store a copy of `a`, increment elements and return stored copy. It is hidden GC allocation. We already have a silent allocation in closures, but here a _really large_ peace of data can be allocated. Yes, this allocation sometimes can be optimized out but not always. IMHO, D should not have `a[]++` operator. Why should it store a copy? o_O I also don't see any allocations in the code on the URL above. int a_orig = a++; int[] arr_orig = arr[]++; If ++ is going to be applied to an array, it needs to have the same meaning as it does elsewhere. After this operation, arr_orig and arr must refer to different arrays for that to be true.
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Re: Reading about D: few questions
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Re: Reading about D: few questions
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.chwrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Maybe you're right, but a[]++; alone, imo, should compile.
Re: Reading about D: few questions
On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations.
Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and
return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data
can be
allocated. Yes, this allocation sometimes can be optimized out
but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Maybe you're right, but a[]++; alone, imo, should compile.
+1.
Re: Reading about D: few questions
On 12/24/2011 08:22 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.chwrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations. Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data can be
allocated. Yes, this allocation sometimes can be optimized out but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array.
And I said: not necessarily
That is because reference types have had semantics that go well with not
making a copy all along, so there is no danger of making things more
inconsistent.
I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
I don't think a[]++ should necessarily be there either.
Re: Reading about D: few questions
On Sat, Dec 24, 2011 at 1:45 PM, Timon Gehr timon.g...@gmx.ch wrote:
On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
On 24.12.2011 21:22, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 07:00 PM, Andrew Wiley wrote:
On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehrtimon.g...@gmx.ch wrote:
On 12/24/2011 06:18 PM, Andrew Wiley wrote:
2011/12/24 Mr. Anonymousmailnew4s...@gmail.com:
On 24.12.2011 19:01, Denis Shelomovskij wrote:
23.12.2011 22:51, bearophile пишет:
++a[] works, but a[]++ doesn't.
Already known compiler bug.
Is it a joke? Array expression in D are for performance reasons to
generate x2-x100 faster code without any compiler optimisations.
Link
to
one of these epic comments (even x100 more epic because of '%' use
instead of 'x###'):
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
But `a[]++` should store a copy of `a`, increment elements and
return
stored copy. It is hidden GC allocation. We already have a silent
allocation in closures, but here a _really large_ peace of data
can be
allocated. Yes, this allocation sometimes can be optimized out
but not
always.
IMHO, D should not have `a[]++` operator.
Why should it store a copy? o_O
I also don't see any allocations in the code on the URL above.
int a_orig = a++;
int[] arr_orig = arr[]++;
If ++ is going to be applied to an array, it needs to have the same
meaning as it does elsewhere. After this operation, arr_orig and arr
must refer to different arrays for that to be true.
Not necessarily.
class D{
int payload;
D opUnary(string op:++)(){payload++; return this;}
}
void main() {
D d = new D;
assert(d.payload == 0);
assert(d++.payload == 1);
}
That doesn't match integer semantics:
int a = 0;
assert(a++ == 0);
assert(a == 1);
Yes, that was my point.
Then I'm not understanding what you're trying to prove.
I'm saying that if we implement a postfix ++ operator for arrays,
keeping the language consistent would require it to make a copy if the
user stores a copy of the original array. I guess it could be argued
that since arrays have hybrid value/reference semantics, no copy
should be made and the original should change.
Actually, looking at it from that angle, a[]++ is fundamentally
ambiguous because it could have value semantics or reference
semantics, so I would argue that we shouldn't have it for that reason.
'++a' and 'a += 1' do not have such ambiguities.
Maybe you're right, but a[]++; alone, imo, should compile.
+1.
You could special case this, but I'd be happy with an error that told
you to use one of the working alternatives.
Re: Catching signals with D
On Saturday, December 24, 2011 10:58:19 Andrew Wiley wrote: On Sat, Dec 24, 2011 at 7:37 AM, Matej Nanut matejna...@gmail.com wrote: @Heywood Floyd: that works, but what exactly am I permitted to use inside the handler, as I assume it's a C function? This might be a useless question as non-atomic operations touching global data aren't supposed to be in signal handlers, but I'm still interested to know. @Alex Rønne Petersen: what exactly is https://github.com/D-Programming-Language/druntime/blob/master/src/core/ sys/posix/signal.d? I don't see it mentioned anywhere on dlang.org? :/ I'm still new to all this stuff. When programming in C, everything I ever needed was in the default repositories of my Linux distribution, so I neved needed to worry about anything. :) That module is part of druntime, and you can import it with import core.sys.posix.signal; The documentation isn't on dlang.org, probably because dlang.org doesn't contain the documentation for OS-specific modules (it's hard to generate the documentation for those when you're not on the same OS). It's really not all that hard thanks to version blocks, but you do have to do some work to make it happen. It's more a case of the fact that druntime doesn't document C stuff in general. It's been argued that it should, and it's been argued that you should just look at the C docs if you want to see what they do. The reality is that it should probably document which C declarations that it has but not actually say what they do (leaving that up to the proper C documentation), but even assuming that that were agreed upon, an effort would have to be made to make that happen, and that hasn't happened. - Jonathan M Davis
Re: Reading about D: few questions
On 24.12.2011 19:18, Andrew Wiley wrote: 2011/12/24 Mr. Anonymousmailnew4s...@gmail.com: On 24.12.2011 19:01, Denis Shelomovskij wrote: 23.12.2011 22:51, bearophile пишет: ++a[] works, but a[]++ doesn't. Already known compiler bug. Is it a joke? Array expression in D are for performance reasons to generate x2-x100 faster code without any compiler optimisations. Link to one of these epic comments (even x100 more epic because of '%' use instead of 'x###'): https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127 But `a[]++` should store a copy of `a`, increment elements and return stored copy. It is hidden GC allocation. We already have a silent allocation in closures, but here a _really large_ peace of data can be allocated. Yes, this allocation sometimes can be optimized out but not always. IMHO, D should not have `a[]++` operator. Why should it store a copy? o_O I also don't see any allocations in the code on the URL above. int a_orig = a++; int[] arr_orig = arr[]++; If ++ is going to be applied to an array, it needs to have the same meaning as it does elsewhere. After this operation, arr_orig and arr must refer to different arrays for that to be true. Actually, when I think of it: int a_orig = a++; int[] arr_orig = arr[]++; Should be read as: int a_orig = a; ++a; int[] arr_orig = arr[]; ++arr[]; (If I'm not mistaken, it was written in the TDPL book) Which means no copy of arr is made, and both arrays (which reference to the same block) are affected.
Re: Function overload with template alias error
On 12/24/2011 11:23 AM, André Stein wrote:
Hi,
I'm trying to write a template function which takes a templated alias to
another type:
struct test(T)
{
}
template aliasT(T)
{
alias test!(T) aliasT;
}
void foo(T)(test!T t) { // works
}
void foo2(T)(aliasT!T t) { // doesn't work
}
int main(string[] args)
{
test!(int) t;
aliasT!(int) t2;
foo(t);
foo2(t2); // error
return 0;
}
When foo2(t2) is called which takes an alias to test!T as argument I get
the following error from dmd:
*(21): Error: template variant.foo2(T) does not match any function
template declaration
*(21): Error: template variant.foo2(T) cannot deduce template function
from argument types !()(test!(int))
I thought that aliasT!T and test!T have the same internal types and the
compiler would be able deduce the template parameters. Am I missing
something or is this a bug in DMD? This is a reduced test case from a
piece of code where I tried to write an templated overload to
std.variant.Algebraic.
Thanks,
André
IFTI can only deduce template parameters for symbols that are defined
inside the template instantiation because then the symbol remembers the
template parameters. IFTI cannot reverse-instantiate templates.
Linking problem on Mac OS X
Running a simple compile and link dmd test.d produces gcc-4.2: Invalid argument What can I provide to track this down?
Re: Linking problem on Mac OS X
On Sat, Dec 24, 2011 at 6:29 PM, Robert Rouse robert.e.ro...@gmail.com wrote: Running a simple compile and link dmd test.d produces gcc-4.2: Invalid argument What can I provide to track this down? Run with `dmd -v` to get the linker commandline.
Re: Linking problem on Mac OS X
Nevermind! I figured it out. Apparently CC was set in my system incorrectly. I found the culprit and removed it. It works now. So if anyone else runs across this, look at your CC environment variable. (I saw a similar issue posted in one of the other newsgroups that just said Post in learn instead basically instead of answering the question, but it looks like that person never did) In article mailman.1898.1324773448.24802.digitalmars-d-le...@puremagic.com, Andrew Wiley wiley.andre...@gmail.com wrote: On Sat, Dec 24, 2011 at 6:29 PM, Robert Rouse robert.e.ro...@gmail.com wrote: Running a simple compile and link dmd test.d produces gcc-4.2: Invalid argument What can I provide to track this down? Run with `dmd -v` to get the linker commandline.
