2013-08-25 20:59:44 +02:00
|
|
|
/**
|
|
|
|
* vim: set ts=4 sw=4 tw=99 noet :
|
|
|
|
* =============================================================================
|
|
|
|
* SourceMod
|
|
|
|
* Copyright (C) 2004-2008 AlliedModders LLC. All rights reserved.
|
|
|
|
* =============================================================================
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it under
|
|
|
|
* the terms of the GNU General Public License, version 3.0, as published by the
|
|
|
|
* Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
|
|
|
|
* FOR A PARTICULAR PURPOSE. See the GNU General Public License for more
|
|
|
|
* details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*
|
|
|
|
* As a special exception, AlliedModders LLC gives you permission to link the
|
|
|
|
* code of this program (as well as its derivative works) to "Half-Life 2," the
|
|
|
|
* "Source Engine," the "SourcePawn JIT," and any Game MODs that run on software
|
|
|
|
* by the Valve Corporation. You must obey the GNU General Public License in
|
|
|
|
* all respects for all other code used. Additionally, AlliedModders LLC grants
|
|
|
|
* this exception to all derivative works. AlliedModders LLC defines further
|
|
|
|
* exceptions, found in LICENSE.txt (as of this writing, version JULY-31-2007),
|
|
|
|
* or <http://www.sourcemod.net/license.php>.
|
|
|
|
*
|
|
|
|
* Version: $Id$
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef _include_sourcemod_namehashset_h_
|
|
|
|
#define _include_sourcemod_namehashset_h_
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @file sm_namehashset.h
|
|
|
|
*
|
|
|
|
* @brief Stores a set of uniquely named objects.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <am-allocator-policies.h>
|
|
|
|
#include <am-hashmap.h>
|
|
|
|
#include <am-string.h>
|
|
|
|
#include "sm_stringhashmap.h"
|
|
|
|
|
|
|
|
namespace SourceMod
|
|
|
|
{
|
|
|
|
|
2018-07-10 23:38:40 +02:00
|
|
|
// The HashPolicy type must have these methods:
|
2013-08-25 20:59:44 +02:00
|
|
|
// static bool matches(const char *key, const T &value);
|
2018-07-10 23:38:40 +02:00
|
|
|
// static uint32_t hash(const CharsAndLength &key);
|
2013-08-25 20:59:44 +02:00
|
|
|
//
|
2018-07-10 23:38:40 +02:00
|
|
|
// Depending on what lookup types are used, and how hashing should be done.
|
|
|
|
// Most of the time, key hashing will just call the key's hash() method.
|
2013-08-25 20:59:44 +02:00
|
|
|
//
|
|
|
|
// If these members are available on T, then the HashPolicy type can be left
|
|
|
|
// default. It is okay to use |T *|, the functions will still be looked up
|
|
|
|
// on |T|.
|
|
|
|
template <typename T, typename KeyPolicy = T>
|
2013-08-25 23:04:01 +02:00
|
|
|
class NameHashSet : public ke::SystemAllocatorPolicy
|
2013-08-25 20:59:44 +02:00
|
|
|
{
|
|
|
|
typedef detail::CharsAndLength CharsAndLength;
|
|
|
|
|
|
|
|
// Default policy type: the two types are different. Use them directly.
|
|
|
|
template <typename KeyType, typename KeyPolicyType>
|
2013-08-25 20:59:46 +02:00
|
|
|
struct Policy
|
|
|
|
{
|
2013-08-25 20:59:44 +02:00
|
|
|
typedef KeyType Payload;
|
|
|
|
|
|
|
|
static uint32_t hash(const CharsAndLength &key)
|
|
|
|
{
|
2018-07-10 23:38:40 +02:00
|
|
|
return KeyPolicyType::hash(key);
|
2013-08-25 20:59:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool matches(const CharsAndLength &key, const KeyType &value)
|
|
|
|
{
|
2020-05-20 21:35:26 +02:00
|
|
|
return KeyPolicyType::matches(key.c_str(), value);
|
2013-08-25 20:59:44 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
// Specialization: the types are equal, and T is a pointer. Strip the
|
|
|
|
// pointer off so we can access T:: for match functions.
|
|
|
|
template <typename KeyType>
|
|
|
|
struct Policy<KeyType *, KeyType *>
|
|
|
|
{
|
|
|
|
typedef KeyType *Payload;
|
|
|
|
|
2018-07-10 23:38:40 +02:00
|
|
|
static uint32_t hash(const CharsAndLength &key)
|
2013-08-25 20:59:44 +02:00
|
|
|
{
|
2018-07-10 23:38:40 +02:00
|
|
|
return KeyType::hash(key);
|
2013-08-25 20:59:44 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool matches(const CharsAndLength &key, const KeyType *value)
|
|
|
|
{
|
2020-05-20 21:35:26 +02:00
|
|
|
return KeyType::matches(key.c_str(), value);
|
2013-08-25 20:59:44 +02:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-08-25 23:04:01 +02:00
|
|
|
typedef ke::HashTable<Policy<T, KeyPolicy>, ke::SystemAllocatorPolicy> Internal;
|
2013-08-25 20:59:44 +02:00
|
|
|
|
|
|
|
public:
|
|
|
|
NameHashSet()
|
|
|
|
{
|
|
|
|
if (!table_.init())
|
|
|
|
this->reportOutOfMemory();
|
|
|
|
}
|
|
|
|
|
|
|
|
typedef typename Internal::Result Result;
|
|
|
|
typedef typename Internal::Insert Insert;
|
2013-08-25 20:59:48 +02:00
|
|
|
typedef typename Internal::iterator iterator;
|
2013-08-25 20:59:44 +02:00
|
|
|
|
2013-08-30 19:16:28 +02:00
|
|
|
Result find(const char *aKey)
|
|
|
|
{
|
Make all command lookups case-insensitive (#1542)
SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes #1480, #1529
2021-07-18 20:05:06 +02:00
|
|
|
CharsAndLength key(aKey);
|
|
|
|
return table_.find(key);
|
2013-08-30 19:16:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Insert findForAdd(const char *aKey)
|
|
|
|
{
|
Make all command lookups case-insensitive (#1542)
SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes #1480, #1529
2021-07-18 20:05:06 +02:00
|
|
|
CharsAndLength key(aKey);
|
|
|
|
return table_.findForAdd(key);
|
2013-08-30 19:16:28 +02:00
|
|
|
}
|
|
|
|
|
2015-03-08 09:16:51 +01:00
|
|
|
template <typename U>
|
2015-05-09 12:57:49 +02:00
|
|
|
bool add(Insert &i, U &&value)
|
2013-08-30 19:16:28 +02:00
|
|
|
{
|
2020-05-17 08:15:32 +02:00
|
|
|
return table_.add(i, std::forward<U>(value));
|
2013-08-30 19:16:28 +02:00
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:44 +02:00
|
|
|
bool retrieve(const char *aKey, T *value)
|
|
|
|
{
|
|
|
|
CharsAndLength key(aKey);
|
Make all command lookups case-insensitive (#1542)
SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes #1480, #1529
2021-07-18 20:05:06 +02:00
|
|
|
Result r = table_.find(key);
|
2013-08-25 20:59:44 +02:00
|
|
|
if (!r.found())
|
|
|
|
return false;
|
|
|
|
*value = *r;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-03-08 09:16:51 +01:00
|
|
|
template <typename U>
|
|
|
|
bool insert(const char *aKey, U &&value)
|
2013-08-30 19:16:28 +02:00
|
|
|
{
|
|
|
|
CharsAndLength key(aKey);
|
|
|
|
Insert i = table_.findForAdd(key);
|
|
|
|
if (i.found())
|
|
|
|
return false;
|
2020-05-17 08:15:32 +02:00
|
|
|
return table_.add(i, std::forward<U>(value));
|
2013-08-30 19:16:28 +02:00
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:47 +02:00
|
|
|
bool contains(const char *aKey)
|
|
|
|
{
|
|
|
|
CharsAndLength key(aKey);
|
Make all command lookups case-insensitive (#1542)
SM internally maintained both a case-sensitive and a case-insensitive
lookup method for commands, where the case-sensitive hashmap was used as
a fast path, and case-insensitive iteration over a list used as the slow
path if a command was not found in the hashmap. But only command
dispatch handling used this dual path approach, chat triggers for
example only did a loopup in the hashmap.
Over the years Valve has made more and more of the command dispatch
logic case-insensitive to the point where all console commands are now
case-insensitive, so maintaining case sensitivity when using chat
triggers does not make a lot of sense. There are somewhat popular
plugins that attempt to "correct" this behaviour - but at least one is
having issues after the previous case-sensitivity fixes for commands -
see #1480.
We still have to keep the list around for the sorted help use case and
command iteration, but this PR changes the hashmap to use a
case-insensitive hashing policy (as previously done for convars, and
more recently for game command lookup) and changes all by-name lookup to
exclusively use the hashmap (as there is no need to fall back to the
list any more).
Tested a bunch in TF2, I don't know of any games that still have a
case-sensitive command dispatch pipeline to test. I think the worst case
would be that we'd accept a chat command in the "wrong" case then fail
to execute the underlying command. If that turns out to be an issue in
practice, we should be able to fix it easily enough by replacing the
command name in the buffer with the correct casing of the command we
looked up.
Also fixed a couple of very minor Lookup vs. Key issues in NameHashSet
(noted in #1529) that were being masked due to CharsAndLength's
converting constructor. I tried to make the constructor explicit to
avoid this happening in the future but HashTable's add function relies
on being able to do an implicit conversion so that wasn't possible. We
might want to just rely on the implicit conversion up here as well, but
it doesn't really matter either way.
Fixes #1480, #1529
2021-07-18 20:05:06 +02:00
|
|
|
Result r = table_.find(key);
|
2013-08-25 20:59:47 +02:00
|
|
|
return r.found();
|
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:44 +02:00
|
|
|
bool remove(const char *aKey)
|
|
|
|
{
|
|
|
|
CharsAndLength key(aKey);
|
|
|
|
Result r = table_.find(key);
|
|
|
|
if (!r.found())
|
|
|
|
return false;
|
|
|
|
table_.remove(r);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-08-30 19:16:28 +02:00
|
|
|
void remove(Result &r)
|
|
|
|
{
|
|
|
|
table_.remove(r);
|
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:47 +02:00
|
|
|
void clear()
|
|
|
|
{
|
|
|
|
table_.clear();
|
|
|
|
}
|
|
|
|
|
2013-08-25 21:20:38 +02:00
|
|
|
size_t mem_usage() const
|
|
|
|
{
|
|
|
|
return table_.estimateMemoryUse();
|
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:48 +02:00
|
|
|
iterator iter()
|
|
|
|
{
|
|
|
|
return iterator(&table_);
|
|
|
|
}
|
|
|
|
|
2013-08-25 20:59:44 +02:00
|
|
|
private:
|
|
|
|
Internal table_;
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif // _include_sourcemod_namehashset_h_
|