On Tuesday, 11 December 2012 at 07:50:10 UTC, js.mdnq wrote:
On Tuesday, 11 December 2012 at 07:15:38 UTC, Zhenya wrote:
I'm sorry for my english.
I know that D != Python and my example don't need
any RTTI.
D has alias this feature.My example shows that we can use
alias this with types.
And I
I feel incredibly stupid asking this one, but how does one
extract the address of return value of a member function that
returns by ref?
Case in point:
//
struct S
{
int i;
ref front() @property
{
return i;
}
}
void foo(int*){}
void main()
{
auto s = S();
On 12/11/2012 02:53 AM, Zardoz wrote:
> auto acelByObjs = map!( (Entity o) {
> Vector3 r = o.pos[0] - pos[0];
> return r * (o.mass / pow((r.sq_length + epsilon2), 1.5));
> } )(objects);
> newAcel = reduce!("a + b")(acelByObjs);
>
> It works very well with the std.algorithm Map and Reduce but when
Ali Çehreli:
The single pointer of the lambda is not sufficient to store
both without big changes in the compiler.
I think adding a heavier 3-word delegate is not too much hard to
do. But it makes the language more complex, so so far Walter is
not willing to introduce them.
But in the end
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it feels hackish. Any other way?
Is this the fastest way to append a char to string?
char c = 'a';
string s;
s ~= c;
?
I have a program that does this many many times... and it's slow.
So I was wondering it it could be it.
Thanks for tips!
On Tuesday, 11 December 2012 at 15:52:31 UTC, Chopin wrote:
Is this the fastest way to append a char to string?
char c = 'a';
string s;
s ~= c;
?
I have a program that does this many many times... and it's
slow. So I was wondering it it could be it.
Thanks for tips!
This may or may not be
Chopin:
Is this the fastest way to append a char to string?
char c = 'a';
string s;
s ~= c;
?
I have a program that does this many many times... and it's
slow. So I was wondering it it could be it.
Try the appender from std.array. It's supposed to be faster, but
sometimes it's not faster.
On Tuesday, 11 December 2012 at 15:22:49 UTC, Ali Çehreli wrote:
That used to work a couple of dmd versions ago. I think it was
a bug that it worked, so it stopped working after bug fixes.
If I'm not mistaken this is actually related to a compiler
implementation issue: Lambda's have a single p
On Thursday, 6 December 2012 at 10:31:43 UTC, Alex Rønne Petersen
wrote:
On 06-12-2012 10:02, Russel Winder wrote:
What is the right idiom for testing that a function call does
segfault
when you want it to?
There is basically no portable, clean way to do that. Why are
you relying on segment
On Tuesday, 11 December 2012 at 09:40:08 UTC, Ali Çehreli wrote:
On 12/11/2012 01:05 AM, Ali Çehreli wrote:
> /* Fundamental types must be made differently; probably due
to syntax
> * issues. I would have expected for the following to work:
> *
> * return Type!index(args); // <-- compilation err
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it feels hackish. Any other way?
auto p = &(s.front());
Not s
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra
wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
wrote:
:/
I got it to work with a cast, which removes the ambiguity:
auto p = &cast(int)s.front;
But it fee
On 12/11/2012 08:42 AM, Zhenya wrote:
> But how do you think does it make sense to open enhancement
> allow alias this with types?
> Or it is completely useless?
Usual compromises: Is it useful in large number of projects? Does it
break existing programs? Does it fit well with the existing feat
On Tuesday, December 11, 2012 17:16:58 Russel Winder wrote:
> I am not relying on segfaults, that would just be silly ;-) The
> issue is that unit tests should test error as well as success. I
> want to know if I get a segfault when I have an infinite
> recursion in an algorithm (due to incorrect p
On Tue, 2012-12-11 at 18:58 +0100, Jonathan M Davis wrote:
[…]
> I'd argue that if you want an error condition that you test for, you should
> actually do something in your code that generates an error condition (e.g.
> throw an exception) and that it really makes no sense to test for segfaults.
On 12/11/2012 05:58 PM, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra wrote:
:/
I got it to work with a cast, which removes the ambig
On Tuesday, 11 December 2012 at 21:00:11 UTC, Timon Gehr wrote:
On 12/11/2012 05:58 PM, monarch_dodra wrote:
On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra
wrote:
On Tuesday, 11 December 2012 at 14:57:27 UTC, monarch_dodra
w
On 12/11/12 22:05, monarch_dodra wrote:
> On Tuesday, 11 December 2012 at 21:00:11 UTC, Timon Gehr wrote:
>> On 12/11/2012 05:58 PM, monarch_dodra wrote:
>>> On Tuesday, 11 December 2012 at 16:45:54 UTC, cal wrote:
On Tuesday, 11 December 2012 at 15:38:38 UTC, monarch_dodra wrote:
> On Tue
On 2012-12-11 20:21, Russel Winder wrote:
I appreciate where you are coming from with respect to general testing
strategy, and am basically in agreement with what you say. However in
this specific case a segfault is just another exception. In terms of
recursion the exception is "recursion stac
20 matches
Mail list logo
