-
Notifications
You must be signed in to change notification settings - Fork 170
style: # define
および /* implementation-defined */
の表記修正
#1471
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
76deb2c
to
c355b3a
Compare
@@ -5,7 +5,7 @@ | |||
* cpp20deprecated[meta cpp] | |||
|
|||
```cpp | |||
# define ATOMIC_VAR_INIT(value) see below | |||
#define ATOMIC_VAR_INIT(value) see below |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see below となっていますが他の場所では大体 implementation-defined になっています。#define
系統で see below になっているのは、このファイルも含めて以下の3件あります。
$ git grep -nE '#.*see[ -]below'
./reference/atomic/atomic_flag_init.md:8:#define ATOMIC_FLAG_INIT see below
./reference/atomic/atomic_var_init.md:8:#define ATOMIC_VAR_INIT(value) see below
./reference/cstddef/offsetof.md:6:#define offsetof(type, member) see-below
これらも implementaion-defined にするべき? しかし、改めて考えてみるとこれらは本当に implementation-defined なのでしょうか? implementation-defined というのは規格が処理系に対してその具体的値を文書に記述することを要求するという意味です。でも、マクロの具体的な値について文書に記述することを要求している箇所って規格にあるのでしたっけ。寧ろ implementation-defined ではなくて unspecified なのではという気もします…。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ありがとうございます。そういう意味では see below のままで問題があるというわけでもない (ちゃんと "下" に説明があれば) のですが、他の多くの記事において規格で see below だったものが implementation-defined や C規格に合わせたconstant-expression などに置き換えられているので、この3記事だけで see below が残っているのは、余り一貫していないなと思ったのでした。他の記事のほうも see below に書き換えるべきか(?)というとそれも微妙な気がしています。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
改めて確認してみた所、
- 既存の "see below" → "implementation-defined" は、半分くらいは、実はC規格の方で implementation-defined と明記されているものでした (→ 変更なし)
- それでも、既にこのPRの中にあるように、HUGE_VAL, HUGE_VALF, HUGE_VALL などは implementation-defined ではないのに see below が implementation-defined に置き換えられて記述されていました (→ 978af3c)
- 他にも、
<cfenv>
のマクロなどは規格では see below, C規格では文中で integer constant expression と書いてあって、implementation-defined とは一言も書かれていないのに、cpprefjp の記事中では implementation-defined と書かれています (→ 978af3c) - offsetof は現状で cpprefjp で see below になっていますが、C規格の方で integer constant expression と書いてあるのでそちらに改めても良さそうです (→ 978af3c)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
執筆者が仕様解釈して "see below" から置換表記されるケースがあるのですね。このパターンは認識していませんでした。
<concepts>
や<execution>
以下のページだと「仕様をインラインコードで書くと複雑すぎる/自然言語を用いて仕様記述する」ために "see below" が使われており、cpprefjpサイト上でも前後関係を維持してそのまま表記してる箇所も多いですね。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
これらも implementaion-defined にするべき? しかし、改めて考えてみるとこれらは本当に implementation-defined なのでしょうか? implementation-defined というのは規格が処理系に対してその具体的値を文書に記述することを要求するという意味です。でも、マクロの具体的な値について文書に記述することを要求している箇所って規格にあるのでしたっけ。寧ろ implementation-defined ではなくて unspecified なのではという気もします…。
対象マクロ ATOMIC_FLAG_INIT
, ATOMIC_VAR_INIT
, offsetof
の仕様定義を確認したところ「自然言語を用いて仕様記述する」ケースであり、現状の "see below" 表記で妥当に思えます。
C++規格では implementation-defined / unspecified いずれもプログラムの振る舞い(behavior)に関する用語となっており、今回ケースはいずれにも該当しないと思います。
- implementation-defined behavior: 起こり得る候補のうちいずれかの挙動となる。選択された挙動は処理系によって文書化すべきである。
- unspecified behavior: 起こり得る候補のうちいずれかの挙動となる。文書化の必要はない。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ありがとうございます! ATOMIC_{FLAG,VAR}_INIT
は see below のままにするのが妥当そうですね。そのままにしようと思います。
offsetof
についてはC規格の方で integer constant expression 云々の記述があるので、既に integer_constant_expression などになっていたものに合わせて、integer-constant-expression にしようとかなと思います。正確には "integer-constant-expression" だけで説明を尽くせている訳ではないので、それでも see below for more details って感じですが、部分的注釈はあっても悪くはないかなと…。説明を尽くせていないと言い出したら、あらゆる synopsis は全部 see below としか書けなくなってしまうので…という言い訳です。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
C規格(C17)の offsetof
定義を確認してみました。確かに integer constant expression で良さそうですね。
offsetof(type, member-designator)which expands to an integer constant expression that has type
size_t
, the value of which is the
offset in bytes, to the structure member (designated by member-designator), from the beginning of its
structure (designated by type).
c275846
to
4cb96df
Compare
貢献ポイント備考: これは機械的な置換の後に目視確認で該当するものだけ拾っ たものです。 cpprefjp#1470 (comment)
53e132e
to
a3029b0
Compare
構文説明なので C++ としての着色は不要かもしれないが、着色しても問題な いような気がするので。
エラーだったら ec を設定し、それ以外だったら ec.clear() にするのは既に status(p, ec), symlink_status(p, ec) が実施しているので、改めて呼び出 し元で設定する必要はないように思われる。 std::filesystem::exists に関しては status_known (つまり s.type() == std::filesystem::file_type::none) 以外の時は ec.clear() を実行すると規 格には書かれていたが、既存の説明だと ec が空の時しか ec.clear() を呼び 出さないようになっていた。これは記述の修正になる。
a3029b0
to
d8458b6
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
他にも implementation-defined ではないのに implementation-defined と書かれてしまっているところを修正しました。
@faithandbrave 一つご確認いただきたい commit があるのですが、こちら d8458b6 見ていただけないでしょうか。よろしくお願いいたします。
勘違いでなければ、規格を見る限りはこれらの「エラーだったら ec を設定して、そうでなければ ec.clear() をする」といった処理は、全て status(p, ec)
の中で既に実行されているように見えます。なので、大幅に単純化しました。
一点、記述されている振る舞いが変更になっているのが filesystem::exists で ec.clear() が実行される条件です。規格は status_known(s)
でなければならば ec.clear()
を実行すると書かれていますが、cpprefjp の記述ですと先に if (ec) return false;
してしまっているので、ec.clear()
を免れてしまうパターンがあるように思われます。書き換えました。
りょうかいです。見ておきます。 |
お忙しいところありがとうございます。お言葉に甘えこちらのペースでマージさせていただきますね。 |
#1470 (comment)
#1470 (comment)