C++相談室 part136

2018/06/07(木) 23:40:12.36

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

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

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

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

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

2018/06/14(木) 00:42:29.58

gtkもtcl/tkもwxも撲滅しなきゃならんのけ？

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/14(木) 00:43:59.29

>>201
＞ノードで循環を監視できれば
そんなことが、果たして可能なのか？

2018/06/14(木) 01:14:20.14

>>197
分けて書く理由にバリエーションの数は関係ないでしょう。

2018/06/14(木) 04:20:54.09

問：ある時刻tの日本の年号を返すプログラムをC++とSTLを使って表現しなさい。年号はコードに埋め込むものとする。

2018/06/14(木) 06:40:46.06

宿題は自分で頑張れ

2018/06/14(木) 07:14:11.27

>>198
参照のクモの巣と言えばDOMが有名だけど、あれはスクリプト言語ユーザーの都合上そうなっているだけで、C++ユーザーにとっては無用の長物なんだよね。
タブを一つ開くたびに500MB消費するのは許容限界を超えていると思う。

2018/06/14(木) 07:19:10.82

そして、ブラウザをCで書くのは非常につらい作業になるので、実用上C++を使うことになる。
したがって、スクリプト言語をホストする以上、自分たちにとって参照のクモの巣が無用の長物であったとしても、C++は、必要とされればいつでも参照のクモの巣をサポートする力が必要になる。

2018/06/14(木) 07:54:07.51

>>203
循環の検出ならスタックとノード毎の到達済みフラグがあれば逝ける
ドーナツ型の図形を塗りつぶすのと同じやり方
（個々のノードは、参照先の到達済みフラグがTRUEならああ循環したんだなあとﾜｶﾙ

2018/06/14(木) 08:05:57.75

まあ分岐の無い循環しかないならスタックは無しでも逝けるがな！
末尾再帰の最適化と同じやり方
（ループで済む

2018/06/14(木) 08:14:46.47

つまり古典的なマークアンドスイープ最強ってこったな。

**デフォルトの名無しさん** · 2018/06/14(木) 08:27:43.24

量子コンピュータなら循環なんて一瞬で分かるよね

知らんけど

2018/06/14(木) 08:37:33.66

そもそも再帰的なデータ構造じゃないものなら
循環参照のしようがないので普通に shared_ptr で良いし
そういう処理もごく普通によくある

>>209
＞（個々のノードは、参照先の到達済みフラグがTRUEならああ循環したんだなあとﾜｶﾙ

循環に限らず単純な共有でもこうなるので
そんなことでは循環したんだなあとﾜｶﾗﾅｲと思う

2018/06/14(木) 09:46:17.13

循環参照は甘え。

**かさぶた** (ﾜｯﾁｮｲ 99b3-4tVh) · 2018/06/14(木) 09:52:01.49

質問です、下記はソースの1部分なんですが、あるプロセスのメモリを検索しています。00000000～7FFFFFFFまでを検索しているのですが7FFFFFFFを9FFFFFFFまでに増やしたいです、単純に終了アドレスを9FFFFFFFにしても検索してくれないですが何故でしょうか？
http://codepad.org/cdLpKbdw

**デフォルトの名無しさん** · 2018/06/14(木) 12:13:24.04

>>215
INT36-C. ポインタから整数への変換、整数からポインタへの変換
https://www.jpcert.or.jp/sc-rules/c-int36-c.html

2018/06/14(木) 13:43:20.70

>>216
どの部分ですか？

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/14(木) 21:03:45.53

>>209
kwsk

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/14(木) 21:04:41.22

>>211
他に方法がないが、いちいち mark and sweep するなんて考えられない

2018/06/14(木) 23:42:44.50

>>213
>循環に限らず単純な共有でもこうなるので
到達済みフラグをセットするのは開放時なので
ならない

>ドーナツ型の図形を塗りつぶすのと同じやり方(>>213)
と書いただけでは通じなかったですかそうですか、

2018/06/15(金) 00:11:08.99

ごめｗｗｗｗｗｗ
×：到達済みフラグをセットするのは開放時なので
○：到達済みフラグをセットするのは参照カウントを減らすときなで

2018/06/15(金) 00:31:56.81

と思って今作ったがあんま使い勝手の良いものにはならんかったorz
使い方としては
class Foo {
　sumapo<Foo> m_pCar;
　sumapo<Foo> m_pCdr;
　/*...*/
};
sumapo<Foo> ptr(new Foo());
と書いた後、ptrが開放されたとき、ptrが指すFooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しいわけだが
これにはptrが握っているFooを開放する前に、ptrがFoo::m_pCdrやFoo::m_pCarを辿れる必要があるので
m_pCarやm_pCdrとptrが裏で手を握る必要がある

2018/06/15(金) 01:30:57.51

sumapoが酢マンポに見えた

2018/06/15(金) 07:32:17.48

ごめｗｗｗｗｗｗｗまた言い方をちょっとまつがえたorz
誤： Fooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しい
正： Fooが握っているsumapoが（循環があろうとなかろうと二重破棄を招かない形で）参照カウントを減じて欲しい

リフレクションがあればsumapoからFoo（やBar）のメンバが丸見えなのでsumapoのリンクを辿って破棄予定オブジェクトを事前にマークすることで2重破棄の防止を自然に実現できる
リフレクションが無い現行のC++なら、sumapoのデストラクタで破棄される予定なFoo（やBar）をマークだけして破棄を遅延する、みたいな細工をするしかないが
デストラクタの中から全てのFoo（やBar）のマークが完了したか知る術が無いから、sweepする呼び出しが別途要る、、

やっぱC++にもリフレクション欲しい…

2018/06/15(金) 08:54:27.46

>>224
JavaScripterマジで死ねよ

JavaScriptのコミュニティが腐っているのは、
馬鹿であることを自覚出来ないお前みたいな大馬鹿が、嘘を平気で垂れ流しているからだよ。
そして初心者はそれを見抜けず、騙されて馬鹿が再生産されてる。

お前らがC++のコミュニティを破壊する権利はない。JavaScriptのゴミ貯めに戻れ。
お前らはプログラマ全体からするとゴミ以下のクズなんだよ。それを自覚しろ。
C++初心者の為に、俺がお前の嘘を暴いておいてやる。

> リフレクションがあれば
お前のリフレクションの使い方は、メンバの中身を参照したいだけのようだ。
ならば、全てのメンバがpublicだったらいいはずだ。
このケースで、どうやって実現出来るのか説明してみろ。
お前は本当に何も分かってない。最初から躓くと思うぜ。

