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












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;

}





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







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
    yesterday






  • 2





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

    – Aconcagua
    yesterday






  • 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
    yesterday
















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;

}





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







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
    yesterday






  • 2





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

    – Aconcagua
    yesterday






  • 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
    yesterday














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;

}





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







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




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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited yesterday









Fabio Turati

2,63452341




2,63452341










asked yesterday









Soulimane MammarSoulimane Mammar

553414




553414








  • 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
    yesterday






  • 2





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

    – Aconcagua
    yesterday






  • 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
    yesterday














  • 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
    yesterday






  • 2





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

    – Aconcagua
    yesterday






  • 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
    yesterday








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
yesterday





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
yesterday




2




2





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

– Aconcagua
yesterday





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

– Aconcagua
yesterday




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
yesterday





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
yesterday












1 Answer
1






active

oldest

votes


















8














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
    yesterday






  • 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
    yesterday








  • 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
    yesterday






  • 2





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

    – geza
    yesterday






  • 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
    yesterday











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









8














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
    yesterday






  • 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
    yesterday








  • 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
    yesterday






  • 2





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

    – geza
    yesterday






  • 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
    yesterday
















8














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
    yesterday






  • 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
    yesterday








  • 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
    yesterday






  • 2





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

    – geza
    yesterday






  • 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
    yesterday














8












8








8







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 yesterday

























answered yesterday









eerorikaeerorika

87.3k663134




87.3k663134








  • 2





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

    – Ben Voigt
    yesterday






  • 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
    yesterday








  • 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
    yesterday






  • 2





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

    – geza
    yesterday






  • 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
    yesterday














  • 2





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

    – Ben Voigt
    yesterday






  • 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
    yesterday








  • 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
    yesterday






  • 2





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

    – geza
    yesterday






  • 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
    yesterday








2




2





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

– Ben Voigt
yesterday





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

– Ben Voigt
yesterday




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
yesterday







@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
yesterday






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
yesterday





@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
yesterday




2




2





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

– geza
yesterday





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

– geza
yesterday




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
yesterday





@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
yesterday




















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

數位音樂下載

Image
數位音樂下載 為非以「實體」方式來販賣音樂的相關產品，而使用數位格式如mp3、AAC等文件格式來進行銷售販賣的一种音乐产业形式。著名的數位音樂下載服務商有iTunes Store、RecoChoku、Google Play音乐和微软Zune等。数字音乐下载在二十一世纪初一度风靡全球， [1] [2] 使得传统唱片产业走向衰落，但其自身也在2010年代流媒体音乐服务如Apple Music、Spotify等的挤压下迅速失去市场份额。 [3] [4] 数字音乐下载有便于携带、传播迅速、制作简单成本低等优点，与流媒体音乐相比也能更好保障音乐人权益； [5] 但它同时很可能带来侵犯版权和滥用的情形， [6] 也给音乐产业带来了诸多不利影响。数字音乐下载为音乐人和乐迷提供了更加便捷直接的交流渠道，也一定程度上推动了网络音乐人的出现和独立音乐的迅速发展。 [7] 目录 1 历史 1.1 技术积淀（1987-2000） 1.2 出现与兴起（2000-2004） 1.3 唱片市场的颠覆者（2004-2007） 1.4 巅峰和衰落（2005-2013） 1.5 摇摇欲坠的现状与不可预知的明天（2014至今） 2 主要文件格式 2.1 PCM编码格式 2.1.1 WAV 2.1.2 APE 2.1.3 FLAC 2.2 苹果推出的无损文件格式 2.2.1 AIFF 2.2.2 ALAC 2.3 有损压缩格式 2.3.1 MP3 2.3.2 AAC 3 主要市场 3.1 iTunes Store 3.2 Google Play音乐商店 3.3 亚马逊音乐商店 3.4 部分其他音乐商店 4 影响与评价 4.1 对音乐产业的影响 4.2 对科技行业的影响 4.3 正面评价 4.4 负面评价 4.4.1 侵权问题 4.4.2 经营模式不明晰 4.4.3 不适应移动时代 4.5 文化现象 5 延伸阅读 6 参考资料 历史 苹果iTunes+iPod的软硬件搭配让数字音...
Read more

When can things happen in Etherscan, such as the picture below?

Image
2 I don't know why balance of the address is 0. when can this situation? etherscan balances share | improve this question asked yesterday Ru Hi Ru Hi 11 1 New contributor Ru Hi is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct. add a comment  |  ...
Read more

格利澤436b

Image
格利泽436b 太陽系外行星 太陽系外行星列表 艺术家笔下的格利泽436b 母恆星 母恆星 Gliese 436 星座 獅子座 赤經 ( α ) 11 h  42 m  11.0941 s [1] 赤緯 ( δ ) +26° 42′ 23.652″ [1] 距離 33.4 ly (10.2 pc) 光譜類型 M2.5 V [1] 軌道參數 半长轴 ( a ) 0.0291±0.0004 [2] AU 軌道離心率 ( e ) 0.150±0.012 [2] 公轉週期 ( P ) 2.643904±0.000005 [3] d (0.00723849 y) 軌道傾角 ( i ) 85.8 +0.21 −0.25 [3] ° 角距 ( θ ) 2.794 mas 近星點時間 ( T 0 ) 2,451,551.716 ±0.01 JD 半振幅 ( K ) 18.68±0.8 m/s 物理性质 质量 ( m ) 22.2±1.0 [2] M ⊕ 半徑 ( r ) 4.327±0.183 [2] [4] R ⊕ 密度 ( ρ ) 1.51 g cm -3 表面重力 ( g ) 1.18 g 溫度 ( T ) 712±36 [2] K 發現 發現時間 2004 發現者 巴特勒、沃格特、 馬西 et al. 發現方法 徑向速度、凌日法 發現地點 美國加利福尼亞州 發表論文 出版 其他名稱 Ross 905 b, GJ 436 b, [5] LTT 13213 b, GCTP 2704.10 b, LHS 310, AC+27:28217 b, Vyssotsky 616 b, HIP 57087 b, GEN# +9.80120068 b, LP 319-75 b, G 121-7 b, LSPM J1142+2642 b, 1RXS J114211.9+264328 b, ASCC 683818 b, G 147-68 b, UCAC2 41198281 b, BP...
Read more