Avoid or warn on implicit conversion from const char* to bool in GCC












22















Consider the following code:



void foo(bool parameter) {

    std::cout << parameter << "n";

}



int main() {

    foo("const char *argument");

}


I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo.



But GCC implicitly converts it. I tried -Wall, -Wextra, and -Wpedantic, but none of these issue a warning. Is there a flag that could catch such an implicit conversion (invalid parameter type)?



Ignore the fact that the function has an argument of type bool, which some may see as bad code style. I can't refactor that part.



The standard just mentions such an implicit conversion will occur:




A prvalue of integral, floating-point, unscoped enumeration, pointer, and pointer-to-member types can be converted to a prvalue of type bool.




I know such behavior is very convenient in if (ptr) statements, but for me, in the case of passing parameters, it is clearly wrong and a source of bugs.






c++ gcc implicit-conversion gcc-warning







share|improve this question




















  • 7





    ...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

    – Scheff
    15 hours ago






  • 2





    a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

    – user463035818
    15 hours ago






  • 1





    @user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

    – Yksisarvinen
    15 hours ago











  • @Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

    – user463035818
    15 hours ago











  • You may have another overload void foo(const char *parameter).

    – Hi I'm Frogatto
    15 hours ago
















22















Consider the following code:



void foo(bool parameter) {

    std::cout << parameter << "n";

}



int main() {

    foo("const char *argument");

}


I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo.



But GCC implicitly converts it. I tried -Wall, -Wextra, and -Wpedantic, but none of these issue a warning. Is there a flag that could catch such an implicit conversion (invalid parameter type)?



Ignore the fact that the function has an argument of type bool, which some may see as bad code style. I can't refactor that part.



The standard just mentions such an implicit conversion will occur:




A prvalue of integral, floating-point, unscoped enumeration, pointer, and pointer-to-member types can be converted to a prvalue of type bool.




I know such behavior is very convenient in if (ptr) statements, but for me, in the case of passing parameters, it is clearly wrong and a source of bugs.






c++ gcc implicit-conversion gcc-warning







share|improve this question




















  • 7





    ...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

    – Scheff
    15 hours ago






  • 2





    a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

    – user463035818
    15 hours ago






  • 1





    @user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

    – Yksisarvinen
    15 hours ago











  • @Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

    – user463035818
    15 hours ago











  • You may have another overload void foo(const char *parameter).

    – Hi I'm Frogatto
    15 hours ago














22












22








22


2






Consider the following code:



void foo(bool parameter) {

    std::cout << parameter << "n";

}



int main() {

    foo("const char *argument");

}


I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo.



But GCC implicitly converts it. I tried -Wall, -Wextra, and -Wpedantic, but none of these issue a warning. Is there a flag that could catch such an implicit conversion (invalid parameter type)?



Ignore the fact that the function has an argument of type bool, which some may see as bad code style. I can't refactor that part.



The standard just mentions such an implicit conversion will occur:




A prvalue of integral, floating-point, unscoped enumeration, pointer, and pointer-to-member types can be converted to a prvalue of type bool.




I know such behavior is very convenient in if (ptr) statements, but for me, in the case of passing parameters, it is clearly wrong and a source of bugs.






c++ gcc implicit-conversion gcc-warning







share|improve this question
















Consider the following code:



void foo(bool parameter) {

    std::cout << parameter << "n";

}



int main() {

    foo("const char *argument");

}


I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo.



But GCC implicitly converts it. I tried -Wall, -Wextra, and -Wpedantic, but none of these issue a warning. Is there a flag that could catch such an implicit conversion (invalid parameter type)?



Ignore the fact that the function has an argument of type bool, which some may see as bad code style. I can't refactor that part.



The standard just mentions such an implicit conversion will occur:




A prvalue of integral, floating-point, unscoped enumeration, pointer, and pointer-to-member types can be converted to a prvalue of type bool.




I know such behavior is very convenient in if (ptr) statements, but for me, in the case of passing parameters, it is clearly wrong and a source of bugs.






c++ gcc implicit-conversion gcc-warning




c++ gcc implicit-conversion gcc-warning






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited 11 mins ago









Cody Gray♦

192k35377464




192k35377464










asked 15 hours ago









Szymon ZimnowodaSzymon Zimnowoda

1215




1215








  • 7





    ...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

    – Scheff
    15 hours ago






  • 2





    a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

    – user463035818
    15 hours ago






  • 1





    @user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

    – Yksisarvinen
    15 hours ago











  • @Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

    – user463035818
    15 hours ago











  • You may have another overload void foo(const char *parameter).

    – Hi I'm Frogatto
    15 hours ago














  • 7





    ...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

    – Scheff
    15 hours ago






  • 2





    a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

    – user463035818
    15 hours ago






  • 1





    @user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

    – Yksisarvinen
    15 hours ago











  • @Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

    – user463035818
    15 hours ago











  • You may have another overload void foo(const char *parameter).

    – Hi I'm Frogatto
    15 hours ago








