www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - offsetof bug?

reply MaR <MaR_member pathlink.com> writes:
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
next sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 7 Jun 2005 15:49:50 +0000 (UTC), MaR wrote:


 hi, I'm new to D so sorry if I'm posting a known bug or just a misfeature.


LOL.  "misfeature" ~ a neat term I haven't come across before.


 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?


I suggest that it's the documentation that's at fault. The 'static'
attribute sort of makes sense as the 'offset' property relates to the
struct declaration rather than any specific instance of the struct.
 

 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)


This is something that just hasn't been implemented yet. There is a lot of
requests for this to be done sooner rather than later.


 - there can be only one ret_value opCast(). this is annoying... why isn't it
 void opCast(out ret_value) which could be overloaded?


Has been discussed many, many times. Everyone except Walter seems to think
that the current opCast is useless.


 - why isn't it possible to overload the opAssign operator? it would be damn
 useful


Amen to that! Again, this has been discussed countless times. It is against
Walter's philosophy for D to allow this. He believes that there are other
ways to achieve the same thing. He's wrong.


 - 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?


If you don't wish to use the GC for some allocations, then use the
malloc/free method of managing your own RAM.


 - 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 as a compiler option. It has been discussed a few times that we need
more precision about what is trimmed out by -release.


 - 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)


Again, this is something that has a lot of airplay, and we have been
promised better reflection functionality, but not until after v1.0 has been
released.


 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.


Not yet, but some people are working on a few.


 - why do I have to specify final prefix when I want a (nonlocal) member
function
 to be inlined (dmd)?


Just lucky I guess ;-)

-- 
Derek Parnell
Melbourne, Australia
8/06/2005 7:22:03 AM
Jun 07 2005
prev sibling parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
 - 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?


Note that growing by powers of two is currently very inefficient. I hope 
someday that is no longer the case. See the thread started with 
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/23924
Jun 07 2005