cpprefjp雑談部屋 - Githubissues

faithandbrave commented 1 month ago

cpprefjp雑談部屋ルール

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

wx257osn2 commented 1 month ago

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

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

faithandbrave commented 1 month ago

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

onihusube commented 1 month ago

話題提供

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

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

yohhoy commented 1 month ago

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

onihusube commented 1 month ago

P2422R0 Remove nodiscard annotations from the standard library specification

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

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

faithandbrave commented 1 month ago

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

onihusube commented 1 month ago

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

faithandbrave commented 1 month ago

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

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

akinomyoga commented 1 month ago

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

faithandbrave commented 1 month ago

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

akinomyoga commented 1 month ago

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

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

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

faithandbrave commented 1 month ago

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

faithandbrave commented 1 month ago

直しました！ https://github.com/cpprefjp/markdown_to_html/commit/533bf5f9eb2abc21bf17f2ef90ac29aaab44b498

wx257osn2 commented 1 month ago

@akinomyoga

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

見つけました！ https://github.com/cpprefjp/site/issues/774#issuecomment-1330165823 (複数リポジトリのissueだったりMRだったりに議論がとっ散らかってるから過去の議論を追いかけるのが中々大変ですね…)

wx257osn2 commented 1 month ago

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

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

akinomyoga commented 1 month ago

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

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

wx257osn2 commented 1 month ago

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

akinomyoga commented 1 month ago

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

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

yumetodo commented 1 month ago

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

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

ToruNiina commented 1 month ago

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

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

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

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

faithandbrave commented 1 month ago

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

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

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

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

tshino commented 1 month ago

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

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

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

faithandbrave commented 1 month ago

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

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

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

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

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

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

akinomyoga commented 1 month ago

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

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

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

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

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

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

faithandbrave commented 1 month ago

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

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

akinomyoga commented 1 month ago

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

yumetodo commented 1 month ago

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

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

yumetodo commented 1 month ago

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

提案文章番号、たしかに・・・。言われてみれば例えばコンパイラの実装状況見に行くときも提案文章番号でgrepしますからそのほうがいいですね。

faithandbrave commented 1 month ago

2件、issue化しました。 issue化したものはそちらに議論を移動お願いします。 issue化できていない議論があれば、継続をお願いします。

sukeya commented 1 month ago

こんばんは。些細なことなのですが、LaTeXで書いた数式が左詰めになっているように見えてちょっと気になりました(例えばここ)。個人的には引用くらいのスペースが前につくとより見やすくなると思いました(例えばここ)。

faithandbrave commented 1 month ago

現状がどうなってるのか、まず調べます！ MathJaxにマージンの設定があるのかどうか・・・

faithandbrave commented 1 month ago

https://github.com/cpprefjp/site/issues/1284

issue化しました！

akinomyoga commented 1 month ago

サンプルコードのコーディングスタイル修正にルールはありますか。