7




7





...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

– Scheff
15 hours ago





...and good for bad surprises: If there is a function which accepts std::string and another which accepts bool instead, guess which one is chosen for "const char *argument". (Spoiler alert: yes the second - and it drove me crazy until I got a clue.) ;-)

– Scheff
15 hours ago




2




2





a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

– user463035818
15 hours ago





a bit offtopic, but I am puzzled why you think having a bool parameter would be bad coding-style..

– user463035818
15 hours ago




1




1





@user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

– Yksisarvinen
15 hours ago





@user463035818 "Uncle Bob said so" could be a good reason. He argues that function with bool parameter never has a single responsibility. Uncle Bob has many strong opinions about coding though.

– Yksisarvinen
15 hours ago













@Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

– user463035818
15 hours ago





@Yksisarvinen you mean that there should be a fooTrue and a fooFalse instead? Hum, maybe i could agree in some cases, but not in general, though if Bob said so there must be some truth to it

– user463035818
15 hours ago













You may have another overload void foo(const char *parameter).

– Hi I'm Frogatto
15 hours ago





You may have another overload void foo(const char *parameter).

– Hi I'm Frogatto
15 hours ago












2 Answers
2






active

oldest

votes


















25














You could declare an overload of foo for pointers as deleted:



template <class T>

void foo(T*) = delete;


Or better yet, as @Ted comments, simply declare a vanilla overload to not compile any implicit conversions:



template <class T>

void foo(T) = delete;





share|improve this answer





















  • 2





    Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

    – Stack Danny
    15 hours ago






  • 3





    Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

    – Arne Vogel
    15 hours ago






  • 2





    ... or just void foo(T) = delete; to delete all implicit conversions.

    – Ted Lyngmo
    14 hours ago



















15















I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo. ... I tried -Wall, -Wextra, and -Wpedantic




You need to add -Wconversion to your compiler flags. Note that seems to work with clang (recent or older version), but not with gcc.



If this triggers too many warnings that you don't want to handle, you can selectively enable -Wstring-conversion (clang only).






share|improve this answer





















  • 1





    I tried but without luck: Live Demo on coliru. Did I oversee something?

    – Scheff
    15 hours ago






  • 1





    @Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

    – lubgr
    15 hours ago








  • 1





    I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

    – Scheff
    15 hours ago











  • @Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

    – user463035818
    15 hours ago











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%2f54515792%2favoid-or-warn-on-implicit-conversion-from-const-char-to-bool-in-gcc%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









25














You could declare an overload of foo for pointers as deleted:



template <class T>

void foo(T*) = delete;


Or better yet, as @Ted comments, simply declare a vanilla overload to not compile any implicit conversions:



template <class T>

void foo(T) = delete;





share|improve this answer





















  • 2





    Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

    – Stack Danny
    15 hours ago






  • 3





    Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

    – Arne Vogel
    15 hours ago






  • 2





    ... or just void foo(T) = delete; to delete all implicit conversions.

    – Ted Lyngmo
    14 hours ago
















25














You could declare an overload of foo for pointers as deleted:



template <class T>

void foo(T*) = delete;


Or better yet, as @Ted comments, simply declare a vanilla overload to not compile any implicit conversions:



template <class T>

void foo(T) = delete;





share|improve this answer





















  • 2





    Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

    – Stack Danny
    15 hours ago






  • 3





    Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

    – Arne Vogel
    15 hours ago






  • 2





    ... or just void foo(T) = delete; to delete all implicit conversions.

    – Ted Lyngmo
    14 hours ago














25












25








25







You could declare an overload of foo for pointers as deleted:



template <class T>

void foo(T*) = delete;


Or better yet, as @Ted comments, simply declare a vanilla overload to not compile any implicit conversions:



template <class T>

void foo(T) = delete;





share|improve this answer















You could declare an overload of foo for pointers as deleted:



template <class T>

void foo(T*) = delete;


Or better yet, as @Ted comments, simply declare a vanilla overload to not compile any implicit conversions:



template <class T>

void foo(T) = delete;






share|improve this answer














share|improve this answer



share|improve this answer








edited 13 hours ago









Ted Lyngmo

2,5211317




2,5211317










answered 15 hours ago









Paul EvansPaul Evans

19k32038




