cpprefjp雑談部屋

[faithandbrave]

cpprefjp雑談部屋ルール

• issueに起こすほどでもない雑多な議論をする場所です
• 通知がうるさいと感じた方は、issue個別で通知をオフにできるので、そちらをご利用ください
• 個人のつぶやきをゆるく投稿してもらってOKです
• cpprefjpメンバー以外の投稿も歓迎します
• X/Twitterなど、ほかの場所で発せられたcpprefjpの問題などがあったら、ここで教えてください (issueを起こしてもらってもOKです)
• ここで始まった話題で詳細な議論が必要になってきたら、ぜひissueを起こして移動してください
• 専門分野ごとの部屋が必要になってきたら、部屋を分けることを検討します
• 質問掲示板というわけではないので、回答が得られることは期待しないでください
• だれかが議論していても、気にせず別な話題を投稿してください
• 攻撃的な批判、ハラスメント行為、ヘイトなどは禁止とします

[wx257osn2]

だれかが議論していても、気にせず別な話題を投稿してください

前の議論が終わるのを待つのもアレなのでこれはそう運用されるべきというのは同意した上で、GitHub issueのUIでやるの結構大変そうだなという気持ちに…(GitLabみたいにスレッド形式だと同じ話題だけまとまって話せるんですけどねぇ…)(まぁある程度話が盛り上がってきたら別途issue切って引っ越しましょう、でなんとかなるかな)

[faithandbrave]

一旦はアクティブユーザー数がそんなに多くないだろうという想定で、試しに運用してみる、という感じですかね

[onihusube]

話題提供

3月に行われた東京でのWG21会議のトリップレポートがいくつか

• 2024-03 Tokyo ISO C++ Committee Trip Report — Third C++26 meeting! 🗼 : r/cpp
• Trip Report: Winter ISO C++ Standards Meeting in Tokyo | by David Sankel | Apr, 2024 | Adobe Tech Blog

大きな機能の追加はなさそうですが、個人的体感としては値ベース静的リフレクション（P2996）がにわかに盛り上がりつつあるのを感じています。

[yohhoy]

C++標準ライブラリでの[[nodiscard]]属性付与に関する P3201 もAprovedされたのですね。今後は nodiscard指定されることは原則なさそう...（既存関数はそのままかな？）

[onihusube]

P2422R0 Remove nodiscard annotations from the standard library specification

が採択されると全部消えそうですね

この場合cpprefjp的には備考かどこかにこの関数は実装によって[[nodiscard]]指定される場合がある、みたいに書くことになるんですかね

[faithandbrave]

リフレクションはstd::metaライブラリだけかと思ったら、^とか言語機能もいろいろ入るんですね

[onihusube]

リフレクション、機能そのもののことと^Tすることと^Tして得られたmeta::infoのことをそれぞれreflectionって呼んでて、訳語大変そうだなって思ってます
というかややこしい・・・

[faithandbrave]

https://cpprefjp.github.io/lang/cpp26/user-generated_static_assert_messages.html

ページタイトルにもキーワードリンクが貼られるのですが、これをよしとするかどうか、悩ましいところです

[akinomyoga]

記憶余り定かじゃないですが、たしか、最初は見出しには適用しないようにして PR 作ったのですが、その後で誰かの指摘により見出しにも適用するように変更したような…。

[faithandbrave]

見出し2以降は、キーワードリンクがあると便利な気はしますね

[akinomyoga]

すみません。経緯が少し違いました: cpprefjp/markdown_to_html#5 の時点では見出し除外 (akinomyoga/cpprefjp-markdown_to_html@a9086f4) は入っていました。その後で修正 cpprefjp/markdown_to_html@8f04104 が入っていますね (この追加変更は何となく記憶にあったのですが、実際に議論があったのだったかそれとも個人的に commit を見て知ってただけだったのか分かりません)。(追記: うーんでもやっぱり見出しにも適用した方が良いみたいな議論がどこかであったような気がします…が脳が勝手に作り出した虚偽記憶の可能性も…)

見出し2以降は、キーワードリンクがあると便利な気はしますね

そうですね。でしたら、該当箇所に h[2-6] h1 (訂正: ごめんなさい逆でした) を戻すだけで良さそう(?)ですね。

[faithandbrave]

かんたんに直せそうなので、h1は除外してみます！

[faithandbrave]

直しました！
cpprefjp/markdown_to_html@533bf5f

[wx257osn2]

@akinomyoga

うーんでもやっぱり見出しにも適用した方が良いみたいな議論がどこかであったような気がします

