Re: How would you solve this 'interview' question in D?
On Wednesday, 26 June 2013 at 20:51:35 UTC, Gary Willoughby wrote: Just for a bit of fun, I saw this question posted on reddit the other day and wondered how *you* would solve this in D? http://stackoverflow.com/questions/731832/interview-question-ffn-n First answer port: http://dpaste.dzfl.pl/0e3d145c
Re: A GUI library to begin with
On 08.02.2012 7:04, Gour wrote: On Wed, 08 Feb 2012 05:55:37 +0200 Mr. Anonymousmailnew4s...@gmail.com wrote: Has anyone tried these? Any suggestions? wxD (http://wxd.sourceforge.net/) Sincerely, Gour The website says: wxD is intended for D language version 1.0, and doesn't work as good with D 2.0. Once the new language specification is released, wxD can be updated to support it. Is it still relevant, or is the website outdated?
Re: Reading about D: few questions
On 25.12.2011 11:28, Denis Shelomovskij wrote:
OK. As I wrote: Yes, this allocation sometimes can be optimized out but
not always.. Consider this:
---
void main()
{
int[] a = new int[5];
void f(int[] b)
{
// Here we assume that b is unchanged a.
// As these array differ we need a copy.
assert(b[0] == 0);
assert(a[0] == 1);
}
f(a[]++); // Note: compilation error now
}
---
Why not to rewrite `f(a[]++);` as `f(a); ++a[];`? Because postincrement
is expected to increment its argument when it is executed. It just
returns an unchanged copy. Analogous D code with integers illustrates this:
---
void main()
{
int a;
void f(int b)
{
assert(b == 0);
assert(a == 1);
}
f(a++);
}
---
I wasn't familiar with this postincrement behavior. I would expect both
a and b to be 0 inside f().
Anyway, what do you suggest? To leave it not compilable?
My original point was to just allow:
a[]++;
More complicated scenarios like the one above is beyond my knowledge, as
I'm only learning the language, but I think they have to be addressed as
well.
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.
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: 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 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.
Reading about D: few questions
Hi guys!
I'm mostly familiar with C (and a bit of PHP). I've stumbled upon the D
language, and I must say I really like it.
Now I'm reading the The D Programming Language book, and I have a
couple of questions:
1. Uninitialized Arrays and GC.
http://dlang.org/memory.html#uninitializedarrays
It's said here ^ that:
The uninitialized data that is on the stack will get scanned by the
garbage collector looking for any references to allocated memory.
With the given example of: byte[1024] buffer = void;
So does the GC really scan this byte array? Or (sounds more logical to
me) does it scan only reference types?
If the latter is true, I think the example should use some kind of a
pointer array. Also, in this case, I can't see why Uninitialized data
can be a source of bugs and trouble, even when used correctly.?
If the former is true, then, well, I'll ask more questions.
2. Setting Dynamic Array Length.
http://dlang.org/arrays.html#resize
A more practical approach would be to minimize the number of resizes
The solution works but is not as clean as just using array ~= c;
Is there any way (language, runtime, or phobos) to declare an array that
would reallocate memory by chunks, which are multiple of x?
3. const and immutable.
Is there any use for const when defining variables?
As I see it, there is no use for using e.g. const int x;, as it can't be
modified anyway;
So with immutable, const is only good for reference variables that are
initialized to refer to another variable (like a function const ref
parameter).
Am I right?
4. if (lhs != rhs)?
std.algorithm has this in it's swap function.
Is it different than if (lhs !is rhs)?
Just wondering.
5. Align attribute.
http://dlang.org/attribute.html#align
struct S {
align(4) byte a; // placed at offset 0
align(4) byte b; // placed at offset 1
}
Explain this please.
6. Array slices manipulation.
a[] += 1; works but a[]++ doesn't.
Not so important but just wondering: why, and is it intended?
7. Anonymous structs.
In C you can write:
struct { int a; } s = {10};
printf(%d\n, s.a);
In D you must declare the struct first:
struct S { int a; };
S s = {10};
writeln(s.a);
Why doesn't D allow anonymous structs?
Best regards.
Re: Reading about D: few questions
On 23.12.2011 19:47, Ali Çehreli wrote:
On 12/23/2011 07:25 AM, Mr. Anonymous wrote:
I have a couple of questions:
I prefer separate threads for each. :)
Should I resend the questions as separate messages?
1. Uninitialized Arrays and GC.
http://dlang.org/memory.html#uninitializedarrays
It's said here ^ that:
The uninitialized data that is on the stack will get scanned by the
garbage collector looking for any references to allocated memory.
With the given example of: byte[1024] buffer = void;
So does the GC really scan this byte array? Or (sounds more logical to
me) does it scan only reference types?
I am not an expert on garbage collectors but I've never heard about
differentiating the bits of data. The GC would have to need to keep meta
data about every part of the allocated space as such and it would not be
practical.
Maybe not every part, but only reference parts.
If the latter is true, I think the example should use some kind of a
pointer array. Also, in this case, I can't see why Uninitialized data
can be a source of bugs and trouble, even when used correctly.?
I don't think that the last part is any different than the initialize
all of your variables advice. The uninitialized data has come from
memory that has been used earlier in the program and may have valid data
(and references) to existing or already-destroyed data. Hard to debug.
2. Setting Dynamic Array Length.
http://dlang.org/arrays.html#resize
A more practical approach would be to minimize the number of resizes
The solution works but is not as clean as just using array ~= c;
Is there any way (language, runtime, or phobos) to declare an array that
would reallocate memory by chunks, which are multiple of x?
Array expansion is already more efficient than they look at first. This
article is a good read:
http://www.dsource.org/projects/dcollections/wiki/ArrayArticle
Thanks, I'll take a look.
3. const and immutable.
Is there any use for const when defining variables?
As I see it, there is no use for using e.g. const int x;, as it can't be
modified anyway;
So with immutable, const is only good for reference variables that are
initialized to refer to another variable (like a function const ref
parameter).
Am I right?
Right. I have two observations myself:
- To be more useful, function parameters should not insist on immutable
data, yet we type string all over the place.
- To be more useful, functions should not insist on the mutability of
the data that they return.
The following function makes a new string:
char[] endWithDot(const(char)[] s)
{
return s ~ '.';
}
char[] s;
s ~= hello;
auto a = endWithDot(s);
It is good that the parameter is const(char) so that I could pass the
mutable s to it.
But the orthogonal problem of the type of the return is troubling. The
result is clearly mutable yet it can't be returned as such:
Error: cannot implicitly convert expression (s ~ '.') of type
const(char)[] to char[]
We've talked about this before. There is nothing in the language that
makes me say the returned object is unique; you can cast it to mutable
or immutable freely.
I saw that std.string functions use assumeUnique from std.exception.
As for your example, it probably should be:
char[] endWithDot(const(char)[] s)
{
return s.dup ~ '.';
}
5. Align attribute.
http://dlang.org/attribute.html#align
struct S {
align(4) byte a; // placed at offset 0
align(4) byte b; // placed at offset 1
}
Explain this please.
I don't know more than what the documentation says but I remember
reading bugs about align().
6. Array slices manipulation.
a[] += 1; works but a[]++ doesn't.
Not so important but just wondering: why, and is it intended?
Again, I remember discussion and limitations about this feature.
Fixed-length arrays have better support and the regular increment works:
double[3] a = [ 10, 20, 30 ];
++a[];
++a[] works, but a[]++ doesn't.
7. Anonymous structs.
In C you can write:
struct { int a; } s = {10};
printf(%d\n, s.a);
In D you must declare the struct first:
struct S { int a; };
S s = {10};
writeln(s.a);
Why doesn't D allow anonymous structs?
It may be related to palsing. D does not require the semicolon at the
end of the struct definition, so it wouldn't know what 's' is:
struct { int a; } // definition (of unmentionable type :) )
s = {10}; // unknown s
There could be special casing but I don't think that it would be worth it.
Sounds reasonable.
Ali
Uninitialized Arrays and GC
On 23.12.2011 21:51, bearophile wrote: Mr. Anonymous: http://dlang.org/memory.html#uninitializedarrays It's said here ^ that: The uninitialized data that is on the stack will get scanned by the garbage collector looking for any references to allocated memory. With the given example of: byte[1024] buffer = void; So does the GC really scan this byte array? Or (sounds more logical to me) does it scan only reference types? If the latter is true, I think the example should use some kind of a pointer array. Also, in this case, I can't see why Uninitialized data can be a source of bugs and trouble, even when used correctly.? If the former is true, then, well, I'll ask more questions. The current D GC is not precise, so I think the current DMD+GC scan this array. Future better compilers/runtimes probably will be able to avoid it (with a shadow stack the gives precise typing information at runtime, used by a precise GC). Well, if that's really so, then it's not 100% reliable. e.g. you generate an array of random numbers, and one of them appears to be an address of an allocated array. This array won't free even if not used anymore.
Re: Reading about D: few questions
On 23.12.2011 19:47, Ali Çehreli wrote: On 12/23/2011 07:25 AM, Mr. Anonymous wrote: 2. Setting Dynamic Array Length. http://dlang.org/arrays.html#resize A more practical approach would be to minimize the number of resizes The solution works but is not as clean as just using array ~= c; Is there any way (language, runtime, or phobos) to declare an array that would reallocate memory by chunks, which are multiple of x? Array expansion is already more efficient than they look at first. This article is a good read: http://www.dsource.org/projects/dcollections/wiki/ArrayArticle std.array.Appender is what I was talking about :)
