C++相談室 part141

**デフォルトの名無しさん** · 2019/02/22(金) 03:07:43.52

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

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

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/

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

■長いソースを貼るときはここへ。■
　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

**デフォルトの名無しさん** · 2019/03/03(日) 10:26:03.14

>>141
そのポインタは渡した先でどうなってると思う？
頭悪すぎだろ

**デフォルトの名無しさん** · 2019/03/03(日) 10:31:40.12

よくわかんねえけど楽してJavaを移植したいってこと？
Boehm GCでも使ってみたらどうだ

◆QZaw55cn4c · 2019/03/03(日) 10:35:18.92

>>142
new したポインタを捨ててしまっている記述に限り、処理系で delete する、と決めるのですから「ポインタを渡した先」というのは存在しないことになります

>>143
C++ と Java で classpath ライブラリを共用したいのです！

**デフォルトの名無しさん** · 2019/03/03(日) 10:35:19.96

make_uniqueがやりたいってことかね

◆QZaw55cn4c · 2019/03/03(日) 10:41:59.49

>>145
スマートポインタを導入せずとも、ナマポであっても classpath を共用できるようにならないものか
そのためには c++ 処理系にどんな制限or追加を課せばいいか？

◆QZaw55cn4c · 2019/03/03(日) 10:47:25.17

>>142
内容を誤解していました、すみません
あらためて回答します

プログラマが new したポインタ値を変数に取っておく記述をした場合は、delete の責任はプログラマにあるものとし、処理系では何もしないものとします

**デフォルトの名無しさん** · 2019/03/03(日) 10:53:36.82

>>116
遅レスだけど、テンプレートはcppに隠蔽しようとか考えない方がいいと思う
dllとかにしたいなら別だけど・・

**デフォルトの名無しさん** · 2019/03/03(日) 10:59:02.77

javaでnewしているからってc++でnewするなって
classpath共用が何を意味しているのかは分からんが

**デフォルトの名無しさん** · 2019/03/03(日) 11:02:05.72

・繰り返し構文とgotoの全廃

**デフォルトの名無しさん** · 2019/03/03(日) 11:24:20.63

>>147
だからさあ
newして渡した先では殆どの場合はそれをフィールドに入れてるだろ
殆ど100%のケースでは「何もしない」に該当するんだよ

**デフォルトの名無しさん** · 2019/03/03(日) 11:44:43.82

>>147
そのオレオレC++拡張の仕様を自分で決めて自分で実装して公開してみな。
万に一つもないと思うが、それを有用だと思って喜ぶ人がいるかもよ。

◆QZaw55cn4c · 2019/03/03(日) 11:58:52.90

>>151
んんー、それは c++ 的な扱い（delete はプログラマの責任）でいいかと、私の思考に何が抜けているのかな？もう少し考えて見ます

**デフォルトの名無しさん** · 2019/03/03(日) 12:18:50.69

>>139
規格ではdeleteしないものをdeleteしたら互換性に問題が出る。
自動でdeleteしたかったらスマートポインタ使うべき
独自c++擬き想定しているならc++17使うのも当然okのはず

生のnew使わせるなんて今時のc++ではとんでもない悪手

**デフォルトの名無しさん** · 2019/03/03(日) 13:13:27.54

VS2017は十分な出来なんだがテンプレートの展開中に内部エラーで転けることがあってそこだけは不満

**デフォルトの名無しさん** · 2019/03/03(日) 15:47:18.29

shared_ptr でJavaやC#のガーベージ・コレクションとほぼ同じ役目が期待できるから別にいいのでは。
C++は、shared_ptrが正式採用されたC++11で別の言語になった印象すらあるわ。

**デフォルトの名無しさん** · 2019/03/03(日) 15:57:24.31

循環参照が検出できないからJavaプログラムの参照をそのまま置き換えればオッケーというわけでもない
もちろんナマポよりは遥かにマシだけど

