When does type information flow backwards in C++?










88















I just watched Stephan T. Lavavej talk at CppCon 2018 on "Class Template Argument Deduction", where at some point he incidentally says:




In C++ type information almost never flows backwards ... I had to say "almost" because there's one or two cases, possibly more but very few.




Despite trying to figure out which cases he might be referring to, I couldn't come up with anything. Hence the question:



In which cases the C++17 standard mandates that type information propagate backwards?










share|improve this question
























  • pattern matching partial specialization and destructuring assignments.

    – v.oddou
    Nov 13 '18 at 5:11















88















I just watched Stephan T. Lavavej talk at CppCon 2018 on "Class Template Argument Deduction", where at some point he incidentally says:




In C++ type information almost never flows backwards ... I had to say "almost" because there's one or two cases, possibly more but very few.




Despite trying to figure out which cases he might be referring to, I couldn't come up with anything. Hence the question:



In which cases the C++17 standard mandates that type information propagate backwards?










share|improve this question
























  • pattern matching partial specialization and destructuring assignments.

    – v.oddou
    Nov 13 '18 at 5:11













88












88








88


26






I just watched Stephan T. Lavavej talk at CppCon 2018 on "Class Template Argument Deduction", where at some point he incidentally says:




In C++ type information almost never flows backwards ... I had to say "almost" because there's one or two cases, possibly more but very few.




Despite trying to figure out which cases he might be referring to, I couldn't come up with anything. Hence the question:



In which cases the C++17 standard mandates that type information propagate backwards?










share|improve this question
















I just watched Stephan T. Lavavej talk at CppCon 2018 on "Class Template Argument Deduction", where at some point he incidentally says:




In C++ type information almost never flows backwards ... I had to say "almost" because there's one or two cases, possibly more but very few.




Despite trying to figure out which cases he might be referring to, I couldn't come up with anything. Hence the question:



In which cases the C++17 standard mandates that type information propagate backwards?







c++ types language-lawyer c++17 type-deduction






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 22:12









curiousguy

4,51422943




4,51422943










asked Nov 12 '18 at 21:16









MassimilianoMassimiliano

5,38822951




5,38822951












  • pattern matching partial specialization and destructuring assignments.

    – v.oddou
    Nov 13 '18 at 5:11

















  • pattern matching partial specialization and destructuring assignments.

    – v.oddou
    Nov 13 '18 at 5:11
















pattern matching partial specialization and destructuring assignments.

– v.oddou
Nov 13 '18 at 5:11





pattern matching partial specialization and destructuring assignments.

– v.oddou
Nov 13 '18 at 5:11












3 Answers
3






active

oldest

votes


















78














Here is at least one case:



struct foo 
template<class T>
operator T() const
std::cout << sizeof(T) << "n";
return ;

;


if you do foo f; int x = f; double y = f;, type information will flow "backwards" to figure out what T is in operator T.



You can use this in a more advanced way:



template<class T>
struct tag_t using type=T;;

template<class F>
struct deduce_return_t
F f;
template<class T>
operator T()&& return std::forward<F>(f)(tag_t<T>);
;
template<class F>
deduce_return_t(F&&)->deduce_return_t<F>;

template<class...Args>
auto construct_from( Args&&... args )
return deduce_return_t [&](auto ret)
using R=typename decltype(ret)::type;
return R std::forward<Args>(args)... ;
;



so now I can do



std::vector<int> v = construct_from( 1, 2, 3 );


and it works.



Of course, why not just do 1,2,3? Well, 1,2,3 isn't an expression.



std::vector<std::vector<int>> v;
v.emplace_back( construct_from(1,2,3) );


which, admittedly, require a bit more wizardry: Live example. (I have to make the deduce return do a SFINAE check of F, then make the F be SFINAE friendly, and I have to block std::initializer_list in deduce_return_t operator T.)






share|improve this answer

























  • Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

    – Massimiliano
    Nov 12 '18 at 22:28






  • 5





    The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

    – Justin
    Nov 12 '18 at 22:42






  • 1





    That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

    – llllllllll
    Nov 12 '18 at 23:59






  • 3





    @lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 0:13






  • 1





    @lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 2:26


















29














Stephan T. Lavavej explained the case he was talking about in a tweet:




The case I was thinking of is where you can take the address of an overloaded/templated function and if it’s being used to initialize a variable of a specific type, that will disambiguate which one you want. (There’s a list of what disambiguates.)




we can see examples of this from cppreference page on Address of overloaded function, I have excepted a few below:



int f(int) return 1; 
int f(double) return 2;

void g( int(&f1)(int), int(*f2)(double) )

int main()
g(f, f); // selects int f(int) for the 1st argument
// and int f(double) for the second

auto foo = () -> int (*)(int)
return f; // selects int f(int)
;

auto p = static_cast<int(*)(int)>(f); // selects int f(int)



Michael Park adds:




It's not limited to initializing a concrete type, either. It could also infer just from the number of arguments




and provides this live example:



void overload(int, int) 
void overload(int, int, int)

template <typename T1, typename T2,
typename A1, typename A2>
void f(void (*)(T1, T2), A1&&, A2&&)

template <typename T1, typename T2, typename T3,
typename A1, typename A2, typename A3>
void f(void (*)(T1, T2, T3), A1&&, A2&&, A3&&)

int main ()
f(&overload, 1, 2);



which I elaborate a little more here.






share|improve this answer




















  • 4





    We could also describe this as: cases where the type of an expression depends on the context?

    – M.M
    Nov 12 '18 at 23:56


















20














I believe in static casting of overloaded functions the flow goes the opposite direction as in usual overload resolution. So one of those is backwards, I guess.






share|improve this answer


















  • 6





    I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

    – Yakk - Adam Nevraumont
    Nov 12 '18 at 22:08










Your Answer






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: "1"
;
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: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53270242%2fwhen-does-type-information-flow-backwards-in-c%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes









78














Here is at least one case:



struct foo 
template<class T>
operator T() const
std::cout << sizeof(T) << "n";
return ;

;


if you do foo f; int x = f; double y = f;, type information will flow "backwards" to figure out what T is in operator T.



You can use this in a more advanced way:



template<class T>
struct tag_t using type=T;;

template<class F>
struct deduce_return_t
F f;
template<class T>
operator T()&& return std::forward<F>(f)(tag_t<T>);
;
template<class F>
deduce_return_t(F&&)->deduce_return_t<F>;

template<class...Args>
auto construct_from( Args&&... args )
return deduce_return_t [&](auto ret)
using R=typename decltype(ret)::type;
return R std::forward<Args>(args)... ;
;



so now I can do



std::vector<int> v = construct_from( 1, 2, 3 );


and it works.



Of course, why not just do 1,2,3? Well, 1,2,3 isn't an expression.



std::vector<std::vector<int>> v;
v.emplace_back( construct_from(1,2,3) );


which, admittedly, require a bit more wizardry: Live example. (I have to make the deduce return do a SFINAE check of F, then make the F be SFINAE friendly, and I have to block std::initializer_list in deduce_return_t operator T.)






share|improve this answer

























  • Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

    – Massimiliano
    Nov 12 '18 at 22:28






  • 5





    The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

    – Justin
    Nov 12 '18 at 22:42






  • 1





    That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

    – llllllllll
    Nov 12 '18 at 23:59






  • 3





    @lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 0:13






  • 1





    @lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 2:26















78














Here is at least one case:



struct foo 
template<class T>
operator T() const
std::cout << sizeof(T) << "n";
return ;

;


if you do foo f; int x = f; double y = f;, type information will flow "backwards" to figure out what T is in operator T.



You can use this in a more advanced way:



template<class T>
struct tag_t using type=T;;

template<class F>
struct deduce_return_t
F f;
template<class T>
operator T()&& return std::forward<F>(f)(tag_t<T>);
;
template<class F>
deduce_return_t(F&&)->deduce_return_t<F>;

template<class...Args>
auto construct_from( Args&&... args )
return deduce_return_t [&](auto ret)
using R=typename decltype(ret)::type;
return R std::forward<Args>(args)... ;
;



so now I can do



std::vector<int> v = construct_from( 1, 2, 3 );


and it works.



Of course, why not just do 1,2,3? Well, 1,2,3 isn't an expression.



std::vector<std::vector<int>> v;
v.emplace_back( construct_from(1,2,3) );


which, admittedly, require a bit more wizardry: Live example. (I have to make the deduce return do a SFINAE check of F, then make the F be SFINAE friendly, and I have to block std::initializer_list in deduce_return_t operator T.)