見つけました！ #774 (comment) (複数リポジトリのissueだったりMRだったりに議論がとっ散らかってるから過去の議論を追いかけるのが中々大変ですね…)

[wx257osn2]

過去の議論を追いかけるのが中々大変

GitHubはコミットに対してコメントが付けられることを思い出したので，試しにコミットから関連コメントへのリンクをはってみました いつか何かで遡ったときに議論が少しは追いやすくなりそう cpprefjp/markdown_to_html@533bf5f#commitcomment-141949065 cpprefjp/markdown_to_html@8f04104#commitcomment-141949048

[akinomyoga]

おー、ありがとうございます! リンクのコメントもありがとうございます!

本来は (PR を介さずに) 議論の末に追加された変更に関してはできるだけ commit message に関連するリンク (単なる #番号 などではなくフルの URL) を入れておくのが良いですね。

[wx257osn2]

そうですねぇ，ただ実際うっかりコミットメッセージにURL含めるの忘れてた！みたいなことは私もやりがちなので…(PR経由だとPR側にコメント残すなどでコミットからでも2hopでアクセスできることはわかっていたのですが，直接コミットでの取り返しの付け方が今まで(私が)わかってなかったのですよね)

[akinomyoga]

私も前から git で後付け注釈を入れられる仕組みはないのかと何となく思っていたのですが、今調べたら git notes というものがあるみたいですね。

• git notes でコミット自体を変更せずに git に注釈を残す #Git - Qiita
• Git - git-notes Documentation

でも GitHub でのサポートは削除されたみたいです。理由はよく分かりませんが、たぶん色々と問題があるのでしょう。Commit hash で紐づけてるみたいなので、(勝手な予想ですが) rebase とか filter-branch とかしたら紐づけが切れそうですし、異なる複数の branch に cherry-picked された元々同じ commit にも反映されなそうですし…。

[yumetodo]

https://twitter.com/wx257osn2/status/1610601153292828672

cpprefjpにどう立てつければいいかは浮かんでないですが、constexprみたいに初期仕様からドラスティックに仕様が変わっていったものを複数ページ見てマージして読むのはやっぱり辛いかもしれない、と思いました。

[ToruNiina]

yumetodoさんのコメントと関連するのですが、私個人も似たような経験を何回かしていて、例えばどのattributeがどの時点で入ったかなどを簡単に確認したいときなどに年表のようなものがあると嬉しいと考えていました。

具体的には、各言語機能のページ（lang/cppXX）にある表の項目（「定数式」など）ごとにページを立てて、バージョンごとに節を作って対応する言語機能の表をコピーしてきて並べるだけでもそれなりに役に立つのではと考えています。もちろん、年表ページに行って表を眺めなければならない、という点でわかりやすさは言語機能の個別ページを書くよりも劣るでしょうが、コスト面で一考の余地はあるかと思います。

内容がほぼ既存のものの切り貼りで済み、ページの内容もほぼ表だけで短いので、「constexpr」のようなページを新たに作成して変遷の説明を書くことと比べると手間はかなり少ないはずです。メンテコストは少し上がってしまいますが、基本的に過去のバージョンにおける機能追加の数は増減しないと考えてよいので、言語機能の記事を追加する際にしか影響はないはずです（とはいえ言語機能の記事を書く時点でコストが高いので追加コストは避けるべき、という意見もあるかとは思います）。

ただ、パッと見バージョンごとに表の切り分けの粒度が少し違うように思えるので、それに応じて既存の言語機能ページの表の項目わけを少し調整する必要は出るかもしれません。

[faithandbrave]

おそらく表だけであればすでにあるかと思います。

cpprefjpで初出の言語機能ページには、関連項目としてその機能に関連するアップデートへのリンクを記載しているので辿れるようになっています。

• https://cpprefjp.github.io/lang/cpp11/attributes.html
• https://cpprefjp.github.io/lang/cpp11/lambda_expressions.html
• https://cpprefjp.github.io/lang/cpp11/constexpr.html

yumetodoさんがリンクを貼られた先の問題としては、constexprの初出ページで「できない」と書かれていたことが後のバージョンでは「できる」に変わっており、初出ページ内で書いてあることだけ読んでも、現在使っている言語バージョンでできることがわからない、ということかなと思います。
問題として理解はできますが、結局この問題は、対象となる言語機能のすべての仕様が書かれたページを用意しないと解決しない気がします。

それはいずれやらないといけない気はしますが、私には当面、余裕がないですね。
なので、リファレンス作成に余裕ができるか、完成のために尽力できる方がでてきて差分ではない言語機能の解説に取り組む表明をすれば、話が進むと思います。

[tshino]

言語機能のページタイトルの横に「C++11」などと書いてありますが、
そのC++バージョン以降でずっと通用するという誤解が生じやすいのは分かる気がします。

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

みたいな注意書きの定型文章をページの最初の方に書くのはどうでしょう？

[faithandbrave]

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

これは暫定対応としてすぐにでき、ある程度の効果も期待できるので、よい気がします。
ページタイトルの下、概要の上に全ページ、機械的に載せてしまっていい気がします。
あとは、「## 関連項目」にアンカーをつけてページ内リンクを貼る、とかでしょうか。

あとは、以下のような対応も追加で検討してみましょうか。

• 言語機能のページタイトルを提案文書の直訳的なものから、機能的・説明的なものにできるだけ変更する
• 関連項目を箇条書きではなく表にしてページタイトルからは読み取れない情報を補完するか、箇条書きをネストして情報補完する

例として、C++14の「constexprの制限緩和」ページは、どう緩和されたのかページタイトルだけではわからないので、「constexpr関数内での条件分岐とループの文を許可」などのページタイトルに変更することが考えられます。
ページタイトルの変更だけでは対応しきれないものがあった場合に、表もしくは箇条書きのネストを検討するのでどうでしょう。

一旦は、「ページタイトルから具体的な変更内容がわかりにくいページを探す」issueを立てて、一通りチェックしてみるのはいかがでしょうか。

[akinomyoga]

「このページはC++11時点での言語機能を解説しています」
「のちの規格で変更されている場合があるため関連項目を参照してください」

これは暫定対応としてすぐにでき、ある程度の効果も期待できるので、よい気がします。

よいと思いますが、例えば同じ C++11 の提案の間でも、初期の提案で取り込まれたものが後の提案・修正で変更されることもある(提案の内容がそのまま C++11 の確定した振る舞いになっているとは限らない) ので文言は調整した方が良い気がします。たとえば

「このページはC++11規格原稿に取り込まれた変更を解説しています」
「他の変更で上書きされている場合があるため関連項目を参照してください」

(あまり深く考えていないのでまだ問題があるかも)

---

ページタイトルには提案文書・バグ修正の番号 (複数関連するものがある場合は一番最後のもの) も付記されていると、例えば Web の検索結果一覧から特定しやすくて良いなと思います。

[faithandbrave]

ページタイトルに提案文書の番号をつけるのは、タイトル末尾に以下のようにつけるのでどうでしょうか。先頭だと、Web検索結果で最も見せたいであろうタイトルが切れてしまう懸念があります。

「符号付き整数型が2の補数表現であることを規定 [P1236R1]」

[akinomyoga]

ありがとうございます! その形式で良いと思います!

[yumetodo]

目を離した隙に一気に話が進んでました・・・。

そうですね、今だと初見ではそのページに加えて何を読むべきなのか見抜けない可能性があるので、そういう警告をつけるのはいいかもしれません。

[akinomyoga]

雑談部屋が沈んでいると思ったら unpin されていますね。何やら通知か広告みたいに表示されるので右上の✕を押しがちかもですが罠ですね…。

---

大したことじゃないのですが Actions のページで一つの push ごとにたくさんの workflows が走っていますが、統合できませんか。現状だとActions の1ページで 3 push 分程度しか表示できていないのと、push 間の境界が分かりにくいので。一つのファイルに複数の jobs を記述すれば一つの workflow の中で複数のタスクを並列で走らせられます。

[faithandbrave]

unpinできる権限とかは設定できないようなので、このissueがピン留めされてないのを見かけた方はpin issueしてくださいませ。

GitHub Actionsは、check、build、outer link checkの3つくらいにまとめてもいい気はします。

[faithandbrave]

GitHub Actionsのbuildタスクに、ビルドだけしてデプロイしないモードがあればPull RequestのCIとして使えて便利そうですね。。。(ぜんぜん余裕がない)

[Raclamusi]

cpprefjp のサイドバーが死んでませんか？

[akinomyoga]

死んでます! cpprefjp/kunai#145 (comment)

[faithandbrave]

すいません、フロントエンドの修正を一旦巻き戻しました。
いまはサイドバーが復旧しています。

[yohhoy]

#1360 (comment) で言及されているような記事、需要はあるとは思いつつ「どんなターゲット読者向け（前提とする理解度）に、何を伝えるか（実践的／理論的な側面）」が難しいなーといつも思うのでした。

本当は評価順序や同期についての包括的な記事もあった方が助かるのだとは思います。
読者層によるとは言え、寧ろ初心者にとってこそ、規格に当たることなく難しいことを俯瞰できる日本語の情報には価値があるのでは

[faithandbrave]

cpprefjpに記事 (article) を書くハードルがそれなりに高い気がしてるのですが、なにかしらルール決めした方が書きやすかったりしますかね。。。
リファレンスサイトであるため、記事は初心者向けとかよりは、厳密性が求められるのだとは思いますが、ぜいたくなことを言えば「## ざっくりとしたイメージをもちたい人向け」「## 初心者向けの説明」「## 専門的な説明」とかでターゲットごとに説明を変えられると便利そうな気はしますね。

記事を書く最大の要件は、「未来永劫メンテナンスし続けること」になるかと思いますが、書いた人しかメンテナンスできない難易度の高さだと困るので、ほかの人も修正できるようにするためにも参考文献とか編集者向け情報が充実すると助かりはしますね。

ほかには、本サイトのスコープを拡張するような記事になる場合には事前相談が必要、くらいでしょうか (前に逆引きリファレンスの記事は結局却下になってしまいましたが…あれもスコープ拡張。Pull Requestでがんばって書く前に相談してもらったほうがよかった)。

[yohhoy]

なにかしらルール決めした方が書きやすかったりしますかね。
リファレンスサイトであるため、記事は初心者向けとかよりは、厳密性が求められるのだとは思いますが、ぜいたくなことを言えば「## ざっくりとしたイメージをもちたい人向け」「## 初心者向けの説明」「## 専門的な説明」とかでターゲットごとに説明を変えられると便利そうな気はしますね。

cpprefjp記事のガイドラインとして、何を重視するか（正確性？わかりやすさ？）、だれをターゲットとするか、は明記あった方が良いかなと思いました。

cpprefjpに記事 (article) を書くハードルがそれなりに高い気がしてる

逆説的ですが、一定のハードルがあるのは仕方ない／必要かなとも思います。
cpprefjp以外にも記事公開の場所が存在する中で、日本語リファレンスサイトは一定の説得力をもちますから、ある程度は慎重にならざるを得ないかなと思いました。

---

ここまで書いて、大手Q&Aサイトで過去に「集合知的にリファレンス記事群を作る」 プロジェクト Stack Overflow Documentation が存在し、1年後に シャットダウン した歴史を思い出しました。
質問＆回答(StackOverflow) と ライブラリ・言語仕様(cpprefjp) ではそれぞれ事情が異なるものの、体系立てた一定ボリュームを持つ記事群を集合知的に記述し維持管理することの難しさがありそうです。

[akinomyoga]

私が元々のコメントを書いたときは、記事のレベルだとか内容は執筆者に任せる形を想像していました。

ターゲット読者は、勿論「規格を自分で読むような人たち」は除外して考えて良いとは思います。しかし、初心者向けであっても、C++の詳細に触れる手がかりとなる規格的概念 (元 PR で言えば happens before, etc.) が目に触れる・手が届くところにあるというのは、記事自体のレベルが読者にとってたとえ難解であっても意味があるのではないか。というのが元々のコメントの趣旨です。意欲のある初心者であれば難しいことが書いてあっても食いつくでしょうし、そうでなければ単に「そういう概念があるのだなぁ」という印象だけでも持ってもらえたらいいなと感じます。

# 個人的には、例えば、初心者向けと称して定義を避けた具体例中心の解説は個人的に大変わかりにくい (というよりむしろ理解不能) です。個人的な好みにすぎないかもですが、先に self contained な解説をして、その後で付加的に動機・背景・具体例を示すという形の記事があったら嬉しいなという感じです。なんというか、「規格の(詳細を省略した)日本語訳」みたいな記述がやっぱり分かりやすい (これは専門家が分かりやすく的確になるように規格を書いているのだから当たり前といえば当たり前) と感じるのです。ただ、それだけだと色々背景や動機などが分からなかったり、具体的にどう使うのか or どう何が起こるのかというのが分からなかったりするので、それが分かるような背景情報を追加する、という形です。これは、自分が既に C++ に慣れているからそう思うのではなくて、自分が初心者だったときから思うことです。

でも、人それぞれ「わかりやすさ」というのは違うので、最終的には執筆者が執筆者の思うわかりやすさで記述するしかありません。「わかりやすい記事」って「読者のレベル」みたいな一次元のパラメータで決まるものじゃないはずで、一つの読者層を想定したとしてもみんなにわかりやすい解説は不可能だと思うんです。