MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2016 Charybdis Development Team
|
|
|
|
* Copyright (C) 2016 Jason Volk <jason@zemos.net>
|
|
|
|
*
|
|
|
|
* Permission to use, copy, modify, and/or distribute this software for any
|
|
|
|
* purpose with or without fee is hereby granted, provided that the above
|
|
|
|
* copyright notice and this permission notice is present in all copies.
|
|
|
|
*
|
|
|
|
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR
|
|
|
|
* IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
|
|
|
|
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
|
|
|
|
* DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT,
|
|
|
|
* INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
|
|
|
|
* (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
|
|
|
|
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
|
|
|
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
* STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING
|
|
|
|
* IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
|
|
|
|
* POSSIBILITY OF SUCH DAMAGE.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
#define HAVE_IRCD_MAPI_H
|
|
|
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
namespace ircd {
|
|
|
|
namespace mapi {
|
|
|
|
|
2016-09-13 10:29:50 +02:00
|
|
|
enum flags
|
|
|
|
{
|
|
|
|
NO_FLAGS = 0x00,
|
|
|
|
RELAXED_INIT = 0x01,
|
|
|
|
};
|
|
|
|
|
|
|
|
using export_vector = std::vector<std::pair<const void *, std::type_index>>;
|
|
|
|
using metadata = std::map<std::string, std::string>;
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
struct init
|
|
|
|
:std::function<void ()>
|
|
|
|
{
|
|
|
|
using std::function<void ()>::function;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct fini
|
|
|
|
:std::function<void ()>
|
|
|
|
{
|
|
|
|
using std::function<void ()>::function;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct exports
|
|
|
|
:export_vector
|
|
|
|
{
|
|
|
|
template<class... List> exports(List&&... list);
|
|
|
|
};
|
|
|
|
|
2016-11-02 23:12:56 +01:00
|
|
|
const char *const header_symbol_name
|
|
|
|
{
|
|
|
|
"IRCD_MODULE"
|
|
|
|
};
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
struct header
|
|
|
|
{
|
|
|
|
static constexpr const magic_t MAGIC
|
|
|
|
{
|
|
|
|
0x4D41
|
|
|
|
};
|
|
|
|
|
2016-09-13 10:29:50 +02:00
|
|
|
magic_t magic; // The magic must match MAGIC
|
|
|
|
version_t version; // Version indicator
|
|
|
|
enum flags flags; // Option flags
|
|
|
|
int64_t timestamp; // Module's compile epoch
|
|
|
|
struct exports exports; // Generated export vector
|
|
|
|
metadata meta; // Various key-value metadata
|
|
|
|
|
|
|
|
// get and set metadata
|
|
|
|
auto &operator[](const std::string &s) const;
|
|
|
|
auto &operator[](const std::string &s);
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
|
|
|
|
template<class... Exports>
|
|
|
|
header(const char *const &desc,
|
|
|
|
const enum flags &flags,
|
|
|
|
Exports&&... exports);
|
2016-09-05 22:06:30 +02:00
|
|
|
|
|
|
|
header(const char *const &desc = "<no description>");
|
2016-09-13 10:31:12 +02:00
|
|
|
~header() noexcept;
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
};
|
|
|
|
|
2016-09-05 22:06:30 +02:00
|
|
|
inline
|
|
|
|
header::header(const char *const &desc)
|
|
|
|
:header
|
|
|
|
{
|
|
|
|
desc, NO_FLAGS
|
|
|
|
}
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
template<class... Exports>
|
|
|
|
header::header(const char *const &desc,
|
|
|
|
const enum flags &flags,
|
|
|
|
Exports&&... exports)
|
|
|
|
:magic(MAGIC)
|
|
|
|
,version(4)
|
|
|
|
,flags(flags)
|
|
|
|
,timestamp(RB_DATECODE)
|
|
|
|
,exports{std::forward<Exports>(exports)...}
|
2016-09-13 10:29:50 +02:00
|
|
|
,meta
|
|
|
|
{
|
|
|
|
{ "description", desc }
|
|
|
|
}
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2016-09-13 10:31:12 +02:00
|
|
|
inline
|
|
|
|
header::~header()
|
|
|
|
noexcept
|
|
|
|
{
|
2016-09-25 04:45:37 +02:00
|
|
|
mods::static_destruction = true;
|
2016-09-13 10:31:12 +02:00
|
|
|
}
|
|
|
|
|
2016-09-13 10:29:50 +02:00
|
|
|
inline auto &
|
|
|
|
header::operator[](const std::string &key)
|
|
|
|
{
|
|
|
|
return meta[key];
|
|
|
|
}
|
|
|
|
|
|
|
|
inline auto &
|
|
|
|
header::operator[](const std::string &key)
|
|
|
|
const
|
|
|
|
{
|
|
|
|
return meta.at(key);
|
|
|
|
}
|
|
|
|
|
MAPI IV. This iteration leverages the C++11 standardized RTTI.
* Simplifies the export declarations for module developers. While
MAPI III utilized a flexible key-value vector to eliminate positional
arguments in a header initializer, now the developer simply makes
a list of pointers to what they want to export for injection into
IRCd. Example:
mapi::header IRCD_MODULE
{
"mymod",
"My module adds a command, a hook, and a CLICAP",
&my_cmdtab,
&some_hook,
&clicaptab
};
* Distributes the handlers for items passed to the above vector.
Anyone can add a type-handler to the module system from anywhere in IRCd
(and other modules?) When your type is encountered a handler is called
providing the symbol name to read out of the module. Example in parser.cc:
mods::add_loader<Message>([]
(mod &loading, const std::string &symbol)
{
auto &msg(get<Message>(loading, symbol));
add_command(msg.name, msg);
});
2016-08-29 21:09:59 +02:00
|
|
|
template<class... List>
|
|
|
|
exports::exports(List&&... list)
|
|
|
|
{
|
|
|
|
const std::vector<std::type_index> types
|
|
|
|
{
|
|
|
|
typeid(List)...
|
|
|
|
};
|
|
|
|
|
|
|
|
const std::vector<const void *> ptrs
|
|
|
|
{
|
|
|
|
std::forward<List>(list)...
|
|
|
|
};
|
|
|
|
|
|
|
|
assert(types.size() == ptrs.size());
|
|
|
|
for(size_t i(0); i < types.size(); ++i)
|
|
|
|
this->emplace_back(ptrs.at(i), types.at(i));
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace mapi
|
|
|
|
} // namespace ircd
|
|
|
|
#endif // __cplusplus
|