1

Topic: Comparison of signatures

Greetings! For example, we have such function: template <typename... Args> yas:: shared_buffer func (Args&&... args) {yas:: mem_ostream os; yas:: binary_oarchive <yas:: mem_ostream, yas:: binary> oa (os); oa and std:: make_tuple (std:: forward <Args> (args)...); return os.get_shared_buffer ();} For example, we cause it with such arguments - func (' a ', 3, 4ull); also it is received  archive. On the opposite side we try to deserialise archive in other types - that we receive - depends... A question in how on the side of serialization of arguments to create a certain identifier of the signature that  it in archive before arguments, and to check correspondence on the opposite side. Is such primitive and wildly  a variant: to use __ PRETTY_FUNCTION __, in  from it to select only the signature + to count  from the received line. And yes, GCC speaks that __ PRETTY_FUNCTION __ not a constant expression though clang speaks what yes. Well... There are some more variants, type of creation for standard types  ID, and adding of the list of these ID `  in archive. But it would not be desirable to have  in the form of the manual job of association for each non-standard type. What thoughts?

2

Re: Comparison of signatures

Hello, Kodt, you wrote: to Reconcile with , - because pull out __ func __ in pure  it can to be difficult. Well clang is able. return hash_value (__ func __);//TODO: to tear out from  hash_value (const (&char) [N]) it is not necessary from , is: https://gist.github.com/niXman/e12d1858 … 6eabebbf27 thanks, I think...

3

Re: Comparison of signatures

Hello, Kodt, you wrote:... Family __ FUNCTION __ - as constant arrays (to which gcc, likely, forgot to fasten constexpr). Did not forget, and  it is intended. Recently in GCC ML there was this subject. Someone  asked, why is that is, and in  - ? So  answered that in the standard so it is written, differently - amateur performance. Also suggested to write . And thus recognized that  - it is simple, and no backward compatibility breaks.

4

Re: Comparison of signatures

Hello, Kodt, you wrote: only not __ func __, and __ PRETTY_FUNCTION __, certainly. That types in the text climbed through. That it is clear)

5

Re: Comparison of signatures

Hello, niXman, you wrote: X> what thoughts? struct S <auto... args> {}; typeid (S <Args...>)?

6

Re: Comparison of signatures

Hello, Alexander G, you wrote: AG> typeid (S <Args...>) typeid () it is intolerable. About it I, to mine,  queue thought.

7

Re: Comparison of signatures

Hello, niXman, you wrote: X> is such primitive and wildly  a variant: to use __ PRETTY_FUNCTION __, in  from it to select only the signature + to count  from the received line. X> and yes, GCC speaks that __ PRETTY_FUNCTION __ not a constant expression though clang speaks what yes. X> what thoughts? Can be so: https://github.com/Manu343726/ctti https://github.com/Manu343726/ctti/blob … nction.hpp

8

Re: Comparison of signatures

Hello, Kodt, you wrote: More than that, identifiers (numerical and hashes, including) at type_info can change from start to start. It is stipulated in the standard.  what %)

9

Re: Comparison of signatures

Hello, YuriV, you wrote: YV> Can be so: YV> https://github.com/Manu343726/ctti YV> https://github.com/Manu343726/ctti/blob … nction.hpp the good idea, in only it does not gather: https://github.com/Manu343726/ctti/issues/19

10

Re: Comparison of signatures

Hello, niXman, you wrote: X> for example, we cause it with such arguments - func (' a ', 3, 4ull); also it is received  archive. X> on the opposite side we try to deserialise archive in other types - that we receive - depends... X> a question in how on the side of serialization of arguments to create a certain identifier of the signature that  it in archive before arguments, and to check correspondence on the opposite side. Can it is necessary to approach on the other hand and to have a format  structures. And on this format to generate the code , deserialisings, help and check of a validity and completeness of the data? serialize_using (PUBLIC_FORMAT_1).store (' a ', 3,4ull);

11

Re: Comparison of signatures

Hello, kov_serg, you wrote: _> Can it is necessary to approach on the other hand and to have a format  structures. And on this format to generate the code , deserialisings, help and check of a validity and completeness of the data? serialize_using (PUBLIC_FORMAT_1).store (' a ', 3,4ull); so I also try to make it: template <typename... Args> yas:: shared_buffer func (Args&&... args) {yas:: mem_ostream os; yas:: binary_oarchive <yas:: mem_ostream, yas:: binary> oa (os); oa and make_public_format <typename std:: decay <Args>:: type...> ()//<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< and std:: make_tuple (std:: forward <Args> (args)...); return os.get_shared_buffer ();} now in the project nearby 300 , from them ~120 public, remaining for dialogue of services among themselves.  something to change  it would not be desirable...

12

Re: Comparison of signatures

Hello, niXman, you wrote: X> Hello, YuriV, you wrote: YV>> Can be so: YV>> https://github.com/Manu343726/ctti YV>> https://github.com/Manu343726/ctti/blob … nction.hpp X> the good idea, in only it does not gather: https://github.com/Manu343726/ctti/issues/19 I once should know a name of type without rtti, then need disappeared also I at all did not check. All began here with it: https://stackoverflow.com/questions/359 … stexpr-way

13

Re: Comparison of signatures

Hello, niXman, you wrote: YV>> Can be so: YV>> https://github.com/Manu343726/ctti YV>> https://github.com/Manu343726/ctti/blob … nction.hpp X> the good idea, in only it does not gather: https://github.com/Manu343726/ctti/issues/19 If enough only to receive a type name in runtime I use the simplified version: https://github.com/pmed/v8pp/blob/maste … y.hpp#L235

14

Re: Comparison of signatures

Hello, PM, you wrote: PM> Hello, niXman, you wrote: YV>>> Can be so: YV>>> https://github.com/Manu343726/ctti YV>>> https://github.com/Manu343726/ctti/blob … nction.hpp X>> the good idea, in only it does not gather: https://github.com/Manu343726/ctti/issues/19 PM> If enough only to receive a type name in runtime I use the simplified version: https://github.com/pmed/v8pp/blob/maste … y.hpp#L235 the Interesting operating time, but for various compilers, type_id () returns different string representation, i.e. for serialization does not approach. For example, type_id <void (long)> ().name () it turns out: "void (long)" clang, "void (long int)" gcc and "void (long)" msvc

15

Re: Comparison of signatures

Hello, ffk, you wrote: PM>> If enough only to receive a type name in runtime I use the simplified version: https://github.com/pmed/v8pp/blob/maste … y.hpp#L235 ffk> the Interesting operating time, but for various compilers, type_id () returns different string representation, i.e. for serialization does not approach. ffk> for example, type_id <void (long)> ().name () it turns out: "void (long)" clang, "void (long int)" gcc and "void (long)" msvc Yes, it is exact, intolerable and for serialization does not approach.

16

Re: Comparison of signatures

It is necessary to do specializations for fundamental and standard types, and for ... I think to make so: template <typename> struct my_typeid; template <> struct my_typeid <bool> {enum: std:: uint32_t {id = fnv1a ("bool")};}; template <> struct my_typeid <std:: int8_t> {enum: std:: uint32_t {id = fnv1a ("std:: int8_t")};}; macroes simplify all... A question in how me to add id ` , received at hash coding? I.e. I assume something like: constexpr std:: uint32_t sig_id () {return 0;} template <typename Arg0, typename... Args> constexpr std:: uint32_t sig_id (const Arg0&, const Args&... args) {constexpr std:: uint32_t id = my_typeid <Arg0>:: id + sig_id (args...);} whether increases simple summation probability of collisions?

