Hash.h File Reference

#include <iosfwd>
#include <unordered_set>
#include <unordered_map>

Include dependency graph for Hash.h:

This graph shows which files directly or indirectly include this file:

Go to the source code of this file.

Namespaces
namespace	std

Macros
#define	ZYPP_DEFINE_ID_HASHABLE(C)
	Define hash function for id based classes.

Functions
template<class D>
unordered_set< D > *	std::rwcowClone (const std::unordered_set< D > *rhs)
	clone function for RW_pointer
template<class K, class V>
std::unordered_map< K, V > *	std::rwcowClone (const std::unordered_map< K, V > *rhs)
	clone function for RW_pointer

Macro Definition Documentation

ZYPP_DEFINE_ID_HASHABLE

#define ZYPP_DEFINE_ID_HASHABLE

(

C

)

Value:

namespace std {                                      \
  template<class Tp> struct hash;               \
  template<> struct hash<C>                     \
  {                                             \
    size_t operator()( const C & __s ) const    \
    { return __s.id(); }                        \
  };                                            \
}

Define hash function for id based classes.

Class has to provide a method id() retuning a unique number.

// in global namespace define:
ZYPP_DEFINE_ID_HASHABLE( ::zypp::sat::Solvable )

In a C++20 named module interface unit the primary template std::hash is already declared in the global module fragment (via <unordered_set>). Re-declaring it inside the module purview attaches it to the named module and causes a conflicting-declaration error. We therefore suppress the redundant primary-template forward decl when compiling under modules.

GCC defines __cpp_modules when building a named module. Clang 19 does NOT define __cpp_modules even in module interface units (longstanding Clang policy); we therefore also suppress the forward decl unconditionally for Clang — safe because Hash.h itself #includes <unordered_set>, so std::hash is always already declared before the macro expands.

Definition at line 48 of file Hash.h.