share|improve this answer

























  • Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

    – Massimiliano
    Nov 12 '18 at 22:28






  • 5





    The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

    – Justin
    Nov 12 '18 at 22:42






  • 1





    That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

    – llllllllll
    Nov 12 '18 at 23:59






  • 3





    @lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 0:13






  • 1





    @lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 2:26













78












78








78







Here is at least one case:



struct foo 
template<class T>
operator T() const
std::cout << sizeof(T) << "n";
return ;

;


if you do foo f; int x = f; double y = f;, type information will flow "backwards" to figure out what T is in operator T.



You can use this in a more advanced way:



template<class T>
struct tag_t using type=T;;

template<class F>
struct deduce_return_t
F f;
template<class T>
operator T()&& return std::forward<F>(f)(tag_t<T>);
;
template<class F>
deduce_return_t(F&&)->deduce_return_t<F>;

template<class...Args>
auto construct_from( Args&&... args )
return deduce_return_t [&](auto ret)
using R=typename decltype(ret)::type;
return R std::forward<Args>(args)... ;
;



so now I can do



std::vector<int> v = construct_from( 1, 2, 3 );


and it works.



Of course, why not just do 1,2,3? Well, 1,2,3 isn't an expression.



std::vector<std::vector<int>> v;
v.emplace_back( construct_from(1,2,3) );


which, admittedly, require a bit more wizardry: Live example. (I have to make the deduce return do a SFINAE check of F, then make the F be SFINAE friendly, and I have to block std::initializer_list in deduce_return_t operator T.)






share|improve this answer















Here is at least one case:



struct foo 
template<class T>
operator T() const
std::cout << sizeof(T) << "n";
return ;

;


if you do foo f; int x = f; double y = f;, type information will flow "backwards" to figure out what T is in operator T.



You can use this in a more advanced way:



template<class T>
struct tag_t using type=T;;

template<class F>
struct deduce_return_t
F f;
template<class T>
operator T()&& return std::forward<F>(f)(tag_t<T>);
;
template<class F>
deduce_return_t(F&&)->deduce_return_t<F>;

template<class...Args>
auto construct_from( Args&&... args )
return deduce_return_t [&](auto ret)
using R=typename decltype(ret)::type;
return R std::forward<Args>(args)... ;
;



so now I can do



std::vector<int> v = construct_from( 1, 2, 3 );


and it works.



Of course, why not just do 1,2,3? Well, 1,2,3 isn't an expression.



std::vector<std::vector<int>> v;
v.emplace_back( construct_from(1,2,3) );


which, admittedly, require a bit more wizardry: Live example. (I have to make the deduce return do a SFINAE check of F, then make the F be SFINAE friendly, and I have to block std::initializer_list in deduce_return_t operator T.)







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 13 '18 at 15:49

























answered Nov 12 '18 at 21:26









Yakk - Adam NevraumontYakk - Adam Nevraumont

184k19191376




184k19191376












  • Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

    – Massimiliano
    Nov 12 '18 at 22:28






  • 5





    The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

    – Justin
    Nov 12 '18 at 22:42






  • 1





    That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

    – llllllllll
    Nov 12 '18 at 23:59






  • 3





    @lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 0:13






  • 1





    @lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 2:26

















  • Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

    – Massimiliano
    Nov 12 '18 at 22:28






  • 5





    The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

    – Justin
    Nov 12 '18 at 22:42






  • 1





    That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

    – llllllllll
    Nov 12 '18 at 23:59






  • 3





    @lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 0:13






  • 1





    @lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

    – Yakk - Adam Nevraumont
    Nov 13 '18 at 2:26
















Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

– Massimiliano
Nov 12 '18 at 22:28





Very interesting answer, and I learned a new trick so thank you very much! I had to add a template deduction guideline to make your example compile, but other than that it works like a charm!

– Massimiliano
Nov 12 '18 at 22:28




5




5





The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

– Justin
Nov 12 '18 at 22:42





The && qualifier on the operator T() is a great touch; it helps avoid the poor interaction with auto by causing a compilation error if auto is misused here.

– Justin
Nov 12 '18 at 22:42




1




1





That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

– llllllllll
Nov 12 '18 at 23:59





That's very impressive, could you point me to some reference/talk to the idea in the example? or maybe it's original :) ...

