Re: dcollections ArrayList pb with mixin template
On Thu, 01 Jul 2010 18:26:06 -0400, bearophile bearophileh...@lycos.com wrote: Steven Schveighoffer: I think a member initializer has to be a constant expression, like int i = 1. Anything else has to be done in the constructor. There are the static constructors too, for modules, structs, classes. static constructors don't help initialize member variables. -Steve
Is the memory address of classinfo the same for all instances of a class?
Good day!
Consider
// - - - -
class Foo{}
auto one = new Foo();
auto two = new Foo();
writefln(one: %x two: %x, one.classinfo, two.classinfo);
// - - - -
For me this results in two identical memory addresses every time.
Can I rely on this?
Can I design software based on the assumption that these addresses are always
the same?
(I'd like to be able to use the memory address as the key in an associative
array, for quick by-class
lookups.)
BR
/heywood
Re: Is the memory address of classinfo the same for all instances of a class?
On Fri, 02 Jul 2010 09:32:39 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd soul...@gmail.com
wrote:
Good day!
Consider
// - - - -
class Foo{}
auto one = new Foo();
auto two = new Foo();
writefln(one: %x two: %x, one.classinfo, two.classinfo);
// - - - -
For me this results in two identical memory addresses every time.
Can I rely on this?
Can I design software based on the assumption that these addresses are
always the same?
(I'd like to be able to use the memory address as the key in an
associative array, for quick by-class
lookups.)
Use classinfo.name. The classinfo is the same memory address in the
same executable/dynamic library. If you open another D dynamic library,
the classinfo address for the same class may be different, but the name
will be the same.
Note that comparing classinfo.names will be just as fast as comparing
classinfo addresses if the names are at the same address (which will be
true if the classinfo is at the same address) because the string
comparison function short-circuits if the addresses are the same.
Duh, just realized, classinfos should use this same method to compare.
Just use the whole class info as the key, don't take the address.
-Steve
Re: Purity of alloca()
Hello bearophile, Is alloca() pure? Given the same input alloca() generally returns different pointers, so it's not a pure function. But the same is true for the ptr field when you allocate an array on the heap. And the memory allocated by alloca() never escapes the function, so it looks more pure than normal heap allocation :-) As long as you don't pop the stack and do funky stuff with pointers. Vote++ -- ... IXOYE
Re: Is the memory address of classinfo the same for all instances of a class?
On Jul 2, 2010, at 15:34 , Steven Schveighoffer wrote:
On Fri, 02 Jul 2010 09:32:39 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Fri, 02 Jul 2010 09:24:20 -0400, Heywood Floyd soul...@gmail.com wrote:
Good day!
Consider
// - - - -
class Foo{}
auto one = new Foo();
auto two = new Foo();
writefln(one: %x two: %x, one.classinfo, two.classinfo);
// - - - -
For me this results in two identical memory addresses every time.
Can I rely on this?
Can I design software based on the assumption that these addresses are
always the same?
(I'd like to be able to use the memory address as the key in an associative
array, for quick by-class
lookups.)
Use classinfo.name. The classinfo is the same memory address in the same
executable/dynamic library. If you open another D dynamic library, the
classinfo address for the same class may be different, but the name will be
the same.
Note that comparing classinfo.names will be just as fast as comparing
classinfo addresses if the names are at the same address (which will be true
if the classinfo is at the same address) because the string comparison
function short-circuits if the addresses are the same.
Duh, just realized, classinfos should use this same method to compare. Just
use the whole class info as the key, don't take the address.
-Steve
Alright thanks!
Ok, loading in code dynamically changes the addresses. Good point. Thanks!
I looked up the TypeInfo_Class-implementation and it seems to compare class
names. So that looks good. Will use the classinfos directly like you suggested.
Seems proper.
***
Hm, but still, I can't quite let go of this.
Even if the string comparer can short-circuit, it still has to go through
strings that are _not_ of the same address untill it spots a difference, as
they could potentially be equal anyway?
I noted that the classinfo.name-strings typically looks like this:
classtype.Foo
classtype.Bar
classtype.Cat
classtype.Dog
Doesn't this first classtype.-part introduce overhead when these strings are
used as keys in an AA? The string comparer more or less always have to check
the first 10 chars, which are equal for all. (I know I'm being picky here. But
the whole using memory addresses-thing came from the fear of string comparisons
being suboptimal.)
/heywood
(PS. Feature-request: move the classtype.-part of classinfo names to the end
; )
Storing auto types in classes
I'm sure this has come up before, but I want to store something like an
std.array appender in a class. All of the examples use auto for the type but
you can't put that in a class definition, so what do you put?
Example:
class packet{...}
class A {
packet [] packetlist;
appender!(packet) packappender; // wrong format
this () {
packetlist = new packet[0];
packappender = appender(packetlist);
}
:
}
What's the format to store the appender in the class?
Re: Storing auto types in classes
On Friday, July 02, 2010 09:46:37 Rob Adelberg wrote:
I'm sure this has come up before, but I want to store something like an
std.array appender in a class. All of the examples use auto for the type
but you can't put that in a class definition, so what do you put?
Example:
class packet{...}
class A {
packet [] packetlist;
appender!(packet) packappender; // wrong format
this () {
packetlist = new packet[0];
packappender = appender(packetlist);
}
}
What's the format to store the appender in the class?
In this case, the type would be Appender!(packet[]). However, if you ever want
to know the exact type of something, one way to do it is something like this:
writeln(typeid(appender(packelist)));
It will print out the type of the expression for you.
- Jonathan M Davis
MS VirtualFree(), VirtualAlloc()
Hi, for reasons I don't completely understand I would like to implement a BIP Buffer in D2. ;) well async IO is the use case .. I think. How can I allocate/free buffer-space from virtual memory ? What I am looking for is a way to do platform independent allocating of memory from the virtual address space. Like - VirtualAlloc/Free() in MS Win. Thanks in advance, Bjoern
Re: Is the memory address of classinfo the same for all instances of a class?
Heywood Floyd soul...@gmail.com wrote: I noted that the classinfo.name-strings typically looks like this: classtype.Foo classtype.Bar classtype.Cat classtype.Dog Doesn't this first classtype.-part introduce overhead when these strings are used as keys in an AA? The string comparer more or less always have to check the first 10 chars, which are equal for all. (I know I'm being picky here. But the whole using memory addresses-thing came from the fear of string comparisons being suboptimal.) Have you profiled your code and found that comparing classinfo is a bottleneck? If it is, have you considered a two-layer system? i.e. foo[transmutedClassInfo], where transmutedClassInfo is the result of another lookup, that is based purely on the pointer to the classInfo? (PS. Feature-request: move the classtype.-part of classinfo names to the end ; ) I find it unlikely that will ever happen. The classinfo name should be the same as the FQN of the class. -- Simen
throwing a RangeError in non-release mode
When not in release mode, accessing an out-of-bounds element in an array throws a RangeError. I would like to do the same thing in dcollections when indexing, but the only tool I know of that enables throwing an error in non-release mode is assert, and that only throws an assert error. Does anyone know how to throw an arbitrary exception on an error when not in release mode? -Steve
Re: throwing a RangeError in non-release mode
Steven Schveighoffer schvei...@yahoo.com wrote:
When not in release mode, accessing an out-of-bounds element in an array
throws a RangeError. I would like to do the same thing in dcollections
when indexing, but the only tool I know of that enables throwing an
error in non-release mode is assert, and that only throws an assert
error.
Does anyone know how to throw an arbitrary exception on an error when
not in release mode?
Untested code. Also, horrible:
void throwInNonRelease( T = Exception )( lazy bool test, lazy string msg )
{
try {
assert( test );
} catch ( AssertError ) {
throw new T( msg );
}
}
--
Simen
