Re: string hashing design/implementation questions involving string
literals
* tragomaskhalos:
On 12 Feb, 13:30, Sebastian Karlsson <Sebastian.Karls...@mmorpgs.org>
wrote:
[ snip ]
If above is true there's still a very large problem remaining, users
passing strings that aren't string literals, for example
std::string::c_str() comes to mind. These aren't guaranteed to be
constant between calls to a StringHash constructor so I can't use the
memory address as a key to the value. I could create a constructor of
StringHash which accepts a std::string&, however that certainly
doesn't guarantee that the user doesn't use c_str(), and std::string
isn't really the only possible problem anyway. What really would help
me here would be if there's any neat way to guarantee that the client
only uses string literals for my StringHash( const char* )
constructor. Is there any?
Any feedback appreciated!
Firstly, I don't think there is any way to enforce string
literals. One might be tempted to defeat passing a char*
via eg
template<int N> void bar(const char(&ca)[N]) { ...}
This will accept
bar("yowza");
but reject e.g.
bar(std_string.c_str());
The problem is it _also_ accepts
char oh_dear[] = "In trouble now";
bar(oh_dear);
Where oh_dear may eg be on the stack.
How to avoid this is a FAQ. Essentially, you document that one
shouldn't do that. No design can prevent all cases of PEBCAK, and so
it's futile to try, and generally invalid to use the impossibibility of
100% perfection in that regard as argument against something.
But I think the problem is this: you've gone down
a rat-hole looking for a solution without looking
properly at the problem, because what actual use
is:
bar("magically works only with literals"); ??
For example, an exception object where there should be no possibility of
failure for construction of the exception object.
For another example, returning a string from a function, in a general
format that requires no further processing to be used along with e.g.
dynamically created strings, without the overhead of dynamic allocation
or string copying.
Some code available at <url: http://alfsstringvalue.sourceforge.net/>,
with an example showing constant time for various operations at bottom.
When the string has to be hard-coded in, you
may as well just do this:
void bar(int tag) { .... }
so that the user can just do this:
enum my_tags {
wow, yowza, hooray
};
bar(wow);
bar(yowza);
etc
No, that's an invalid argument. Try to replace all string literals in
your code with symbolic constants. Then go on to maintain that code.
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?