**デフォルトの名無しさん** · 2019/03/03(日) 15:59:19.15

>>155
面倒だとは思うけど、時間あるなら再現するコードと共にバグ報告送ってやってくれ

**デフォルトの名無しさん** · 2019/03/03(日) 16:11:53.27

unique_ptr<hoge> up0(new hoge());
や
shared_ptr<hoge> sp0(new hoge());

と書いたときと

unique_ptr<hoge> up1 = new hoge();
や
shared_ptr<hoge> sp1 = new hoge();

と書いた時で
違いは生じますか？
生じるとしたらどんな違いですか？

**デフォルトの名無しさん** · 2019/03/03(日) 16:19:53.78

副業解禁で激変する若者世代とマネージャー世代のキャリア観
https://www.businessinsider.jp/post-107782
フリーランスの職種20個の仕事内容と平均年収をわかりやすく解説
https://www.proof0309.com/entry/shokushu
時給1万円のバイトも。会社員向きのプチ副業を、“バイト芸人”が教える
https://headlines.yahoo.co.jp/article?a=20190226-00127948-bizspa-bus_all
副業が「会社にバレる人」と「バレない人」の大差
https://headlines.yahoo.co.jp/article?a=20190303-00268007-toyo-bus_all
正社員の10%以上が副業　中には過重労働で体調崩す人も
https://headlines.yahoo.co.jp/hl?a=20190227-00010000-wordleaf-bus_all
「副業で年2000万円稼ぐ男」に学ぶキャリア戦略
https://headlines.yahoo.co.jp/article?a=20190221-00266856-toyo-bus_all
加速する「副業社会」正社員の4割が「副業したい」気になる収入はどれくらい？
https://headlines.yahoo.co.jp/hl?a=20190218-00010001-danro-life
おすすめ副業22選を現役フリーランスが解説【在宅も可能】
https://www.proof0309.com/entry/zaitaku-hukugyou
会社を辞めてフリーランスで働きたいあなたが知っておくべき10のこと
https://www.businessinsider.jp/post-165731
フリーランスと会社員､働き方の根本的な差広がる｢雇用されない働き方｣の課題とは何か
https://toyokeizai.net/articles/-/263055
フリーランス人口は増える！今後は仕事もプロジェクト単位になる!？
https://freelance.mts-career.com/population/

**デフォルトの名無しさん** · 2019/03/03(日) 17:35:34.30

>>159
直接初期化とコピー初期化の違いを説明するとクソややこしい話になるんだけど
結論から言えばその場合はどっちも全く同じ

**デフォルトの名無しさん** · 2019/03/03(日) 17:53:40.63

make_shared使った方が良い？

**デフォルトの名無しさん** · 2019/03/03(日) 19:22:53.95

うん

**デフォルトの名無しさん** · 2019/03/04(月) 04:26:14.48

new 呼び出しが少なければ少ないほど精神衛生に良い。

**デフォルトの名無しさん** · 2019/03/04(月) 06:09:53.20

複数の関数の戻り値を足し合わせる処理で、それぞれの関数の戻り値をチェックしたい場合のすっきりする方法は何かありますか？
std::string result;
result += func1(a);
result += func2(b);
result += func3(c);
の各func1,2,3の戻り値をresultに足す前に空でないかを確認したいのです (1つでも空があった場合はresultも空にしたい)
単純に一時変数を用意して一つずつ判定するしかありませんか？

**デフォルトの名無しさん** · 2019/03/04(月) 06:27:48.33

typename Iterator::container_type::value_type
こんな風に::で三個つなげるのは合法ですかね？？

**デフォルトの名無しさん** · 2019/03/04(月) 06:31:54.66

エイリアス使えば

**デフォルトの名無しさん** · 2019/03/04(月) 06:33:10.80

funcN() を追加する直前の result.size() を記憶しておいて、
足した後に長さが増えてなかったら、今呼んだ funcN() の結果は空だった、
と判定することはできるか。

