Why do compilers behave differently when static_cast(ing) a function to void*? The 2019 Stack Overflow Developer Survey Results Are InWhat are the differences between a pointer variable and a reference variable in C++?Why use static_cast<int>(x) instead of (int)x?When should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?Static constant string (class member)Why does flowing off the end of a non-void function without returning a value not produce a compiler error?Why do we need virtual functions in C++?What does int argc, char *argv[] mean?Why is the new operator allowed to return *void to every pointer-type?Implementation of static_cast operator and it's limitsWhy deleting void* is UB rather than compilation error?

How to charge AirPods to keep battery healthy?

Slides for 30 min~1 hr Skype tenure track application interview

What is the light source in the black hole images?

Why was M87 targeted for the Event Horizon Telescope instead of Sagittarius A*?

What is preventing me from simply constructing a hash that's lower than the current target?

What is this sharp, curved notch on my knife for?

What is the motivation for a law requiring 2 parties to consent for recording a conversation

What do hard-Brexiteers want with respect to the Irish border?

If I can cast sorceries at instant speed, can I use sorcery-speed activated abilities at instant speed?

Is one supposed to eat the zero'ah (shank bone) from the Seder plate?

Accepted by European university, rejected by all American ones I applied to? Possible reasons?

Is it ok to offer lower paid work as a trial period before negotiating for a full-time job?

What is this business jet?

Kerning for subscripts of sigma?

Button changing its text & action. Good or terrible?

Did any laptop computers have a built-in 5 1/4 inch floppy drive?

Can we generate random numbers using irrational numbers like π and e?

Pokemon Turn Based battle (Python)

How come people say “Would of”?

Why not take a picture of a closer black hole?

Loose spokes after only a few rides

Is it possible for absolutely everyone to attain enlightenment?

Geography at the pixel level

Can you cast a spell on someone in the Ethereal Plane, if you are on the Material Plane and have the True Seeing spell active?



Why do compilers behave differently when static_cast(ing) a function to void*?



The 2019 Stack Overflow Developer Survey Results Are InWhat are the differences between a pointer variable and a reference variable in C++?Why use static_cast<int>(x) instead of (int)x?When should static_cast, dynamic_cast, const_cast and reinterpret_cast be used?Static constant string (class member)Why does flowing off the end of a non-void function without returning a value not produce a compiler error?Why do we need virtual functions in C++?What does int argc, char *argv[] mean?Why is the new operator allowed to return *void to every pointer-type?Implementation of static_cast operator and it's limitsWhy deleting void* is UB rather than compilation error?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;








9















The following code compiles without any error in VSC++2017 and doesn't compile in gcc 7.3.0 (error: invalid static_cast from type ‘int(int)’ to type ‘void*’
void* p = static_cast<void*>(func)
)



#include <iostream>

int func(int x) return 2 * x;

int main()

void* p = static_cast<void*>(func);
return 0;










share|improve this question



















  • 1





    Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

    – user4581301
    Mar 24 at 0:27






  • 2





    @user4581301 Not really – the other question is about C, and there might be differences in the languages...

    – Aconcagua
    Mar 24 at 0:35






  • 1





    While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

    – doug
    Mar 24 at 0:57

















9















The following code compiles without any error in VSC++2017 and doesn't compile in gcc 7.3.0 (error: invalid static_cast from type ‘int(int)’ to type ‘void*’
void* p = static_cast<void*>(func)
)



#include <iostream>

int func(int x) return 2 * x;

int main()

void* p = static_cast<void*>(func);
return 0;










share|improve this question



















  • 1





    Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

    – user4581301
    Mar 24 at 0:27






  • 2





    @user4581301 Not really – the other question is about C, and there might be differences in the languages...

    – Aconcagua
    Mar 24 at 0:35






  • 1





    While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

    – doug
    Mar 24 at 0:57













9












9








9


1






The following code compiles without any error in VSC++2017 and doesn't compile in gcc 7.3.0 (error: invalid static_cast from type ‘int(int)’ to type ‘void*’
void* p = static_cast<void*>(func)
)



#include <iostream>

int func(int x) return 2 * x;

int main()

void* p = static_cast<void*>(func);
return 0;










share|improve this question
















The following code compiles without any error in VSC++2017 and doesn't compile in gcc 7.3.0 (error: invalid static_cast from type ‘int(int)’ to type ‘void*’
void* p = static_cast<void*>(func)
)



#include <iostream>

int func(int x) return 2 * x;

int main()

void* p = static_cast<void*>(func);
return 0;







c++ function-pointers void-pointers static-cast






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 24 at 0:26









Fabio Turati

2,64552341




2,64552341










asked Mar 24 at 0:18









Soulimane MammarSoulimane Mammar

552414




552414







  • 1





    Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

    – user4581301
    Mar 24 at 0:27






  • 2





    @user4581301 Not really – the other question is about C, and there might be differences in the languages...

    – Aconcagua
    Mar 24 at 0:35






  • 1





    While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

    – doug
    Mar 24 at 0:57












  • 1





    Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

    – user4581301
    Mar 24 at 0:27






  • 2





    @user4581301 Not really – the other question is about C, and there might be differences in the languages...

    – Aconcagua
    Mar 24 at 0:35






  • 1





    While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

    – doug
    Mar 24 at 0:57







1




1





Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

– user4581301
Mar 24 at 0:27





Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes.

– user4581301
Mar 24 at 0:27




2




2





@user4581301 Not really – the other question is about C, and there might be differences in the languages...

– Aconcagua
Mar 24 at 0:35





@user4581301 Not really – the other question is about C, and there might be differences in the languages...