namespace std { の { の前のスペースなのですが、以下のように入っていない例がありまして、

$ git grep 'namespace std{'
reference/numeric/accumulate.md:namespace std{
reference/numeric/exclusive_scan.md:namespace std{
reference/numeric/inclusive_scan.md:namespace std{
reference/numeric/iota.md:namespace std{
reference/numeric/reduce.md:namespace std{
reference/numeric/transform_exclusive_scan.md:namespace std{
reference/numeric/transform_inclusive_scan.md:namespace std{
reference/numeric/transform_reduce.md:namespace std{
$ git grep 'namespace std {' | wc -l
1820

勝手に直そうかなと思ったのですが、もしかしたら敢えて残しているなどのポリシーはありますか。規格 (というより正確には cplusplus/draft ですが) ではコア言語部分では「C++ では本来色々なスタイルで書けることを示すためにスペースの入れ方も含めてスタイルのばらつきは修正しないのだ」などと言ってます [1] が…。

[1] Formatting declarations and definitions - Specification Style Guidelines · cplusplus/draft

因みに「規格がこの部分だけ namespace std{ としている可能性」もあるかもと思って確認してみましたが、別にそういう訳でもないみたいです。

faithandbrave commented 1 month ago

とくにルールがないところなので、編集合戦にならない (無相談修正で争いごとに発展させない) レベルの修正ならさっとやってしまってよいと思います。 grepででてきているのは私が書いたところなので、スペースいれる修正をしてもらって大丈夫です。

akinomyoga commented 1 month ago

ありがとうございます!

faithandbrave commented 2 weeks ago

https://cpprefjp.github.io/reference/linalg/add.html

この関数は、add(x, y, ref(z))して使う想定なのかな

onihusube commented 2 weeks ago

全部mdspanで良くて、ただしzだけは要素に書き込みができる必要がある、という感じです

akinomyoga commented 2 weeks ago

std::dynamic_extent だと大きさ情報もコピーする前提って事なんでしょうか。(余り C++ らしくないなと思ったけれど、dereference のコストとか strict aliasing とか考えたら、参照で受けたとしても結局使う側で値をコピーして使いまわした方がいいから、関係ないのかな。)

akinomyoga commented 2 weeks ago

https://github.com/cpprefjp/site/issues/1276#issuecomment-2167858055 のために cpprefjp の Google 検索を使ったのですが、サイドバーに含まれる語にもヒットして情報が探しにくいです。。。

ページの一部をインデックス対象から除外する方法はないのかと思ったのですがない?

seo - Is there a way to prevent Googlebot from indexing certain parts of a page? - Stack Overflow

そもそもサイドバーの内容はページのソースに含まれていなくて動的に生成されている筈なので、Google のクローラーは JavaScript 実行して動的な内容も記録する (ようになった) ということなのでしょうか。もしそうだとしたら、User-agent か何かで判定してサイドバーの生成を抑制できたりするのでしょうか。

yohhoy commented 2 weeks ago

linalgヘッダのアルゴリズム群は、実利用ケースの挙動説明が難しいんですよねぇ... 出力先mdspanのDynamic extent／Static extent別はlinalgアルゴリズム動作に影響せず、呼出側の責任で出力先mdspanサイズを初期化しておく必要がありますね。

int a[3] = {1, 2, 3};
int b[3] = {4, 5, 6};
std::mdspan ma{a};  // static extent
std::mdspan mb{b};  // static extent

int c[3];
std::mdspan mc{c, 3}; // dynamic extent
static_assert(mc.static_extent(0) == std::dynamic_extent);

std::linalg:add(ma, mb, mc);
assert(mc[0] == 5 && mc[1] == 7 && mc[2] == 9);

（脳内コンパイルなので多少怪しい...）

sukeya commented 2 weeks ago

皆さんのご意見をお聞きしたいのですが、どのコンパイラも実装していない機能のページを書く時、サンプルコードを書いた方が良いでしょうか？

faithandbrave commented 2 weeks ago

私としては、仕様理解のため、使用上の注意を経験した上で概要・備考を書くためにも、脳内コンパイルでもサンプルコードは書いたほうがよいと考えています。 linalgについては参照実装もないのでむずかしいところではあると思いますが (私もstacktraceのリファレンス作成は実装がなくて書きにくく、停滞してましたし)、書ける範囲で書いておくとよいのではないかなと思います。

ひとりで完璧な解説を書ききる必要はないので、ご自身のできる範囲でだいじょうぶです。

akinomyoga commented 2 weeks ago

実装がないのに間違いのないようにしようと思うと厳しくなるので、余り悩まずに但し書きでその旨 (処理系がないのでコード例は想像である旨) 触れておけば良いと思います。

sukeya commented 2 weeks ago

コメントありがとうございます。間違っているコードを載せるのも誤解を招きそうなので実装されてからでいいかなと思ってましたが、注意書きを入れた上でできる限りサンプルコードを書こうと思います。 (linalgが実装されるまでに忘れてそうですし😅)

onihusube commented 2 weeks ago

NVC++だと実験的ながら<linalg>実装されてるみたいですね（どこで利用できるのかはともかく・・・ https://docs.nvidia.com/hpc-sdk/compilers/hpc-compilers-user-guide/#stdpar-cpp-linear-algebra

kokkosにも実験実装があったのでこっちなら頑張れば動かせるかも・・・？ https://github.com/kokkos/stdBLAS/tree/main

faithandbrave commented 2 weeks ago

https://godbolt.org/

Compiler ExplorerでMSVCの実行ができるようになったとのことで (最近はコンパイルまでしかできなかった)、これで動作確認が捗りますね。

https://x.com/CompileExplore/status/1803618566375174590

The Microsoft C & C++ compilers are back on the site, and are now running on CE's own infrastructure. That means execution is back! Huge thanks to MS & the whole CE team for this group effort. We are still working on bringing libraries back Let us know if you hit any issues.

日本語：

マイクロソフトのC＆C++コンパイラがサイトに戻り、CE独自のインフラで動作するようになった。つまり、実行が戻ってきたということだ！MSとCEチーム全員に感謝します。私たちはまだライブラリの復旧に取り組んでいます。何か問題がありましたら、お知らせください。

cpprefjp / site

cpprefjp雑談部屋 #1273