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検索結果で最も見せたいであろうタイトルが切れてしまう懸念があります。
|
|
ありがとうございます! その形式で良いと思います! |
|
目を離した隙に一気に話が進んでました・・・。 そうですね、今だと初見ではそのページに加えて何を読むべきなのか見抜けない可能性があるので、そういう警告をつけるのはいいかもしれません。 |
|
issue化しました！ |
|
サンプルコードのコーディングスタイル修正にルールはありますか。
$ 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] が…。 因みに「規格がこの部分だけ |
|
とくにルールがないところなので、編集合戦にならない (無相談修正で争いごとに発展させない) レベルの修正ならさっとやってしまってよいと思います。 |
|
ありがとうございます! |
|
https://cpprefjp.github.io/reference/linalg/add.html この関数は、 |
|
全部 |
|
|
|
#1276 (comment) のために cpprefjp の Google 検索を使ったのですが、サイドバーに含まれる語にもヒットして情報が探しにくいです。。。 ページの一部をインデックス対象から除外する方法はないのかと思ったのですがない? そもそもサイドバーの内容はページのソースに含まれていなくて動的に生成されている筈なので、Google のクローラーは JavaScript 実行して動的な内容も記録する (ようになった) ということなのでしょうか。もしそうだとしたら、User-agent か何かで判定してサイドバーの生成を抑制できたりするのでしょうか。 |
|
linalgヘッダのアルゴリズム群は、実利用ケースの挙動説明が難しいんですよねぇ... 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);（脳内コンパイルなので多少怪しい...） |
|
皆さんのご意見をお聞きしたいのですが、どのコンパイラも実装していない機能のページを書く時、サンプルコードを書いた方が良いでしょうか？ |
|
私としては、仕様理解のため、使用上の注意を経験した上で概要・備考を書くためにも、脳内コンパイルでもサンプルコードは書いたほうがよいと考えています。 ひとりで完璧な解説を書ききる必要はないので、ご自身のできる範囲でだいじょうぶです。 |
|
実装がないのに間違いのないようにしようと思うと厳しくなるので、余り悩まずに但し書きでその旨 (処理系がないのでコード例は想像である旨) 触れておけば良いと思います。 |
|
コメントありがとうございます。 |
|
NVC++だと実験的ながら kokkosにも実験実装があったのでこっちなら頑張れば動かせるかも・・・？ |
|
Compiler ExplorerでMSVCの実行ができるようになったとのことで (最近はコンパイルまでしかできなかった)、これで動作確認が捗りますね。 https://x.com/CompileExplore/status/1803618566375174590
日本語：
|
|
@suomesta |
|
返事遅れて申し訳ありません。 |
|
消しましたー |
|
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 に変わったと言っても、単に名前が変わっただけで鼻から悪魔なのは変わりないです。 |
cpprefjp雑談部屋ルール
The text was updated successfully, but these errors were encountered: