C++相談室 part132

2017/10/10(火) 00:11:34.01

次スレを立てる時は本文の1行目に以下を追加して下さい
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part131
http://mevius.2ch.net/test/read.cgi/tech/1501295308/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.101【環境依存OK】
http://mevius.2ch.net/test/read.cgi/tech/1500329247/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2017/11/11(土) 08:59:35.86

ていうかstd::stringにお任せしておけばデータサイズの管理が不要とか池沼の考え
何文字でも受け付けるとかいうのはテストしようが無いからまともな仕様ではない
よってまともな設計は不可能

2017/11/11(土) 09:01:47.94

常識的な範囲で受け入れてくれればよい。
それを行うことで何をしたいのかが見えないなぁ。

2017/11/11(土) 09:03:17.54

手前の常識がクライアントの常識と思い込むのは池沼のry

2017/11/11(土) 09:06:15.75

つか>>537もかなり問題発言
スタックは関数を抜けたら開放されるのだから、
スタック領域を使い果たさないように設計された関数ならスタックをいくら使うかは関数の勝手
ここでも「スタックの消費は少ないほうが良い」という手前の常識が

2017/11/11(土) 09:06:43.21

じゃあ、君はメモリが確保できないことをどう説明するんだい？
スタック大量に確保したら余計引っかかるぞ。

2017/11/11(土) 09:10:47.99

本質は同じ。瞬間メモリ使用量の問題だからな。
少ない方がイイに決まって無いかい？

2017/11/11(土) 09:17:19.24

>>542
スレッド生成時にそのスレッドが使えるスタックは一般に割り当てが完了するから、
割り当てられた領域をオーバーしなければどう使っても良い
もちろんフルに使ってもヒープの圧迫にはならない

スタックが伸びれば伸びただけヒープ用メモリ領域を圧迫するとか
ごく一部の超ロースペックな組み込み環境（スタックがただ1本だけ＝スレッドが1個だけ）限定の話じゃないの；
プログラムのメモリの使い方について一体どんな理解をしているのか；；

2017/11/11(土) 09:22:37.81

>>544
じゃあnewしても問題なく確保できるじゃないか。
クライアントが不足の文字数ブッコンで落ちるよりはいいと思うけどね。
あと、ほかがヒープ食っててスタック確保できないケースはないの？
なんでもヒープにキックする人嫌い。

2017/11/11(土) 09:23:01.72

>>543
std::string経由でヒープ上にchar commad[256０００];を確保する方が
スタック上にchar commad[256０００];を確保するより常に優れた設計であるという根拠は？

2017/11/11(土) 09:25:34.33

>>546
仕様が提示されてないから。250kbも使う保証がない。
なら、std::stringがchar command[256000]と確保するのは優れてるの？
折衷案なだけじゃない？

2017/11/11(土) 09:26:29.15

>>545
藻前は文字数ブッコンでエラーを返すことと文字数ブッコンで落ちることの意味の違いの重大さがわかっていない
漏れは終始エラーを返すことを目指した発言をしてゐる

2017/11/11(土) 09:27:27.12

>>548
あそー。
確保できなかたらSIZEは0になるから、ほとんどの処理は通らないようにエラー処理はできる。

2017/11/11(土) 09:29:57.09

c++には例外もアルヨ。

2017/11/11(土) 09:40:15.26

化石か！

2017/11/11(土) 09:42:44.46

>>547
なんか文字数の上限仕様が提示されたらスタック上に取るほうが良いと言ってねえが？まあ一般にそれで良いのだけども

>>549
メモリ不足チェックと文字数チェックを混同するのは池沼のry
メモリ不足はさまざまな要因が重なった結果起きる現象なので
「入力Xを与えたらメモリ不足でクラッシュする」という仕様はありえない
（入力とメモリ不足との関係は、一般に再現性のある形ではテスト仕様に組み込めない

一方、「文字数n未満の入力Xはエラーとする」という仕様ならアリで
再現性のあるテストケースも書けてバッファとしてとるべき配列サイズも計算できる（きちんと設計しているなら

2017/11/11(土) 09:44:02.22

>>552訂正ｽﾏﾝorz
誤：文字数n未満の入力Xはエラーとする
正：文字数nを超過した入力Xはエラーとする