string から整数になるだけで、一時変数を使うのは変わらない上に、
処理内容が分かりやすくなるわけでもないけど。

**デフォルトの名無しさん** · 2019/03/04(月) 07:56:06.21

>>165
例外

**デフォルトの名無しさん** · 2019/03/04(月) 08:09:41.73

>>166
合法

**デフォルトの名無しさん** · 2019/03/04(月) 15:31:21.38

unique_ptr<int> u(new int[2]{4, 5}); // OK (A) -> int * が作られる u.get()[n] でアクセス可能 *u だめ

unique_ptr<int> u = make_unique<int>(6); // OK -> int * が作られる *u でアクセス可能 u[0] だめ

unique_ptr<int[]> u = make_unique<int[]>(2); // OK (B) -> int [] が作られる u[n] でアクセス可能 *u だめ *u.get() 可能

unique_ptr<int *> u = make_unique<int>(2); // コンパイルエラー (C)

unique_ptr<int *> u = make_unique<int *>(2); // コンパイルエラー (D)

unique_ptr<int *> u(new int *); // ok -> int ** が作られる *u = &hoge あれば **u でアクセス可能

(C)(D)がエラーになる理由と
(B)を(A)の様に同時に初期化したいとき
どう書けば良いか知りたいです

**デフォルトの名無しさん** · 2019/03/04(月) 17:39:35.24

C 型が違う
D int*が2から作れない

**デフォルトの名無しさん** · 2019/03/04(月) 19:03:47.51

>>170
どうもありがとう。

**165** · 2019/03/04(月) 22:26:16.82

>>168
>>169
ありがとうございます

結局こうすることにしてみました
auto addString = [&result] (std::string&& temp){
　if (temp.empty()){
　　throw 0;
　}
　result += temp;
};
try{
　addString(func1(a));
　addString(func2(b));
　・・・
}catch (...){
　return "";
}

**デフォルトの名無しさん** · 2019/03/04(月) 23:05:47.73

void f()
{
　static std::mutex mtx;
　std::lock_guard<std::mutex> lock(mtx);
　//何がしかの処理
}

これっていいの？

**デフォルトの名無しさん** · 2019/03/04(月) 23:25:00.41

C++11以降はセーフ、じゃなかったかな。

**デフォルトの名無しさん** · 2019/03/05(火) 00:17:46.56

セーフなわけがあるか！！１１１１！１１！！！！１！

**デフォルトの名無しさん** · 2019/03/05(火) 00:55:28.26

C++11だろうがなかろうが関係なくセーフだよ。

**KAC** · 2019/03/05(火) 01:01:35.52

人によってセーフの定義が違ってたりしない？

**デフォルトの名無しさん** · 2019/03/05(火) 01:03:06.00

C++11以降はセーフになったらしい（ｷﾘ
ttps://cpprefjp.github.io/lang/cpp11/static_initialization_thread_safely.html

**デフォルトの名無しさん** · 2019/03/05(火) 01:04:55.09

Double Checked Lockingはジャヴァのメモリモデルがうまく対応できてなくて騒ぎになったことがある技法

**デフォルトの名無しさん** · 2019/03/05(火) 01:11:12.97

もし関数内static変数の初期化をDouble Checked Lockingを使わずにスレッドセーフにしようとしたら、
関数に入る度に毎回馬鹿正直にクリティカルセクションに入るために1000クロックぐらい捨てることになってしまうま
スピンロックか何かの黒魔術で若干緩和する実装も有り得るかもしれんが基本は

ジャヴァではなくてC++の処理系がdouble checked lockingする分には
処理系がサポートするネイティブなアーキテクチャのみ考えれば良いから
問題が生じることは無いはずでとりあえずはめでたいと思うが、

**デフォルトの名無しさん** · 2019/03/05(火) 01:34:00.08

