57
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Day 6

C++ Advent Calendar 2025

@wx257osn2

Re: C++は常に進化している！ C++26・C++23の新機能と今後のトレンド

57
Last updated at Posted at 2025-12-06

はじめに

2025年12月6日16時34分現在，Google日本語検索でC++26と検索したときの結果が以下である:

image.png

検索結果の2つ目，『C++は常に進化している！ C++26・C++23の新機能と今後のトレンド』はC++標準規格の機能策定の大雑把な流れやコンパイラのサポート状況，C++23やC++26の言語機能についての俯瞰などを含む11月に公開された記事であり，Qiita上では101いいねと88ストックを得ている．
世間の人々はそれなりに最新C++に対して興味があるらしい．喜ばしいことだ．

などと，諸手を挙げて喜べれば良かったのであるが．
残念ながら，現状は憂うべき状況である．
何故なら，Google日本語検索においてC++26の検索結果の2つ目という一等地に座しているのが不備と誤りに塗れたトンデモ記事なのであるから――

I(@wx257osn2)です．Qiitaで記事を書くのは7年ぶりでしょうか1．
本稿では，11月に公開された記事『C++は常に進化している！ C++26・C++23の新機能と今後のトレンド』(以下Sakai_path2025)について，その内容の不十分な箇所や誤った箇所を示し，内容の補足と訂正を行います．
後述するように当該記事には一貫性に欠ける記述や事実と異なる記述が散見される(特にC++26の章は正しい記述を見つけるほうが困難なレベルな)のですが，これが多くの日本語話者に支持され，あまつさえC++26の日本語記事として代表のような扱いを受けている現状は危惧すべきことだと考えています．
またこれも後述しますが，私からするとそもそも技術記事の執筆姿勢としてかなり問題のある記事だという認識です．
本稿の内容によって，皆様のC++に対する認識が少しでも正しいものとなること，そして技術記事執筆に対するより良い姿勢が広まることを祈っています．

なお，本稿で対象とするSakai_path2025は11/9の版となります 11/9版を最後に削除されたため不要な注釈 ．
念の為以下にWayback Machineでの当該記事を置いておきます: https://web.archive.org/web/20251202164429/https://qiita.com/Sakai_path/items/24537a84c2437e9e527f
Wayback Machineも消し飛んでしまったので，中国語に(たぶん勝手に)翻訳されたページをGoogle Translateで日本語に再翻訳した記事を置いておきます(翻訳元の記事の寿命が心許ないですが…): https://codelove-tw.translate.goog/@tony/post/awo8Pa?_x_tr_sl=zh-TW&_x_tr_tl=ja&_x_tr_hl=ja&_x_tr_pto=wapp
手元のスマホから元記事を発掘できたのでバックアップを置いておきます: https://qiita.com/wx257osn2/private/6a9b3c6c866358f36243

記事全体の問題点

そもそもなのですが，おそらくSakai_path2025はAI生成記事です．しかもほぼポン出しで人手のレビューは行っていないものと推測されます．
(2025/12/10追記: 推測しましたが，氏曰く人手の調査とAI生成物のハイブリッド記事とのこと．AI生成物パートが目につきまくってしまった結果見誤りました．内容が誤っているのはシンプルにレビューをするための知識を持ち合わせていなかったことによるものらしく，少なくともポン出しではないそうです．上記推測については訂正します)
理由としては(仔細は「記述個別の問題点」の章で扱うとして，おおまかには)以下のとおりです:

  • 全体的に情報が古い．2025年11月時点の情報でない
  • 関連する情報についての記述が甘く，その結果文章構成が滅茶苦茶になっている箇所もある
  • 明確な誤りが含まれている
    • これについてはAIのハルシネーションであると信じたい．さもなければ明らかな捏造になってしまうので…
  • 情報をまとめた記事でありながら参考文献がほぼ無い
    • Web上の技術記事ですので参考文献の形でまとめていなくとも，リンクくらいは記事中から複数貼るべきでしょう
    • cppreferenceや提案文書など参考にした情報があるならいくらでも貼れるはずです

このように人間が理解して書いた文章とは思えない箇所が散見されます．
C++ AdC 2025ではAI製の記事による参加をご遠慮いただいておりますが，このような記事が増えることを避けたいというのがその趣旨の一つでありました2．

さて，仮にAI製の内容を含む記事であった場合，当該記事はQiitaのコミュニティガイドラインに反する記事となります:

☝ AIが生成した内容は正確性を確かめよう

記事等の執筆に便利なAIツールを活用することそのものは禁止していませんが、AIが生成した内容は、そのまま投稿するのではなく、正しいかどうかを検証した上で投稿するようにしましょう。 Qiitaで提供しているAI機能を利用する場合も同様です。 正確ではない情報が投稿されることは、コミュニティにとって望ましいことではありません。内容に責任をもって投稿しましょう。

そしてもし人手で書いたものであった場合，どのような機序で捏造と言われても仕方ないレベルの誤りが含まれるに至ったのか本当にわからないのですが，いずれにしても当該記事のような事実確認があまりにも杜撰な記事は望ましくないでしょう．

別の視点で捉えてみると，もしAI製の記事なのであれば2025年の年の瀬時点でのAIは所詮この程度だ3，というベンチマーク的記録と見做すことができるかもしれません．
特に上述のようにC++26に関する記述は概ね全て間違っているのですが，よく言われるようにAIは最新情報のキャッチアップは苦手ですから，無策で最新情報を出力させようとするとこのようになってしまうという典型的な症例として，当該記事に一定の価値を見出すこともできます．

いずれにしても，Sakai_path2025が そのような 記事である，ということを，正しい情報とともにお伝えするのが本稿の主たる目的であります．

記述個別の問題点

「2025年11月時点の情報」という記述

記事内で類似の注釈が4回ほど出てくるのですが，このような記述は記事の内容が誤っていることに対する免罪符にはなりません．
この記述の意味するところは「この記事は2025年11月時点の情報である」という字義通りの意味であって，2025年11月時点で最新でない情報を載せたり，そもそも全く誤った情報を載せた場合をカバーするものではないです．
なんならSakai_path2025のような多数の誤りや時代錯誤が含まれる記事でこのような記述があると，記載内容が事実でないにもかかわらず記事執筆時点での最新情報かのように読者に誤解させるため，悪質ですらあります．

「現在のC++エコシステム」

近年，一般に「プログラミング言語のエコシステム」と言った場合，コンパイラやビルドツール，パッケージマネージャやパッケージレジストリ，LSPやlinterなどの開発ツール群や，ライブラリ・フレームワークなど，開発に関わるソフトウェアの総体を指すことが多い，というのが私の認識です．
したがって誤りとまでは言いませんが，C++標準規格とTSの関係性を指して「C++エコシステム」と呼称するのはかなり独特なワードチョイスに感じます．

「コンパイラサポート状況」

コンパイラのバージョンが古すぎます．
2025年11月現在の内容なのであれば，どうして2025年11月リリースのMSVC 18.0に関する記述が無いのでしょうか．ホットトピックでしょうに．
他のコンパイラも同様です．GCC 14.2のリリースは昨年8月，Clang 18に至っては昨年3月です．
最新のコンパイラバージョンで書くならそれぞれGCC 15.2, Clang 21.1，MSVC 18.0となるはずです．
もし仮に，例えば広く普及しているコンパイラバージョンを選んだほうが多くの読者にとって有益だろう，といった理由をもって少し古いバージョンのコンパイラで執筆するのであれば，そのような選択事由を明記すべきです．

また，MSVC STLはMSVCとは独立にGitHub上で開発されており比較的開発スピードが速いです．
実際にC++23の機能で部分的にlibstdc++(GCCのC++標準ライブラリ実装)やlibc++(Clangの標準ライブラリ実装)より実装が進んでいる機能もあることがcppreferenceのページからもわかります．
コア言語の実装が現状両者に比べて劣っているのは事実ですが，ライブラリ部分についても同様かのように記述するのはフェアではないでしょう．

C++26の機能についての記述も一貫性に欠けます．
-std=c++2c が必要なのはClangも同じです．MSVCも /std:c++latest が必要です．
また，Clangも18の時点でplaceholder変数(P2169R4)などを実装していますし，最新のClang 21ではGCC 15と肩を並べる程度には実装が進んでいる印象です．
MSVCはコア言語はまだまだのようですがライブラリ側は先述の通り実装が速いので，C++26対応も進みつつあるようです(例えば記事に記載の17.11であってもライブラリ側はC++26の機能が少し実装されていることがわかります)．
あと「拡張機能レベル」というのはなんなのでしょうか．聞き馴染みのない単語ですが…

「2.1 std::expected - エラーハンドリングの革命」

サンプルコードのコンパイルが通りません．
2.2の節で紹介している std::println を使っているのに， <print> ヘッダのincludeを忘れているためです．
サンプルコードはコンパイルをしましょう．

「2.2 std::print / std::println - 型安全な出力」

たしかにC++23の目玉機能の1つではあるのですが，C++20の時点で std::format が実装済みです．
したがって，極端な話 std::cout << std::format("type {} format!", "safe"); のようなことをすればC++20時点で型安全なフォーマットによる標準出力は実現できたわけです(もちろん std::print に比べれば不格好ですが)．
C++23がまだ使えない環境であってもC++20さえ使えれば標準で型安全なフォーマットが可能であることは読者によっては重要な情報のはずです．
この事実に言及すること無くC++23でようやく，のような表現はやや不親切と言えるでしょう．

「2.3 deducing this - メソッドチェーンの簡潔化」

deducing thisについてはC++ Advent Calendar 2022 1日目の記事が詳しいので，そちらを参考にしていただければと思います．

さて，この節の記述にはかなり問題があります．
というのも，序文では「CRTPが不要になります」としておきながらCRTPについての説明が一切無いのです．
この「一切」というのは，サンプルコードも含みます．サンプルコードで示しているのはdeducing thisの最も一般的な利用方法であり，CRTPとは全く無関係です．
当該の記述は一見すると，サンプルコードで行っているようなメンバ関数を参照修飾子毎に書き分けなければいけないことをCRTPと呼ぶかのように見えますが，違います．
この記事にCRTPに関する言及はこの一文しか存在しません．
おそらく，筆者自身CRTPとはなんであるかわからない状態で記事を公開したものと思いますが，わざわざ新しい単語を導入するのであればその単語について説明すべきでしょう．

ちなみに，deducing thisによってCRTPが不要になる，これ自体は部分的に事実です．
というわけで，CRTPについて本稿で補足説明をしておきましょう．

CRTPについて

CRTP(Curiously Recurring Template Pattern: 奇妙な再帰テンプレートパターン)とは，基底クラスに派生クラスの型情報を渡しておくことで，基底クラスで派生クラスの情報を用いたコードを書くことができるイディオムです．
具体的には以下のようなコードになります(wandbox):

従来のCRTP
#include <print>

template<typename Derived>  // template引数で継承先の型を取る
struct base{  // 基底クラス
  // 基底クラスでprintメンバ関数を実装しておき
  void print()const{
    // その中でtemplateパラメータを使って派生クラスのメンバ関数にアクセス
    std::println("{}", static_cast<const Derived&>(*this).f());
  }
};

struct S : base<S>{  // 自身をbaseのtemplateパラメータに渡して継承
  int f()const{  // fを実装しておく
    return 42;
  }
};

struct T : base<T>{
  float f()const{  // fの戻り値型は(printでの使われ方から)intでもfloatでもOK
    return 3.14f;
  }
};

int main(){
  S s;  // base<S>をpublic継承しているのでprintメンバ関数が呼べる
  s.print();  // 42
  T t;
  t.print();  // 3.14
}

この「継承時にtemplateパラメータとして自身を渡す」「基底クラスで本来知り得ないはずの継承先の型を使える」という辺りがCRTPの妙となります．
そして，deducing thisを使うことでCRTP無しに同様のことが可能になります(wandbox):

deducing thisを用いた場合
#include <print>

struct base{  // 基底クラスはtemplateパラメータを取らない
  // printメンバ関数でdeducing thisを取る
  void print(this auto&& self){
    // deducing thisで受けた引数は派生クラスの型を持つので，メンバ関数にアクセス可能
    std::println("{}", self.f());
  }
};

struct S : base{  // 単にbaseを継承すれば良い
  int f()const{  // fを実装しておく
    return 42;
  }
};

struct T : base{
  float f()const{
    return 3.14f;
  }
};

int main(){
  S s;
  s.print();  // 42
  T t;
  t.print();  // 3.14
}

これが，

CRTP（Curiously Recurring Template Pattern）が不要になります

の意味するところです．
ちなみにdeducing thisはメンバ関数内でしか扱えないので，メンバ関数外で派生クラスの要素を使いたい場合(例えば派生クラスの持つメンバを用いて基底クラス側でメンバ型を定義するなど)には引き続きCRTPが必要になるはずです．
本来はSakai_path2025においてこのような説明がなされるか，あるいはCRTPについて触れないでいるべきでした．

「2.4 std::mdspan - 多次元配列ビュー」

std::mdspan はメモリブロックを多次元配列のようにアクセスする機能を提供します．

科学計算やゲーム開発で頻繁に使用される行列演算をサポート

これは誤りです． std::mdspan それ自体は行列演算の機能を提供しません．
行列演算の機能，例えば密行列積などはC++26で採択された提案P1673R13によって提供される <linalg> というヘッダで提供される別の機能となります(こちらで提供される関数が std::mdspan を引数に取る形)．

<linalg> については，cpprefjpなどを参照してください．
また， <linalg> の実装を通して内実を探る記事がC++ Advent Calendar 2024 2日目にありますので，興味のある方は読んでみるとよいでしょう．

「3. C++26の革新的機能（プレビュー）」

(プレビュー)

って何？

また，紹介する機能のチョイスもなんだか不思議なメンツです．

特に注目されているのは、メタプログラミングを大幅に簡素化する機能群

という切り口なので仕方ないのかもしれませんが，C++26で多くの人から待ち望まれてる紹介しがいのある機能といえばContracts(契約プログラミング，P2900R14)ではないのか…？という気持ちになりました．ちなみにSakai_path2025で挙げられている機能のうちC++26入りが決定したのは後述するように静的リフレクションのみですが，Contractsは他2つとは異なりC++26入りが決定しています．

「3.1 静的リフレクション - メタプログラミングの新時代」

いつの提案文書から引っ張ってきたのかわかりませんが，最終的にC++26に通った提案(P2996R13)とは構文が全く異なります．
P2996R13は6月に可決されていますので，提案・審議中の内容ではなく，仕様・構文・名称が変更される可能性は(よほど致命的な問題が生まれてCWG行きしない限りは)ほぼ無いと考えてよいでしょう．
ですから，可決から5ヶ月経ってまるでデタラメなサンプルコードを書いておきながら「将来的には構文が変わるかも」などと宣っても，言い訳にはなりません．誤りです．

Sakai_path2025に記載の serialize_to_json を採択された構文で記述すると以下のようになります(Compiler Explorer):

template<typename T>
constexpr void serialize_to_json(const T& obj) {
    std::print("{{");
    bool first = true;
    
    template for (constexpr auto member :
                      std::define_static_array(
                          std::meta::nonstatic_data_members_of(
                              ^^T, std::meta::access_context::current()))) {
        if (!std::exchange(first, false)) std::print(", ");
        
        std::print(R"("{}": )", std::meta::identifier_of(member));
        serialize_value(obj.[:member:]);
    }
    
    std::print("}}");
}

「3.2 パターンマッチング - より表現力豊かな分岐」

この節には3つの問題があります．
ですが具体的な問題点について詳らかにする前に，C++におけるパターンマッチングの提案文書について見ていきましょう．
C++のパターンマッチ構文に関する提案文書は3つあります: P1371R3, P2392R3, P2688R5です．
それぞれ提案する構文が異なり，Sakai_path2025に記載の例で行くとそれぞれ以下のようになるはずです(いずれも脳内コンパイラでのチェックなのでやや自信がないですが…):

P1371R3
std::variant<int, double, std::string> value = 42;

inspect (value) {
    <int> i => std::println("整数: {}", i);
    <double> d if (d > 0) => std::println("正の実数: {}", d);
    <std::string> s => std::println("文字列: {}", s);
    __ => std::println("その他");
}

struct Point { int x, y; };
std::optional<Point> maybe_point = Point{10, 20};

inspect (maybe_point) {
    (*?) [0, 0] => std::println("原点");
    (*?) [x, y] if (x == y) => std::println("対角線上: {}", x);
    (*?) [x, y] => std::println("点: ({}, {})", x, y);
    __ => std::println("なし");
}
P2392R3
std::variant<int, double, std::string> value = 42;

inspect (value) {
    as int i => std::println("整数: {}", i);
    as double d && if d > 0 => std::println("正の実数: {}", d);
    as std::string s => std::println("文字列: {}", s);
    is _ => std::println("その他");
}

struct Point { int x, y; };
std::optional<Point> maybe_point = Point{10, 20};

inspect (maybe_point) {
    is [0, 0] => std::println("原点");
    as Point [x, y] && if x == y => std::println("対角線上: {}", x);
    as Point [x, y] is _ => std::println("点: ({}, {})", x, y);
    is _ => std::println("なし");
}
P2688R5
std::variant<int, double, std::string> value = 42;

value match {
    int: let i => std::println("整数: {}", i);
    double: let d if (d > 0) => std::println("正の実数: {}", d);
    std::string: let s => std::println("文字列: {}", s);
    _ => std::println("その他");
}

struct Point { int x, y; };
std::optional<Point> maybe_point = Point{10, 20};

maybe_point match {
    ? [0, 0] => std::println("原点");
    ? let [x, y] if (x == y) => std::println("対角線上: {}", x);
    ? let [x, y] => std::println("点: ({}, {})", x, y);
    _ => std::println("なし");
}

上記からわかるように，Sakai_path2025の記述はP1371R3をベースとしたものであることが推測できます．

それでは問題点なのですが，まず第一にSakai_path2025の記述はP1371R3に厳密に沿っていません．具体的には，wildcard patternが __ ではなく _ であることや， std::optional に対してalternative patternを使用している点4などです．
この時点で提案文書が上手く読み込めていないことがわかります．

次に，仮にSakai_path2025内のサンプルコードがP1371R3の構文で正しく記述できていたとして，P1371R3は採用されないことが既に決まっている点です．
既に何度かリンクで示した通り，C++の規格に対する提案文書はGitHub上で管理されているのですが，P1371R3に対するチケットは去年の時点でcloseされています．
つまり，2024年11月の時点でP1371R3の構文にならないことはわかっていたことです．

そして最後に，そもそもパターンマッチ構文はいずれもC++26に入らないという点です．
現時点ではP2392R3とP2688R5でどちらの構文を採用するのか確定していない5よう(実際にP2392R3のチケットもP2688R5のチケットもopenのまま)ですが，Herb Sutterも6月のtrip reportで

Today the ISO C++ committee completed the feature freeze of C++26, in our meeting in Sofia, Bulgaria.(拙訳: 本日(訳註: 2025/6/21)C++標準化委員会はブルガリアのソフィアで開催された会議でC++26の機能を凍結しました．)

と述べている通り，C++26に対する機能追加は既に打ち切られています．
また6月にP2688R5のチケットにC++29のラベルが付与されていることからも分かる通り，パターンマッチ構文は現在C++29に向けて議論が進められており，C++26の新機能としてお目見えすることはありません．

「3.3 std::embed - コンパイル時リソース埋め込み」

Sakai_path2025において最も重篤な節です．
この節も2つの問題を抱えているので順に述べます．

まず， std::embed の紹介に当たって #embed について一切触れていないのが最初の問題です．
#embed はC23で提案されたプリプロセスディレクティブで，ファイルをバイナリデータとしてソースコードに埋め込みます．つまり:

constexpr uint8_t icon[] = {
#embed "file.png"
};

のようにすることで， file.png の中身をあたかもソースコード上に記述したかのようにプログラムに埋め込むことが可能になります．
そして，C++26において #embed を導入する提案P1967R14が採択されました．
しかし， #embed はプリプロセスディレクティブです．
したがって，上述の例では file.png の中身がプリプロセス時に展開されます．
尤も実際にコンパイラがファイルの中身を(例えばカンマ区切りの16進数値列のような形で)大量のトークンとして展開するわけではないのですが6，少なくともコンパイル時のAST上にはバイナリファイルのデータが載るわけです．
一方P1040R8で提案されている std::embed は(内部実装はコンパイラマジックの)ライブラリ関数ですから，AST上も関数呼び出しのノード1つで済みます．
結果的にstd::embed の方がファイルサイズが大きい(数百MB～GBクラスの)ファイルを相手にしたときに #embed に対してコンパイル時の時間・空間性能が良いことが提案文書でも報告されており，この点が #embed よりも std::embed の優れている点の1つです．
他にも取れる引数の違いなどもありますが，ここでは割愛します7．

ともかく， std::embed とよく似た #embed という機能があり，こちらは既にC++26入りが決まっているのに対して，std::embed はまだ提案中の段階です(概ね採択の流れのようではありますが)．
上述のようにC++26の機能は6月に凍結済みですので，やはり std::embed についてもC++26には入りません．
この状況でC++26の機能として #embed を紹介すること無く，未採択の std::embed のみを紹介しているのは明らかに不適切でしょう．

さらに，次がSakai_path2025最大の問題なのですが，サンプルコード上に 過去一度も提案されていないAPIが記載されています (当該記事が削除されたため，Webの汚染を防ぐために明記していた存在しないAPI名を削除しました．気になる方は下のリンクをクリック)．
試しに当該記事に記載されていた存在しないはずの関数名をGoogleで調べてみるとわかりますが，std::embed の検索結果と異なり提案文書が検索結果に出てこない，どころかわずか8記事しかヒットしないことがわかります(他の記事はいずれも std:: の付かない変数名がひっかかっていたり，Rustの同名のマクロだったり，Sakai_path2025の中国語翻訳記事だったりです)．
そしてその最上位に出てくるのがSakai_path2025です．
それもそのはず，当該APIはSakai_path2025が初出なのですから．

提案されていないAPIを提案されたと主張するのは，捏造と言って差し支えないでしょう．
おそらくAIのハルシネーションをそのまま出したのだろうと思いますが，内容に責任を持つのは著者の務めです．
また，こうした誤った情報がAIに学習されたり検索に残ることで世界の情報はどんどん歪められていきます．
技術記事の態度としても社会への影響の観点でも非常に問題だと思います．

「4. C++とRust/Carbonの共存戦略」

全体的に何を言いたいのかよくわからない章です．
「【現実的な使い分け】」の項で

// パフォーマンスクリティカルな部分はRustで

とありますが，C++ベースのコードでパフォーマンスクリティカルな部分だけRustに切り出すというのは…まぁ無いとは言い切れないと思いますが，かなりレアケースだと思います．あまり現実味を感じません．
C++とRustを共存させる場合，むしろベースはRustで，よくチューニングされたC++製の既成ライブラリをRustにバインディングするとか，GPUを使いたいのでCUDAやOpenCLを叩く部分だけC++で実装してRustから呼ぶとか，Rustではまだ扱えないArm SVEをC++側で書いてRustで呼び出すとか，そういうケースが殆どではないでしょうか．
つまり， パフォーマンスクリティカルな部分こそC++を使う という形が(現時点では)圧倒的に多数だと思います．

もちろん現時点でのRustはMIRを経た強力な最適化機構を持ち，シンプルなコードと高速な動作の両立がC++よりも容易なのは事実です．
ですが，本当に切り詰めたときのC++はやはり強力であり，少なくともRustで出せる実行時性能は(そのためにかかる労力には大きな差こそあれど)C++でも出せる，はずです．
さらにC++は高度に抽象化されたコードから数多のアクセラレータへアクセスできますから，(純粋な実行時間のみならず，ワットパフォーマンスなども加味すれば)Rustより性能を出せる環境は多いと言えます(この差はRustコンパイラの開発や各種ベンダーのRustサポートが進むことでいずれ縮まっていくと思いますが)．