2017/11/11(土) 09:46:24.25

>>552
ロースペックじゃないコンピュータつかってるんだろ？
非常識な文字数入れられたらはじくなんて別に難しくないだろ。
スペックわかってるんだったらなおさら。

2017/11/11(土) 09:47:59.39

スタックに充分な領域を確保したから大丈夫って頭おかしい設計だわ

2017/11/11(土) 09:49:50.67

>>554
文字数チェック不要と考えているかもしれない>>530とかに言うべき

2017/11/11(土) 09:54:01.12

はいはい。もういいわ。
エラー処理真面目にやるんだったら、そういう方向で考えるけど。
ここではそんなに求められてない。一般感覚が無いとそれ何回もやるのか？

不適当で有名な5chでなにを演説してるのやら。

2017/11/11(土) 09:58:28.19

>>555
やみくもにスタック消費量最小を目指すのは、
自分の関数がどれぐらいスタック使うのかおよびスタック領域にどれぐらい余裕があるのか
見積もる手間を惜しんで手抜きしているだけな可能性が微ﾚ存、

ていうか「スタックに充分な領域を確保した」というのが真なら（机上検証、レビュー、テストで担保できたなら
「大丈夫」という結論で何の問題も無いんじゃ…

2017/11/11(土) 10:07:34.21

>>544
スタック領域には当然上限があるが、常にその上限まで割り当てていたら無駄だろう。
LinuxもWindowsも必要に応じてページを割り当てる。

2017/11/11(土) 10:17:10.01

>>559
スタック領域を使い切るのが美徳とは言っていないわけでありまして、
なおかつページングの発生頻度は、メモリ消費箇所がスタックかヒープかの違いよりは
領域へのアクセス頻度の問題ではなかろうかと、

2017/11/11(土) 10:35:02.95

パフォーマンスの話じゃなくて、これが一般には正しくないって言ってるの。

>スレッド生成時にそのスレッドが使えるスタックは一般に割り当てが完了するから、
>割り当てられた領域をオーバーしなければどう使っても良い
>もちろんフルに使ってもヒープの圧迫にはならない

2017/11/11(土) 10:53:30.83

んでchar commad[256０００];をどうやってリターンするんだ？

2017/11/11(土) 11:07:32.64

普通ならstd::string使う
char使いたい人は使えばいい
おしまい

2017/11/11(土) 11:11:42.29

256000という数字にセンスを感じるなあ

2017/11/11(土) 11:50:48.17

> char commad[256０００];
しかも0が非ascii

2017/11/11(土) 13:26:05.59

>>529
いや、commandを何バイト確保しておこうが snprintf() の方を使った方が良い。
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/sprintf.3.html
gcc で asprintf() 使ってもいいなら command は char * でも行ける(その代わり後でfree())。
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/asprintf.3.html

2017/11/11(土) 14:07:40.16