– Aconcagua
Mar 24 at 0:35




1




1





While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

– doug
Mar 24 at 0:57





While function pointers are different animals than object pointers, most incompatibilities occur when the sizeof() the two differ. If they are the same you can usually safely convert back and forth to a void*. Even so, while it may work, it's not portable and just one of those things best avoided.

– doug
Mar 24 at 0:57












1 Answer
1






active

oldest

votes


















9














Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.



Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.




On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:



void* p = reinterpret_cast<void*>(func);


But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).



Standard quote:




[expr.reinterpret.cast]



Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning
of such a conversion is implementation-defined, except that if an implementation supports conversions in both
directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification,
shall yield the original pointer value.




Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.






share|improve this answer




















  • 2





    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

    – Ben Voigt
    Mar 24 at 0:43






  • 1





    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

    – eerorika
    Mar 24 at 2:07







  • 2





    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

    – Peter
    Mar 24 at 5:15






  • 2





    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

    – geza
    Mar 24 at 11:19






  • 2





    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

    – geza
    Mar 24 at 13:31











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%2f55319602%2fwhy-do-compilers-behave-differently-when-static-casting-a-function-to-void%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









9














Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.



Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.




On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:



void* p = reinterpret_cast<void*>(func);


But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).



Standard quote:




[expr.reinterpret.cast]



Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning
of such a conversion is implementation-defined, except that if an implementation supports conversions in both
directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification,
shall yield the original pointer value.




Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.






share|improve this answer




















  • 2





    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

    – Ben Voigt
    Mar 24 at 0:43






  • 1





    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

    – eerorika
    Mar 24 at 2:07







  • 2





    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

    – Peter
    Mar 24 at 5:15






  • 2





    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

    – geza
    Mar 24 at 11:19






  • 2





    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

    – geza
    Mar 24 at 13:31















9














Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.



Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.




On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:



void* p = reinterpret_cast<void*>(func);


But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).



Standard quote:




[expr.reinterpret.cast]



Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning
of such a conversion is implementation-defined, except that if an implementation supports conversions in both
directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification,
shall yield the original pointer value.




Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.






share|improve this answer




















  • 2





    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

    – Ben Voigt
    Mar 24 at 0:43






  • 1





    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

    – eerorika
    Mar 24 at 2:07







  • 2





    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

    – Peter
    Mar 24 at 5:15






  • 2





    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

    – geza
    Mar 24 at 11:19






  • 2





    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

    – geza
    Mar 24 at 13:31













9












9








9







Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.



Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.




On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:



void* p = reinterpret_cast<void*>(func);


But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).



Standard quote:




[expr.reinterpret.cast]



Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning
of such a conversion is implementation-defined, except that if an implementation supports conversions in both
directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification,
shall yield the original pointer value.




Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.






share|improve this answer















Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.



Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.




On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:



void* p = reinterpret_cast<void*>(func);


But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).



Standard quote:




[expr.reinterpret.cast]



Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning
of such a conversion is implementation-defined, except that if an implementation supports conversions in both
directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification,
shall yield the original pointer value.




Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.







share|improve this answer














share|improve this answer



share|improve this answer








edited Mar 24 at 2:36

























answered Mar 24 at 0:39









eerorikaeerorika

89.9k664136




89.9k664136







  • 2





    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

    – Ben Voigt
    Mar 24 at 0:43






  • 1





    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

    – eerorika
    Mar 24 at 2:07







  • 2





    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

    – Peter
    Mar 24 at 5:15






  • 2





    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

    – geza
    Mar 24 at 11:19






  • 2





    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

    – geza
    Mar 24 at 13:31












  • 2





    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

    – Ben Voigt
    Mar 24 at 0:43






  • 1





    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

    – eerorika
    Mar 24 at 2:07







  • 2





    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

    – Peter
    Mar 24 at 5:15






  • 2





    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

    – geza
    Mar 24 at 11:19






  • 2





    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

    – geza
    Mar 24 at 13:31







2




2





POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

– Ben Voigt
Mar 24 at 0:43





POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make dlsym work.

– Ben Voigt
Mar 24 at 0:43




1




1





@Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

– eerorika
Mar 24 at 2:07






@Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard.

– eerorika
Mar 24 at 2:07





2




2





@eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

– Peter
Mar 24 at 5:15





@eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not.

– Peter
Mar 24 at 5:15




2




2





@Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

– geza
Mar 24 at 11:19





@Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages".

– geza
Mar 24 at 11:19




2




2





@SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

– geza
Mar 24 at 13:31





@SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work).

– geza
Mar 24 at 13:31



















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%2f55319602%2fwhy-do-compilers-behave-differently-when-static-casting-a-function-to-void%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

Moe incest case Sentencing See also References Navigation menu"'Australian Josef Fritzl' fathered four children by daughter""Small town recoils in horror at 'Australian Fritzl' incest case""Victorian rape allegations echo Fritzl case - Just In (Australian Broadcasting Corporation)""Incest father jailed for 22 years""'Australian Fritzl' sentenced to 22 years in prison for abusing daughter for three decades""RSJ v The Queen"

Who is our nearest planetary neighbor, on average?Santa Claus flies to the South PoleSeven Spheres of Unequal Mass, a weighing problem with a twistDescribe a large integerFast Mental Calculation of $7.5^7$Math in Space (without the help of celebrities)Find the value of $bigstar$: Puzzle 8 - InequalityWho drinks beer while running anyway?A Crucial DeliveryRanking And AverageHow long will my money last at roulette?

Daza language Contents Vocabulary Phonology References External links Navigation menudaza1242Daza"Dazaga"eeee178086576