View mode: basic / threaded / horizontal-split · Log in · Help
June 07, 2005
offsetof bug
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
June 07, 2005
Re: offsetof bug
-----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-----
Top | Discussion index | About this forum | D home