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/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++があるってのはわかる

2023/01/04(水) 18:07:51.27

ところでiostreamに変わるioを作って
標準に入れようという動きはないんですか?

2023/01/04(水) 18:09:17.48

さすがに入出力の書式化を標準ライブラリとして用意しないわけにもいかんからな。
良いのが出来るまで先送りとは言えないんだからそのとき出来たものを入れるのはしょうがないんじゃないの。

2023/01/04(水) 18:18:11.23

>>60
私が把握してないけかもしれないけれどストリームの基本構造を変えようという大きな動きはない。
C++20 から書式化 (オブジェクトを文字列表現にする) は std::format として切り出されて、
書式の情報は std::formatter 型で扱うのでグローバルな状態に影響を与えるマニピュレータを使う必要はなくなった。

2023/01/04(水) 18:26:24.86

「作業ディレクトリ」という概念はプロセス全体でひとつでしたっけ。これはOS依存ですかね。
スレッド処理実行中に作業ディレクトリが変わるのは許容範囲かな

2023/01/04(水) 18:40:11.15

>>62
へーstd::formatなんてのもあるんですね
ちょっと眺めてみたけどcstdioとも
boost::formantともまた違うようですね

2023/01/04(水) 18:43:31.27

std::format の設計は Rust の std::fmt::Display と似てる感じがするね。

2023/01/04(水) 23:47:37.00

iostream はよくあんなもん公開する勇気が有ったな

2023/01/05(木) 00:04:17.98

当時はC with Classesなんて研究をしてる人が珍しくて
やってる人のところへ見物に来る人がぞろぞろいたんだよ

禿にとって味方をつくることも大事な仕事で
先行きがまだ見えない試みも怯まず果敢に攻める必要があった

その当時の作品を今さら未来人がドヤ顔で揶揄しても
聞いてるのは当時の人じゃなく同じ未来人だぞ
おまえ自身がどんな批判に晒されるのか怖くないの？
・・・だから匿名掲示板なのか　失笑

2023/01/05(木) 00:06:22.64

いや、発表当時から微妙な反応だったよ
ユーザーが求めてたのはオブジェクト指向で、
あんな実装じゃない

2023/01/05(木) 00:11:53.94

そういう手前味噌なおも鋳込みが激しいのもこの界隈だわな
おまえさんのようなシュトロハイム型のやつの受け流し方もみんな憶えてる

2023/01/05(木) 00:12:40.81

- おも鋳込み
+ 思い込み

2023/01/05(木) 00:38:06.59

そんなに不満なら何で自分で作らんの?
皆不満なら公開したら支持を集められるよ

2023/01/05(木) 00:45:23.91

PowerShellのパイプに似たコレジャナイ感でしょうかね
なお、PowerShellのリダイレクトはさらなる魔改造のために温存されている模様

2023/01/05(木) 01:10:26.32

std::formatは整数が%d、浮動小数点が%f、文字列が%sのprintfに近い書式でよかったのに…

2023/01/05(木) 06:48:29.39

>>72
PowerShell のパイプって特に変じゃ無いような気がするが...

2023/01/05(木) 08:19:32.24

パイプで渡すものがオブジェクトの配列なだけならまだしも、
要素数が0と1の時だけ特別な処理がかかるのは使い勝手を損ねてるだけだぞ

2023/01/05(木) 11:10:59.66

>>68
ほんそれ

2023/01/05(木) 11:12:50.46

>>75
便所や下水のPipeだね

2023/01/05(木) 11:14:43.82

>>75
> 要素数が0と1の時だけ特別な処理がかかる
なにそれ？

2023/01/05(木) 11:46:32.29

>>68
発表当時って西暦年で言うといつだ？

2023/01/05(木) 13:10:14.84

何を今更と思ったけど iostream 叩いとけばわかってる感出るってことなんですかね

2023/01/05(木) 13:13:50.03

>>80
それはある
実用上困ってないくせに叩いてるバカ多い

2023/01/05(木) 13:20:30.85

実用上困ったことがない程度しかio使ってないのに養護するﾊﾞｶが他人をﾊﾞｶ呼ばわりして笑える

2023/01/05(木) 14:03:21.88

実用上どう困るのかを強い説得力で話すやつを見かけないな

2023/01/05(木) 14:11:12.67

またperlerが湧いてきたな

2023/01/05(木) 14:42:05.42

>>83
そりゃ実用上は困らんよ
iostreamなんて使わずに普通にprintfとかでやるし...

2023/01/05(木) 14:48:29.85

へーえ、printfならご満足なのか

2023/01/05(木) 14:52:05.98

マジで不満なら作ったらどうだ? IOくらい余裕でできるやろ?

