When does type information flow backwards in C++?
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
add a comment |
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
pattern matching partial specialization and destructuring assignments.
– v.oddou
Nov 13 '18 at 5:11
add a comment |
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
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
c++ types language-lawyer c++17 type-deduction
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
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.)
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 theoperator T()
is a great touch; it helps avoid the poor interaction withauto
by causing a compilation error ifauto
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
|
show 7 more comments
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.
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
add a comment |
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.
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
add a comment |
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
);
);
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%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
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.)
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 theoperator T()
is a great touch; it helps avoid the poor interaction withauto
by causing a compilation error ifauto
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
|
show 7 more comments
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.)
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 theoperator T()
is a great touch; it helps avoid the poor interaction withauto
by causing a compilation error ifauto
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
|
show 7 more comments
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.)
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.)
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 theoperator T()
is a great touch; it helps avoid the poor interaction withauto
by causing a compilation error ifauto
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
|
show 7 more comments
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 theoperator T()
is a great touch; it helps avoid the poor interaction withauto
by causing a compilation error ifauto
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
|
show 7 more comments
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
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%2fstackoverflow.com%2fquestions%2f53270242%2fwhen-does-type-information-flow-backwards-in-c%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
pattern matching partial specialization and destructuring assignments.
– v.oddou
Nov 13 '18 at 5:11