グローバルなスタティック変数のように実行前に初期化する仕様にいまさら変えられない事情でもあったか。

**デフォルトの名無しさん** · 2019/03/05(火) 01:38:41.08

リンカにシンボルを渡す手段がｲﾏｲﾁ決め手に欠くｷﾓｽ

**デフォルトの名無しさん** · 2019/03/05(火) 01:40:59.82

あと複数の翻訳単位間ではグローバル変数の初期化順序は保証されない（保証しようが無い）から
そういう混乱を避けるために関数内staticは関数に入ったとき初期化されてﾎｽｲ

個人的には使わないから知らんが

**デフォルトの名無しさん** · 2019/03/05(火) 02:16:13.00

>>171
unique_ptr<int[]> u(new int[2]{6, 7});

**デフォルトの名無しさん** · 2019/03/05(火) 02:54:35.71

std::dynarray ってどこ行ったん？
http://ezoeryou.github.io/boost-benkyokai-sapporo

**デフォルトの名無しさん** · 2019/03/05(火) 03:25:14.57

なんだろう
この違和感

**デフォルトの名無しさん** · 2019/03/05(火) 04:45:14.68

ライブラリを作るときは、hpp にはクラスの定義を、cpp には実装を書く、と理解しています。

クラスのメンバでない関数はどう扱うべきでしょうか。
hpp にプロトタイプ宣言を、cpp に中身を書く、というので合っていますか。

**デフォルトの名無しさん** · 2019/03/05(火) 04:47:10.42

inlineは？

**デフォルトの名無しさん** · 2019/03/05(火) 04:50:23.83

なぜヘッダはクラス限定だとおもったんだ?
それ以前にクラス以外では使用したことがないのか?

**デフォルトの名無しさん** · 2019/03/05(火) 05:01:47.80

宣言（Declaration）と定義（Definition）は用語なんで覚えといた方がいいよ

**デフォルトの名無しさん** · 2019/03/05(火) 05:18:53.19

ヘッダに書くのはクラスだから関数だからとかじゃなくて、複数の翻訳単位(≒cpp)で共通で使うかどうかで決まる
1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ

**デフォルトの名無しさん** · 2019/03/05(火) 05:48:49.52

>>190
inline なので（苦笑

>>191
ハ？
回答の体をなしていない。
> hpp にプロトタイプ宣言を、cpp に中身を書く
というやり方は許容されるという意味か。

>>192
覚えました。それで？

>>193
であれば、今私は複数の cpp ファイルを持つ予定はないので、ヘッダファイルは全く不要ということになります。

**デフォルトの名無しさん** · 2019/03/05(火) 05:55:22.28

ライブラリなんだろ？
自分はcpp1つでも、他の人のcppで使わせるためのクラスや関数があるはずだ
それをヘッダに書け

**デフォルトの名無しさん** · 2019/03/05(火) 05:59:24.21

>>195
その際、「プロトタイプ宣言はヘッダで、中身は cpp ファイルに」というルールかマナーか慣習はありますか

**デフォルトの名無しさん** · 2019/03/05(火) 06:13:55.29

>>196
特にないから適当に他人のマネしとけばいいと思う。

**デフォルトの名無しさん** · 2019/03/05(火) 11:45:31.15

>>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ

staticは付けた方が良いですか？(苦笑

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/05(火) 12:27:38.14

内部リンケージにするには static を付けるよりも
無名の namespace に入れる方が良いやり方
みたいな雰囲気があるんだけど、
インデントが深くなるのがなんか嫌なんだよね。

インデントは文法に影響しないわけだから、
付けないという選択肢もとれるけど、
それはそれでなんだかなぁって感じだし、
結局は static を付けちゃうんよ。

無名 (unnamed) namespace って使う？

**デフォルトの名無しさん** · 2019/03/05(火) 12:35:48.55

関数よりファンクタの方が速いという情報を見たのですが、メンバ関数を入れ子クラスでメンバファンクタ化すると高速化が期待できますか？

**デフォルトの名無しさん** · 2019/03/05(火) 12:41:35.39

コンパイラ次第だろ
実験

**デフォルトの名無しさん** · 2019/03/05(火) 12:50:59.28

VC2017で試したのですがテスト用の関数が単純すぎるのかグローバルのインライン関数、クラスのメンバ関数、クラスのメンバファンクタで差異が見られませんでした・・・

**デフォルトの名無しさん** · 2019/03/05(火) 12:51:22.93

どこに書いてもいいだろ
他人の書いたコードなんてどうせ誰も読まないし
読ませたいならドキュメントしっかりさせたほうがいい

**デフォルトの名無しさん** · 2019/03/05(火) 15:12:40.70

>>202
その「ファンクタの方が速い」ってのは、一般的に関数ポインタを介するのと比較して、だよ
理由はインライン展開できるからであって、その実験で差異が出ないのは当然

**デフォルトの名無しさん** · 2019/03/05(火) 19:05:23.76

ストアドよりインデックスのほうが速いよってスレなかったっけ。

**デフォルトの名無しさん** · 2019/03/05(火) 20:02:38.14

>>204
なるほど
ありがとうございます

**デフォルトの名無しさん** · 2019/03/05(火) 21:56:22.01

>>199
使う理由としてはメンバ関数を内部リンケージにしたらリンク速くなるかもという期待だけだな
実際速くなるか調べたことないけど

明示的にstaticとある方が読みやすいし、無名はデバッガで見たときクソ見辛くなるし

c++はこういうダメ仕様多過ぎてうんざりだわ

**デフォルトの名無しさん** · 2019/03/05(火) 22:06:02.21

腐ったビルド戦略のせいで無駄なオブジェクトコードの重複を生じるのはゼロオーバーヘッド原則に反しないのか？は疑問だな
極一部のマニアしか使わない機能付けてオナニーしてる暇があったら、いいかげん時代錯誤なビルド処理の抜本的な見直しをやってほしい

**デフォルトの名無しさん** · 2019/03/05(火) 22:21:06.27

メンバ関数の数はクラスのオブジェクト生成コストにどれくらい影響しますか？

**デフォルトの名無しさん** · 2019/03/05(火) 22:30:58.04

>>209
まず自分で計測しろ

**デフォルトの名無しさん** · 2019/03/05(火) 23:07:56.79

>>209
数によるコスト差0だよ

>>210
計測したことあんの？

**デフォルトの名無しさん** · 2019/03/05(火) 23:19:26.52

ありがとうございます
というのもメンバ変数がなく多数の関数をまとめただけのクラスがあるのですが、次のどれがいいのか悩んでいまして
(1) 全部static関数にする
(2) クラスをnamespaceにして全部グローバル関数にする
(3) 呼び出す場所で逐次インスタンスを作成する
(4) 呼び出し側クラスでこのクラスのポインタをメンバとして持ち、コンストラクタでインスタンスを受け取るまたは生成する
この場合のベストプラクティスはありますか？

**デフォルトの名無しさん** · 2019/03/06(水) 00:13:14.35

(1)か(2)を好みに応じて

**デフォルトの名無しさん** · 2019/03/06(水) 00:17:08.38

特に何もないなら2

templateと組み合わせるなら1とか3は多用するけど4は無いな

**212** · 2019/03/06(水) 00:21:02.86

ありがとうございます
(2)でやってみることにします

**デフォルトの名無しさん** · 2019/03/06(水) 00:32:13.90

1 は、どうして君はすべての関数を、static 関数にできると思ったの？
static関数と、関数のライブラリ・モジュール化は関係ない

3, 4 は、どうして君は、関数を使うのにインスタンスが必要なの？

インスタンスの関数は、他の言語ではメソッドと言って、
そのインスタンスのメンバ変数を使うものに対して、特別な名称を付けている。
つまり、各インスタンスで値が異なるもの

メソッドは、一般的な関数とは異なる。
メソッドや一般的な関数と、関数のモジュール化は関係ない

例えば、Ruby では、
Math.log2( 8 ) #=> 3.0

このようにインスタンスを作らなくても、呼べる関数をモジュール関数と言って、
各インスタンスから呼ぶ関数を、メソッドと言って区別している

**212** · 2019/03/06(水) 00:42:25.73

そう言われるとそうですね
オブジェクト指向ではmain関数以外全部クラス/構造体で作成するものだという先入観がありました

**デフォルトの名無しさん** · 2019/03/06(水) 01:06:06.33

>>214
無理矢理4にしたいケースを考えると、同じインターフェースを持つ関数群A,Bを場合によって切り替えて使いたい場合に敢えてインスタンスのポインタとすることもあるかな。今回の質問者の場合には当てはまらないだろうけど。

**デフォルトの名無しさん** · 2019/03/06(水) 01:10:14.42

>>193
>1つのcppの中でしか使わず外に見せないクラスや関数はcppの中でいいよ
名前無しでも何でも良いが、その場合はクラスはnamespaceの中に入れないと危険が危なすぐる…

同じ名前空間に属する同じシグネチャのFoo::func()が異なる関数として複数のcppで定義された場合、
どっちが呼ばれるか定まらない処理系が実在する（VC++2010とか
多分ODR違反で未定義動作なんだと思う

**デフォルトの名無しさん** · 2019/03/06(水) 01:13:13.20

曖昧さは、利点にも欠点にもなりうる。
namespaceのグローバル関数ではなくクラスのスタティック関数にすることで曖昧さがなくなりコンパイルエラーを避けられる場合がある。

**デフォルトの名無しさん** · 2019/03/06(水) 01:14:08.29

>>219訂正
CPPでクラスを定義する場合は無名namespaceに入れないと危険が危なすぐる、
無名namespaceは異なる翻訳単位間では別名として扱われるから安全

一方、名前付きnamespaceでは異なるCPPで偶然
同じ名前空間に属する同じシグネチャのFoo::func()が作られてしまう危険性を排除できない

**デフォルトの名無しさん** · 2019/03/06(水) 01:21:31.24

>>220
そのクラスに非staticなメソッドを設けたとたん、
>>219と同じ話でどのFoo::func()が呼ばれるかわからないという不正な動作をする危険性が生じる

驚くべきことに、VC++2010の場合リンカが何のエラーも警告も出さない
それでいてしっかり変な動作になる（a.cppで定義したFoo::func()を呼んだつもりがb.cppで定義された同じシグネチャの別のFoo:func()が呼ばれる

**KAC** · 2019/03/06(水) 01:53:40.57

>>216
C/C++では、staticなどキーワードが全く違う複数の意味で使われるから注意な。

**216** · 2019/03/06(水) 02:00:53.56

Ruby では、関数名のバッティングを避けるため、2重に囲む。
module 内にclass か、class内にclassを作る

module Net
class HTTP end
class FTP end
end

# インスタンス
Net::HTTP.new
Net::FTP.new

**デフォルトの名無しさん** · 2019/03/06(水) 02:06:24.72

>>224
rubyボットはお呼びでないからもう巣に帰ってくれ

**216** · 2019/03/06(水) 02:12:57.91

static みたいな複雑な概念を、初心者が理解するのは難しい

スコープを限定する意味と、生成・破壊のタイミングの違いと、
2つの異なる概念を使うから、難しい

C++ は、すべてのリソースの生成・破壊のタイミングを追っかけるだけでも、大変

ドワンゴ江添の本「C++11/14 コア言語」にも書いてあるけど、

呼ばれる関数を探索する方法に、Andrew Koenig が提案した、実引数依存の名前探索 (ADL)もある

実引数依存の名前探索とは、C++において関数呼出時に与えられた引数の型に依存して、
呼び出す関数を探索 (lookup)する仕組みのことである。
英語ではKoenig lookup、argument dependent lookup (ADL)、argument dependent name lookupなどと呼ばれる

**デフォルトの名無しさん** · 2019/03/06(水) 02:46:55.34

>>216
>>212の(1)はクラスのstaticメンバ関数のことを言っているのだか、>>216や>>226を見てるとそれを理解していないように思える。
いつも書籍や他人の発言を引用して～～では、という書き方ばかりしているのを見かけるが、自分の中に落とし込んで理解できてないならわざわざ書き込まないでくれ。

**デフォルトの名無しさん** · 2019/03/06(水) 04:34:02.55

>>227
#激同

**デフォルトの名無しさん** · 2019/03/06(水) 06:59:23.47

質問(ネタ振り)に対して見当違いな返答は混乱の元ってのはその通りとして。
読者の立場では、話題が広がってくのは嫌いじゃない。

投稿者の意見として消化しきれてなくても、
参考資料として「誰それの書いたナントカって本では…」と
紹介してくれるのも有難いし。

その上で「あの著者/本は間違いが多い、例えば…」とか、
「記述が古い、新しい規格でもっと便利な機能が追加された」みたいな
追加情報(具体的なもの)が出てくればなお嬉しい。

**デフォルトの名無しさん** · 2019/03/06(水) 09:56:40.41

>>205
SQLの話ですか(苦笑)

**デフォルトの名無しさん** · 2019/03/06(水) 18:18:48.94

名前なし名前空間を名前あり名前空間の中に作ることができる。便利ちゃあ便利。

namespace hoge {
namespace {
int foobar = 1;
};
};

**デフォルトの名無しさん** · 2019/03/06(水) 21:53:00.33

64bit環境で文字列ストリームクラスstd::ostringstreamのインスタンスのスタックサイズが、
gccで376バイト, VS2017で232バイトもあるんだがもっと小さくできるんじゃないの？
ちなみに、std::string はgccとVS2017どちらも32バイト。
どうよ？

**はちみつ餃子** ◆8X2XSCHEME · 2019/03/06(水) 22:13:52.26

>>232
std::ostringstream は文字列の一種というよりも入出力の系統だし、
std::basic_ostream を抱えているのでそんなもんちゃう？

**デフォルトの名無しさん** · 2019/03/06(水) 22:36:11.10

継承してるしデータとして保持しておくものでもないしな

**デフォルトの名無しさん** · 2019/03/06(水) 23:24:49.53

>>232
質問と関係ないけどスタックサイズって何かわかってないだろ

**デフォルトの名無しさん** · 2019/03/07(木) 01:12:44.42

このあとスタックがおいしくいただきました

**デフォルトの名無しさん** · 2019/03/07(木) 01:36:59.97

ostream, ofstream, ostringstreamのスタックサイズはgccとVS2017でそれぞれ以下のようになる。
gcc: ostream=112, ofstream=264, ostringstream=232
VS2017: ostream=272, ofstream=512 ostringstream=376

どうよ？

**237** · 2019/03/07(木) 01:39:26.14

間違えた。gccとVS2017は逆です。
何が言いたいというと、組み込みで気軽に使えるC++を目指すならiostream周りを何とかしないとね、という話。

**デフォルトの名無しさん** · 2019/03/07(木) 01:41:48.62

組み込みで気軽に使えるC++を目指してないしどこまで削れるかはベンダーの努力次第

**237** · 2019/03/07(木) 01:45:06.81

Cがコンパイル言語であるにもかかわらずprintf()系の構文解析でJITコンパイルする野暮ったさを解決すべく導入されたはずのiostreamがまったく活かされていないね。

**デフォルトの名無しさん** · 2019/03/07(木) 01:45:09.29

その程度のスタック消費でヒーヒー言うような組み込み案件でiostream使わんだろ