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