どちらかというと現時点でC++アプリケーション上に部分的にRustを持ち込むのは安全性とかRust製ライブラリを呼びたいとか汎整数拡張の無い整数演算がしたいとかそういった理由が主になるのではないかと思います．

また，「【移行戦略の実例】」では何故か章の冒頭で出てきたCarbonは出てこず，代わりにGoが出てきます．
Carbonはいつどのように実用されるのか全く述べられていません．
というか，章のタイトルが「共存戦略」なのに移行しないでください．
この辺りも一貫性に欠けた記述です．

「5. 実践的なC++23/26導入ガイド」

ガイドと言いつつ特にガイドしていません(単に CMakeLists.txt のサンプルが置いてあるだけです)．
また，

以前は -fcoroutines などの試験的フラグが必要でしたが、C++20以降では不要です。

とありますが，これは各処理系でC++20の機能が安定化したからであり，C++26の実験的な機能を使う際は2025年11月現在でも引き続き必要になることもあります(例えば template for のための -fexpansion-statements や契約プログラミングのための -fcontracts など)．

まとめ

以上のように，Sakai_path2025は誤り・一貫性に乏しい記述・不親切な記述などが多数含まれる記事でした．
本稿では当該記事と合わせて読むことで正しい理解や適切な理解の助けとなることを目的として，そうした問題点について指摘や補足を行いました．
本稿によって皆様が正しい情報を得て世に溢れる謬説を見極められるようになること8，そして技術記事の執筆に対して真摯な姿勢で臨まれることを祈っています．

本稿は公開前に@onihusube9さんにレビューいただきました．ありがとうございました！

  1. ここ数年はZennで記事を書いていました．何故久々にQiitaで筆を執ったかといえば，Sakai_path2025の読者にこの記事を届けるためにはQiitaで執筆したほうが目に入りやすいだろう，という考えからです．つまりこの記事限りであって，他にここで何か執筆をする予定はありません． ↩

  2. 念の為補足ですがSakai_path2025自体はC++ AdC 2025参加記事というわけではないです．それ故，Sakai_path2025がAI生成記事であることそれ自体を批判するものではないことに注意してください(レギュレーションの対象ではないのでAI生成記事を投稿すること自体は自由にすれば良いと思います)．本稿は事実でないことを事実であるかのごとく喧伝していることを強く，そしてあまり適切でない・親切でない記述をやや問題視しています． ↩

  3. どんなモデルとプロンプトで生成したのかはわからないので，「最先端モデルをちゃんと使えばここまで酷いことにはならん」という反論もあろうとは思いますが，多くの人々はそこまで真剣にAIと向き合ってないからこういう記事が生まれてしまうわけで…市井の人々のユースケースという観点で言えばこの程度なのではないでしょうか． ↩

  4. 私の認識が正しければ， std::variant-likeでも std::any-likeでもpolymorphic typeでもない std::optional はalternative patternの対象ではないはずです． ↩

  5. いずれの提案も現時点でコンセンサスが取れていない，つまり標準化委員会内でのレビューを受けた提案文書の改定が必要な状態 ↩

  6. この辺の挙動は処理系にとって都合のいい方法を取って良いことになっているようで，実際にそのような展開をするとあまりにも過負荷なので(少なくとも提案文書においては)もう少し穏当な方法で扱うことを念頭に置いている様子 ↩

  7. ちなみに歴史的経緯を話すと std::embed が最初に提案され，紆余曲折あって #embed が派生し，そちらが先にC/C++双方に採択されたという流れがあります．なのでpaperの番号は std::embed の方が若い(P1040R8)ですが #embed (P1967R14)が先に採択されているんですね． ↩

  8. 本稿では具体的な証拠(標準化委員会の提案文書やその進行チケット)をもってSakai_path2025の誤りを示しました．本稿で具体的に「謬説を見破る方法」を解説したわけではないですが，リンク先は一次情報ですから，その周辺情報を眺めることでみなさんも正しい情報を得ることが可能になるはずです． ↩

57
27
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
57
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?