www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - offsetof bug

reply k_mar seznam.cz writes:
2nd attempt to post a message :)

hi, I'm new to D so sorry if I'm posting a known bug or just a misfeature.
consider the following code:

class bug
{
struct elem {
int value;
}
int get_ofs()
{
return elem.value.offsetof;     
}
}

it fails to compile (dmd 0.12x?) but the following workaround works fine:

class ok
{
struct elem {
int value;
static int get_ofs()
{
return value.offsetof;
}
}
void get_ofs()
{
return elem.get_ofs();
}
}

why is that? I think it should work without problems, maybe I missed something
in the specs?

a few suggestions:

- why is it impossible to initialize local struct/array (even if initializers
evaluate to constant expressions which can be determined at compile time)?
currently only statics can be initialized that way (according to the docs)
- there can be only one ret_value opCast(). this is annoying... why isn't it
void opCast(out ret_value) which could be overloaded?
- why isn't it possible to overload the opAssign operator? it would be damn
useful
- why is the GC so sloooow? I tried to implement a very simple vector-like
container which grows by powers of two. then fed it with 10MB bytes. the GC
occured 5 times, ending up when resizing to 16MB. however, the last collection
took approximatel 0.5 seconds on my celeron/366. imagine a huge app that uses
100+MB of memory. it's a lag that can be fatal if you try to write a realtime
application where low latency is crucial. besides, all threads get stopped:(
imagine a background thread mixing sounds ... is there something I could do to
avoid ugly hacks like allocating the C-way/"customizing" gc/linking C(++) code?
- why is the profiler using QueryPerformanceCounter instead of using rdtsc?
QueryPerformanceCounter is f...in' slow :(
- I think the preconditions/postconditions should be kept in the release build.
if there're only asserts, they should be removed. if not, they should remain
because could be VERY useful. for example one could write own profiler only for
those "big" functions so that the application will run very fast while retaining
profile info
- maybe (don't know if worth) there could be more in
TypeInfo(_Class)/ClassInfo/whatever, for classes/structs so that one could
iterate through (public) member variables. this would be useful when writing a
class property editor that could be fed directly with class instances. the
problem with redundancy would be solved by only storing new members for a class,
the rest should be accessed through the base class (recursively)

questions:

- is there a GOOD IDE supporting debugging including watches/calls stack and
project management? I saw some syntax-highlighters but it really isn't enough if
you'd try to write a serious project in D.
- why do I have to specify final prefix when I want a (nonlocal) member function
to be inlined (dmd)?

MaR
Jun 07 2005
parent Thomas Kuehne <thomas-dloop kuehne.this-is-spam.cn> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

k_mar seznam.cz schrieb am Tue, 7 Jun 2005 15:55:21 +0000 (UTC):
 2nd attempt to post a message :)

 hi, I'm new to D so sorry if I'm posting a known bug or just a misfeature.
 consider the following code:

 class bug
 {
 struct elem {
 int value;
 }
 int get_ofs()
 {
 return elem.value.offsetof;     
 }
 }

 it fails to compile (dmd 0.12x?) but the following workaround works fine:

 class ok
 {
 struct elem {
 int value;
 static int get_ofs()
 {
 return value.offsetof;
 }
 }
 void get_ofs()
 {
 return elem.get_ofs();
 }
 }

 why is that? I think it should work without problems, maybe I missed something
 in the specs?
class bug declares only the type "struct elem", there is no instance of the type elem struct. <snip>
 - why is the GC so sloooow? I tried to implement a very simple vector-like
 container which grows by powers of two. then fed it with 10MB bytes. the GC
 occured 5 times, ending up when resizing to 16MB. however, the last collection
 took approximatel 0.5 seconds on my celeron/366. imagine a huge app that uses
 100+MB of memory. it's a lag that can be fatal if you try to write a realtime
 application where low latency is crucial. besides, all threads get stopped:(
 imagine a background thread mixing sounds ... is there something I could do to
 avoid ugly hacks like allocating the C-way/"customizing" gc/linking C(++) code?
It's difficult to reason if we don't know the algos you used. <snip>
 - maybe (don't know if worth) there could be more in
 TypeInfo(_Class)/ClassInfo/whatever, for classes/structs so that one could
 iterate through (public) member variables. this would be useful when writing a
 class property editor that could be fed directly with class instances. the
 problem with redundancy would be solved by only storing new members for a
class,
 the rest should be accessed through the base class (recursively)
ClassInfo.vtbl contains some information. Including agrument & return types as well as names to the TypeInfos shouldn't be too difficult for the compiler and would open the reflection door a bit more. <snip> Thomas -----BEGIN PGP SIGNATURE----- iD8DBQFCpeZo3w+/yD4P9tIRAsm3AJkBBzmrDFuRRtLCjb6bboQwKpV92wCfYloT LOPi/DEhIx7u+nNl7AMbFoY= =TqAu -----END PGP SIGNATURE-----
Jun 07 2005