2023/01/05(木) 15:00:05.80

printf は型システム的にガバガバすぎるだろ。
書式と実引数が食い違っててもコンパイル時に検出されないこともあるし。

2023/01/05(木) 15:19:01.89

Bの関数をC++スレで持ち出してドヤァ

2023/01/05(木) 17:25:17.77

はちみつはいつもprintfをdisってるが、printfには捨て難い便利さがある。

2023/01/05(木) 18:01:34.63

>>90
補足すれば、cout系はメンドクサイ。書くのが非効率。

2023/01/05(木) 19:16:41.23

仕方ないじゃん
当時はいいと思っちゃったんだから
何十年前ものアイデアを今の知見で考察しても仕方がない

2023/01/05(木) 19:55:51.72

>>78
パイプに流したオブジェクトが
2つ以上なら配列
1つならオブジェクトそのまま
0個ならnull
になってパイプ先に渡る

2023/01/05(木) 20:56:47.09

>>90
書きやすさは printf のほうがよいというのはわかる。
stream の文法がうっとうしいというのは俺だって思うよ。それが良いとは思わん。

2023/01/05(木) 21:36:43.88

>>93
どんなコード書いてるの？
PS C:\> function x {
>> param([parameter(ValueFromPipeline=$true)]$p)
>> begin { Write-Host 'BEGIN' }
>> process { Write-Host "PROCESS: $p" }
>> end { Write-Host 'END'}
>> }
PS C:\> @() | x
BEGIN
END
PS C:\> @(1) | x
BEGIN
PROCESS: 1
END
PS C:\> @(1,2) | x
BEGIN
PROCESS: 1
PROCESS: 2
END
PS C:\>
普通に動いてるけど？

2023/01/05(木) 21:40:39.42

iostreamは開発用ログの出力方法としては最適なんだけど、それ以上ではない感じ

2023/01/05(木) 22:43:53.60

ログ出力用に<<をオーバーロードしたら
バイナリ出力は別の手段を考えることに……
namespaceでオーバーロード内容をさらに区分するとかはできるのかどうか知らんがやりたくない、、、

2023/01/05(木) 22:50:41.68

printfだと、見たいオブジェクトの型に気にすることなくログ関数に突っ込む、という他の言語で当たり前にできることができない。

2023/01/05(木) 23:36:19.07

formatのお陰でもう議論する意味なんてないんだが、

17以前は
誰かが状態を書き換えてるかもしれないからいちいち保存と復元が必要、
文字列とコードが入り乱れていて、i18n化できない＆何が書かれているかひと目で分からないから
到底実用的じゃない

会社で20が使えるようになったらiostreamに戻るよ…

2023/01/05(木) 23:43:57.03

>>97
いくつかやり方はあると思うけど……。

同じストリームにログ出力用の表現とバイナリ表現の両方を出力する可能性があるなら
適当なクラスに包むだけでいいと思う。
こんな感じで書ければ十分でしょ。

Foo bar;
std::cout << binary_style(bar) << std::endl;
std::cout << log_style(bar) << std::endl;

Haskell でこんな感じで処理を切り替えるのをよく見た気がする。
だいぶん前にちょっと遊んだだけなのであまり覚えてないけど。

出力先によって表現を変えるのならストリームクラスを定義してしまえばいいと思う。
直接的な入出力はストリームバッファがやっていて、
書式化を担当するストリームがストリームバッファを所有するという構造がある。
オブジェクトの表現形式が大きく変わるとしたら出力先ごとに変えるという用途だろうから
こっちのほうが使い勝手が良い場合も多いかもしれない。
雑な例だけどこんな感じ。
https://wandbox.org/permlink/3AaOGSXLNCw2aNJv

2023/01/06(金) 00:06:44.93

はちみつは、何かに忖度しているように感じるな。
職人は自分の腕で食っていくので忖度しないが、就職先を探すサラリーマンは忖度する。

2023/01/06(金) 00:22:08.66

前にも書いたことがあるがワイはプログラミングは完全に趣味でやってるだけなので
プログラミングについて私が配慮すべき何者かなど存在せぇへんで。

2023/01/06(金) 00:30:02.38

じゃあ、はちみつ職人に改名しなよ。

2023/01/06(金) 00:32:36.82

なんか、何かにおべんちゃらしてるような感じを受ける。

2023/01/06(金) 00:41:45.62

>>103
職人でもないが、はちみつより餃子のほうが名前として大事なので
もしも職人という言葉を入れて改名するとしたら職人餃子にするわ。

2023/01/06(金) 05:35:52.57

NGしやすくていいじゃんよ

2023/01/06(金) 07:56:26.71

>>95
@(...)は長さに関わらず強制的に配列にする書き方でしょ