オブジェクトＡのメンバはすべてpublicである。
オブジェクトＡのインスタンスa,b,c,dは
・aはbを参照している
・bはaを参照している(a-b間で循環参照）
・cはbを参照している
・dはcを参照している
の状態で、a-b間で循環参照があり、参照はd -> c -> b <-> aとなっている。
これらへの参照は他にはない。
今、dへの参照がなくなり、dのデストラクタが起動された。

この状態で、どのように回収されるのか、説明してみろ。
お前みたいな馬鹿には出来ないと思うぜ。

さっさとJavaScripterの巣に帰れ。邪魔でしかないから。

2018/06/15(金) 09:22:53.91

>>220
単純な共有と循環を区別できるコードを書いてみてごらんよ。
あなたが考えているような簡単なものにはならない。
恐らくはあなたには書けないから。

コード書かずに妄想してるから間違えるんだよ

2018/06/15(金) 09:28:19.83

いや違うか。
普通はコード書かずともちょっと考えればそんな間違いしない。
考えずに書くから間違いばかりする。

2018/06/15(金) 10:24:12.07

C++って難しいの？

2018/06/15(金) 10:24:22.09

有向グラフでマークしてトラバースすれば循環がわかるのは単方向リストくらいなものだろ
ドーナツがどうとか言ってるのは無向グラフと混同している

2018/06/15(金) 11:47:40.97

>>228
難しい人が多いよ

**デフォルトの名無しさん** · 2018/06/15(金) 12:08:37.80

難しい人ってか、基地外な人が多いね

2018/06/15(金) 14:00:33.64

JavascriptとC++では要求されるレイヤーが違うので、比較するのは無理だと思う。

2018/06/16(土) 01:44:46.69

複雑な参照を持つシステムってまぁほとんどシミュレーション系で速度も要件に入ってくるんですよ。
糞遅いJavascriptやpythonなんて普通に使いものにならずC++の独擅場なわけですよ。
pythonでAIとか笑っちゃいますね。

2018/06/16(土) 03:04:09.42

>>233
この場合の Python はいわゆるグルー言語でしょ。
高速なコンポーネントのパラメータを指定して組み合わせるだけみたいな使い方なんじゃないの。

高速な計算が出来るコンポーネントは C++ が主流であったとしても、
それをビジネスロジックにさっと適用するという意味での「Python で AI」は現実的だし、
実際よくあることだと思う。

2018/06/16(土) 03:46:18.97

高額なPython屋募集のAI案件は、99%非現実的。
AIを何も分かってな奴が企画したプロジェクト。散々利用されてきた統計学以上の成果など出やしない。
昨今のAIブームは過去のAIブームと同じく破綻プロジェクトばかりなのは言わずもがな。

なぜPythonか。失敗したときにPythonだからと言い訳するため。
そもそも簡単な言語なのに高額で募集する時点で辻褄が合わない。
嘘ついて投資募ってるのは明らか。読売新聞のAI記事読んでると騙す気満々だと分かる。

openCVスレでもpythonから入る奴は何もできやしない。最初から分かりきったこと。フフフ、笑えますね。

2018/06/16(土) 04:06:22.88

結局はコンポーネント間の通信回数を減らすことが肝。しっかりと設計を吟味すれば従来通りのIPCで十分だったりする。

2018/06/16(土) 09:29:46.67

>>235
でもAIってモジュール部分は超簡単なんじゃない？　それにそんなもの「作る」って
レベルじゃないから、出来の悪い奴でもいいから一人がC++でモジュール書いていば
OKでやっぱPythonレベルの方が重要なのではないか？

2018/06/16(土) 09:39:44.63

そのあたりはpythonのソースコードを見ると分かる
ttps://github.com/python/cpython/blob/master/Objects/weakrefobject.c

2018/06/16(土) 12:41:15.99

C++の公式スクリプト言語はPythonだから慣れるしかない。

2018/06/16(土) 16:48:42.77

何かのネタ？

2018/06/16(土) 16:56:00.16

AIで一番大変なのはデータを食わせることだよな。パイトンでもC++でもなくて
一番重要なのはエサやりして大切に飼いならす人だよ。だから愛がないとできない。
お前等には無理だな。三日やったら課長の机に糞してとんづら。

2018/06/16(土) 17:02:55.51

その学習させた膨大なデータが高額で取引される時代が来るのかね

2018/06/16(土) 23:47:37.78

OCamlがあるのだからオッパイソンがあってもいいはずだが。

2018/06/17(日) 09:57:43.12

>>235
ほとんどのAI案件がやばいってのは同意だが
pythonなら言い訳できるってのはねーわw

そもそもAI案件の難しさはプログラム言語がどうのとかそういう問題じゃない。

2018/06/17(日) 11:12:20.33

>>230-231
仮にそれでもJavaScripterよりマシだ。
お前も含めて、JavaScripterには、馬鹿かつキチガイしか居ない。
例>>220,224：　反論することも出来ず、間違いを認めることもなく、ただ逃亡

これをやるからJavaScriptのWebリソースは大半が腐ってる。
俺は知らんがC/C++はWeb上の間違いに異常に厳しかった時代があったと聞く。
それが今も引き続いていて、Web上の正確性を担保してくれているのなら、有り難い話だよ。
ゆとりには「ぼくがおこられなければいい」という幼稚園児並みの知能しかないから、
JavaScriptコミュニティみたいなことが発生する。
あれは最早完全に手遅れで、その状態のゆとりが教える側に回っていることが最悪。
連中は平気で嘘をつく韓国人レベルのモラルしか持ってないし。
結果的に間違いであったにせよ、修正しておかないと、後で読む人の為にならないだろ。
「嘘だと認めなければ嘘ではない」という、韓国人みたいな奴は、キッチリ殺すべき。

間違ったことを書いたら叩かれるのは、長期的に見ればいいことだ。
それがゆとりには分からないだけでね。

あと、わざわざID消して自演しているゴミ、それは余計に目立つぞ。
他の誰もそんなことをしてないから、逆にコテトリになってる。
お前は他でも荒らしまくってるよな。

2018/06/17(日) 11:26:31.91

>>227
一番足りないのは謙虚さなんだけどな。

JavaScripterは本当に馬鹿しかいないから、コードがマジでゴミしかない。
だから糞コードしか書けない馬鹿がつけあがる。
そしてそれを諫める年長者もいない。幼稚園で先生がいない状態だ。

C++は30年の歴史があって、仕様も改訂し続けているのだから、
今の仕様はその中で今一番マシな方法ということになっている。
JavaScripterみたいなぽっと出のゴミがぱっと考えて思いつくような手法を、
今まで30年間誰も思いつかなかったと思うこと自体がキチガイでしかない。

2018/06/17(日) 11:30:36.00

というわけで先に進める。
沸きまくっている馬鹿を振り落とす為に速度を上げるからよろしく。

>>213
> そもそも再帰的なデータ構造じゃないものなら
> 循環参照のしようがないので普通に shared_ptr で良いし
> そういう処理もごく普通によくある
「再帰的なデータ構造ではないとき、循環参照は発生しない」については同意だが、
「循環参照がない場合は、shared_ptrでいい」には反対だ。
これだとC++の速度優位性が無くなるので、俺ならGC言語を検討する。
ただしこれは宗教だからもういい。

本題は、

・shared_ptr（静的共有)必須な構造が、果たしてあるか