– llllllllll
Nov 12 '18 at 23:59




3




3





@lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

– Yakk - Adam Nevraumont
Nov 13 '18 at 0:13





@lili Which idea? I count 5: Using operator T to deduce return types? Using tags to pass the deduced type to a lambda? Using conversion operators to roll-your-own placement object construction? Connecting all 4?

– Yakk - Adam Nevraumont
Nov 13 '18 at 0:13




1




1





@lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

– Yakk - Adam Nevraumont
Nov 13 '18 at 2:26





@lili Tha "more advanced way" example is, as I said, just 4 or so ideas glued together. I did the gluing on the fly for this post, but I certainly have seen many pairs or even triplets of those used together. It is a bunch of reasonably obscure techniques (as tootsie complains), but nothing novel.

– Yakk - Adam Nevraumont
Nov 13 '18 at 2:26













29














Stephan T. Lavavej explained the case he was talking about in a tweet:




The case I was thinking of is where you can take the address of an overloaded/templated function and if it’s being used to initialize a variable of a specific type, that will disambiguate which one you want. (There’s a list of what disambiguates.)




we can see examples of this from cppreference page on Address of overloaded function, I have excepted a few below:



int f(int) return 1; 
int f(double) return 2;

void g( int(&f1)(int), int(*f2)(double) )

int main()
g(f, f); // selects int f(int) for the 1st argument
// and int f(double) for the second

auto foo = () -> int (*)(int)
return f; // selects int f(int)
;

auto p = static_cast<int(*)(int)>(f); // selects int f(int)



Michael Park adds:




It's not limited to initializing a concrete type, either. It could also infer just from the number of arguments




and provides this live example:



void overload(int, int) 
void overload(int, int, int)

template <typename T1, typename T2,
typename A1, typename A2>
void f(void (*)(T1, T2), A1&&, A2&&)

template <typename T1, typename T2, typename T3,
typename A1, typename A2, typename A3>
void f(void (*)(T1, T2, T3), A1&&, A2&&, A3&&)

int main ()
f(&overload, 1, 2);



which I elaborate a little more here.






share|improve this answer




















  • 4





    We could also describe this as: cases where the type of an expression depends on the context?

    – M.M
    Nov 12 '18 at 23:56















29














Stephan T. Lavavej explained the case he was talking about in a tweet:




The case I was thinking of is where you can take the address of an overloaded/templated function and if it’s being used to initialize a variable of a specific type, that will disambiguate which one you want. (There’s a list of what disambiguates.)




we can see examples of this from cppreference page on Address of overloaded function, I have excepted a few below:



int f(int) return 1; 
int f(double) return 2;

void g( int(&f1)(int), int(*f2)(double) )

int main()
g(f, f); // selects int f(int) for the 1st argument
// and int f(double) for the second

auto foo = () -> int (*)(int)
return f; // selects int f(int)
;

auto p = static_cast<int(*)(int)>(f); // selects int f(int)



Michael Park adds:




It's not limited to initializing a concrete type, either. It could also infer just from the number of arguments




and provides this live example:



void overload(int, int) 
void overload(int, int, int)

template <typename T1, typename T2,
typename A1, typename A2>
void f(void (*)(T1, T2), A1&&, A2&&)

template <typename T1, typename T2, typename T3,
typename A1, typename A2, typename A3>
void f(void (*)(T1, T2, T3), A1&&, A2&&, A3&&)

int main ()
f(&overload, 1, 2);



which I elaborate a little more here.






share|improve this answer




















  • 4





    We could also describe this as: cases where the type of an expression depends on the context?

    – M.M
    Nov 12 '18 at 23:56













29












29








29







Stephan T. Lavavej explained the case he was talking about in a tweet:




The case I was thinking of is where you can take the address of an overloaded/templated function and if it’s being used to initialize a variable of a specific type, that will disambiguate which one you want. (There’s a list of what disambiguates.)




we can see examples of this from cppreference page on Address of overloaded function, I have excepted a few below:



int f(int) return 1; 
int f(double) return 2;

void g( int(&f1)(int), int(*f2)(double) )

int main()
g(f, f); // selects int f(int) for the 1st argument
// and int f(double) for the second

auto foo = () -> int (*)(int)
return f; // selects int f(int)
;

auto p = static_cast<int(*)(int)>(f); // selects int f(int)



