Gammon Software Solutions forum

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

Entire forum
Programming
General
Self-managed hashed strings

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

(New message)

Subject:	Self-managed hashed strings
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Raz] [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.[/quote] 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.[/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. [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.[/quote] Why would you drag around an allocator? It was a goal of mine to not have to do such a thing. For example: [code] 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; } [/code] 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.[/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. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Pages: 1 2 3 4

Posted by

David Haley USA (3,881 posts)

bio Moderator

Date

Mon 20 Mar 2006 04:15 AM (UTC) [ quote ]

Message

Version 0.9.f is released. It includes implementation of the < operator, in addition to some more documentation.

I removed the distinction between str and str_const, in favor of only using the constant version. There isn't really any reason to have a method that returns a copy; if you need a copy you can grab the reference and copy that.

On the web page I note some future plans:
http://david.the-haleys.org/index.php?page=shared-str

David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone

http://david.the-haleys.org