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

How did Captain America manage to do this?

Image
2 How does Captain America lift Thor's hammer? In Avengers: Age of Ultron , he is not worthy but how he is worthy in this film. plot-explanation marvel-cinematic-universe avengers-age-of-ultron avengers-endgame share | improve this question edited 19 mins ago A J ♦ 42.7k 16 229 246 asked 39 mins ago Andi AR Andi AR 325 1 4 14
Read more

迪纳利

Image
迪纳利峰 位于迪纳利国家公园和保留区的迪纳利峰（旧名麦金利峰） 最高点 海拔 20,237英尺（6,168米）   NGVD 29 . [1] [2] 相對高度 20,073英尺（6,118米） 列表 各洲最高峰列表 特独立山峰 各国最高点列表 美国最高点  排名第一 [3] 坐标 63°04′10″N 151°00′27″W  /  63.06944°N 151.00750°W  / 63.06944; -151.00750  ( Mount McKinley ) 坐标： 63°04′10″N 151°00′27″W  /  63.06944°N 151.00750°W  / 63.06944; -151.00750  ( Mount McKinley )   地理 位置   美國阿拉斯加州迪纳利自治市镇 迪纳利国家公园和保留区 山脈 阿拉斯加山脉 攀山 首次登頂 （ 英语 ： First ascent ） 1913年6月7日 哈德逊·史塔克 哈里·卡斯坦斯 沃尔特·哈珀 罗伯特·塔特姆 最簡路線 西坡路线（攀登冰川/雪） 迪纳利 （北阿萨巴斯卡语支、 英语： Denali ， / d ᵻ ˈ n ɑː l i / ，直译“高山”），1917年至2015年官方名称为 麦金利山 （另译作 麦金利峰 ， 英语： Mount McKinley ），位于阿拉斯加州东南部、阿拉斯加山脉中段，海拔6194米，是北美洲最高峰，也是美国的最高峰。它的俄语名称是 Большая Гора ， 罗马化：Bolshaya Gora ，意思是“大山”。 迪纳利山地区拥有变幻莫测的高山风、典型的北极植被以及野生动植物。这里大部分地区终年积雪，山间经常浓雾不断，雾气在皑皑白雪中缭绕弥漫时，几百米之外的景物便不可见。夏季，迪纳利山的青青山坡上鲜花盛开，紫色的杜鹃和精巧的铃状石南花随处可见。迪纳利山还是世界登山爱好者的汇集之地。每年5月到7月有数百人登山，只有一半不到的人能登顶成功。一次登山约花3个星期。 2015年8月31日，美國政府宣佈將山名由“麦金利山”改回原名“迪纳利山”。美國內政部發表聲
Read more

南乌拉尔铁路局

Image
南乌拉尔铁路局 Южно-Уральская железная дорога 成立 1934年1月4日 国家   蘇聯（1934年—1991年）   俄羅斯（1991年—） 总部 车里雅宾斯克 隶属 俄罗斯铁路股份公司 路局代码 80 铁路里程 4,934.9公里 奖项 网址 http://yuzd.rzd.ru/ 查 论 编 南乌拉尔铁路局 （俄语： Южно-Уральская железная дорога ， 羅馬化： Yuzhno-Uralskaya zheleznaya doroga ，简称 ЮУЖД ）是俄罗斯铁路股份公司属下的铁路管理局之一，总部位于车里雅宾斯克，负责管辖俄罗斯联邦乌拉尔南部地区的铁路系统，范围包括奥伦堡州、车里雅宾斯克州、库尔干州的大部分铁路，以及萨马拉州、斯维尔德洛夫斯克州、巴什科尔托斯坦共和国的少部分铁路，并有部分铁路延伸至或穿过哈萨克斯坦境内。南乌拉尔铁路局的营业里程为4,934.9公里，与伏尔加铁路局、古比雪夫铁路局、斯维尔德洛夫斯克铁路局、西西伯利亚铁路局相邻，并与南方的哈萨克斯坦铁路连接。 外部链接 （俄文） Южно-Уральская железная дорога — филиал ОАО РЖД （俄文） 南乌拉尔铁路局管辖路线图（一） （俄文） 南乌拉尔铁路局管辖路线图（二） 查 论 编 俄罗斯铁路（集团）股份公司 十月铁路局 · 莫斯科铁路局 · 北高加索铁路局 · 高尔基铁路局 · 古比雪夫铁路局 · 北方铁路局 · 伏尔加铁路局 · 东南铁路局 · 斯维尔德洛夫斯克铁路局 · 南乌拉尔铁路局 · 西西伯利亚铁路局 · 克拉斯诺亚尔斯克铁路局 · 东西伯利亚铁路局 · 后贝加尔铁路局 · 远东铁路局 · 加里宁格勒铁路局 This page is only for reference, If you need detailed information, please check here
Read more