Ichthyostega
806db414dd
* Lumiera source code always was copyrighted by individual contributors * there is no entity "Lumiera.org" which holds any copyrights * Lumiera source code is provided under the GPL Version 2+ == Explanations == Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above. For this to become legally effective, the ''File COPYING in the root directory is sufficient.'' The licensing header in each file is not strictly necessary, yet considered good practice; attaching a licence notice increases the likeliness that this information is retained in case someone extracts individual code files. However, it is not by the presence of some text, that legally binding licensing terms become effective; rather the fact matters that a given piece of code was provably copyrighted and published under a license. Even reformatting the code, renaming some variables or deleting parts of the code will not alter this legal situation, but rather creates a derivative work, which is likewise covered by the GPL! The most relevant information in the file header is the notice regarding the time of the first individual copyright claim. By virtue of this initial copyright, the first author is entitled to choose the terms of licensing. All further modifications are permitted and covered by the License. The specific wording or format of the copyright header is not legally relevant, as long as the intention to publish under the GPL remains clear. The extended wording was based on a recommendation by the FSF. It can be shortened, because the full terms of the license are provided alongside the distribution, in the file COPYING.
143 lines
3.4 KiB
C++
143 lines
3.4 KiB
C++
/*
|
||
SUB-ID.hpp - extensible symbolic identifier
|
||
|
||
Copyright (C)
|
||
2009, Hermann Vosseler <Ichthyostega@web.de>
|
||
|
||
**Lumiera** is free software; you can redistribute it and/or modify it
|
||
under the terms of the GNU General Public License as published by the
|
||
Free Software Foundation; either version 2 of the License, or (at your
|
||
option) any later version. See the file COPYING for further details.
|
||
|
||
*/
|
||
|
||
|
||
/** @file sub-id.hpp
|
||
** Extensible symbolic ID type.
|
||
** @remark this is a design sketch (from 9/2009) an not used anywhere as of 3/2017...
|
||
**
|
||
** My observation is that, during design, I did run again and again into a specific
|
||
** situation, which I then needed to circumvent in lack of a first class solution.
|
||
** Learning from that experiences, I start building this structured ID template.
|
||
** - it shall be an \em symbolic identifier, not an artificial ID
|
||
** - the basic value set should be limited and statically type safe.
|
||
** - possibility of structured adornments and variations
|
||
** - optionally concealing these extensions from the interface level
|
||
**
|
||
** The first attempt to build such an entity is based on standard techniques,
|
||
** disregarding performance and memory footprint considerations.
|
||
**
|
||
** @todo 1/2016 this idea seems very reasonable, and we should just make it
|
||
** robust and usable, along the lines pointed out by that draft
|
||
** - use std::tuple as storage
|
||
** - remove the `format-util` dependency (!) ////////////////////////////////TICKET #985
|
||
** - provide a hash implementation for real
|
||
** - extend to arbitrary number of sub-dimensions (variadic)
|
||
** - implement comparisons as you'd do for any algebraic type
|
||
** - provide a metaprogramming facility to get an id tuple
|
||
**
|
||
** @see SubID_test
|
||
** @see MultiFact
|
||
**
|
||
*/
|
||
|
||
|
||
|
||
#ifndef LIB_SUB_ID_H
|
||
#define LIB_SUB_ID_H
|
||
|
||
#include "lib/format-util.hpp"
|
||
|
||
//#include <functional>
|
||
#include <boost/functional/hash.hpp> /////TODO better push the hash implementation into a cpp file (and btw, do it more seriously!)
|
||
|
||
#include <string>
|
||
|
||
|
||
namespace lib {
|
||
|
||
using boost::hash_value;
|
||
using std::string;
|
||
|
||
|
||
|
||
/**
|
||
*
|
||
*/
|
||
template<typename I>
|
||
class SubId;
|
||
|
||
class SubID
|
||
{
|
||
public:
|
||
virtual ~SubID() { }
|
||
|
||
virtual operator string() const =0;
|
||
};
|
||
|
||
|
||
inline size_t
|
||
hash_value (SubID const& sID)
|
||
{
|
||
return hash_value (string (sID));
|
||
}
|
||
|
||
inline bool
|
||
operator== (SubID const& id1, SubID const& id2)
|
||
{
|
||
return (string (id1) == string (id2));
|
||
}
|
||
|
||
////////TODO a serious implementation should descend recursively, instead of relying on the string representation
|
||
|
||
|
||
|
||
|
||
|
||
|
||
template<typename I>
|
||
class SubId
|
||
: public SubID
|
||
{
|
||
I baseID_;
|
||
|
||
public:
|
||
SubId (I id)
|
||
: baseID_(id)
|
||
{ }
|
||
|
||
operator string() const
|
||
{
|
||
using util::toString;
|
||
return toString (baseID_); // note: extension point
|
||
}
|
||
};
|
||
|
||
|
||
template<typename I, class SUZ>
|
||
class ExtendedSubId
|
||
: public SubId<I>
|
||
{
|
||
typedef SubId<I> _baID;
|
||
|
||
SUZ extID_;
|
||
|
||
public:
|
||
ExtendedSubId (I i, SUZ const& chain)
|
||
: _baID(i)
|
||
, extID_(chain)
|
||
{ }
|
||
|
||
operator string() const
|
||
{
|
||
return _baID::operator string()
|
||
+ '.'
|
||
+ string (extID_);
|
||
}
|
||
};
|
||
|
||
|
||
|
||
|
||
} // namespace lib
|
||
#endif
|