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?










share|improve this question









New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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

















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?










share|improve this question









New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




















  • 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















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?










share|improve this question









New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question









New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 30 mins ago





















New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 2 hours ago









Guillaume Racicot

1115




1115




New contributor




Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Guillaume Racicot is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












  • 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




















  • 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


















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

















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.










draft saved

draft discarded


















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.










draft saved

draft discarded


















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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Morgemoulin

Scott Moir

Souastre