scanf("%s"にツッコミなし！

2017/11/11(土) 14:52:43.33

>>567
あまりに低レベルで目に入らんかったw

2017/11/11(土) 17:48:20.77

>んでchar commad[256０００];をどうやってリターンするんだ？

だからそれはstringでも同じだな。stringを使えばいいという発想では駄目ということだ。
メモリを確保する必要がある。
しかも、サブルーチンを抜けた後で、何処かでそれを解放する機構が必要だ。サブルーチンを抜けた
後だと自動で解放しない限りは解放する方法はない。つまり肝心なのは自動でメモリ解放機能が
ついていることだ。それがついてないstringクラスなんてこの場合は全く使い道がないってことだ。
だからstringって馬鹿の一つ覚えを言うやつは間違いってことだね。

2017/11/11(土) 18:01:59.33

頭おかしい

2017/11/11(土) 18:12:16.05

なんかおかしな雰囲気を出してるね

2017/11/11(土) 18:18:07.19

>>569 std::string はデストラクタで自動でメモリ解放するよ。

2017/11/11(土) 18:20:22.00

auto f() {
　struct { char a[256]; } r{};
　return r;
}
int main (){ auto[array] = f(); }
ちょっとスタックが厳しそうだ

2017/11/11(土) 18:43:22.06

>>569
本当のバカはその一つすらまともに知りませんでした

2017/11/11(土) 19:32:54.25

今どきstd::stringを批判してcharの配列の優位性を説くとか

2017/11/11(土) 19:56:58.42

string_viewとか持ち出して言うならともかく

2017/11/11(土) 20:40:48.77

>>575
全く批判になってないから。

string_viewも今回のような用途に使うもんじゃない

2017/11/11(土) 21:23:35.64

テンプレートって基本ヘッダファイルに書くと思うけど、コンパイル単位ごとに全部コードのコピーが作成されるの？

2017/11/11(土) 21:25:00.09

>>577
string_viewって何か知らないのか？

2017/11/11(土) 21:41:30.08

そこでmoveですよ。

2017/11/11(土) 21:45:04.19

>>578
規格は生成コードまで規定しないから、気になるならアセンブリとか見るのがいい。
関数テンプレートあたりだとコンパイル単位またいでも同じポインタが得られることが要求されていたりはする。

2017/11/11(土) 22:32:22.44

>>579
今回の件にstring_view使ってみなよ

2017/11/11(土) 22:37:09.49

もしかして
string_viewとか(無理やり)持ち出して(バッファーを解放しないと)言うならともかく
という意味か？
そうだったらそこまでエスパーにはなれんかったわ

2017/11/11(土) 22:42:02.84

みじゅくもの

2017/11/12(日) 05:09:14.57

>>583
何か勘違いしているか？
俺は生配列を使いたがるガイキチたちを擁護したいわけじゃないし
もちろん意見が一致していない
C++スレなのにC++のライブラリを食わず嫌いしてるフシのあるやつに
ちょっと話題を振ってみただけだ

2017/11/12(日) 05:12:35.53

エスパー通訳頼む

2017/11/12(日) 05:23:52.17

ストリングビューはストレージを保持しないぞ。
外部からやってきたやつに操作を与えるだけ。
パペットっていうかなんていうか。

2017/11/12(日) 05:33:48.19

>>587
誰もそんな事は聞いてないんだけど

2017/11/12(日) 07:18:14.98

そっか、当たり前すぎたな。

2017/11/12(日) 07:30:16.55

頭でっかちなアスペ池沼多過ぎか

2017/11/12(日) 08:13:37.80

std::stringは有用だがstd::XXXstream系は糞杉
→必然的にsptintf_s()とstd::stringを併用するスタイルになる

いずれﾜｶﾙ

2017/11/12(日) 08:22:45.23

および有用だからといってプログラムの動作根拠を成す
数量的関係の把握をサボるというのは話が違う
std::stringにメモリが許す限りいくらでも長い文字列を格納できるから大丈夫とか、
スマポを使っとけばいつか（10万年後かもしれないが）確実に開放してくれるから大丈夫という見込みだけで
テストもせずに青天井なデータ処理を許すプログラムをリリースするのは
素人プログラミングに後退である
ていうか現在の潤沢なメモリ搭載環境では問題の発覚が遅れる分なお悪い

2017/11/12(日) 08:32:07.61

10万年後ｗもうお前黙っておけ

2017/11/12(日) 08:47:13.70

どんなひどいプロジェクトで仕事すれば、こんなパラノイアを発症するんだろうな

2017/11/12(日) 09:05:22.76

>>592
つーことは、おまえbad_allocをcatchせずに放置してるのか

2017/11/12(日) 09:15:31.43

つか今気づいたが>>561は一体何が言いたいんじゃ…
ページ割り当ては論理アドレス上の領域確保に対し透過的なので

>スレッド生成時にそのスレッドが使えるスタックは一般に割り当てが完了するから、
>割り当てられた領域をオーバーしなければどう使っても良い
>もちろんフルに使ってもヒープの圧迫にはならない

の否定根拠にはなりえぬ

2017/11/12(日) 09:17:28.25

>>595
ていうかむしろ藻前は正常系がbad_allocのcatchに依存した設計してるの？

2017/11/12(日) 09:25:43.37

>>597
なぜそう思った？

2017/11/12(日) 10:48:39.64

>>594
お前らがよってたかっていじめるからだろ w

2017/11/12(日) 13:20:18.65

まだ516の糞コードの話題やってんのか
まったく飽きないフレンズどもだな
セルリアンに喰われちまえよ

2017/11/12(日) 17:58:51.11

次は20が控えててどんどん進化してるけどmeyers本なしについていける自信がないよ。
17以降遭難者が続出するんじゃなかろうか。

2017/11/12(日) 18:04:43.84

17ってそんなに難しいか？
14以後ってか11以後、03までのストイックを通り越したマゾプレーからの離脱が
大きなテーマになっていてautoのinitializer_listみたいなミスはしながらも
ちゃんとそれを正していく自浄作用が機能していると俺は思うが

2017/11/12(日) 18:39:00.77

auto_ptrとかgetsとかトライグラフとかboolの++とか
危険で無駄で混乱を招くゴミが続々取り除かれてどんどん使いやすくなってるよね
生ポインタや生配列をいじくり回してメモリ壊すこともほとんどなくなった

2017/11/12(日) 20:18:16.94

c++の機能がこのまま進歩していったとしてマクロは消えるかな？

◆QZaw55cn4c (ﾜｯﾁｮｲ 7f60-20FA) · 2017/11/12(日) 20:20:30.26

テンプレートがマクロそのもの

2017/11/12(日) 20:33:05.49

constexprとかautoのおかげでtemplateもマクロとして使いやすくなったよね。

そう考えるとテンプレートで出来なくてマクロじゃないと出来ないのって何かある？

◆QZaw55cn4c (ﾜｯﾁｮｲ 7f60-20FA) · 2017/11/12(日) 20:47:50.42

多重マクロはテンプレートで置き換えられるのだろうか？

お題：http://mevius.2ch.net/test/read.cgi/tech/1432402159/18

ベタな回答：
http://mevius.2ch.net/test/read.cgi/tech/1432402159/106
http://peace.2ch.net/test/read.cgi/tech/1313183984/803
https://code.hackerearth.com/2642c4w

多重マクロによる回答
http://mevius.2ch.net/test/read.cgi/tech/1432402159/128
https://ideone.com/vNZWaH

2017/11/12(日) 21:24:58.95

>>605
テンプレートとマクロの本質的な違いがわかってないな
スコープに従うテンプレートやconstと
ほとんど何も考えてないおまえみたいなマクロは
オブジェクト指向という観点からは全く別次元なものだ

◆QZaw55cn4c (ﾜｯﾁｮｲ 7f60-20FA) · 2017/11/12(日) 21:43:24.64

「ほとんどなにも考えていない」とは手厳しいですね…

2017/11/12(日) 21:52:12.94

オブジェクトたいして指向関係ないだろ

2017/11/12(日) 21:52:39.76

何だこの日本語ｗｗｗｗ

オブジェクト指向たいして関係ないだろ

2017/11/12(日) 22:01:17.81

マクロの乱用をさけるためにテンプレートが発達してきたんだからマクロ使わないでね

2017/11/12(日) 22:17:39.90

オブジェクト指向関たいして係ないだろ

2017/11/12(日) 22:36:48.97

>>606
文字列リテラルを、リテラルとして連結するのはマクロじゃないと無理じゃないかな。

2017/11/12(日) 23:06:22.93

>>614
不可能ではないと思うけど、そう気軽ではないというのは確かだと思う。

2017/11/13(月) 00:53:11.35

const char8_t[] u8hage = "hage"; // = u8"hage"
const char16_t[] u16hage = "ハゲ"; // = u"ハゲ"
const char32_t[] u32hage = "禿"; // = U"禿"
const wchar_t[] whage = "はげ"; // = L"はげ"
みたいなプレフィックス省略が出来ればいいのになって思うときがあるね

2017/11/13(月) 01:19:29.77

>>616
Haskell だとリテラルは多相になっていて、型推論で適当な型にあてはめられるんだが……。

C++ では返却値だけ型が違う関数はオーバーロードできないルールがある。
その延長でリテラルは無引数の関数のようなものと考えると文字列リテラルが様々な型で有りうるようなのは難しいと思う。

型の情報が重複してるのがダサいと思うなら型名の方を auto で書くくらいかなぁ。

2017/11/13(月) 02:08:07.11

kotlinとかswiftにあるiterator.forEach{}の構文がc++にもついてほしい
c++だとiterator.for[=]{ }みたいな構文になるんだろうか

2017/11/13(月) 02:48:35.71

>>615
うーん…
文字列リテラルは無理じゃね？

2017/11/13(月) 03:24:18.68

言語仕様変えないと無理かな？

2017/11/13(月) 04:17:46.93

>>619
コンパイル時定数という意味でのリテラルであれば出来るが

2017/11/13(月) 07:31:48.15

templateだったら関数の返り値が異なってもokだしconstexprならコンパイル時定数だから変換さえ出来ればやれそうな気もする。

>>618
範囲for文は駄目？

2017/11/13(月) 07:34:39.03

範囲FORとSTLにfor_eachがある。
http://en.cppreference.com/w/cpp/algorithm/for_each

2017/11/13(月) 09:15:04.60

>>622
変数.for...って書き方がしたい

2017/11/13(月) 09:27:56.98

自作クラスならtemplate関数で範囲forを閉じ込めるとか？
試して無いけどこんな感じで
class test{
//begin()とend(),++が定義されているものとする
template<typename Func>
void for_(Func func){
for(auto& it: *this){
func(lt);
}
}
}

2017/11/13(月) 09:34:12.47

そういう臭い書き方はC++ではあまり採用されない方針
オブジェクト指向じたい、もうあまり言われてなくて
テンプレートによるメタプログラミングが主体になってる
オブジェクト指向を前面に押し出した言語はオワコンになるという法則があって
なもんで、魔除け、キチガイ除けの意味も含めて
Java や C# や C++ など、主流言語は
「マルチパラダイム言語」、「オブジェクト指向をサポート」
といった、ちょっと距離を置いた付き合いかたをしてるね
きっと、「全ての手続きは必ずただ一つのオブジェクトに紐づかなくてはならない」
という強迫観念的ともいえる窮屈な考え方が脳や精神に良くなかったのだろう
本当に精神疾患を引き起こしてリタイアする人多いし

2017/11/13(月) 09:59:56.81

変数forならラッパ作れば終わりだけどなんかつまらないね。
apply(op).for(sequence)とかのほうがインターフェースとしては見栄えがいいかも

2017/11/13(月) 10:38:35.17

>>624
ユニファイドコールシンタックスっていう提案が出ていたけど、ぽしゃった。
俺もほしい。

2017/11/13(月) 10:50:06.32

「制御構造までオブジェクトに属するべき」ってやり過ぎというより単に根拠のない主張だよね。

2017/11/13(月) 11:12:29.10

range-based forで十分じゃん何が不満なんだ理解できない
俺が思うのはインデックス取れたらいいなあということぐらい

2017/11/13(月) 11:19:17.35

書いといてなんだけど624と630の意見に賛成

2017/11/13(月) 11:43:20.37

zipwith相当のことをどうやって書く？

**デフォルトの名無しさん** (JP 0H8f-2Hq5) · 2017/11/13(月) 12:13:53.76

>>630
最終的な結果がその処理順序に影響する(ここのオブジェクトへの操作が独立していない)場合には範囲for文使うなってことじゃね？
標準で取れるようにしてる言語も中にはあるけど

2017/11/13(月) 12:34:55.34

>>628
それは全然別の機能だけどな

2017/11/13(月) 13:01:28.76

>>601
meyers本ってそんなに役立つかねぇ
最初のeffective c++ちょろっと読んだ程度なので最近のは知らんけど
あの人の本に従ってる人は、自分で考えて創意工夫しない人が多いよ
セオリーに固執する日本人はそういうパターンに陥りがち

2017/11/13(月) 13:13:06.32

お前らの創意工夫よりメイヤーズの方が100倍信じられるから

2017/11/13(月) 13:29:22.72

自分の才能や経験の不足を虎の威で補おうとしてるのなら、終わってるよ
meyersが「こうしろ」と言ってることの、理由まで含めて納得するならいいけど
そうでない人の方が圧倒的に多いからなぁ

>>636がまともな実力持ってるなら、meyersが言うセオリーに当てはまらない場面なんて山ほど経験してるはずだが