cpprefjp雑談部屋 #1273
Comments
前の議論が終わるのを待つのもアレなのでこれはそう運用されるべきというのは同意した上で、GitHub issueのUIでやるの結構大変そうだなという気持ちに…(GitLabみたいにスレッド形式だと同じ話題だけまとまって話せるんですけどねぇ…)(まぁある程度話が盛り上がってきたら別途issue切って引っ越しましょう、でなんとかなるかな) |
|
一旦はアクティブユーザー数がそんなに多くないだろうという想定で、試しに運用してみる、という感じですかね |
|
話題提供 3月に行われた東京でのWG21会議のトリップレポートがいくつか
大きな機能の追加はなさそうですが、個人的体感としては値ベース静的リフレクション（P2996）がにわかに盛り上がりつつあるのを感じています。 |
|
C++標準ライブラリでの |
|
P2422R0 Remove nodiscard annotations from the standard library specification が採択されると全部消えそうですね この場合cpprefjp的には備考かどこかにこの関数は実装によって |
|
リフレクションは |
|
リフレクション、機能そのもののことと |
|
https://cpprefjp.github.io/lang/cpp26/user-generated_static_assert_messages.html ページタイトルにもキーワードリンクが貼られるのですが、これをよしとするかどうか、悩ましいところです |
|
記憶余り定かじゃないですが、たしか、最初は見出しには適用しないようにして PR 作ったのですが、その後で誰かの指摘により見出しにも適用するように変更したような…。 |
|
見出し2以降は、キーワードリンクがあると便利な気はしますね |
|
すみません。経緯が少し違いました: cpprefjp/markdown_to_html#5 の時点では見出し除外 (akinomyoga/cpprefjp-markdown_to_html@a9086f4) は入っていました。その後で修正 cpprefjp/markdown_to_html@8f04104 が入っていますね (この追加変更は何となく記憶にあったのですが、実際に議論があったのだったかそれとも個人的に commit を見て知ってただけだったのか分かりません)。(追記: うーんでもやっぱり見出しにも適用した方が良いみたいな議論がどこかであったような気がします…が脳が勝手に作り出した虚偽記憶の可能性も…)
そうですね。でしたら、該当箇所に |
|
かんたんに直せそうなので、h1は除外してみます！ |
見つけました！ #774 (comment) (複数リポジトリのissueだったりMRだったりに議論がとっ散らかってるから過去の議論を追いかけるのが中々大変ですね…) |
GitHubはコミットに対してコメントが付けられることを思い出したので，試しにコミットから関連コメントへのリンクをはってみました いつか何かで遡ったときに議論が少しは追いやすくなりそう cpprefjp/markdown_to_html@533bf5f#commitcomment-141949065 cpprefjp/markdown_to_html@8f04104#commitcomment-141949048 |
|
おー、ありがとうございます! リンクのコメントもありがとうございます! 本来は (PR を介さずに) 議論の末に追加された変更に関してはできるだけ commit message に関連するリンク (単なる |
|
そうですねぇ，ただ実際うっかりコミットメッセージにURL含めるの忘れてた！みたいなことは私もやりがちなので…(PR経由だとPR側にコメント残すなどでコミットからでも2hopでアクセスできることはわかっていたのですが，直接コミットでの取り返しの付け方が今まで(私が)わかってなかったのですよね) |
|
私も前から git で後付け注釈を入れられる仕組みはないのかと何となく思っていたのですが、今調べたら でも GitHub でのサポートは削除されたみたいです。理由はよく分かりませんが、たぶん色々と問題があるのでしょう。Commit hash で紐づけてるみたいなので、(勝手な予想ですが) |
|
https://twitter.com/wx257osn2/status/1610601153292828672 cpprefjpにどう立てつければいいかは浮かんでないですが、constexprみたいに初期仕様からドラスティックに仕様が変わっていったものを複数ページ見てマージして読むのはやっぱり辛いかもしれない、と思いました。 |
|
yumetodoさんのコメントと関連するのですが、私個人も似たような経験を何回かしていて、例えばどのattributeがどの時点で入ったかなどを簡単に確認したいときなどに年表のようなものがあると嬉しいと考えていました。 具体的には、各言語機能のページ（lang/cppXX）にある表の項目（「定数式」など）ごとにページを立てて、バージョンごとに節を作って対応する言語機能の表をコピーしてきて並べるだけでもそれなりに役に立つのではと考えています。もちろん、年表ページに行って表を眺めなければならない、という点でわかりやすさは言語機能の個別ページを書くよりも劣るでしょうが、コスト面で一考の余地はあるかと思います。 内容がほぼ既存のものの切り貼りで済み、ページの内容もほぼ表だけで短いので、「 ただ、パッと見バージョンごとに表の切り分けの粒度が少し違うように思えるので、それに応じて既存の言語機能ページの表の項目わけを少し調整する必要は出るかもしれません。 |
|
おそらく表だけであればすでにあるかと思います。 cpprefjpで初出の言語機能ページには、関連項目としてその機能に関連するアップデートへのリンクを記載しているので辿れるようになっています。
yumetodoさんがリンクを貼られた先の問題としては、constexprの初出ページで「できない」と書かれていたことが後のバージョンでは「できる」に変わっており、初出ページ内で書いてあることだけ読んでも、現在使っている言語バージョンでできることがわからない、ということかなと思います。 それはいずれやらないといけない気はしますが、私には当面、余裕がないですね。 |
|
言語機能のページタイトルの横に「C++11」などと書いてありますが、 「このページはC++11時点での言語機能を解説しています」 みたいな注意書きの定型文章をページの最初の方に書くのはどうでしょう？ |
これは暫定対応としてすぐにでき、ある程度の効果も期待できるので、よい気がします。 あとは、以下のような対応も追加で検討してみましょうか。
例として、C++14の「 一旦は、「ページタイトルから具体的な変更内容がわかりにくいページを探す」issueを立てて、一通りチェックしてみるのはいかがでしょうか。 |
よいと思いますが、例えば同じ C++11 の提案の間でも、初期の提案で取り込まれたものが後の提案・修正で変更されることもある(提案の内容がそのまま C++11 の確定した振る舞いになっているとは限らない) ので文言は調整した方が良い気がします。たとえば 「このページはC++11規格原稿に取り込まれた変更を解説しています」 (あまり深く考えていないのでまだ問題があるかも) ページタイトルには提案文書・バグ修正の番号 (複数関連するものがある場合は一番最後のもの) も付記されていると、例えば Web の検索結果一覧から特定しやすくて良いなと思います。 |
|
ページタイトルに提案文書の番号をつけるのは、タイトル末尾に以下のようにつけるのでどうでしょうか。先頭だと、Web検索結果で最も見せたいであろうタイトルが切れてしまう懸念があります。
|
|
ありがとうございます! その形式で良いと思います! |
|
目を離した隙に一気に話が進んでました・・・。 そうですね、今だと初見ではそのページに加えて何を読むべきなのか見抜けない可能性があるので、そういう警告をつけるのはいいかもしれません。 |
|
消しましたー |
|
Compiler Explorer (godbolt.org) でVisual Studioのバージョン情報を取得しようとしましたが、とれませんでした。。。 #pragma comment(lib, "user32.lib")
#pragma comment(lib, "version")
#include <print>
#include <windows.h>
int main() {
char fileName[MAX_PATH + 1];
::GetModuleFileNameA(nullptr, fileName, sizeof(fileName));
DWORD size = ::GetFileVersionInfoSize(fileName, nullptr);
BYTE* version = new BYTE[size];
if (::GetFileVersionInfoA(fileName, 0, size, version)) {
VS_FIXEDFILEINFO* fileInfo;
UINT queryLen;
::VerQueryValueA(version, "\\", (void**)&fileInfo, &queryLen);
std::println("{}.{}.{}.{}",
HIWORD(fileInfo->dwFileVersionMS),
LOWORD(fileInfo->dwFileVersionMS),
HIWORD(fileInfo->dwFileVersionLS),
LOWORD(fileInfo->dwFileVersionLS) );
}
else {
std::println("Can't get visual studio version"); // こっちにくる
}
delete[] version;
} |
|
ふと気づいたのですが、C++26 2024-04 Mailingの対応チケットが漏れているでしょうか？ |
|
確認します！ |
当該コード片だと「生成された実行可能ファイル(exe)のバージョン情報リソース」の取得を試みており、この情報が不在のためにエラーとなりますね。 VC++コンパイラのバージョン確認は マクロ #include <print>
int main() { std::println("{} {}", _MSC_VER, _MSC_FULL_VER); } |
|
パッチバージョンだけ上がった場合、 |
|
2024-04 mailingの対応完了しました |
|
まあパッチバージョンだけ上がった場合については私をメンションしていただけたら多分対応します・・・。 |
|
を書きつつ、ところで大元になったQiitaの記事を見てくると
いつの間にかUBの記述が消えてるんですね・・・。 |
気になって調べてみたら、CWG 2300. Lambdas in multiple definitions 適用によって "behavior is undefined" から "program is ill-formed, no diagnostic required" に変わったようです。同CWG 2300は Accepted as a DR とのことですから、ODR違反は未定義動作ではなくなったのか...
最新ドラフトのWording は CWG 2494. Multiple definitions of non-odr-used entities 由来でした。C++20モジュール導入と相まって診断基準(diagnostic is required only if ...)がよくわからないことになってますね。 |
|
情報ありがとうございます。Qiita の記事は EB の和訳が定まった辺りで cpprefjp の標準規格と処理系と一緒にまとめて更新することにしますね。 まあ、翻訳時のいわば "動作保証外" が ill-formed; NDR で実行時の "動作保証外" が UB だってことを考えると、そもそもとして翻訳時の規則のはずの ODR に対して UB があったのが変だったといえば変でした。CWG 2300 は、特にこの UB の記述の修正を目的としたものではなくて、他の変更の序でにしれっと UB を ill-formed; NDR にしているみたいですね。ちなみに規格的な取り扱いは、NDR も UB も「診断対象外」かつ「規格は処理系に対して何の制限もおかない」という感じなので、UB が NDR に変わったと言っても、単に名前が変わっただけで鼻から悪魔なのは変わりないです。 |
|
2024年度の貢献度の集計をそろそろ始めないと・・・。週明けからがんばります |
|
EB の和名が決まったので #1273 (comment) の更新も含めつつ、 標準規格と処理系 - cpprefjp C++日本語リファレンス 用の画像の更新案です。
|
|
ありがとうございます！そのページの更新はどうしようかと思っていたところでした |
|
このPull Requestに追加コミットしてもらってもいい気はします。近々マージできそうな気はしますが |
|
PR番号直しました |
|
"標準規格と処理系" の画像の原本は pptx (Power Point) で |
|
GLOBAL_DEFINED_WORDS.json の内容を見ていて思ったのですが "適格要件" の説明が気になります。cpprefjp では宣言に対する "Mandates:" の項目が "適格要件" に対応するのだと思いますが、 site/GLOBAL_DEFINED_WORDS.json Lines 76 to 78 in 3f56e5b という説明 (特に後半) は間違ってはいないのかもしれないけれど、的確な説明ではない気がします。あと、 |
|
確認します。 https://github.com/cpprefjp/site/blob/master/start_editing/function_template_page.md |
修正案を考えました↓
|
|
更に、一連の他の要素も加えると共に、頭に「関数の意味論を構成する要素の1つ。」などのようにどのようなカテゴリーの用語なのかわかるようにしたら良いのではないかと思っています。更に更に、適格要件 ⇔ Mandates の対応関係がわかりにくいので 「Mandates。」も tooltip に含まれているといいなと思っています。 |
|
そうですね。その用語が使われる文脈もわかったほうがいいので、ご指摘の通りでよいかと思います。 ちょっと私が向こう数日間は作業できなさそうなので、できそうであればどなたかやっていただければと思います。 |
|
今年の貢献ポイントの集計についてです。 去年はPull Request上で各人の貢献ポイントをレビューしてもらいましたが、Webサイト上で貢献の表を見られたほうがよいと思うので、集計はPull Requestでやりますが、レビューはissue上で相談させていただければと思います。 |
|
commit idの列挙がMarkdownベタ書きだと大変つらくて効率悪いので、こういう記法を導入して従来のリンクに変換しようかと思います |
cpprefjp雑談部屋ルール
The text was updated successfully, but these errors were encountered: