C++相談室 part163

2022/12/30(金) 23:16:31.37

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

※前スレ
C++相談室 part162
https://mevius.5ch.net/test/read.cgi/tech/1667194175/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2022/12/30(金) 23:48:59.52

≫1 << 乙 << endl;

2022/12/31(土) 09:58:55.55

皆さまあけましておめでとうございます
今年もよろしくお願いします
今日も今日とて相談がございます

基底クラスのポインタを格納できるコンテナに押し込んだ派生クラスへのポインタから、その派生クラスのインスタンスをユニークポインタで生成し、それを規定クラスのユニークポインタに押し込んで使いたいです
std::vector<Base*> BaseCnt;
Driv1 Driv1_;
Driv2 Driv2_;
Driv3 Driv3_;
BaseCnt.push_back(&Driv1_);
BaseCnt.push_back(&Driv2_);
BaseCnt.push_back(&Driv3_);
～数々の名誉ある処理を挟んで……～
std::unique_ptr<Base> BaseUni;
BaseUni=どうにかして実体をユニポで生成する関数(BaseCnt.back());
BaseUni->Update();//ここで望んでいる挙動はDriv3のオーバーライドでございます

上記の、どうにかして実体をユニポで生成する関数、が実現できなくて困っています
template<typename T>
std::unique_ptr<Base>&& theFunc(T*t)
{
return std::make_unique<T>();
}
で行けるのかなと思いましたがいけませんでした(^^)……
そもそも基底クラスに押し込んであるため、T型で受けると基底型になってしまいます（＾_＾）……
どうにかして派生クラスにメモリを確保し、かつそれを規定クラスのユニークポインタに押し込めないものでしょうか？

このままでは年が越せない……
どうかおしえてください
私はc++プリミティブの混乱予約型言語でございます……

2022/12/31(土) 10:30:40.33

うだうだ長文書かんとコード全体をwandboxなりideoneなりに書いてくれや
Updateにvirtualついてないとかだったら張っ倒すぞ

2022/12/31(土) 12:27:13.18

確かに問題点が複数ある＆想定する挙動が曖昧で分からないから、コメントのしようがない。

最小限の再現コードと期待する挙動をwandboxなりideoneなりに書いてからの話だな。

2022/12/31(土) 12:49:15.56

>>3 こんなこと?
class Base;
using Base_Ptr = std::unique_ptr <Base>;
struct Base {
virtual ~Base () = default;
virtual Base_Ptr construct () const = 0;
};
struct Driv3: Base {
virtual Base_Ptr construct () const
{
return std::make_unique <Driv3> ();
}
};
int main () {
std::vector<Base*> BaseCnt;
Driv3 Driv3_;
BaseCnt.push_back(&Driv3_);
std::unique_ptr<Base> BaseUni;
BaseUni=BaseCnt.back()->construct ();
return 0;
}

2022/12/31(土) 18:55:55.24

コメントは対応するコードの前後どちらに書く？

// 別行なら前だが
int i = 0;

int i = 0; // 同じ行なら後？

同じ行に書いてたものが変更で長くなって別行に移したら前後が入れ替わるの気持ち悪くない？

2022/12/31(土) 19:51:29.83

基本、同じ行
無理があるときは前の行

2022/12/31(土) 19:52:40.15

エディタの都合に合わせてたら人間向けのメモでなくなる

2022/12/31(土) 19:56:33.63

grepなどによるキーワード検索がやりやすくなるよう意識したら良い
ctagsや統合開発環境みたいな高性能な検索機能がなくても探しやすいのが理想

2022/12/31(土) 20:10:39.20

>>7
> 同じ行に書いてたものが変更で長くなって別行に移したら前後が入れ替わるの気持ち悪くない？
修正が面倒だとは思うけど気持ち悪くはないな

2022/12/31(土) 20:52:41.08

気持ち悪いつか、気になるものは後で見ても気になるから
そりゃ気持ちよく直すでしょ

2022/12/31(土) 21:28:19.88

気持ちはわかるよ
差分ツールで見たとき差分として出ちゃうからな

2022/12/31(土) 23:41:26.87

コメントの移動だけが (一回分のコミットとして) 差分に出るのだったらちょっと嫌な感じだけど、
周辺のコードを修正した結果として行が長くなりすぎないようにコメントの位置も変えるという話なんだから
差分ツールで見たらどうせそこらへん一帯が出るわけでしょ。
その中にコメントのちょっとした移動が含まれるかどうかなんて気にするようなもんじゃないと思うけどなぁ。

2022/12/31(土) 23:56:21.90

書くべきものは横着しないで書け
書かなくてよいもので油売るな
これだけのこと

2023/01/01(日) 00:07:36.95

ところで私がよく使う言語に Scheme があって Scheme ではセミコロンから改行までがコメントになるんだけど、
Scheme の (というか主な LISP 系言語の) 習慣では状況によってセミコロンの数を変えるし
フォーマッタはセミコロンの数に基づいてインデントを変える。
https://www.gnu.org/software/emacs/manual/html_node/elisp/Comment-Tips.html
便利な習慣だと思うんだけど他の言語ではこういうのを見ないなぁ。

2023/01/01(日) 00:14:48.52

何なら、本文の途中で折り返して、行末コメントにするわ

2023/01/01(日) 03:55:44.18

>>16
いらんわ
全然、羨ましくない
願い下げ

2023/01/01(日) 11:42:43.03

コメントを同じ行に書くことはほとんどないかなあ
そもそも1行コメントで済む処理っどんなの？　コメント必要なのかな？

俺は処理の塊の前に意図など含めて長文コメントを書いてる

2023/01/01(日) 14:59:08.11

行内コメントはどこまで下げるのかと言う問題が、
　　foo();　　　　　　　　　// xxxとyyyを更新
　 assertIm(xxx) + Im(yyy) == 0); // 変換結果は共役のはず
－－－－－－－－－＞| 40 カラム？
－－－－－－－－－－－－－－＞| 56 カラム？

オートフォーマッター任せにしたいが定説が無さげ
perltidyだとなんか隣接する行コメは64カラム目か、それを超える場合は一番長いのに合わせてくれるが
コードの長さがかなり不ぞろいなとき罪悪感みある、
　a();　　// (aのコメント)
b();　　// (bのコメント)
　very_long_long_long_name_function_call_to_baz(long_long_name_param, 1234567); // (←のコメント)

2023/01/01(日) 15:01:54.19

あとif文の行内コメントも悩む、
　　if (a==b)
　　{
　 }else

2023/01/01(日) 15:03:25.53

・コメントは41桁目から
・一行は95桁迄

が俺のマイルール

2023/01/01(日) 15:05:17.13

あとif文の行内コメントも悩む、
　　if (a==b) // ここには分岐条件のコメントを書くべき？
　　{ 　　　　　　// ここにはthen節のコメントを書くべき？
　　　　...
　　}
　 else　　　 // else節のコメントはここでええのか？
　 {　　　　　　// それともここか？
　　　　....
　　}

どう書くかによってブレーススタイルやオートコードフォーマッタとの
共存具合が変わってくるので行内コメントはいろいろ問題が多いシステム、

2023/01/01(日) 15:09:39.48

>>21
// a と b が等しいなら...
if (a==b){
// 等しい時の処理
...
// 等しくないなら...
} else {
// 等しくない時の処理
}
が俺のマイルール
※ いないと思うけどコメントの内容にはツッコミ厳禁ね

2023/01/01(日) 15:17:33.19

>>23
ありゃ行内コメントか...

if (a==b){ // a と b が等しいなら...
... //. 等しい時の処理
} else { // 等しくないなら...
... // 等しくない時の処理
}

確かに通常のコメントと行内コメントが混在するとモヤモヤするのはある

2023/01/01(日) 17:05:55.66

>>16
よく使うって、何に使うんだよ？

2023/01/01(日) 17:43:06.94

>>26
手癖で使えるなじんだ言語ってひとつくらいはあるもんだろ。
俺はそれが Scheme だってだけで、やってることは自動でネットを巡回したりだとか
ファイルを条件別にフォルダに仕分けしたりだとかとかいった普段のちょっとした自動化とかだよ。

2023/01/01(日) 17:48:24.72

(真理情報)grep検索しやすいのが正義

2023/01/01(日) 18:20:59.18

ニンジャ凄いな。
全部のコア使い切ってる。

2023/01/01(日) 18:29:13.35

新しいパソコンのメリットを特に感じていなかったけど、大物をビルドすると圧倒的に速いな。

2023/01/01(日) 18:29:31.45

何か間違えたのかと思ったわ。
あまりにも早すぎて。

2023/01/01(日) 19:58:13.71

>>16
/** */ や /// を普通のコメントとは区別してドキュメンテーションに使うでしょ？
c++だったらDoxygenとか

2023/01/01(日) 20:35:59.39

>>32
へー。
そういうツールを使ったことなかった。

2023/01/02(月) 15:24:57.96

>>16
フォーマッタと相性悪すぎん？
Python といい見た目の違いに意味持たせるのカスでしかない

2023/01/02(月) 17:07:12.86

PEP8

2023/01/02(月) 17:17:16.57

>>34
意味によってセミコロンの個数を変えるとそれをフォーマッタが見た目 (インデント) に反映するという話なんだけど

2023/01/02(月) 17:55:39.66

自分が理解できないものは使えない奴とか言ういつもの人でしょ
スルーでいいかと

2023/01/02(月) 19:45:33.11

>>36
すまん Scheme には普通の文末にセミコロン付ける訳では無いのね、そこ知らなくて勘違いしたわ

C++ に取り入れるならセミコロン以外の記法にする訳ね

2023/01/03(火) 08:07:29.43

>>37
必要性を感じていないものをいらんというだけだ
スルーしてもらえるならこっちも助かる

いらんつーてるものをしつこくすすめてくるな

2023/01/03(火) 08:12:15.59

忘れてもらっちゃ困るのは
C++界は新しい機能に前向きだ
待ってましたという新機能にはみんな飛びつく

凝り固まろうとしてるのと違う
特にC++11以後は断じて違う

2023/01/03(火) 08:39:47.41

誰もお前に勧めてなんてないし自意識過剰すぎるだろw

2023/01/03(火) 09:59:45.56

にわか横レスには俺も何も言ってないよ

2023/01/03(火) 11:34:31.19

C++11でshared_ptrが導入されて、C++に対するJava・C#の優位性がひとつ消滅したよな

2023/01/03(火) 13:45:59.96

10年以上も前のことを何を今更って感じもするし
std::shared_ptr以前からスマートポインタは
一般的だったから事実誤認のような気もする
特にC#が登場した2000年にはスマートポインタの利用は一般的だった
Java登場の1995年当時を知る人はいるかな?

2023/01/03(火) 14:00:08.10

>>44
> 一般的だったから事実誤認のような気もする

C++スレに書き込む人にとってはもちろんそうだろうけど、C++やらないプログラマにとってはそうではなかった
理解が広まるのに時間がかかる

2023/01/03(火) 14:23:27.79

モノとしては誰でも知ってたけど、標準に入ってるかどうかってやっぱりだいぶ違うんだよな
プロダクトでの使いやすさとか

2023/01/03(火) 15:05:23.38

>>44
1995年にはまだスマポは一般的でなかったと思う
デストラクタにdelete書きまくってた記憶がある

2023/01/03(火) 16:23:49.38

>>44 47
c++で言うなら前身のboost::shared_ptrの初出が1998年。
その前身のcounted_ptrの最初の提案は1994年だって。(rejectされたけど)

2023/01/03(火) 19:10:25.71

標準ライブラリのみで外部依存ありませんは結構な強みになるからな

2023/01/03(火) 20:16:21.45

以下の記事、プログラマ脳なら神様の定義の変化を重視するよなあ。あるか、ないかじゃなくて。

【神様はいる？いない？】古代の人々は神をどう考えたのか？（ダイヤモンド・オンライン） - Yahoo!ニュース
https://news.yahoo.co.jp/articles/621899c69768ec530aa5377fed89908dc3eef8d4

2023/01/04(水) 00:21:00.82

懐かしいなboost
みんな直接WG21へ提案持っていくようになってすっかり立ち位置が微妙になっちゃった

2023/01/04(水) 01:31:15.66

そうか？言語機能に改定が必要なことならともかく
ライブラリは実績があるほうが通しやすいし、
標準に取り込まれなくても細かな便利機能がある Boost が衰退したとは感じないな。

サードパーティのライブラリを導入する手続きが面倒というのはよくある話だから
そういう面でもカバー範囲が広い Boost の出番は多いんじゃないの。

2023/01/04(水) 01:55:44.13

単純に必要な便利機能はあらかたC++標準の方に取り込まれてて
もうマイナーやマニアックな機能かゴミしか残ってないから使う機会なくなったわ
なんかこれ今でも便利だよってのある？

2023/01/04(水) 02:11:04.13

>>53
他の言語ではとっくの昔に標準化されているXMLやJSONのパーサーが標準化されたら便利になると思うよ

2023/01/04(水) 02:42:57.82

＞54
1.75でBoost.Jsonが入った。

2023/01/04(水) 03:00:12.42

>>53
Boost.Beast。

2023/01/04(水) 14:34:57.16

>>53
asioとか標準には入ってないんじゃない?
serializationもたまに使う

2023/01/04(水) 14:42:05.39

>>53
小物だとlexical_castは便利だけどこれも標準にないのでは?
統計検定するのにMath Libraryの分布関数もちょこちょこ使う

2023/01/04(水) 18:00:15.11

うっかり標準化して負の遺産になってしまったiostreamでの失敗の知見のうえに今のC++があるってのはわかる