Re: AA clear property
Am 06.11.2011, 00:15 Uhr, schrieb Alex_Dovhal alex_dov...@yahoo.com: Marco Leise marco.le...@gmx.de wrote: Are you this Alex? yes. As I understand it this function is defined in object_.d which is always imported by default and can be called on an (associative) array through a mechanism called universal function call, that matches the part before the dot with the first parameter of the function. This only works for arrays. So I believe it is a free function (to invalidate/finalize a variable) and not a property of an array at all. Thanks for clarification. So now my question and task changes. Is there a way to reuse previous memory occupied by AA, when I need to change all of it element? E.g. for dynamic arrays it's possible to make: dyn_arr.length = 0; assumeSafeAppend(dyn_arr); fill_new_values(dyn_arr); No way I heard of. You could delete the entries one by one. :D I guess setting all references to null is the easiest way to 'clear' an AA.
Re: AA clear property
Marco Leise marco.le...@gmx.de wrote: No way I heard of. You could delete the entries one by one. :D I guess setting all references to null is the easiest way to 'clear' an AA. Thanks. I tried both of them in small benchmark. Results are (1) fill_values(aa); aa = null (2) fill_values(aa); aa.remove(...) For both methods time1/time2 is around 35/52, with aa size 10, 100, 1000, and 1. Interesting enough, with aa size 1M, 10M, 100M time1/time2 is around 1/1. So (1) is prefered for 10-1000 elements situation i have, but it allocates memory each time :( while 2 reuses it, IMHO.
Re: AA clear property
On Sunday, November 06, 2011 13:39:27 Alex_Dovhal wrote: Marco Leise marco.le...@gmx.de wrote: No way I heard of. You could delete the entries one by one. :D I guess setting all references to null is the easiest way to 'clear' an AA. Thanks. I tried both of them in small benchmark. Results are (1) fill_values(aa); aa = null (2) fill_values(aa); aa.remove(...) For both methods time1/time2 is around 35/52, with aa size 10, 100, 1000, and 1. Interesting enough, with aa size 1M, 10M, 100M time1/time2 is around 1/1. So (1) is prefered for 10-1000 elements situation i have, but it allocates memory each time :( while 2 reuses it, IMHO. 2 doesn't necessarily reuse it. It depends on what the GC does and how AAs are currently implemented. It's likely that in both cases, you end up with a fair bit of stuff which is on the heap and no longer referenced such that if a garbage collection cycle runs, it would be collected (or if one doesn't run, it just sits there still taking up memory). The only real difference is that _some_ of the memory will be reused with 2, whereas with 1, you need a whole new AA. In both cases, new memory will be required. How much that is depends n the current implementation of AAs. And which one is more likely to trigger a GC cycle probably depends on a number of factors. So, it wouldn't suprise me at all either way. I imagine that it's at least simpler for the GC to collect the memory quickly in the first case, since the entire AA can be collected instead of all of it, but I don't know. AAs are a _completely_ different situation from dynamic arrays. With dynamic arrays, you have a clear block of contiguous memory that you're playing with, and it's obvious what's going to be reused if you want reuse. The situation is _far_ more complicated with a hash table, which is likely to have a fair number of items on the heap - particularly for handling each bucket (and there's a decent chance that each of those is a dynamic array). So, I very much doubt that your going to reuse much memory from an AA unless a GC cycle is run, regardless of whether you do #1 or #2. - Jonathan M Davis
Re: AA clear property
On Sunday, November 06, 2011 04:11:07 Jonathan M Davis wrote: On Sunday, November 06, 2011 13:39:27 Alex_Dovhal wrote: Marco Leise marco.le...@gmx.de wrote: No way I heard of. You could delete the entries one by one. :D I guess setting all references to null is the easiest way to 'clear' an AA. Thanks. I tried both of them in small benchmark. Results are (1) fill_values(aa); aa = null (2) fill_values(aa); aa.remove(...) For both methods time1/time2 is around 35/52, with aa size 10, 100, 1000, and 1. Interesting enough, with aa size 1M, 10M, 100M time1/time2 is around 1/1. So (1) is prefered for 10-1000 elements situation i have, but it allocates memory each time :( while 2 reuses it, IMHO. 2 doesn't necessarily reuse it. It depends on what the GC does and how AAs are currently implemented. It's likely that in both cases, you end up with a fair bit of stuff which is on the heap and no longer referenced such that if a garbage collection cycle runs, it would be collected (or if one doesn't run, it just sits there still taking up memory). The only real difference is that _some_ of the memory will be reused with 2, whereas with 1, you need a whole new AA. In both cases, new memory will be required. How much that is depends n the current implementation of AAs. And which one is more likely to trigger a GC cycle probably depends on a number of factors. So, it wouldn't suprise me at all either way. I imagine that it's at least simpler for the GC to collect the memory quickly in the first case, since the entire AA can be collected instead of all of it, but I don't know. AAs are a _completely_ different situation from dynamic arrays. With dynamic arrays, you have a clear block of contiguous memory that you're playing with, and it's obvious what's going to be reused if you want reuse. The situation is _far_ more complicated with a hash table, which is likely to have a fair number of items on the heap - particularly for handling each bucket (and there's a decent chance that each of those is a dynamic array). So, I very much doubt that your going to reuse much memory from an AA unless a GC cycle is run, regardless of whether you do #1 or #2. And actually, I should point out that #2 would result in a _lot_ more overhead due to all the work done for each remove call than you get with #1. So, given that fact, I would actually _expect_ #1 to be faster in the general case. - Jonathan M Davis
Re: AA clear property
Thakns for details. Arfer another small benchmark, it appeared that addition to AA is 10x times slower than removal from it. So that's why (2) isn't so bad in my previous tests - most of time AA was adding elements to remove later. Anyway if (2) also reallocates it's much much worse that (1).
odd use of preprocessor
poking about in elfutils headers, I've come across the following idiom
several times
/* Error values. */
enum
{
DW_TAG_invalid = 0
#define DW_TAG_invalid DW_TAG_invalid
};
anyone know if anything strange is going on here that would prevent
trivial conversion to d?
Re: odd use of preprocessor
On 06-11-2011 20:43, Ellery Newcomer wrote:
poking about in elfutils headers, I've come across the following idiom
several times
/* Error values. */
enum
{
DW_TAG_invalid = 0
#define DW_TAG_invalid DW_TAG_invalid
};
anyone know if anything strange is going on here that would prevent
trivial conversion to d?
The only thing I can think of is fully-qualified enums. The #define
ensures that you _don't_ have to fully qualify DW_TAG_invalid. But why
they would do this (considering C doesn't have this enum feature), I
don't know.
- Alex
Re: odd use of preprocessor
On 11/06/2011 01:50 PM, Alex Rønne Petersen wrote:
On 06-11-2011 20:43, Ellery Newcomer wrote:
poking about in elfutils headers, I've come across the following idiom
several times
/* Error values. */
enum
{
DW_TAG_invalid = 0
#define DW_TAG_invalid DW_TAG_invalid
};
anyone know if anything strange is going on here that would prevent
trivial conversion to d?
The only thing I can think of is fully-qualified enums. The #define
ensures that you _don't_ have to fully qualify DW_TAG_invalid. But why
they would do this (considering C doesn't have this enum feature), I
don't know.
- Alex
nor c++, right?
IDE with renaming possibility
Hi, I'm new to D, I just started to read the book of Andrei. As an IDE, I use Eclipse with the DDT plugin. However, I don't find an important feature: renaming variables/functions/etc. If it's not in DDT, what IDE do you suggest? I use Linux. Thanks, Laszlo
Re: odd use of preprocessor
On 2011-11-06 19:43:15 +, Ellery Newcomer
ellery-newco...@utulsa.edu said:
/* Error values. */
enum
{
DW_TAG_invalid = 0
#define DW_TAG_invalid DW_TAG_invalid
};
It's strange all right. The only reason I can come with is that they
want to prevent someone else from defining DW_TAG_invalid as a
preprocessor value that would shadow the enum value.
Just ignore it, D has no preprocessor. :-)
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
Re: IDE with renaming possibility
On Sun, Nov 6, 2011 at 9:28 AM, Jabba Laci jabba.l...@gmail.com wrote: Hi, I'm new to D, I just started to read the book of Andrei. As an IDE, I use Eclipse with the DDT plugin. However, I don't find an important feature: renaming variables/functions/etc. If it's not in DDT, what IDE do you suggest? I use Linux. Thanks, Laszlo I use Emacs and replace regexp.
Expected or Bug? struct range unmodified after foreach
I'm sure if this was changed there would be other interesting behavior,
such as arrays being consumed. And suggestions other than
for(S s; !s.empty, s.popFront())...
Example:
void main() {
S s;
foreach(i; s) {
assert(i == s.popCount); // Fail
}
assert(s.popCount == 10); // Fail
}
struct S {
size_t popCount;
auto empty() {
if(popCount 9)
return true;
return false;
}
auto front() { return popCount; }
auto popFront() {
popCount++;
}
}
Re: Expected or Bug? struct range unmodified after foreach
On Sunday, November 06, 2011 23:26:02 Jesse Phillips wrote:
I'm sure if this was changed there would be other interesting behavior,
such as arrays being consumed. And suggestions other than
for(S s; !s.empty, s.popFront())...
Example:
void main() {
S s;
foreach(i; s) {
assert(i == s.popCount); // Fail
}
assert(s.popCount == 10); // Fail
}
struct S {
size_t popCount;
auto empty() {
if(popCount 9)
return true;
return false;
}
auto front() { return popCount; }
auto popFront() {
popCount++;
}
}
I'd say that it's expected. Stuff isn't normally consumed by foreach iterating
over it - an exception would be a class which is a range, but since it's a
reference, copying it is a shallow copy, unlike with a struct, and my guess
would be that s is being copied when it's passed to the foreach. If it
_wasn't_ copied like this, then passing a range to foreach would consume it
unless you explicitly sliced it or saved it, which would probably break a lot
of code.
- Jonathan M Davis
Is this actually valid code?
I've had a simple problem where I've only wanted to override a setter
from a base class:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
override @property void test(int) {}
void bartest() { auto x = test; } // NG
}
test.d(19): Error: function test.Bar.test (int _param_0) is not
callable using argument types ()
So I thought I'd be clever:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
alias super.test test;
override @property void test(int) {}
void bartest() { auto x = test; }
}
And it actually works! Is this a documented feature?
Re: Is this actually valid code?
On Monday, November 07, 2011 05:10:57 Andrej Mitrovic wrote:
I've had a simple problem where I've only wanted to override a setter
from a base class:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
override @property void test(int) {}
void bartest() { auto x = test; } // NG
}
test.d(19): Error: function test.Bar.test (int _param_0) is not
callable using argument types ()
So I thought I'd be clever:
class Foo
{
@property void test(int) {}
@property int test() { return 1; }
}
class Bar : Foo
{
alias super.test test;
override @property void test(int) {}
void bartest() { auto x = test; }
}
And it actually works! Is this a documented feature?
It has to do with overload sets. I'm pretty sure that it's discussed in the
documention. Once you override a base class function in a derived class, the
_only_ versions of that function that are in the overload set are the ones in
the derived class. If you want the other ones to be in the overload set, you
do an alias like you did.
I'm a bit surprised that super.test works. I wouldn't have thought that super
would work in that context, but apparently it does (I would have expected you
to have to do use Foo.test).
But yes. This is as expected.
- Jonathan M Davis
