[Home] [Downloads] [Search] [Help/forum]

Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

[Folder]  Entire forum
-> [Folder]  Programming
. -> [Folder]  General
. . -> [Subject]  Self-managed hashed strings

Home  |  Users  |  Search  |  FAQ
Username:
Register forum user name
Password:
Forgotten password?

Self-managed hashed strings

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page


Pages: 1  2 3  4  

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #15 on Fri 04 Mar 2005 02:50 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Flannel   USA  (1,230 posts)  [Biography] bio
Date Reply #16 on Fri 04 Mar 2005 04:52 AM (UTC)  quote  ]

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.
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #17 on Fri 04 Mar 2005 05:06 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #18 on Fri 04 Mar 2005 11:37 AM (UTC)  quote  ]
Message
Well, that just blows. So the string hasher won't work in g++ eh? Hopefully a solution won't involve too much hassle?

SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #19 on Fri 04 Mar 2005 01:40 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #20 on Sat 05 Mar 2005 02:20 AM (UTC)  quote  ]
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?

SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #21 on Sat 05 Mar 2005 08:19 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Raz   (32 posts)  [Biography] bio
Date Reply #22 on Sat 05 Mar 2005 02:33 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Raz   (32 posts)  [Biography] bio
Date Reply #23 on Sat 05 Mar 2005 02:39 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #24 on Sat 05 Mar 2005 04:55 PM (UTC)  quote  ]
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.

SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #25 on Sat 05 Mar 2005 09:46 PM (UTC)  quote  ]
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
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #26 on Sun 13 Mar 2005 03:25 AM (UTC)  quote  ]
Message
So has there been any progress on the updated code? :)

SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top

Posted by Samson   USA  (683 posts)  [Biography] bio
Date Reply #27 on Sun 10 Apr 2005 05:51 PM (UTC)  quote  ]
Message
Just looking to see if any further progress has been made on this?

SmaugMuds.org: http://www.smaugmuds.org - The Smaug MUDs Community Center

"The past was erased, the erasure was forgotten, the lie became truth." -- George Orwell, 1984
[Go to top] top

Posted by David Haley   USA  (3,881 posts)  [Biography] bio   Moderator
Date Reply #28 on Tue 14 Jun 2005 08:12 AM (UTC)  quote  ]
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
[Go to top] top

Posted by Raz   (32 posts)  [Biography] bio
Date Reply #29 on Thu 16 Jun 2005 08:28 PM (UTC)  quote  ]
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
[Go to top] 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.


13,301 views.

This is page 2, subject is 4 pages long:  [Previous page]  1  2 3  4  [Next page]

[Reply to this subject]  Reply to this subject   [New subject]  Start a new subject   [Refresh] Refresh page

Go to topic:           Search the forum


[Go to top] top

[Home]

Written by Nick Gammon - 5K

Comments to: Gammon Software support
[RH click to get RSS URL] Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )

[Best viewed with any browser - 2K]    [Internet Contents Rating Association (ICRA) - 2K]    [Web site powered by FutureQuest.Net]