Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ Programming
➜ General
➜ Self-managed hashed strings
|
Self-managed hashed strings
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2 3
4
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #15 on Fri 04 Mar 2005 02:50 AM (UTC) |
| Message
| Well, darn... g++ (at least, version 3.4.1) does not accept non-constant values as template arguments. That means that the design as it is will not work with g++, which is not acceptable. I'm going to move to something of a static solution like Raz suggested (although probably not exactly what he has in mind), which was the original plan anyhow - a shame, though, because I preferred this way of doing things.
Funny how VS and G++ differ so completely on this issue. VS accepted it without a peep. I wonder what the standard says about this... |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Flannel
USA (1,230 posts) Bio
|
| Date
| Reply #16 on Fri 04 Mar 2005 04:52 AM (UTC) Amended on Fri 04 Mar 2005 05:12 AM (UTC) by Flannel
|
| Message
| | Stroustrup says "A template argument can be a constant expression, the address of an object or function with external linkage, or a non-overloaded pointer to member. A pointer used as a template argument must be of the form &of where of is the name of an object or a function, or of the form f, where f is the name of a function. A pointer to member must be of the form &X::of, where of is the name of a member. In particular, a string literal is not acceptable as a template argument." |
~Flannel
Messiah of Rose
Eternity's Trials.
Clones are people two. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #17 on Fri 04 Mar 2005 05:06 AM (UTC) |
| Message
| | I was pretty sure g++'s behavior seemed abnormal, and the standard confirms that. Thanks for pasting that, Flannel. At least I feel better about my understanding of the standard. :-) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #18 on Fri 04 Mar 2005 11:37 AM (UTC) |
| Message
| | Well, that just blows. So the string hasher won't work in g++ eh? Hopefully a solution won't involve too much hassle? | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #19 on Fri 04 Mar 2005 01:40 PM (UTC) |
| Message
| Fortunately I have a work-around that I just finished implementing - like I said it was the original plan, but I find it less elegant and a little of a hassle. As far as the programmer is concerned, you have to do this:SharedString::HashTable * gTable;
MAKE_MANAGER_WRAPPER(HashTableWrapper, &gTable)
typedef SharedString::SharedString< HashTableWrapper > shared_str;
The macro there expands to this:#define MAKE_MANAGER_WRAPPER(name, managerPtr) \
struct name \
{ \
static const std::string * AddString(const std::string & str) \
{ return (*Manager_)->addString(str); } \
static void DeleteString(const std::string & str) \
{ (*Manager_)->deleteString(str); } \
static SharedString::StringManager ** Manager_; \
}; \
SharedString::StringManager ** name::Manager_ = (SharedString::StringManager**) managerPtr;
So, instead of having an address as the template argument, you give it a static class, and when the shared string needs to access the manager it just calls the functions of the static class that (as the name implies) wrap around the manager.
I still do not feel terribly inclined to use an allocator scheme, for a variety of reasons. One thing is that it adds a fair amount of complexity to the scheme and users need (or, at least, should) to understand allocators somewhat to use the system. Until I'm convinced that it's better in the absolute, I'm not sure it's worth the trouble to use it, both from my perspective and that of an API user.
In any case, the code now compiles without warning on g++ 3.4.1 (much stricter than 3.3.3) and on MS VS.net. I'm still surprised that for a change, MS seems to have gotten the standard better than g++. :-) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #20 on Sat 05 Mar 2005 02:20 AM (UTC) |
| Message
| So am I missing something or is my reading of the examples you had put out with the first release correct? All someone needs to do to use this and have them behave more or less like the old style hashstr.c stuff did is to declare something as being a shared_str type variable?
Or are people going to have to jump through a bunch of silly hoops each time they want to use this? | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #21 on Sat 05 Mar 2005 08:19 AM (UTC) |
| Message
| All you have to do is make one typedef to e.g. 'shared_str' (or whatever you want), to associate the type with a manager (or you could specify it every time, but why bother?) and then everytime you define a string as a shared_str, it will be automatically managed. Absolutely nothing to worry about - when you assign a string, it'll look it up in the table and add it if necessary; when you destroy (or change) the string it'll decrement the reference count and only delete the shared memory if nobody else is using it.
The main idea was to make something completely hassle-free and I don't think you can get much better than a single typedef. :-) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Raz
(32 posts) Bio
|
| Date
| Reply #22 on Sat 05 Mar 2005 02:33 PM (UTC) |
| Message
|
Quote: You were saying that it's in the std namespace and that a 'standards-compliant' compiler would fail. Well, it won't- it's in the global namespace.
I did say it would fail, but I thought wrong.
However, it is in the std namespace. It is, at the same time, exposed to the global namespace as well.
Quote: It is for the VS header files. For the g++ header files, it is defined via cstddef which includes stddef.h.
VS does not define C++. The standard clearly says that size_t is only found in cstddef, cstring, and... cstdlib I think (I'd have to dig through the standard. VS defining size_t in cstdio does not agree with the standard.
Quote: It seems that you suggest that instead of dragging around a manager, you drag around an allocator. I'm not sure what the gain is, since you felt it 'clumsy' to drag around a manager - which incidentally I disagree with.
Why would you drag around an allocator? It was a goal of mine to not have to do such a thing. For example:
class StringAllocator {
private:
static InternalAllocator {
private:
hash_type hash;
size_t bytes_allocated;
//...
public:
InternalAllocator();
const char *Share( const char *sz );
void Decrease( const char *sz );
size_t GetBytes( void );
//...
};
public:
StringAllocator();
//... functions using the internal allocator.
};
template< typename T >
class SharedString {
private:
T allocator;
//...
public:
//operators
};
//There would be no bulk in carrying around an allocator
//Each SharedString class would have its own instance
//of the StringAllocator class, but each instance would
//always reference the internal static allocator
//so you would have a real string sharing mechanism.
//If the user wanted to use the allocator directly,
//he or she could:
void func( void )
{
StringAllocator sa;
std::cout << sa.GetBytes() << std::endl;
}
There would be no bulk in carrying around an allocator. There would be minor space added on to each SharedString class, but that would only be a serious problem for MUDs if you dynamically allocated many SharedString instances (which would defeat the purpose).
Quote: You're just shifting the problem. Instead of storing the hash function etc. in a manager, you're making the programmer subclass the shared string class and then you use an allocator to deal with it instead. Personally, I would find it a bother to have to subclass off of the shared string all the time, which is one reason why I didn't do it that way.
I think I have made myself unclear. You wouldn't subclass the shared string class; rather, you would make subclasses (or even unrealted subclasses) of the allocator. Looking at my rough design above, you could see that you could provide a list of requirements for the template parameter so you could create many allocators that would work in the shared string class. |
-Raz
C++ Wiki: http://danday.homelinux.org/dan/cppwiki/index.php | | Top |
|
| Posted by
| Raz
(32 posts) Bio
|
| Date
| Reply #23 on Sat 05 Mar 2005 02:39 PM (UTC) |
| Message
|
Quote: Funny how VS and G++ differ so completely on this issue. VS accepted it without a peep. I wonder what the standard says about this...
Well, the standard says this about it:
Quote: the address of an object or function with external linkage, including function templates and function
template-ids but excluding non-static class members, expressed as & id-expression where the & is
optional if the name refers to a function or array, or if the corresponding template-parameter is a reference;
It seems that you cannot use your allocator in your design unless it has external linkage. |
-Raz
C++ Wiki: http://danday.homelinux.org/dan/cppwiki/index.php | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #24 on Sat 05 Mar 2005 04:55 PM (UTC) |
| Message
|
Quote:
The main idea was to make something completely hassle-free and I don't think you can get much better than a single typedef. :-)
Ok, cool deal then. Messy looking macros or otherwise, as long as it's not necessary to mess with the inner workings to use the code I'm happy :)
Looking forward to the finalized version of this. | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #25 on Sat 05 Mar 2005 09:46 PM (UTC) |
| Message
|
Quote: VS does not define C++. The standard clearly says that size_t is only found in cstddef, cstring, and... cstdlib I think (I'd have to dig through the standard. VS defining size_t in cstdio does not agree with the standard. Look, Raz, check the headers yourself.
cstddef#include <stddef.h>
namespace std
{
using ::ptrdiff_t;
using ::size_t;
}
cstring includes cstddef
cstdlib includes cstddef
Clearly ::size_t is not in the std namespace! Maybe the standard says otherwise but the two major compilers have it in the global namespace first and import it into the std namespace later.
Quote: I think I have made myself unclear. You wouldn't subclass the shared string class; rather, you would make subclasses (or even unrealted subclasses) of the allocator. Looking at my rough design above, you could see that you could provide a list of requirements for the template parameter so you could create many allocators that would work in the shared string class. OK, I see what you want to do now, but I'm still not sure what it gains you to have an allocator as opposed to a manager. My new design - the one that I will release shortly and from which the example above is derived - uses a template argument that specifies a static class that 'wraps around' the manager. I'm just not sure why you think the allocator design is 'better'.
Samson:
Quote: Messy looking macros or otherwise, Oh, come on, it's just one macro and you only ever use it once. :-) (Well, ok, two macros that you use each once; once to define the wrapper and once to initialize its manager) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #26 on Sun 13 Mar 2005 03:25 AM (UTC) |
| Message
| | So has there been any progress on the updated code? :) | | Top |
|
| Posted by
| Samson
USA (683 posts) Bio
|
| Date
| Reply #27 on Sun 10 Apr 2005 05:51 PM (UTC) |
| Message
| | Just looking to see if any further progress has been made on this? | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #28 on Tue 14 Jun 2005 08:12 AM (UTC) |
| Message
| At long last I have a near-final version of the library up.
http://david.the-haleys.org/index.php?page=shared-str
My apologies to everybody for the delay. The beginning of the quarter was much busier than I'd expected, and by the time the dust settled I'd actually sort of forgotten about this. *sheepish* Anyhow, here's the latest version - enjoy, and as always, please send feedback. And also expect me to reappear in the forums tomorrow... :) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Raz
(32 posts) Bio
|
| Date
| Reply #29 on Thu 16 Jun 2005 08:28 PM (UTC) |
| Message
| | Is anyone else having problems extracting the archive? It might just be my Cygwin... |
-Raz
C++ Wiki: http://danday.homelinux.org/dan/cppwiki/index.php | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
146,788 views.
This is page 2, subject is 4 pages long:
1
2 3
4
It is now over 60 days since the last post. This thread is closed.
Refresh page
top