On 3/9/12, Timon Gehr wrote:
> On 03/09/2012 07:08 PM, Andrej Mitrovic wrote:
>> Yeah I understood it as a general concept as well. Probably many
>> people did. Why doesn't Andrei chime in?
>
> I think he does not read the D.learn newsgroup.
>
Ah poo. This is like East Berlin in here. :P
On 03/10/2012 04:32 AM, Caligo wrote:
struct B { }
struct C { }
struct D { }
struct A {
ref A foo(B item) {
/* do something special. */
return this;
}
ref A foo(T)(T item) if(is(T == C) || is(T == D)) {
/* nothing special, do
You can strip
> ref A foo(T)(T item) if (is(T==B)) {
down to:
ref A foo(T : B)(T item) // or to match your example
ref A foo(T == B)(T item)
On Saturday, 10 March 2012 at 03:32:44 UTC, Caligo wrote:
struct B { }
struct C { }
struct D { }
struct A {
ref A foo(B item) {
/* do something special. */
return this;
}
ref A foo(T)(T item) if(is(T == C) || is(T == D)) {
/* nothing sp
On 2012-03-09 18:42:01 +, Jonathan M Davis said:
File has a name property. You can do something like
auto file = File.tmpfile();
auto filename = file.name;
auto str = readText(filename);
Yeah -- again, sorry my original post was so verbose, but part of the
"problem spec" was that my temp
On 2012-03-09 17:56, Jonathan M Davis wrote:
It was never intended that AssertError or any other Error be particularly
catchable, but it's also true that D is a systems programming language, so
it'll let you do stuff which is unsafe, so if you know what you're doing, then
there are circumstances
On 2012-03-09 17:56, Jonathan M Davis wrote:
The current implementation may not skip them, but if so, that might actually
be a bug. Errors are not intended to be recoverable, so you can't rely on them
hitting finally blocks, scope statements, or destructors. They may very well do
so at present.
On 2012-03-09 18:59, H. S. Teoh wrote:
This opens up the question of, what's the *recommended* way of writing
unittests that check for these sorts of stuff?
For example, I believe in being thorough in unit tests, so I like to use
them to verify that the complicated in-contract I just wrote actu
On 2012-03-09 20:06, Jonathan M Davis wrote:
In what way? Yes, they're _catchable_, but everything that was on the unwound
portion of the stack is now in an undefined state. So, recovering from the
AssertError and continuing execution doesn't work. So, a handler can catch the
AssertError and do
On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> On 2012-03-09 18:59, H. S. Teoh wrote:
> > This opens up the question of, what's the *recommended* way of writing
> > unittests that check for these sorts of stuff?
> >
> > For example, I believe in being thorough in unit tests, so I lik
On Saturday, March 10, 2012 16:52:43 Jacob Carlborg wrote:
> On 2012-03-09 17:56, Jonathan M Davis wrote:
> > The current implementation may not skip them, but if so, that might
> > actually be a bug. Errors are not intended to be recoverable, so you
> > can't rely on them hitting finally blocks, s
On Sat, Mar 10, 2012 at 08:48:32AM -0800, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> > On 2012-03-09 18:59, H. S. Teoh wrote:
[.[..]
> > > I agree, though, that catching Errors outside of unittests is a
> > > very, very bad idea in general.
> >
> > I don
On Saturday, March 10, 2012 17:03:43 Jacob Carlborg wrote:
> On 2012-03-09 20:06, Jonathan M Davis wrote:
> > In what way? Yes, they're _catchable_, but everything that was on the
> > unwound portion of the stack is now in an undefined state. So, recovering
> > from the AssertError and continuing e
On Saturday, March 10, 2012 15:44:26 Magnus Lie Hetland wrote:
> On 2012-03-09 18:42:01 +, Jonathan M Davis said:
> > File has a name property. You can do something like
> >
> > auto file = File.tmpfile();
> > auto filename = file.name;
> > auto str = readText(filename);
>
> Yeah -- again, so
On Saturday, March 10, 2012 09:04:42 H. S. Teoh wrote:
> On Sat, Mar 10, 2012 at 08:48:32AM -0800, Jonathan M Davis wrote:
> > On Saturday, March 10, 2012 16:53:42 Jacob Carlborg wrote:
> > > On 2012-03-09 18:59, H. S. Teoh wrote:
> [.[..]
>
> > > > I agree, though, that catching Errors outside of
On Sat, Mar 10, 2012 at 11:09:04AM -0800, Jonathan M Davis wrote:
> On Saturday, March 10, 2012 09:04:42 H. S. Teoh wrote:
[...]
> > Hmm. The more I think about it, the more I'm leaning towards
> > simplifying contracts so that most, if not all, of any complicated
> > checks happen in an external f
Templates not overriding non-template functions is a bug
http://d.puremagic.com/issues/show_bug.cgi?id=1528
On Friday, 9 March 2012 at 14:07:10 UTC, Timon Gehr wrote:
On 03/09/2012 06:50 AM, newcomer[bob] wrote:
The following is a matrix implementation of the fibonacci
algorithm:
int fib(int n) { int M[2][2] = {{1,0},{0,1}} for (int i = 1; i
< n;
i++) M = M * {{1,1},{1,0}} return M[0][0]; }
probl
On 03/10/2012 11:00 PM, newcomer[bob] wrote:
On Friday, 9 March 2012 at 14:07:10 UTC, Timon Gehr wrote:
On 03/09/2012 06:50 AM, newcomer[bob] wrote:
The following is a matrix implementation of the fibonacci algorithm:
int fib(int n) { int M[2][2] = {{1,0},{0,1}} for (int i = 1; i < n;
i++) M =
It took me a while to narrow this down:
struct Foo
{
int val = int.init;
this(inout(int) nval) inout {
this.val = nval;
}
}
test.d(18): Error: cannot modify const/immutable/inout expression this.val
Is there any special reason why this should be disallowed? I mean the
same th
hi,
I would like to know if std.stdio.File.byChunk has a double buffer as in
openGL (in other domain i know) for speed up. When you read the buffer
behind it has already start to precessing the second buffer.
thanks
Hi,
this module is not really well documented, they are no example to use =>
http://dlang.org/phobos/std_mmfile.html . someone could write a little
how to ?
thanks
http://en.wikipedia.org/wiki/Memory-mapped_file
22 matches
Mail list logo