17

Re: Comparison of signatures

I.e. for containers it turns out so: template <typename K, typename V> struct my_typeid <std:: map <K, V>> {enum: std:: uint32_t {id = fnv1a ("std:: int8_t") + my_typeid <K>:: id + my_typeid <V>:: id};}; what problems/deadlocks can?

18

Re: Comparison of signatures

Hello, niXman, you wrote: X> i.e. for containers it turns out so: X> X> template <typename K, typename V> X> struct my_typeid <std:: map <K, V>> {X> enum: std:: uint32_t {id = fnv1a ("std:: int8_t") + my_typeid <K>:: id + my_typeid <V>:: id}; X>}; X> X> what problems/deadlocks can? my_typeid <std:: map <int8_t, int32_t>>:: id == my_typeid <std:: map <int32_t, int8_t>>:: id

19

Re: Comparison of signatures

Hello, Chorkov, you wrote: a C> my_typeid <std:: map <int8_t, int32_t>>:: id == my_typeid <std:: map <int32_t, int8_t>>:: id by the way yes... As to add hashes?

20

Re: Comparison of signatures

Hello, niXman, you wrote: X> Hello, Chorkov, you wrote: a C>> my_typeid <std:: map <int8_t, int32_t>>:: id == my_typeid <std:: map <int32_t, int8_t>>:: id X> by the way yes... X> as to add hashes? If not constexpr, I would advise boost:: hash_combine. And so, it is possible to increase by prime numbers: constexpr std:: uint32_t combine (std:: uint32_t id0, std:: uint32_t id1=0, std:: uint32_t id2=0, std:: uint32_t id3=0, std:: uint32_t id4=0, std:: uint32_t id5=0, std:: uint32_t id6=0, std:: uint32_t id7=0, std:: uint32_t id8=0) {return id0*5 + id1+7 + id2*11 + id3*13 + id4*17 + id5*19 + id6*23 + id7*29 + id8*31;}