Unique compile time (constexpr) type ID without RTTI
up vote
2
down vote
favorite
I am making a library where I need to generate a unique ID for a type where the ID must be known at compile time. I first relied on the address of a template function, but it proved itself unreliable both with MSVC and Clang on windows.
Then I came up with the address of a static data member inside a template class.
I want to support most use cases as possible here's what comes to my mind:
- Eager optimizations that would merge the definition of static variables or inline functions
- DLL and shared libraries
- Link time optimizations
Most of my tests were successful, but I'm not an expert with the kind of use case I want to support so it's hard to tell if I can ensure my claims are okay.
My design work by declaring a static data member of type T*
inside a template class, then taking its address as the value of the ID.
namespace detail {
/**
* Template class that hold the declaration of the id.
*
* We use the pointer of this id as type id.
*/
template<typename T>
struct type_id_ptr {
// Having a static data member will ensure (I hope) that it has only one address for the whole program.
// Furthermore, the static data member having different types will ensure (I hope) it won't get optimized.
static const T* const id;
};
/**
* Definition of the id.
*/
template<typename T>
const T* const type_id_ptr<T>::id = nullptr;
} // namespace detail
/**
* The type of a type id.
*/
using type_id_t = const void*;
/**
* The function that returns the type id.
*
* It uses the pointer to the static data member of a class template to achieve this.
* Altough the value is not predictible, it's stable (I hope).
*/
template <typename T>
constexpr auto type_id() noexcept -> type_id_t {
return &detail::type_id_ptr<T>::id;
}
It is then used like this:
constexpr auto id_of_int_type = type_id_t{type_id<int>()};
It there any caveats to be aware with this design?
c++ c++11
New contributor
add a comment |
up vote
2
down vote
favorite
I am making a library where I need to generate a unique ID for a type where the ID must be known at compile time. I first relied on the address of a template function, but it proved itself unreliable both with MSVC and Clang on windows.
Then I came up with the address of a static data member inside a template class.
I want to support most use cases as possible here's what comes to my mind:
- Eager optimizations that would merge the definition of static variables or inline functions
- DLL and shared libraries
- Link time optimizations
Most of my tests were successful, but I'm not an expert with the kind of use case I want to support so it's hard to tell if I can ensure my claims are okay.
My design work by declaring a static data member of type T*
inside a template class, then taking its address as the value of the ID.
namespace detail {
/**
* Template class that hold the declaration of the id.
*
* We use the pointer of this id as type id.
*/
template<typename T>
struct type_id_ptr {
// Having a static data member will ensure (I hope) that it has only one address for the whole program.
// Furthermore, the static data member having different types will ensure (I hope) it won't get optimized.
static const T* const id;
};
/**
* Definition of the id.
*/
template<typename T>
const T* const type_id_ptr<T>::id = nullptr;
} // namespace detail
/**
* The type of a type id.
*/
using type_id_t = const void*;
/**
* The function that returns the type id.
*
* It uses the pointer to the static data member of a class template to achieve this.
* Altough the value is not predictible, it's stable (I hope).
*/
template <typename T>
constexpr auto type_id() noexcept -> type_id_t {
return &detail::type_id_ptr<T>::id;
}
It is then used like this:
constexpr auto id_of_int_type = type_id_t{type_id<int>()};
It there any caveats to be aware with this design?
c++ c++11
New contributor
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in astd::map
and a compile time map.
– Guillaume Racicot
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I am making a library where I need to generate a unique ID for a type where the ID must be known at compile time. I first relied on the address of a template function, but it proved itself unreliable both with MSVC and Clang on windows.
Then I came up with the address of a static data member inside a template class.
I want to support most use cases as possible here's what comes to my mind:
- Eager optimizations that would merge the definition of static variables or inline functions
- DLL and shared libraries
- Link time optimizations
Most of my tests were successful, but I'm not an expert with the kind of use case I want to support so it's hard to tell if I can ensure my claims are okay.
My design work by declaring a static data member of type T*
inside a template class, then taking its address as the value of the ID.
namespace detail {
/**
* Template class that hold the declaration of the id.
*
* We use the pointer of this id as type id.
*/
template<typename T>
struct type_id_ptr {
// Having a static data member will ensure (I hope) that it has only one address for the whole program.
// Furthermore, the static data member having different types will ensure (I hope) it won't get optimized.
static const T* const id;
};
/**
* Definition of the id.
*/
template<typename T>
const T* const type_id_ptr<T>::id = nullptr;
} // namespace detail
/**
* The type of a type id.
*/
using type_id_t = const void*;
/**
* The function that returns the type id.
*
* It uses the pointer to the static data member of a class template to achieve this.
* Altough the value is not predictible, it's stable (I hope).
*/
template <typename T>
constexpr auto type_id() noexcept -> type_id_t {
return &detail::type_id_ptr<T>::id;
}
It is then used like this:
constexpr auto id_of_int_type = type_id_t{type_id<int>()};
It there any caveats to be aware with this design?
c++ c++11
New contributor
I am making a library where I need to generate a unique ID for a type where the ID must be known at compile time. I first relied on the address of a template function, but it proved itself unreliable both with MSVC and Clang on windows.
Then I came up with the address of a static data member inside a template class.
I want to support most use cases as possible here's what comes to my mind:
- Eager optimizations that would merge the definition of static variables or inline functions
- DLL and shared libraries
- Link time optimizations
Most of my tests were successful, but I'm not an expert with the kind of use case I want to support so it's hard to tell if I can ensure my claims are okay.
My design work by declaring a static data member of type T*
inside a template class, then taking its address as the value of the ID.
namespace detail {
/**
* Template class that hold the declaration of the id.
*
* We use the pointer of this id as type id.
*/
template<typename T>
struct type_id_ptr {
// Having a static data member will ensure (I hope) that it has only one address for the whole program.
// Furthermore, the static data member having different types will ensure (I hope) it won't get optimized.
static const T* const id;
};
/**
* Definition of the id.
*/
template<typename T>
const T* const type_id_ptr<T>::id = nullptr;
} // namespace detail
/**
* The type of a type id.
*/
using type_id_t = const void*;
/**
* The function that returns the type id.
*
* It uses the pointer to the static data member of a class template to achieve this.
* Altough the value is not predictible, it's stable (I hope).
*/
template <typename T>
constexpr auto type_id() noexcept -> type_id_t {
return &detail::type_id_ptr<T>::id;
}
It is then used like this:
constexpr auto id_of_int_type = type_id_t{type_id<int>()};
It there any caveats to be aware with this design?
c++ c++11
c++ c++11
New contributor
New contributor
edited 30 mins ago
New contributor
asked 2 hours ago
Guillaume Racicot
1115
1115
New contributor
New contributor
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in astd::map
and a compile time map.
– Guillaume Racicot
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago
add a comment |
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in astd::map
and a compile time map.
– Guillaume Racicot
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in a
std::map
and a compile time map.– Guillaume Racicot
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in a
std::map
and a compile time map.– Guillaume Racicot
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Guillaume Racicot is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209950%2funique-compile-time-constexpr-type-id-without-rtti%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Guillaume Racicot is a new contributor. Be nice, and check out our Code of Conduct.
Guillaume Racicot is a new contributor. Be nice, and check out our Code of Conduct.
Guillaume Racicot is a new contributor. Be nice, and check out our Code of Conduct.
Guillaume Racicot is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f209950%2funique-compile-time-constexpr-type-id-without-rtti%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
This relies on a kernel that does address space layout randomization, along with plenty of other assumptions about how the system allocates memory. Have you done randomness tests to see if this entropy pool is reliable on your system (leaving alone other people's systems)? There are other, possibly better, ways to have compile-time randomness. Are you trying to do something like library order randomization (ie since OpenBSD 6), I'm not sure I see the purpose?
– esote
2 hours ago
@esote My goal is not to generate compile time randomness, but instead to have a unique value for a given type. I use the ID as key in a
std::map
and a compile time map.– Guillaume Racicot
2 hours ago
I misunderstood your purpose, my bad. How about using what's described here?
– esote
2 hours ago
@esote It cannot work in a constexpr context as far as I know and it requires RTTI, which is the goal of designing an alternative solution.
– Guillaume Racicot
1 hour ago
This really requires a language-lawyer tag. Great question, but unfortunately beyond me.
– vnp
51 mins ago