Hello,
I'm reading The D programming language, part 4.1.7 Array-wise
Expressions.
It states that
The effect of an array-wise expression is that of a loop
assigning each element of the
left-hand side in turn with the corresponding index of the
right-hand side. For example,
the assignment
The following code:
void main()
{
import std.bigint;
BigInt x, m;
BigInt l = x m;
}
Result in:
andrew@ace:~$ dmd f
f.d(6): Error: 'x' is not of integral type, it is a BigInt
f.d(6): Error: 'm' is not of integral type, it is a BigInt
I'm sure there is plans to resolve
On Sunday, June 16, 2013 11:09:27 Alexander wrote:
Hello,
I'm reading The D programming language, part 4.1.7 Array-wise
Expressions.
It states that
The effect of an array-wise expression is that of a loop
assigning each element of the
left-hand side in turn with the corresponding
On Sunday, June 16, 2013 05:14:07 Tyro[17] wrote:
The following code:
void main()
{
import std.bigint;
BigInt x, m;
BigInt l = x m;
}
Result in:
andrew@ace:~$ dmd f
f.d(6): Error: 'x' is not of integral type, it is a BigInt
f.d(6): Error: 'm' is not of integral
I'm writing a little program in D to perform some database
operations and have a small question about design.
Part of my program watches a log file for changes and this
involves code which is wrapped up in a class. So the usage is
something like this:
auto fileWatcher = new
hi,
are there any 64bit windows header files availabe?
Opened the issue
http://d.puremagic.com/issues/show_bug.cgi?id=10384
Thank you!
On Sunday, 16 June 2013 at 09:35:23 UTC, Jonathan M Davis wrote:
On Sunday, June 16, 2013 11:09:27 Alexander wrote:
Hello,
I'm reading The D programming language, part 4.1.7
Array-wise
Expressions.
It states
On Sunday, 16 June 2013 at 02:12:02 UTC, Geancarlo Rocha wrote:
I expected the memory to ramp up in the first couple iterations
and eventually reach a stable point, but for some reason,
windows task manager shows it increases on every iteration.
Compiling with -m64 doesn't seem to change this
On 06/16/2013 07:20 PM, Geancarlo Rocha wrote:
On Sunday, 16 June 2013 at 02:12:02 UTC, Geancarlo Rocha wrote:
I expected the memory to ramp up in the first couple iterations and
eventually reach a stable point, but for some reason, windows task
manager shows it increases on every iteration.
On 06/13/2013 06:14 AM, Alex Horvat wrote:
On Wednesday, 12 June 2013 at 21:44:55 UTC, Mike Wey wrote:
On 06/11/2013 07:55 PM, Alex Horvat wrote:
On Tuesday, 11 June 2013 at 17:41:59 UTC, Mike Wey wrote:
On 06/11/2013 05:56 PM, Alex Horvat wrote:
TreeStore store =
On Sunday, 16 June 2013 at 18:02:26 UTC, Timon Gehr wrote:
On 06/16/2013 07:20 PM, Geancarlo Rocha wrote:
On Sunday, 16 June 2013 at 02:12:02 UTC, Geancarlo Rocha wrote:
I expected the memory to ramp up in the first couple
iterations and
eventually reach a stable point, but for some reason,
I assume the silence means no?
On 06/15/2013 02:22 PM, Namespace wrote:
With the knowledge that 'delete' will be deprecated soon:
Is there then still a way to finalize GC memory? I know it's unsafe etc.
but is there a way? I know of 'destroy' but it does not finalize
anything and AFAIK it's not safe and has also side
On 06/16/2013 08:37 PM, Geancarlo Rocha wrote:
...
the current GC is unreliable, booo!
No it is not. You are not even allocating GC-controlled memory during
the loop.
This is a std.container.BinaryHeap issue. It never shrinks the
underlying container.
http://d.puremagic.com/issues/
If
Being a C++ programmer, I am new to the term finalize. If it
means call the destructor, then destroy() is it.
Finalize - free the memory immediately as 'delete' it does
currently.
And it does
not call the DTor if any struct is allocated with 'new'.
It does:
import std.stdio;
struct S
{
I have adjusted the thread title.
http://en.wikipedia.org/wiki/Finalizer
It's basically just means calling the finalizer, and D
conflates finalizers and
destructors, so the destructor of any object on the GC heap is
that object's
finalizer. Normally, it's called when the object is collected,
but it can get a
bit messy
It seems that does what I want. The result is the same as with
the current 'delete' implementation.
void Delete(T)(ref T var) {
static if (is(T == struct) is(typeof(var.__dtor)))
var.__dtor();
static if (is(T : U[], U))
I made a network server/client that needs no library except
Phobos. Came in a little under 500 lines but is quite generic:
http://arsdnet.net/dcode/server.d
The top of the file shows the usage program, then comes the code
that could go in a library.
Basically you define an interface with a
Adam D. Ruppe:
I made a network server/client that needs no library except
Phobos. Came in a little under 500 lines but is quite generic:
Normal Rosettacode entries are under 40-100 lines. Many entries
are about 10-20 lines long.
There are are few entries (in C or Ada) that reach 500
On Sunday, 16 June 2013 at 23:06:40 UTC, bearophile wrote:
Normal Rosettacode entries are under 40-100 lines. Many entries
are about 10-20 lines long.
I think that biases it toward giant standard libraries. I've
joked before that we could just say:
import rosettacode;
mixin Distributed!();
On Friday, 14 June 2013 at 12:06:11 UTC, Bruno Deligny wrote:
I doesn't work with 2.063
Hmm, I don't know what's going on. Can someone else try to make
it work?
On 06/16/2013 09:44 AM, new wrote:
hi,
are there any 64bit windows header files availabe?
I don't think header files differ that way. Also, the are no header
files in D, but modules.
Ali
On Sunday, 16 June 2013 at 18:22:47 UTC, Mike Wey wrote:
On 06/13/2013 06:14 AM, Alex Horvat wrote:
On Wednesday, 12 June 2013 at 21:44:55 UTC, Mike Wey wrote:
On 06/11/2013 07:55 PM, Alex Horvat wrote:
On Tuesday, 11 June 2013 at 17:41:59 UTC, Mike Wey wrote:
On 06/11/2013 05:56 PM, Alex
24 matches
Mail list logo