だ。木構造で一番身近なファイルシステムを例に取ると、
静的共有(ハードリンク/shared_ptr)と動的共有(シンボリックリンク/getter)のうち、
前者はほぼ使われてないだろ。
これは、ユーザーによる手動管理の場合、シンボリックリンクの方が明示的で使いやすいからだ。
シンボリックリンクは常に最新版を、ハードリンクは常に生成時の対象を参照するところが異なる。

速度的には静的共有の方が優位だとして、動的共有では無理な事例ってあるか？
俺が知っているハードリンクの活用事例は、WindowsUpdateくらいだ。
「動けばいい」なら動的共有の方が適切に思える。
(C++で動的共有はなかなかにきついが、動的言語なら自然に実現出来る）

2018/06/17(日) 11:37:00.29

>>245
何故に自分のことと思ったのか知らんけど、自覚が無いよりはあったほうがいいと思うよ。
別スレでID無しにイジメられたんか？

2018/06/17(日) 11:58:04.60

>>248
俺から見ればお前がキチガイだし、
ここがお前にとって合わないと思うのなら、お前がここに来るのが間違ってる。

ゆとりはゆとりだけでスレ作れよ。
それがお互い一番幸せな解決だ。

俺には韓国人とゆとりは殺すしかないという結論が出てる。
お前らは邪魔しかしないから。今もそうだろ。

2018/06/17(日) 12:17:06.47

初心者で的はずれな質問かもしれませんがお願いします。
1行に約4000文字,区切りで書かれたファイルがあり、これが1000行あります。
このファイルを1行ごとに別の配列に格納したいのですがfgetsだとchar型になりcharは256文字しか入らないようです…
どうしたら読み込みできるのでしょうか

2018/06/17(日) 12:21:49.68

>>250
> fgetsだとchar型になりcharは256文字しか入らないようです

単に間違えたプログラムを書いている。
そのプログラムを提示してみて。

2018/06/17(日) 13:16:47.51

std::getline使え。

**デフォルトの名無しさん** · 2018/06/17(日) 14:34:42.11

C言語を通らずにいきなりC++を使う初学者は
fgetsやcharに触れるべからず
必ずラッパーライブラリを使うべし

2018/06/17(日) 14:38:26.28

>>250
getcを使ってmyfgetsを新たに作る
改行を調べるだけなのでそんなに苦ではない

2018/06/17(日) 15:00:46.90

>>247
C++風に考えるとstd::shared_ptrは必要なくなってくるけど、他の言語の真似をしようとすると、必要になるんだよな。
そしてC++は他の言語から呼び出されるから。
そういう部分で必要があるのかも。

2018/06/17(日) 15:03:38.90

スレッド使う場合は、コピーのほうが速くないかよく考えた方が良い。
意外とコピーのほうが速い。

2018/06/17(日) 15:29:58.46

>>253
宗教じみたことは言わないほうがいい。

C++の入出力クラスiostream系の標準機能は失敗した代物との結論が出ている。
C++学習者は FILE* 系の標準機能を優先して使うのが正道。

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/17(日) 15:54:43.81

>>257
iostream 系のどんなところが失敗しているのですか？

**デフォルトの名無しさん** · 2018/06/17(日) 16:15:29.34

>>257
あり得ない
ポインタも分からん奴に生char使われてたまるか
fgets使いたいならC言語で基礎を身に付けてから出直して来いや

2018/06/17(日) 17:04:58.59

たしかにiostreamはデストラクタで自動的にクローズしてくれるくらいしか
メリットが感じられないから、自分でファイル入出力クラス作ってるわ

2018/06/17(日) 17:21:05.94

iostreamはC++のテンプレートクラスが未発達だったころの遺物だよ。STLに含まれない時点でお察しではあるが。
iostreamを使うよりもshared_ptrなどのスマートポインタでFILE*をラップしたテンプレートクラスを使うほうが現代的。
shared_ptr::shared_ptr<FILE>のコンストラクタで第二引数にfclose()を呼び出すdeleterオブジェクトを渡すだけで事足りる。
shared_ptr::shared_ptr<FILE>直使いもいいが、その派生クラスを使って暗黙のFILE*型キャスト演算子を実装すれば、Cコードとの移植性がさらに高まる。

あと、iostreamはios系の様々なフラグがあるが、煩雑で使い勝手が悪い。覚える価値ゼロ。

2018/06/17(日) 17:21:36.16

>>258
速度じゃないか？
使いもしないオペレータのために余計な処理挟むから。
VCについてくるディンカムウェアなんか一バイトごとに仮想関数呼び出してるぞ。

**261** (ﾜｯﾁｮｲ 45d2-Bw3Y) · 2018/06/17(日) 17:27:10.63

訂正。
shared_ptr::shared_ptr<FILE> じゃなくて、shared_ptr<FILE>でした。
deleterサンプルは以下の通り

struct file_deleter { void operator() (FILE* fp) const {if (fp != NULL) { fclose(fp); } }};
shared_ptr<FILE> fp(fopen(filename, "r"), file_deleter());
// 以下、fp.get() でFILE*にアクセス。

2018/06/17(日) 17:29:10.50

まあでも、明らかな失敗だったら auto_ptr や wstring_convert みたいにとっくに deprecated にされてるよね。

2018/06/17(日) 17:41:30.52

全く理解出来ない
俺が低レベルなのか？

2018/06/17(日) 17:54:24.16

class FILE_Ptr : public ns_shared_ptr::shared_ptr<FILE> {
　struct FILEDeleter {
　　void operator() (FILE* fp) const {
　　　if (fp != NULL) {
　　　　fclose(fp);
　　　}
　　}
　};
public:
　FILE_Ptr(FILE* fp = NULL) : ns_shared_ptr::shared_ptr<FILE>(fp, FILEDeleter()) {}
　operator FILE* () { return get(); }
　template<typename T> bool operator == (const T& obj) const { return get() == reinterpret_cast<FILE*>((void*)((intptr_t)obj)); }
　template<typename T> bool operator != (const T& obj) const { return get() != reinterpret_cast<FILE*>((void*)((intptr_t)obj)); }
};

void fclose(ns_shared_ptr::shared_ptr<FILE>)
{

2018/06/17(日) 17:59:57.67

>>266を途中で送信してしまった。

ns_shared_ptrは、boostなりstdなりstd::tr1なり自分の好きな名前空間に置き換えを。以下のように。
namespace ns_shared_ptr = boost;

グローバル関数fclose(ns_shared_ptr::shared_ptr<FILE>& fp)を別途作れば、
Cのコードをコピペ利用した時のfclose(fp)多重呼び出しを防止できる。

2018/06/17(日) 18:09:36.34

>>207,208
>>255,256
DOMの話か？500MBは言い過ぎだからとりあえず放置したが、
GC言語は基本的にshared_ptrの仕様だから、その実行エンジンの実装に使われるのは妥当だ。
これをサポートする為、shared_ptrは仕様上は必要だ、というのも同意する。

問題はそれがデータ構造として必要か、という点で、
DOMの場合、HTMLは共有無し/循環参照無しの単純な木だからunique_ptrだけで問題なく構成出来る。
ただしJavaScript側に捕まれている場合、ノードが木から取り除かれた場合にも保持し続けねばならず、
この実装にはshared_ptrを使わないと厳しいだろう。
しかしこれはデータ構造ではなく、JavaScriptの仕様が原因だ。

マルチスレッドのキャッシュについては、これは現時点でのハードウェアの問題で、
単純に言えば共有RAMに対して書き込みをすれば著しく遅くなるだけだ。
これはデータ構造の問題ではないので別に取り扱う必要がある。
(速度低下はshared_ptrの問題ではなく、キャッシュ構造起因）

データ構造について言うなら、shared_ptrの使いどころは、

1. 共有ノードがある
2. 循環参照はない
3. 動的に生成/消滅を頻繁に繰り返す

だと思うんだが、2の為にメッシュ構造とかは基本的にアウトで、
3も基本的にないだろ。
実はあんまり使いどころなくね？って話。

2018/06/17(日) 18:14:03.26

weak_ptr の使いどころを見極めるのが難しい。

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/17(日) 18:17:30.15

>>261
＞iostreamはios系の様々なフラグがある
そうそう、今いち、よく定義がわからないんだよね
それに、手元の実装がこのフラグについてまともじゃないかもしれない

2018/06/17(日) 18:30:46.42

iostreamを今、作り直すとしたらfilesystemやstring_viewも視野に入れなきゃね

2018/06/17(日) 18:54:25.32

ビジネスで優秀な人材育成する上司は何を教えているのか？
https://www.youtube.com/watch?v=apxtSqxjw08&;t=13s
美容師の楽しさ再発見！やる気スイッチが入る働き方セミナー
https://www.youtube.com/watch?v=DGzXQT799oY
マクドナルド伝説の店長が教える、最強店長になるために必要なこと
https://www.youtube.com/watch?v=0wMbR7JIeeQ&;t=3154s
『上司が伝えるべき一番大切なこと』
https://www.youtube.com/watch?v=xsfJ-ZC42pQ&;t=1199s

2018/06/17(日) 19:38:39.93

C++でよく使われる各オブジェクトのスタックサイズは以下の通り。
stringstreamとfstreamのサイズは無視できない大きさであることがわかるだろう。

・GCC - ubuntu Linux x64
　(sizeof(std::stringstream), sizeof(std::fstream), sizeof(std::ostream), sizeof(std::string), sizeof(std::vector<std::string>), sizeof(FILE))=(392, 528, 272, 32, 24, 216)

・Visual Studio 2017 - Windows10 x64
　(sizeof(std::stringstream), sizeof(std::fstream), sizeof(std::ostream), sizeof(std::string), sizeof(std::vector<std::string>), sizeof(FILE))=(248, 280, 112, 32, 24, 8)

2018/06/17(日) 19:51:08.65

>>273
数百バイト程度は許容できるんじゃないの。
コンテナに入れるわけでもないし。

2018/06/17(日) 19:53:22.73

>>268
ないよ。

**デフォルトの名無しさん** · 2018/06/17(日) 19:54:46.50

直近のスレを見れば分かるとおり、C++は複雑怪奇魑魅魍魎だから
プログラミング初学者が手を出したらヤケドしかしない

2018/06/17(日) 20:02:30.99

勉強でヤケドする分には問題ないし、
むしろ沢山ヤケドして危険を避ける能力を身に着けるしかない。
実務でやったらアウトだが。

2018/06/17(日) 20:41:28.94

iostream 文句言われてるけど、atomic に動作するところは thread 並列環境では
そこそこ良いのでは？もちろんその分遅さが気になる場面もあるけど。

2018/06/17(日) 21:07:46.84

iostreamは速度を全く期待せずに使うという
C++らしからぬ面を持ったものだ
sync_with_stdio? はははは

2018/06/17(日) 21:11:08.16

国際化に向かないのが致命的。
これだけで捨てる理由としては十分と思う。

2018/06/17(日) 21:48:20.12

MSVCのstd::arrayがC++11に準拠してくれればいいのに。使えねー。
言語レベルで区間チェックしてくれたら、データ破壊の場所がすぐにわかるのに。

2018/06/17(日) 21:52:06.00

スタティックライブラリAが別のスタティックライブラリBのAPIを使っている場合、ライブラリAにライブラリBをリンク、ビルドして、結果できたライブラリAだけをリンクして、実行ファイルを作る形式が良いでしょうか。
それともラリブラリA、ライブラリBを別々にリンク、ビルドして実行ファイルを作る形式が良いでしょうか。

◆QZaw55cn4c (ﾜｯﾁｮｲ 2260-m0US) · 2018/06/17(日) 21:54:39.50

>>282
＞ライブラリAにライブラリBをリンク、ビルドして、結果できたライブラリ
そんなことができるのでしょうか？

2018/06/17(日) 21:55:46.98

後者しかできないような気がするんだけど

2018/06/17(日) 21:57:07.16

>>281
msvcのat()関数は範囲チェックしないの？

2018/06/17(日) 23:22:41.94

>>285
するけど、多数に生配列があって困難

2018/06/18(月) 00:02:38.25

iostream の替わりになるようなデファクトスタンダードが登場していない以上、
ほどほどに付き合っていくしか仕方がないよ。

C スタイルは普段から使うには抽象度が低くて面倒くさい。
printf は std::string を表示するのにさえいちいち c_str を通さなきゃならんのだからな。
書式指定との整合が型システムで保証されないのも古い設計だし。
処理系の方である程度は特別扱いすることで折り合いがついてるけど、
あらためて考えるとだいぶん不格好だと思う。

コンセプトやら何やらが導入されたらもうちょっとマシな入出力ライブラリが出来たりしないもんかね？
提案くらいは出てたりしない？って思ったけど、こないだ江添っちがTwitterで「無い」って言ってた気がする。

2018/06/18(月) 01:00:03.25

現実的にはxmlなど標準的な形式のファイルを扱うライブラリを使うんで本当に低レベルなIOはどっちでもいい

**273** (ﾜｯﾁｮｲ 45d2-Bw3Y) · 2018/06/18(月) 06:12:18.90

>>274
iostreamは肝心な時に使えない橙武者です。

ログ出力するクラスは歌舞伎の黒衣のような慎ましい存在でなければならないのですが、
iostreamはあたかも歌舞伎の花形役者のようなオレ様的存在感を出すので好ましくありません。

実例をあげるならば障害発生した時に、ログ用途でiostream系を使うことがあり得えます。
cout やその他インスタンスが生成されてスタックを多く使うことになります。
つまり、実運用環境とログ埋込環境でメモリ構成が大きく異なる環境になってしまうことが避けられません。
iostreamはマルチスレッド環境など対話デバッグでは追跡しにくい現象をログ出力するのに適さない、と断言できます。

橙武者、黒衣など語の意味が分からない方は、ご自身でおググり下さい。

2018/06/18(月) 08:25:55.66

io_contextで世界が変わる。

2018/06/18(月) 08:29:09.26

coutってアクセスするたびに生成するわけじゃないよね？

2018/06/18(月) 08:34:19.02

ツリートラバースするのに、再帰使うよりstd::deque使ったスタックのほうが速いな。

2018/06/18(月) 08:36:26.28

>>291
グローバルオブジェクトとしてずっと存在してる

2018/06/18(月) 08:54:52.73

内緒ですけどね。書式設定はprintfのほうがソースが見やすいですよ。

2018/06/18(月) 10:18:21.92

内緒な、約束だぞ

2018/06/18(月) 11:02:34.48

「標準出力への書き込みは遅いから」との理由で、メモリ上にログをため込むことは多いかと思います。
iostream系だと stringstreamを使うことになりますがスタックサイズが割と大きくインスタンス生成のたびに時間もかかります。

さらにいえば、MSVCの場合、snprintf()に比べてstringstreamは書き込みに3倍弱時間がかかります。
本来ならば << 演算子はコンパイル時に型が決まるので書き込みが高速なはずなのですが、
MSVCだとstringstreamがsnprintf()に負ける有様ということです。
なお、Linux GCCの場合、snprintf()とstringstreamは書き込み速度の差は少ないようです。

2018/06/18(月) 15:29:29.80

C++を完全に理解したんだけど、質問ある？

2018/06/18(月) 16:23:01.82

CとC++で演算子の優先順位が異なる所があります
どこてしょう
もちろん両方に存在するものです

2018/06/18(月) 17:54:25.08

>>298 の問題は面白いし俺も答えに興味あるけど >>297 への挑戦とすれば
「C++は完全に理解したけどCの方は知らないよ」で逃げられるかと。

2018/06/18(月) 18:01:10.79

C++の規格はCの規格を参照してるし、Cとの差異も規格の一部になってるので
C++の完全な理解の中に当然含まれる

2018/06/18(月) 18:31:36.77

アホなので優先順位の違いはわからないけど、
if ((v=f()) == 0) を if ((v=f()) = 0) とタイポしたとき
c++ だとエラーにならず v が 0 になるのは嫌な感じ