19k32038








  • 2





    Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

    – Stack Danny
    15 hours ago






  • 3





    Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

    – Arne Vogel
    15 hours ago






  • 2





    ... or just void foo(T) = delete; to delete all implicit conversions.

    – Ted Lyngmo
    14 hours ago














  • 2





    Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

    – Stack Danny
    15 hours ago






  • 3





    Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

    – Arne Vogel
    15 hours ago






  • 2





    ... or just void foo(T) = delete; to delete all implicit conversions.

    – Ted Lyngmo
    14 hours ago








2




2





Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

– Stack Danny
15 hours ago





Not wrong but in a real world example these are probably (multiple) functions (maybe even from other files/sources) and that could make this seem quite exhausting.

– Stack Danny
15 hours ago




3




3





Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

– Arne Vogel
15 hours ago





Starting from C++11, you shoul actually declare it as deleted… this will generate earlier and more meaningful error messages. Alternatively, declare it with a body that raises a static_assert if T is not bool (template is ill-formed if it always raises a static_assert, that's the only reason for this check).

– Arne Vogel
15 hours ago




2




2





... or just void foo(T) = delete; to delete all implicit conversions.

– Ted Lyngmo
14 hours ago





... or just void foo(T) = delete; to delete all implicit conversions.

– Ted Lyngmo
14 hours ago













15















I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo. ... I tried -Wall, -Wextra, and -Wpedantic




You need to add -Wconversion to your compiler flags. Note that seems to work with clang (recent or older version), but not with gcc.



If this triggers too many warnings that you don't want to handle, you can selectively enable -Wstring-conversion (clang only).






share|improve this answer





















  • 1





    I tried but without luck: Live Demo on coliru. Did I oversee something?

    – Scheff
    15 hours ago






  • 1





    @Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

    – lubgr
    15 hours ago








  • 1





    I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

    – Scheff
    15 hours ago











  • @Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

    – user463035818
    15 hours ago
















15















I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo. ... I tried -Wall, -Wextra, and -Wpedantic




You need to add -Wconversion to your compiler flags. Note that seems to work with clang (recent or older version), but not with gcc.



If this triggers too many warnings that you don't want to handle, you can selectively enable -Wstring-conversion (clang only).






share|improve this answer





















  • 1





    I tried but without luck: Live Demo on coliru. Did I oversee something?

    – Scheff
    15 hours ago






  • 1





    @Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

    – lubgr
    15 hours ago








  • 1





    I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

    – Scheff
    15 hours ago











  • @Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

    – user463035818
    15 hours ago














15












15








15








I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo. ... I tried -Wall, -Wextra, and -Wpedantic




You need to add -Wconversion to your compiler flags. Note that seems to work with clang (recent or older version), but not with gcc.



If this triggers too many warnings that you don't want to handle, you can selectively enable -Wstring-conversion (clang only).






share|improve this answer
















I want the compiler to raise a warning when passing const char* instead of bool as a parameter to function foo. ... I tried -Wall, -Wextra, and -Wpedantic




You need to add -Wconversion to your compiler flags. Note that seems to work with clang (recent or older version), but not with gcc.



If this triggers too many warnings that you don't want to handle, you can selectively enable -Wstring-conversion (clang only).







share|improve this answer














share|improve this answer



share|improve this answer








edited 13 hours ago









Peter Mortensen

13.6k1984111




13.6k1984111










answered 15 hours ago









lubgrlubgr

11.5k21846




11.5k21846








  • 1





    I tried but without luck: Live Demo on coliru. Did I oversee something?

    – Scheff
    15 hours ago






  • 1





    @Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

    – lubgr
    15 hours ago








  • 1





    I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

    – Scheff
    15 hours ago











  • @Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

    – user463035818
    15 hours ago














  • 1





    I tried but without luck: Live Demo on coliru. Did I oversee something?

    – Scheff
    15 hours ago






  • 1





    @Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

    – lubgr
    15 hours ago








  • 1





    I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

    – Scheff
    15 hours ago











  • @Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

    – user463035818
    15 hours ago








1




1





I tried but without luck: Live Demo on coliru. Did I oversee something?

– Scheff
15 hours ago





I tried but without luck: Live Demo on coliru. Did I oversee something?

– Scheff
15 hours ago




1




1





@Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

– lubgr
15 hours ago







@Scheff Weird, it seems to be handled differently in clang and gcc. Updated the answer accordingly.

– lubgr
15 hours ago






1




1





I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

– Scheff
15 hours ago





I just found this The new Wconversion option and in fact the implicit conversion from const char* to bool isn't mentioned at all. Looks like it isn't covered in gcc...

– Scheff
15 hours ago













@Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

– user463035818
15 hours ago





@Scheff fwiw also no error/warning for uniform initialization of a bool with a const char*

– user463035818
15 hours ago


















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%2f54515792%2favoid-or-warn-on-implicit-conversion-from-const-char-to-bool-in-gcc%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
この記事は検証可能な参考文献や出典が全く示されていないか、不十分です。 出典を追加して記事の信頼性向上にご協力ください。 （ 2019年1月 ） 「 サソリ 」のその他の用法については「サソリ (曖昧さ回避)」をご覧ください。 「 スコーピオン 」と「 スコルピオン 」はこの項目へ転送されています。その他の用法については「スコーピオン」をご覧ください。 サソリ目 生息年代: 430–0 Ma PreЄ Є O S D C P T J K Pg N シルル紀前期-現世 ダイオウサソリ（ Pandinus Imperator ） 分類 界 : 動物界 Animalia 門 : 節足動物門 Arthropoda 亜門 : 鋏角亜門 Chelicerata 綱 : クモガタ綱 Arachnida 目 : サソリ目 Scorpiones 学名 Scorpiones C. L. Koch, 1837 英名 Scorpion 上科 Pseudochactoidea キョクトウサソリ上科 Buthoidea Chaeriloidea Chactoidea Iuroidea Scorpionoidea サソリ （ サソリ類 、 蠍 、 蝎 、 scorpion ）は、鋏角亜門・クモガタ綱の サソリ目 （ Scorpiones ）に属する節足動物の総称である。体の前端に鋏型の触肢、後端に毒針を有する捕食者である。 1700種以上を含め、最古の化石記録は4億3千万年前のシルル紀まで遡る。有毒生物として広く知られるが、人間の命にかかわる毒を持つものはごく一部の種類に過ぎない。 目次 1 形態 1.1 前体 1.2 後体 1.2.1 中体 1.2.2 終体 2 雌雄 3 生態 3.1 天敵 3.2 生殖 4 分布 5 毒 6 蛍光現象 7 分類
Read more

広島県道265号伴広島線

Image
一般県道 広島県道265号伴広島線 路線延長 km 起点 広島県広島市安佐南区伴東7丁目 終点 広島県広島市中区榎町 接続する 主な道路 （記法） 広島県道38号広島豊平線 広島県道71号広島湯来線 山陽自動車道五日市IC 国道183号（ 国道261号重複） ■テンプレート（■ノート ■使い方） ■PJ道路 広島県道265号伴広島線 （ひろしまけんどう265ごう ともひろしません）は広島県広島市安佐南区から広島県広島市中区を結ぶ一般県道である。 目次 1 路線データ 2 通過する自治体 3 見どころ 4 接続道路 4.1 本線 4.2 旧道 5 別名 6 関連項目 路線データ 本線 起点：広島市安佐南区伴東7丁目・大原下橋南詰交差点（広島県道38号広島豊平線（本線・旧道）交点） 終点：広島市中区榎町・十日市交差点（国道183号（国道261号重用）交点） 総延長： 旧道 起点：広島市安佐南区伴東4丁目・新細坂交差点（広島県道38号広島豊平線交点） 終点：広島市安佐南区伴中央4丁目・寺組橋(南)交差点（広島県道265号伴広島線（本線）交点） 総延長： 通過する自治体 広島県 広島市（安佐南区、佐伯区、西区、中区） 見どころ 広島高速交通広島新交通1号線（アストラムライン） 広島広域公園 広島広域公園陸上競技場（広島ビッグアーチ） 己斐峠 己斐橋（太田川放水路） 天満橋（天満川） 接続道路 本線 広島県道38号広島豊平線（本線・旧道）（広島市安佐南区伴東7丁目・大原下橋南詰交差点〔起点〕） 広島県道71号広島湯来線（本線）（広島市安佐南区伴中央2丁目・伴交番入口交差点 - 広島市安佐南区伴中央4丁目・寺組橋(南)交差点間で重用） 広島県道71号広島湯来線（旧道）（広島県道265号伴広島線（旧道）重用）（広島市安佐南区伴中央4丁目・寺組橋(南)交差点） 広島県道71号広島湯来線（広島市安佐南区伴中央4丁目・寺組橋(南)交差点 - 広島市佐伯区五日市町石内・五月が丘(南)交差点間で重用）
Read more

Setup Asymptote in Texstudio

Image
0 Good time of the day! I am trying to compile the following file: documentclass[12pt]{article} usepackage[inline]{asymptote} begin{document} Here is a venn diagram produced with Asymptote, drawn to width 4cm: defA{A} defB{V{B}} begin{figure} begin{center} begin{asy} size(4cm,0); pen colour1=red; pen colour2=green; pair z0=(0,0); pair z1=(-1,0); pair z2=(1,0); real r=1.5; path c1=circle(z1,r); path c2=circle(z2,r); fill(c1,colour1); fill(c2,colour2); picture intersection=new picture; fill(intersection,c1,colour1+colour2); clip(intersection,c2); add(intersection); draw(c1); draw(c2); //draw("$A$",box,z1)
Read more