Michael Park adds:




It's not limited to initializing a concrete type, either. It could also infer just from the number of arguments




and provides this live example:



void overload(int, int) 
void overload(int, int, int)

template <typename T1, typename T2,
typename A1, typename A2>
void f(void (*)(T1, T2), A1&&, A2&&)

template <typename T1, typename T2, typename T3,
typename A1, typename A2, typename A3>
void f(void (*)(T1, T2, T3), A1&&, A2&&, A3&&)

int main ()
f(&overload, 1, 2);



which I elaborate a little more here.






share|improve this answer















Stephan T. Lavavej explained the case he was talking about in a tweet:




The case I was thinking of is where you can take the address of an overloaded/templated function and if it’s being used to initialize a variable of a specific type, that will disambiguate which one you want. (There’s a list of what disambiguates.)




we can see examples of this from cppreference page on Address of overloaded function, I have excepted a few below:



int f(int) return 1; 
int f(double) return 2;

void g( int(&f1)(int), int(*f2)(double) )

int main()
g(f, f); // selects int f(int) for the 1st argument
// and int f(double) for the second

auto foo = () -> int (*)(int)
return f; // selects int f(int)
;

auto p = static_cast<int(*)(int)>(f); // selects int f(int)



Michael Park adds:




It's not limited to initializing a concrete type, either. It could also infer just from the number of arguments




and provides this live example:



void overload(int, int) 
void overload(int, int, int)

template <typename T1, typename T2,
typename A1, typename A2>
void f(void (*)(T1, T2), A1&&, A2&&)

template <typename T1, typename T2, typename T3,
typename A1, typename A2, typename A3>
void f(void (*)(T1, T2, T3), A1&&, A2&&, A3&&)

int main ()
f(&overload, 1, 2);



which I elaborate a little more here.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 13 '18 at 14:12

























answered Nov 12 '18 at 23:51









Shafik YaghmourShafik Yaghmour

126k23324535




126k23324535







  • 4





    We could also describe this as: cases where the type of an expression depends on the context?

    – M.M
    Nov 12 '18 at 23:56












  • 4





    We could also describe this as: cases where the type of an expression depends on the context?

    – M.M
    Nov 12 '18 at 23:56







4




4





We could also describe this as: cases where the type of an expression depends on the context?

– M.M
Nov 12 '18 at 23:56





We could also describe this as: cases where the type of an expression depends on the context?

– M.M
Nov 12 '18 at 23:56











20














I believe in static casting of overloaded functions the flow goes the opposite direction as in usual overload resolution. So one of those is backwards, I guess.






share|improve this answer


















  • 6





    I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

    – Yakk - Adam Nevraumont
    Nov 12 '18 at 22:08















20














I believe in static casting of overloaded functions the flow goes the opposite direction as in usual overload resolution. So one of those is backwards, I guess.






share|improve this answer


















  • 6





    I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

    – Yakk - Adam Nevraumont
    Nov 12 '18 at 22:08













20












20








20







I believe in static casting of overloaded functions the flow goes the opposite direction as in usual overload resolution. So one of those is backwards, I guess.






share|improve this answer













I believe in static casting of overloaded functions the flow goes the opposite direction as in usual overload resolution. So one of those is backwards, I guess.







share|improve this answer












share|improve this answer



share|improve this answer










answered Nov 12 '18 at 21:19









jbapplejbapple

2,6511630




2,6511630







  • 6





    I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

    – Yakk - Adam Nevraumont
    Nov 12 '18 at 22:08












  • 6





    I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

    – Yakk - Adam Nevraumont
    Nov 12 '18 at 22:08







6




6





I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

– Yakk - Adam Nevraumont
Nov 12 '18 at 22:08





I believe this is correct. And it is when you pass a function name to a function pointer type; type information flows from the context of the expression (the type you are assigning to/constructing/etc) backwards into the name of the function to determine which overload is chosen.

– Yakk - Adam Nevraumont
Nov 12 '18 at 22:08

















draft saved

draft discarded
















































Thanks for contributing an answer to Stack Overflow!


  • 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%2fstackoverflow.com%2fquestions%2f53270242%2fwhen-does-type-information-flow-backwards-in-c%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

Use pre created SQLite database for Android project in kotlin

Darth Vader #20

Ondo