| View previous topic :: View next topic |
| Author |
Message |
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
 Posted: Tue Aug 09, 2005 2:39 pm Post subject: Re: Util.d |
 |
|
| sean wrote: |
The only potential catch is that this returns "true" for all classes, I assume because Object defines a toHash method. |
I've been wondering how to do that for awhile. This is great. Thanks. And yes, Object defines a .toHash method. It makes some things a bit easier, but that was before static if, so I'm not certain I think it should be there anymore.
| sean wrote: |
By the way... I've been watching this thread but haven't found the time yet to look at the containers, though I'm hoping to one day soon :p |
It's nothing particularly spectacular yet, but I think it fills a rather large gap in D in that I'm striving for it to be a cohesive, OO containers library. The more sets of eyes to help achieve that goal, the better! If you do take a look at it, please post any/all comments here. |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Thu Aug 11, 2005 1:34 pm Post subject: |
|
|
I'd like to suggest an experimental adjustment to the container ctors ~ mutate them to support user-defined constructs for determining comparison, equality, and/or hash, as appropriate for the container type.
That is, instead of embedding opCmp(), opEqual() and toHash() within an Object, attach them (as appropriate) to the container instead. Default constructs could be provided for usage where custom behaviour is not required.
This should resolve all kinds of problems with having opCmp(), opEqual() and toHash() lurk in the root Object. It should also work for any type of contained data.
Thoughs? |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Thu Aug 11, 2005 1:47 pm Post subject: |
|
|
| kris wrote: | I'd like to suggest an experimental adjustment to the container ctors ~ mutate them to support user-defined constructs for determining comparison, equality, and/or hash, as appropriate for the container type.
That is, instead of embedding opCmp(), opEqual() and toHash() within an Object, attach them (as appropriate) to the container instead. Naturally, default constructs should be provided for usage where custom behaviour is not required.
This should resolve all kinds of problems with having opCmp(), opEqual() and toHash() lurk in the root Object. It should also work for any type of contained data, thereby eliminating the special cases required (in the runtime library) to discriminate between primitive and non-primitive types.
Thoughs? |
You suggested this earlier (at least for toHash) and I didn't mean to ignore you. I think it's a good idea, and I plan on doing it- I just haven't had time to touch it since you mentioned it. I am planning on making this optional, and keeping the current method as the default, however. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Thu Aug 11, 2005 1:55 pm Post subject: |
|
|
| teqdruid wrote: | | You suggested this earlier (at least for toHash) and I didn't mean to ignore you. I think it's a good idea, and I plan on doing it- I just haven't had time to touch it since you mentioned it. I am planning on making this optional, and keeping the current method as the default, however. |
N.P. ~ what I didn't point out before is that it could resolve the many problems inherent in the current D design (vis-a-vis opCmp & opEqual). |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Tue Aug 23, 2005 9:23 am Post subject: |
|
|
OK, I finally had a little more time to work on this. I've added the ability to use funtion pointers as hash and equals functions. I want to be able to use FPs or delegates, but using both seems to screw with the function overloading, so I decided on FPs.
This is what you were talking about, right Kris? |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Tue Aug 23, 2005 9:37 am Post subject: ConcurrentHashMap |
|
|
So it seems ConcurrentHashMap is horribly broken. I only tried it with int,int parameters thus far, but it doesn't compile with anything else. Try uncommenting line 38 of test/containers.d and building it. Lots and lots of errors, which is typical of any build error with templates. One of the error is:
| Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
I don't understand this message. My lack of comprehension is probably due to a total lack of understanding about D/C/C++ volatile/synchronized/threading stuff along with most of the lower level understanding of these languages. I understand the Java threading stuff a bit.
Can anyone explain, or point me to a resource with relevant information?
Also, does anyone have any idea why this all fails? It's probably an oversight on my part, and int only seems to work since when DMD has issues with a type it tries to use int instead. I'll see if combing the code/error messages yields anything useful. |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Aug 23, 2005 11:14 am Post subject: |
|
|
| teqdruid wrote: | OK, I finally had a little more time to work on this. I've added the ability to use funtion pointers as hash and equals functions. I want to be able to use FPs or delegates, but using both seems to screw with the function overloading, so I decided on FPs.
This is what you were talking about, right Kris? |
Yes. But using a delegate instead of a FP would likely permit more flexibility? With a delegate you could assign the &object.hash(), for example (if you want that kind of backward compatability). Then again, you've looked at this much more than I have.
Another approach is to extend the Template itself (via subclassing?) to include such methods. The benefit there would be in terms of performance (no indirection). |
|
| Back to top |
|
|
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Aug 23, 2005 11:18 am Post subject: Re: ConcurrentHashMap |
|
|
| teqdruid wrote: | So it seems ConcurrentHashMap is horribly broken. I only tried it with int,int parameters thus far, but it doesn't compile with anything else. Try uncommenting line 38 of test/containers.d and building it. Lots and lots of errors, which is typical of any build error with templates. One of the error is:
| Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
I don't understand this message. My lack of comprehension is probably due to a total lack of understanding about D/C/C++ volatile/synchronized/threading stuff along with most of the lower level understanding of these languages. I understand the Java threading stuff a bit.
Can anyone explain, or point me to a resource with relevant information?
Also, does anyone have any idea why this all fails? It's probably an oversight on my part, and int only seems to work since when DMD has issues with a type it tries to use int instead. I'll see if combing the code/error messages yields anything useful. |
On the face of it, this looks like an issue of an inner class trying to access an outer, but failing. If you have added 'static' to the Segment inner class, try removing it. If that works, then there's a bug in the compiler. CHM does not need true inner classes, but it may be that the 'static' keyword is messing things up? |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Tue Aug 23, 2005 11:20 am Post subject: Re: ConcurrentHashMap |
|
|
| teqdruid wrote: |
| Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
I don't understand this message. My lack of comprehension is probably due to a total lack of understanding about D/C/C++ volatile/synchronized/threading stuff along with most of the lower level understanding of these languages. |
I think this is a compiler bug. I ran into it when I was working on ares.std.atomic (along with about 3 other template-related bugs). I reported them all and only hope that they're fixed soon. This particular bug is from the compiler somehow confusing template instantiations. In std.atomic, I saw this problem trying to instantiate Atomic!(int) and Atomic!(uint) (ie, two same-sized types). I don't know of a workaround. |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Fri Aug 26, 2005 4:40 pm Post subject: Re: ConcurrentHashMap |
|
|
| teqdruid wrote: | | Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
|
This is a bug with DMD: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/802.html |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sun Sep 04, 2005 1:09 pm Post subject: Re: ConcurrentHashMap |
|
|
| Carlos wrote: | | teqdruid wrote: | | Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
|
This is a bug with DMD: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/802.html |
Are you sure that's it? That bug seems to be related to forward references and delegates, whereas my issue is related to volatile. If I remove all of the volatiles in ConcurrentHashMap, it compiles (and works, as long as only one thread is accessing it).
Any other suggestions? |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Sun Sep 04, 2005 1:19 pm Post subject: |
|
|
| kris wrote: | I'd like to suggest an experimental adjustment to the container ctors ~ mutate them to support user-defined constructs for determining comparison, equality, and/or hash, as appropriate for the container type.
That is, instead of embedding opCmp(), opEqual() and toHash() within an Object, attach them (as appropriate) to the container instead. Default constructs could be provided for usage where custom behaviour is not required.
This should resolve all kinds of problems with having opCmp(), opEqual() and toHash() lurk in the root Object. It should also work for any type of contained data.
Thoughs? |
OK, so I've re-implemented alternate compare (and such) methods via templates. It uses the virtual methods that D uses anyway, so I think it'll be faster. I've only done it for HashMap (and ConcurrentHashMap) for now, and put examples in test/containers.d. Please take a look.
The only problem I have with it now is that you can't not specify an alternate method if you're specifying one of them. That is, it's either all or nothing. Any ideas? |
|
| Back to top |
|
|
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
| Posted: Sun Sep 04, 2005 5:33 pm Post subject: Re: ConcurrentHashMap |
|
|
| teqdruid wrote: | Are you sure that's it? That bug seems to be related to forward references and delegates, whereas my issue is related to volatile. If I remove all of the volatiles in ConcurrentHashMap, it compiles (and works, as long as only one thread is accessing it).
Any other suggestions? |
Oh... *that's* the workaround I'd found. I knew there was something, but in all my changes it got lost and I forgot what it was. Well... until it gets fixed you could leave the volatiles out. It will be a while before people really start to abuse multithreaded code in D anyway. |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Mon Sep 05, 2005 7:52 am Post subject: Re: ConcurrentHashMap |
|
|
| teqdruid wrote: | | Carlos wrote: | | teqdruid wrote: | | Code: | | /home/teqdruid/workspace/include/mango/containers/ConcurrentHashMap.d(304): function mango.containers.ConcurrentHashMap.ConcurrentHashMap!(int,char[]).ConcurrentHashMap.Segment.setTable cannot access frame of function setTable |
|
This is a bug with DMD: http://www.digitalmars.com/d/archives/digitalmars/D/bugs/802.html |
Are you sure that's it? That bug seems to be related to forward references and delegates, whereas my issue is related to volatile. If I remove all of the volatiles in ConcurrentHashMap, it compiles (and works, as long as only one thread is accessing it). |
Well, I haven't seen the code, so I couldn't tell for sure, but the message is the same and the behavior you expect is the same behavior I expected when I posted that bug, so if it's not the same bug, it could be one that's related. Or maybe I'm just wasting your time 
| teqdruid wrote: | | Any other suggestions? |
Unfortunately, no. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
