cpp-book
cpp-book copied to clipboard
rinatz
ゼロから学ぶ C++
配列の要素数
配列の要素数を取得する方法として [`std::extent`](https://timsong-cpp.github.io/cppwp/n3337/meta.unary.prop.query) もあります。 これは C++11 でも使えるので紹介してはいかがでしょうか。
#67 ではStrict Aliasing Ruleについて論じたが、以下のキャストはそもそもpointer interconvertibleではないからStrict Aliasing Rule以前の問題だとする指摘がなされた。 ```cpp class A {}; class B {}; A a; B* b = reinterpret_cast(&a); ``` そもそも元スレのreinterpret_cast式は現在のWDによるといわゆるstrict aliasing ruleで定義されてません。pointer interconvertibleを満たさない場合には意味がすでに必要とされてないため、文面通りの「未定義行為」です。— g_naggnoyil(gint, gchar **) (@gnaggnoyil) November...
https://rinatz.github.io/cpp-book/ch04-01-declarations-and-definitions/ では > 定義は重複が許されません。 とあり、それ自体は正しいのですが、`inline`指定されたとき、同一定義であれば重複していいというのが関数については古くから、変数についてはC++17からあります。~~これをスルーしてしまうとtemplateが説明できなくなります(ちらっとtempalteの説明を見た感じinline 指定が必要という誤った解説がされていたり関数テンプレートをやめてオーバーロードを使うなどというとんでも議論がされていてますがこれはまた別の話)~~
netlify.comを使うとPRに対して自動的にpreview用のWeb siteを作ってくれる。 例としては asciidwango/js-primer#1005 というPRに対してbot-userが生成完了を教えてくれて https://deploy-preview-1005--js-primer.netlify.com/ みたいにPR番号を含むURLを吐いてくれる。 レビューしやすくなるのではないか。 ビルドはGithub Actionsにやらせて成果物をそのまま投げればいいと思われる ref: [Netlifyに7ドル支払った話（GitHub ActionsでNetlifyにデプロイする）](https://blog.70-10.net/2020/05/31/github-actions-deploy-netlify/) ・・・ところで今って`gh-pages`へのデプロイは手動だったりしますかね・・・？
そもそもなんで継承の説明のところにアクセス指定子の話がいるのか見当もつかないのですがそれはさておき。 https://rinatz.github.io/cpp-book/ch07-03-inheritance/  この表の意図が理解できません。多分左側がメンバーに対するアクセス指定子で、上の「継承したクラス」というのはpublic継承したときのことで、「その他」とはクラスの外から見た時の話だと思うのですが、まったく理解できません。 メンバーに対するアクセス指定子の話はもっと最初の https://rinatz.github.io/cpp-book/ch07-01-member-variables/ あたりでしておくべき話で、そうすると自然と https://rinatz.github.io/cpp-book/ch07-11-structs/ の内容が統合され #65 も解決して万々歳となるのではと思います
https://rinatz.github.io/cpp-book/ch07-11-structs/ C++において構造体は存在しません。`struct` keywordと`class` keywordではアクセス指定に差があるのみです。解説文自体は正しいですが、項目の存在自体が、C#のそれのようなものと誤認させます。つまり`struct`を構造体と翻訳することそのものに問題があります。
C++11ではCとのデータ構造互換を考える時に、これまでPODという概念を用いていたのをtrivial classとstandard-layout classに分離し、さらにtrivial classよりゆるい制約としてtrivially copyable classという概念を導入した。本当に必要な制約はtrivially copyable classまたはstandard-layout classであるため、PODはC++20でdeprecatedとなった。 したがってPODとはC++考古学の範疇であり、新たに説明するのは望ましくない。 ref: - #40 - #41 - https://cpprefjp.github.io/reference/type_traits/is_trivially_copyable.html - https://github.com/cpprefjp/site/pull/768 - [C++における標準レイアウトクラスの定義 - Qiita](https://qiita.com/nus_miz/items/d09bfda40d5cc0866675)
https://rinatz.github.io/cpp-book/ch06-02-new-and-delete/ でnew/deleteの解説がされています。 解説文で > new を利用して確保したメモリの解放を忘れるとメモリリークになります。 new と delete は必ずセットで使いましょう。 と書いているにもかかわらず、そのすぐ上のサンプルコードはメモリーリークしています(p1が開放されない)。 ```cpp int* p1 = new int(100); int* p2 = new int[5];// MEMORY LEAK!!!!! delete p1; // new によって確保されたメモリを delete...
https://rinatz.github.io/cpp-book/ch02-09-function-objects/ > std::function で関数ポインタやラムダ式を保持することが出来ます。 std::function を使うことで、関数ポインタのような複雑な構文が簡潔になるという利点もあります。 という説明では、「じゃあ全部std::functionを使えばいいのか！」というミスリードをしかねないという印象を受けます。最適化を阻害するというデメリットを語らないのはフェアではないように感じます。 また、std::functionのメリットが簡潔に書けるだけというのも違う気がします。それだけならusing aliasで型定義すれば済むはず。そうではなくて、型消去によって関数オブジェクトを配列に格納できるということが利点であるはずです。lambda式を含む関数オブジェクトは、引数と戻り値の型が一致していても別の型をもつため、配列に格納できないところを、型消去してくれるstd::functionによって達成できるわけですよね。
https://rinatz.github.io/cpp-book/ch03-08-iterators/ ポインタはイテレータでもある。実際、`std::initializer_listの`begin`/`end`はポインタを返す。 イテレータを使用できるコンテナにC形式の配列がないのも気になる。そのための`std::begin()`/`std::end()`であるはず