TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼
ECMAScript デス 4
国産オープンソースDIコンテナSeasar2 その16
おまいらはディープラーニングの検定試験受けるの？
【SL4】Windows Phone 7 ｱﾌﾟﾘ開発ｽﾚ Part4【XNA】
Visual Studio 2010 Part21
最も美しいプログラミング言語は？ Part6
【.NET】F#について語れ2【OCAML】
【入門】Common Lisp その11【質問よろず】
【Erlang】プログラム言語 Elixir 【BEAM】
Deep learning

C++相談室 part136


1 ：2018/06/07 ～ 最終レス ：
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.2ch.sc/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

2 ：
2get

3 ：
STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後R。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

---- テンプレ ここまで ----

4 ：
C++解ると豪語していた人が後日茂みで戉だらけの死体で発見される例が後を絶ちません
C++解るは何か宗教的禁忌の呪詛なのだと思います

5 ：
青い鳥に「C++を完全に理解した」と語りかけると
もれなく狂人が群がってきて引き裂かれます

6 ：
構文、ライブラリ、パラダイム毎のテクニック、イディオムの一部を覚えて解った気になるなはどの言語でも同じね

7 ：
>>3
このテンプレ貼り付けるの面白いんか

8 ：
C++を完全に理解するには40年の下積みが必要

9 ：
C++77をやっと理解しました

10 ：
c++11とか14とか17って何ですか？

11 ：
ggrks

12 ：
C++完全に理解したわ。

13 ：
>>12
おお凄いですね！
初学者が手をつけるといい分野を教えてください

14 ：
C++完全理解ってすげー
入門本ですら辞書の様に分厚いのに

15 ：
覇王になれます

16 ：
コンパイラの中の人や
規格票の中の人なんかね

17 ：
C++界のラオウ

18 ：
>>12の家に江添が向かうぞー！

19 ：
12による攻略本を待てば良いのか？

20 ：
最近は規格を完全に満たしたコンパイラって存在するの？

21 ：
C++11は結構「満を持して」って感じだったけど、その後14だ17だとアップデートサイクルが
短くなるならCfrontに回帰してもらった方がハッピーな気がしてきた。
今のC++で技術的にどのくらいしんどいのかはわからないけど、TypeScriptやBabelなんかの
JS界隈でうまくいってるエコシステムがうらやましい。

22 ：
>>21
> JS界隈でうまくいってるエコシステムがうらやましい。
それはお前がJSを知らず、隣の芝が青く見えるだけ。
あれは完全に屋上架屋で糞だ。C++のノリで動くと思ったら大間違い。

23 ：
ラムダとか型推論とか
やわらか言語のお遊びだと思ってたのにいまじゃこの有り様だよ

24 ：
コンパイラを駆動するためのプログラミングと、実行可能形式を駆動するためのプログラミングを一度にできる、一粒で二度おいしい言語がC++である。
つまり、ビールとワインを混ぜたらとてもまずかったというお話。

25 ：
>>22
？
TypeScriptもBabelも普通に使ってるけど？
それがうまくいってるのを見てるからこそC++もそうできたらいいと思ったんだが。
まぁ、コンパイルに時間がかかるのとデバッグがちょっと隔靴掻痒気味ってのはある。

26 ：
>>21
つーかC++11って、みんなもう待ちくたびれて
C++0xという期限も守れなくて、
一部でC++オワコン？とか言い出してる雰囲気の中、
ああ、やっぱりあるのかという復活祭的なもんだったろ

27 ：
>>25
C++にそれらがないのは、C++にはそれらが必要とされてないからだよ。
要するに全てはJavaScriptが糞すぎるから始まったことでしかない。
それがいいと思うのも自由だが。

28 ：
>>27
何を言うか！
Javascriptが最強の完成された言語だからこそ、Typescriptが誕生できたんじゃないか！！！

29 ：
金箔貼っても糞は糞

30 ：
C++がこっち方向→に糞だとすると、Javascriptは←あっち方向に糞。

31 ：
>>25
要するに、自分が慣れている環境を持ち込みたいだけだろ。
ならJavaScript流に言えば、お前が作れ、でしかないだろ。
ご自由にOSSにすればいい。誰も使わないと思うけど。

32 ：
歯糞耳糞を笑うというが、本物のウンコには誰も勝てなかったというお話。

33 ：
>>26
結構印象が違うもんだね。
C++03が失敗気味でオワコン視された雰囲気はわかるけど、だからこそ次は失敗できない
C++11はそれなりの完成度になったと思うんだが。逆に14や17は蛇足気味のような。

34 ：
しかしJavascriptとC++を完全に理解した俺が最強ってことだろうな。

35 ：
同じ糞なら書かなきゃソンソン

36 ：
>>33
＞C++03が失敗気味でオワコン
え…それは本当ですか？
C++03 で生きていこうと思っていたんですが…

37 ：
>>33
いや14は重要なバグ直しでautoが安心して使えるようになったし
17はfilesystemやstring_viewにexecution（これすげー）が入って名実共にメジャー
やっぱC++03からの沈黙が異常すぎたんだよ

38 ：
>>36
常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。

C++14 や C++17 はユーザ視点では重要なものも含まれるとは思うが、
C++11 に間に合わなかったりミスがあったりしたのを補った、
マイナーアップデートという印象は有るな。

39 ：
>>38
スマートポインタの恩恵は享受しようと思いますが、右辺値参照はよく理解できません…

40 ：
>>39
テンポラリ＝constと短絡されていたが
実はそうではなかった
禿すらも気付くのが遅れた
それが&&

41 ：
キーワードclassは結局いらなかった
newは忌み子だった

禿がどういう方面で過ちを犯したか
何となく察することができるだろう

42 ：
newで帰ってくるのがunique_ptrにならねえかなあ

43 ：
>>39
えっ、それって重要な機能のひとつじゃね？

ライブラリは標準になくてもなんとかなるけど、
基礎的な機能で大事なトピックがてんこ盛りなのが C++11 でしょ。

最低でも

auto
decltype
constexpr
可変長引数テンプレート

あたりは無いとつらすぎるんですけど！

44 ：
>>38
> 常に最新を使えとまでは思わんが、さすがに C++11 は人権だと思うぞ。
そりゃ人に依るだろ。今でもCは現役なんだし。

>>43
ちなみに他言語を使わない理由は何だ？
おそらく君はインラインアセンブラとか全く使わない人だろ？

45 ：
C++17はDoxygenを凄いことにする。
ひどい奴だ。

46 ：
std::unique_ptrはユニポと読むんだよな？

47 ：
>>44
> ちなみに他言語を使わない理由は何だ？

Scheme スレが私の巣だと思ってるくらいには Scheme 派なんだけど、
話題が少なくて暇だからこっちに出てきてる感じ。

> おそらく君はインラインアセンブラとか全く使わない人だろ？

使わないに越したことは無いというのが基本姿勢ではあるけど、使う必要があるので使うよ。

どういう意図で言ってんのかよくわかんないんだけど、
C++11 以降に加わった機能がスゲー大事という気持ちとこれらが何か関係あるの？

48 ：
人は皆生まれながらにC++が好きだけど、その気持ちに気づくかどうかに違いが出るんだよね。

49 ：
がしゃーん
　　　　　がしゃーん

　　　△ ￥ ▲
　　( Ｃ ＋＋ Ｃ )
　　(　　 　　　)
　／│　 肉　 │＼
＜　 ＼＿＿＿／　 ＞
　　 　┃　　┃
　　　＝　　＝
C++17だよ
自動で Doxygenを凄いことにしてくれる
ひどいやつだよ

50 ：
よく知らないのだけど、いったいC++17でDoxygenに何が起こるんだ・・・

51 ：
>>47
俺はC++を使う利点は

・高位から低位まで同一言語でカバー出来る点

だと思っていて、逆に言えば、
高位でしか組まないのなら他高位言語を使った方がいいと思ってるんだよ。
だからC++の利点を生かす為には、

・高位の機能と低位の機能を混ぜて使う
　＝スマポもラムダもナマポもインラインアセンブラも 『同時に』 使う

事が必要で、逆に、このスレに巣くっているナマポ禁止な連中には若干懐疑的なんだよ。
それなら他言語の方が生産性が高いから。
必要ならその部分だけCのDLLにすれば済む話だし。

そして最近の新機能は高位向けの物が多いから、聞いてみたわけだ。
Schemeは知らんが、他高位言語を使っているのなら済まんかった。

52 ：
>>51
高から低をカバーしてるのが良いというのは私もまったく同意見だよ。
だから、高から低をカバーと言っておきながら、高水準の部分は他言語に任せた方がいいというのはなんか矛盾してないか？

俺は「(現代の水準では) 足りてないからもっと (少なくとも C++11 で追加された分くらいは) 欲しいよな」って気持ちなわけ。

53 ：
>>52
矛盾してない。

高水準の部分はC++は他言語に対して後れているから、
C++がそれを追加するのは妥当ではある。

ただ、俺なら他言語で組んで、CのDLLを呼ぶようにする。
それだと、他言語の進んでいる高水準機能を使えるから。
わざわざ遅れているC++に対して文句を言いながら使う意味がない。

例えば、C#がその作りになってるでしょ。
マーシャルがウザイか、C++の機能的周回遅れがウザイかってだけ。
勿論、インラインアセンブラを使いたいならC++しか解がない。
で、ナマポ禁止派はいったい何がしたいんだ？ってのが疑問で、
それだったら俺と同じでC#＋CのDLLで良いじゃん、と思うわけ。

54 ：
C#やってるとテンプレート欲しくなるじゃん

55 ：
ナマポが本当に必要な所では存分に使えばいいと思うよ
ただし普通は99.9%くらいはそうじゃないからスマポを使え

56 ：
99.9%がスマポなら、最初からスマポがデフォの言語を使った方が捗るでしょ。
Rustでもいいし、C#やJava等のGC言語でもいいし、PythonやRubyのようなスクリプト言語でもいい。
残り0.1%をマーシャルなりしてCのDLLで。

57 ：
話をぶった切ってすんません。

複数のスレッドで

thread_local int* p;

p=new int [1000];

で確保したヒープ領域はやっぱりスレッドセーフ、じゃない、データ競合が
おきるんですか？

58 ：
>>53
まー、生ポインタは一箇所たりとも許さんってほどの原理主義は過激だとは思うよ。
俺も生ポインタを使わないことはないし、 goto を使うことだってあるし。

ただ、「低レイヤから高レイヤまでをひとつの言語の中で扱える」というのは
「高レイヤな機能で低レイヤを隠蔽可能だ」ということであって、
低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
直接的な部分ではインラインアセンブラを使うことが有っても、
その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。

C++ なんてそもそもがクソなんだから、
解決のために追加された機能は積極的に使わないとやっとれんわ。
(でも好き。)

59 ：
>>57
起きないです。

60 ：
>>57
thread_local で宣言した変数は名前が同じだけでスレッドごとに違う存在だし、
それぞれのスレッドで new したならそれぞれのスレッドで配列が確保されてる。

別のスレッドの p (やそれが指す先の配列) にアクセスすれば競合が起こることは有りうるが、そうじゃないんだよね？

61 ：
>>59

ありがとうございます。これが本当ならホッとします。

でも、これって規格書に明確に記述されているのか、コンパイラがそういう仕様の
アセンブラコードを吐き出しているだけなのかわかりません。

データ競合がおきたら修羅場ですｗ

62 ：
>>60

ありがとうございます。

>別のスレッドの p (やそれが指す先の配列) にアクセスすれば競合が起こることは有りうるが、そうじゃないんだよね？

それはないです。

63 ：
>>61
明確です。
newで確保される領域はダイナミックストレージに属します。
これは他のスレッドと同時に読み書きを行えば競合します。

thread_localで確保されたint* pはスレッドストレージに属します。
これは複数のスレッドで別のページに属します。
従って、pに対して読み書きしている分には競合しません。

64 ：
>>58
> 低レイヤを低レイヤのままで扱うスタイルを是とするものではない。
そう。で、俺は、低位はDLLで切り出しても大して問題なく、
高位だけなら他言語を使った方が効率的、という見方。

> その上のレイヤに持ち上げるときには必ずスマートポインタを使えってくらいの主張なら真っ当だと思う。
ちなみにそもそも俺はスマポ自体に懐疑的で、

・スマポじゃないとやってられないのはシャローコピーを永続化させるときくらいで、
　C++でこの使い方をすることはほぼない。
　（部分的シャローコピーでオブジェクト毎の生存期間に差が出て、
　さらにそれがデータ依存しており、プログラム側で確定させるのが面倒なとき。
　(半分満たす)例：このスレのレス配列があったとして、
　特定のIDのみ、ポップアップ用にシャローコピーで抜き出す場合。
　ただしこの場合はポップアップ後も次のポップアップ用に全体配列を保持する為、
　シャローコピーの永続化はせず、寿命管理は全体配列単位となり、スマポじゃなくても苦労しない。
　というより、正直、該当ケースを思いつけない）

なんだな。
要は、オブジェクトの生存期間をコード上で静的に確定させられないときにはスマポは強力だが、
俺には該当ケースがないんだな。
というか、お前ら何に使ってるんだ？
面倒なだけなら、GC言語の方が楽だしいいと思うんだが。

65 ：
で結局ユニポでいいんだよな？

66 ：
俺には分からない日本語をみんなが喋ってる

67 ：
そんな柔な理解力ではこのC++の壁に傷一つ残すことはできんわ！

68 ：
>>64
スマポ＝シャローコピーって意味わからん
unique_ptrを使わずにナマポでpimplとか今となっては考えられんのだが

69 ：
>>50
DoxygenがC++17の新構文に対応してないだけでしょ
まだ仕様が確定してないから対応してないよってどっかに書いてあったような気がする

70 ：
>>64
所有権を移転*しない*ということを表現できるのもスマートポインタの使い方のひとつだよ。

71 ：
>>68
はぁ？？？
pimplてあんなもん生存期間がシンプルすぎて
スマートポインタなんか要らない例だろキチガイかお前

72 ：
ナマポでもpimplはできるが
毎度毎度わかりきったコードを書く
無駄な手間がちょっとイヤ

73 ：
pimplに限らないが、メンバーにunique_ptrを使ったときの空のデストラクタが悲しい。

74 ：
JSはES6でｽｹﾞｰ良くなった希ガス
もはやC++やPerlみたいな工業用言語として十分Rる

75 ：
>>74
つ http://jsgirl.jp

76 ：
URLから連想出来る署名は
IQ110のJS先輩と学ぶ関数型プログラミング14日間

77 ：
工業用言語でperl w

78 ：
何を以て「工業用」と言っているんだろう

79 ：
>>71
生存期間がシンプルすぎるからunique_ptrが入らないっていうのは賛同できないわー。
将来デストラクタが複雑になって誰かがdeleteする経路をすっ飛ばしてreturnしてしまうかもしれんし、使えるところは使っておけばいいじゃない。
何を気にしてunique_ptrさけてるの？

80 ：
>>70
それで何が嬉しいんだ？

ついでに質問しておこう。
君はCのような自前でリソース管理をしなければならない言語でリソース管理をしたことがあるか？


あと、これはC++er全般に対してだが、
shared_ptrが絶対に必要なケースってのは何だ？
unique_ptrで後述A,B以外の使い方Dがあるか？(なおCは予約語)

81 ：
Cでのリソース管理戦略は非常に単純で、おそらく以下の２つしかない。

A. 作成者が責任を持って破棄する。
B. 投げ捨て。基本的に所有権を渡し、末端（付近）で破棄する。

Aが基本パターンになる。
Bは例えば描画用の一時データ等の場合で、
この場合、使用するのは「描画ルーチン『だけ』」であり、それ以降は不要だと自明だから、
・「描画ルーチン」までの途中経路での使用は原則禁止
　（厳密には、「描画ルーチン」呼び出し以降の使用は禁止で、
　呼び出し以前は改変等を加えてもいい＝この例なら、描画スケールの改変等）
・「描画ルーチン」内で必ず破棄
となる。
ただしあまり気にしないのならBも使わず、Aだけで組んでも問題ない。(というか多分そっちが主流か？)
描画の例であれば、描画終了後は普通はかなり速やかに親関数まで帰ってくるので、
親関数側でfreeするA方式でも大差ないからだ。

対して、OOP的に実装した場合、例えばゲームの敵キャラの生成/消滅を管理するとして、
この場合は「描画ルーチン」のように
「静的に明示的に生成/消滅の両方を内包する親関数」が規定出来ないので、
A方式は事実上使えず、Bで対応するしかない。だから上記を書き直せば、以下となる。

A. 「作成/使用の両方を静的に管理下に持つ親関数」を規定出来る場合、（＝構造化プログラミング）
　その親関数内で確保し、親関数のスコープ終了と共に破棄する。
B. 上記親関数を規定出来ず、「作成」「使用」場所が明示的な場合、（＝OOP）
　「作成」後は基本的に所有権を譲渡し、「使用」後に破棄する。

82 ：
既に言ったように、Cの戦略は多分この２つだ。というか、正確に言うと、これ以外での管理は無理だ。
そしてこれはC++では以下のようになる。

A. 自動変数上のunique_ptrに確保、関数呼び出しでは所有権の移転はしない
　＝生成場所のスコープ終了と共に破棄、それ以外の破棄はない
B. unique_ptrに確保し、自関数を抜ける前に『必ず』誰かに所有権を移転する
　自関数が対象関数（上記例なら描画関数）であれば、移転相手がいないので破棄する

だからはっきり言えば、Cのナマポは事実上C++のunique_ptrの使い方しか出来ないし、してない。
C++erがスマポ(ｷﾘｯなのは、上記C流のリソース管理を知らない＝無知だからでしかない。
繰り返すが、Cは最初からunique_ptrしかないのと等しい。
ここがC->C++の連中と、C++しか知らない馬鹿との違いだ。

これに対して、shared_ptrは上記制限を解除するものだ。
だからshared_ptrを使えば新しいプログラミングパラダイムを発見出来る可能性はある。
これは何だ？
俺にはこれがイマイチ思いつかない。

いわゆる構造化プログラミングで、関数を入れ子で呼んでいく場合、必ずAは適用可能だ。
これがCが今までのさばっている理由でもある。
OOP的に組む場合はBが基本戦略となり、必ず誰かが明示的に「生成」し、
同様に、必ず誰かが明示的に「破棄」するので、これまた問題ない。

だから今のところCで間に合っているのも事実だ。
リソース管理が「面倒だ」というのは分かるとしても、
「難しい」というのは根本的に組み方を間違っているからだ。
GC言語しか知らない馬鹿共が知らないのは当たり前だとしても。

shared_ptr等が必要なプログラミングパラダイムが発見され、
それに対応する方法がなければ、お前らの望み通り、Cも死ぬしかない。何かないのか？
或いは上記A,B以外のunique_ptrの使い方Dがあるか？(なおCは予約語)

83 ：
例外安全性の確保でウッカリさんするくらいなら使った方が良い。

84 ：
>>79
誰かがdeleteする経路をすっ飛ばしてreturnってどゆこと？
スタック巻戻しを破綻させるものってstd::exitくらいじゃね

85 ：
>>80
>それで何が嬉しいんだ？
お前さんが大好きなC言語の関数にポインタを渡す場合

86 ：
>>68,79
そもそもpimpl自体が要らんだろ。
あれはC++のコンパイラが単純に仕様変更

・ヘッダにはprivate関数は書く必要がありません

すればいいだけの話で、そもそも「名前空間は開いていますが、クラスは閉じています(ｷﾘｯ」を、
「ヘッダのクラスは開いていますが、実装のクラスは閉じています(ｷﾘｯ」にすればいいだけ。

編集上の都合でソースが汚れるとか、全く馬鹿な話だろ。
気づけよ。

87 ：
>>84
コンストラクタ内で例外発生とか
？

88 ：
http://somn9.xyz/4

89 ：
pimplに近いテクニックとしてC言語の頃から絶縁テクニックというものがあるが
それをやると大概静的解析ツールが横暴な量の警告メッセージを吐いてきやがるので却下
pimplも多分同じ結果に…

90 ：
Javascriptを使って感じるC++の有利な点は仕様の明確さだろう。
Javaは重いと言われユーザーに嫌われる言語のひとつだが、開発者はベンチマークを提示しC++の20倍速いと言う。
しかしユーザーは実際に重くて困っているだろう。
ブラウザも同じ問題を抱えていて、当然Javascriptも重いとユーザーは感じている。

91 ：
Microsoft社はソフトウェアの使用状況を監視させてほしいとユーザーにお願いする。
IMEの誤変換データや、プログラムのクラッシュ時の情報などだ。
これらは、開発者とユーザーの間の意識の乖離を埋める可能性がある。
ユーザーの重いと開発者の軽いのような。
オープンソースに対するアドバンテージがここにあるのかもしれない。

92 ：
>>90
慣れたらJQueryなど使わずとも複数プラットフォーム対応Rる！

93 ：
>>91
Microsoftはつい先日GitHubを買収したから
ソースコード自体を監視に乗り出すようや

94 ：
Visual StudioはCMakeに対応したし、Microsoft社はオープンソースとの付き合い方をやっと学んだようだ。

95 ：
>>84
たいしたこといってないです。
~dtor() {
. if (...) {
. return;
. }
. delete ptr;
}

>>86
pmplがバッドノウハウに属するものであることは同意だけどprivateメンバ変数はどうするつもり？

96 ：
pimplを多用するライブラリの一つにQtがある。
C++はテンプレートによって拡張性を担保できる言語だ。
一方、拡張性はライブラリのユーザーにとってわかりやすさを損なう。
IDEとの結合において、pimplによる公開は一つのテクニックかもしれない。

97 ：
ところでpimplってぽいんぷるって読むんだよな？

98 ：
ピーいんぷるって呼んでた

99 ：
RAIIは？

100 ：
>>82
cで参照カウント使ってる例なんていくらでもあると思うけど。例えばキャッシュとか。
参照カウントを自前で書けばいいからshared_ptrはいらないって言ってるわけではないよね？

101 ：
キャッシュは不意のアクセスに備える目的のやつだから
今誰もアクセスすなくなったからといって即開放（例： キャッシュラインをinvalidate）したら意味半減くね…？
というわけで、参照カウントの使用例としては不適切くね…？？

それはそうとして、
資源の開放タイミングをスマポに頼るのは負けというC言語スキー氏には概ね同意だが
プログラマーが後始末タイミングをどうしても決められないｼﾁｭは存在するからスマポは要る
GCのように、開放タイミングを決めるのが未来のプログラマーなケースがそれ

102 ：
>>95
いい突っ込みだ。
今の実装だと、最低限プライベートの全サイズは要るのか。
Javaとかどうしてんだろうな？

現実的な解としては、
privateフィールドについてはコンパイラが自動的にpimpl的に間接参照に切り替えだな。
どうせpimplにする気だったのなら速度的にも大差ない。

いずれにしても、今の時代、コンパイラに合わせてコードを書くのは間違いで、
人間に合わせてコンパイラが努力するのが正しい。

103 ：
>>80
ワイはオッサンやで。 C++98 が出来る前から C も C++ も使ってるというか、
マイコンで BASIC とアセンブラが主流だった時代の人だで。

そのときは何にも疑問に思わなかったけど、
今どきのモダンな仕組みを知ってしまったら、
昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
(かといって使い慣れたパラダイムから離れるのも面倒くさい。 オッサンなので。)

>>81-82
そこで unique_ptr を使うことに疑問を持つことが意味わからんのだが。
まさにそういう風に使うためのもんだし、
その例で unique_ptr への懐疑を説明されてももう俺には何にも言えねぇ。

104 ：
>>101
参照されている間も消していいキャッシュなら参照カウント不要だけれども、そっちのほうが稀じゃね？

105 ：
>>100
> 参照カウントを自前で書けばいいからshared_ptrはいらないって言ってるわけではないよね？
そういうわけではない。
ただ、参照カウントを自前で書いても大して苦労しないのも事実だが。


> 例えばキャッシュとか。
これはいい例に見えるが、実はちょっと違う。

まず、これは「生存期間にデータ依存性がある為、上位関数からではde.lete出来ない」例ではある。
ただ、実際にキャッシュを実装すると、

1. non_sharedのキャッシュの場合、要するにLRU判定で捨てるときにそのままdeleteすれば良いだけ。
2. shared_cacheの場合、例えばCPUのキャッシュのエミュレーションを行う場合、
　書き込みで他CPUのキャッシュを無効化するとか、その手の上位側の制御が必ず必要で、
shared_ptrだけでサクッと実装、ってことにはならない。

だから、Cで実装してもC++のスマポで実装しても、実は手間があまり変わらない。
それではおいしくないんだよ。
勿論、「書き込み無し」とかだと、破棄の制御をしなくていい分C++の方が楽に実装出来るが。
つまるところ、shared_ptrは、
手抜きデタラメ実装する場合は凄く便利だが、ガチで実装する場合にはあまり恩恵がないんだ。
とりあえず、キャッシュの場合はそう。

ってのが>>101の意見でもあると思うが。

106 ：
>>104
キャッシュは、存在すればアクセスのレイテンシーが短縮されるというラッキーをクライアントに提供するだけのしくみ
よって、キャッシュ上のデータというのは基本いつ消してもシステムにとって致命傷にはならず、
かつ可能な限りキャッシュ上に残存するように普通は設計する
参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無い

一方、仮に>>104で言いたいのがアクセスしている最中に消したらアカン、という話なのであれば、
それは排他制御の話題であってそれも参照カウントとは関係無く言える話やし…

107 ：
>>101
スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。

例えば、mallocも同様だが、
当然ナマポが返ってきて、それを解放するのは未来のプログラマー責任になっている。
要するに「そういう使い方」を規定すれば済むだけなんだよ。

108 ：
unique_ptrが必要ないというのは、C++を使ったことがないってことだから、C++を使ってる人に対して、unique_ptrを使うべきでないと意見しても意味がない。
必要だから使ってるんだし。

109 ：
>>103
俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。

反対する意味もないが、積極的に使う意味もない。
元々そうとしか組めないし、既にコードはそうなってるから。
だからunique_ptrに書き換えろってのは、相当にウザイ。
他言語だとforeachをforに書き換えろとか、あれと同じじゃないかな。

たぶんLinusもこれなんだよ。
C++の奴は新しい文法でやることに意義を感じているようだが、
それによってソースコードの構造が改善されるかというと、全くそうじゃない。
むしろ、おかしくなることの方が多いわけでね。pimplとかもそうでしょ。

> 昔の牧歌的なリソース管理なんて本当にしたくねぇという気持ちなんだよ。
これがよく分からん。
というか俺はリソース管理したくないから当然のごとくGC言語を使っているわけで、
そこまでしてC++に拘る理由が分からん。
スマポ使えというなら、うるせえGC言語使え、と返したい。

110 ：
Cより開発効率が高く、Javaよりユーザーにベネフィットを提供できる。
そういった観点から、広く使われるソフトウェアの開発にC++を採用するのは理にかなっている。
JavaにしろC#にしろ、GUIライブラリがころころ変わるのは、エンドユーザーが受け入れないからだろう。
そう、馬鹿なユーザーはJavaやC＃の利点を気にかけないのだ、自分のことしか考えない利己主義め！
なぜ重いソフトウェアを使うべきなのか、ユーザーをキチンと教育する必要がある。
あるいはC++を選ぶ。

111 ：
>>107
>スマポは未来のプログラマーが解放することを「文法的に」示す意味しかない。
スマポでできて、free()ではできないことがあるからその言い分は違うくね？
いやまあ>>101でGCとしか言わなかったのは言葉足らずだったので今条件を追加するが、
こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケースでは
どうしてもスマポ的な手段に訴える（オブジェクト自身に開放タイミングを決めさせる）必要があるんじゃー！

例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
あるいは、やっぱGC自体が行う本来のガベージコレクション業務タイミングを決める方法とか、
（GCがシステムに1個しか無いのに対して、ユーザーは潜在的に多数でありGCの存在を関知せずに使ってくれる

一方、「必ずfree()せよ」という仕様には、malloc()したヒープ1個の開放以上の意味を持たせられない

112 ：
std::unique_ptrを使用したくない局面では、テンプレート仮引数Allocatorを用意するべきである。
つまり、ほとんどの場合、std::unique_ptrが有用である。

113 ：
>>111
> 例えば画像データみたいに巨大故に必要無い限りコピーしたくないんだけどそんな事情をライブラリ利用者から隠蔽したいケース
なるほど理解した。
ここでshared_ptrを渡して多数に見せかけ、実は中身は一つ、という話か。

となると、当然インミュータブルでないと話にならないわけだが、
逆に言えば、今時のインミュータブルな世界にはshared_ptrが大活躍する余地があるのか？
すぐにはピンと来ないが。

114 ：
>>113
△： 当然インミュータブルでないと話にならないわけだが、
○： 当然インミュータブルなインターフェースでないと話にならないわけだが、

実装は別にミュータブルでもクラスで覆うならやりようはいくらでもあるんじゃ…
画像の書き換えを専用メソッドでやるか、あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
（もちろんcheckout時にコピーを行う

で、内部ではshared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」）ロジックが大活躍！！１１１！！！！１！

115 ：
>>111
いや待てよ、コピーオンライトなスマポがあればミュータブルな世界にも適用可能だが、
今の所、これはないよな？

いずれにしても適用事例はすぐには思いつかないが。

116 ：
訂正；
×： あるいは速度優先でcheckout/checkin式にcheckout中だけ直接アクセスを許すとか、
○： あるいは書き換え速度優先でcheckout/checkin式にcheckout中だけ画像への直接アクセスによる書き換えを許すとか、

117 ：
C++を解った気になった奴らがアンチパターンを量産する

118 ：
>>114,116
まあ分かった。
多分shared_ptrは『ほぼ』インミュータブルな世界とは相性がいい。
(ミュータブルにする必要がほぼなく、その場合は明示的に別メソッドを呼んでもいい場合）

つっても適用事例はWebサーバーくらいしか思いつかない。
ある画像が人気でユーザーが一斉にダウンロードしたとして、
鯖内部に30秒間だけキャッシュする場合とか。

ナマポで渡した場合、各ユーザーのダウンロード完了でカウントを減らし、０になるまで破棄出来ない。
shared_ptrで渡した場合、30秒の期限が過ぎればキャッシュから破棄しても問題ない。
この辺は確かに楽に組めるようになる。

119 ：
>>118
キャッシュにstd::shared_ptrを使用するのは愚策すぎるのではないか。
実のところstd::shared_ptrはほとんど出番がない。
設計を練れば練るほど出番は失われていく。

120 ：
いやすまんインミュータブルなインターフェースといいつつ>>114では画像を書き換えるインターフェースの話をしてしまったｽﾏﾝorz
「画像の書き換えを専用メソッドでやる」は、「加工後の画像を専用メソッドで生成する」、と読み替えてﾎｽｲ

で、ライブラリが画像Aを生成し、その画像がライブラリのユーザーによって不特定多数のクライアントとのセッションスレッドに渡されるｼﾁｭを考える
セッションスレッドの具体的な数は事前にはわからない。（接続してくるクライアント次第
また、何らかのタイミングでクライアントに提示すべき画像Aは、別の画像A'に差し変わる。

ライブラリのユーザーとしてはスレッド間の排他制御に関して面倒な問題を抱え込むのは嫌なので、
メインスレッド（セッションスレッドを起こす）から、画像Aのコピーを、所有権を譲渡する形でセッションスレッドに渡す、という使い方をする。・・・(1)

ライブラリ内部では、(1)の使い方をされるときにいちいち画像Aをコピーしたりしない。

画像Aの開放は、画像AがA'に差し変わるタイミングで行いたい。
ただし、画像Aを使っているセッションスレッドが居る間は開放するわけにはいかない。
しかし、当該スレッドがセッションを終えるのを待っていたら、新規につないで来るクライアントへの画像A'の提示が遅れる

→画像Aの開放タイミングはスマポで解決！

121 ：
>>118
ちょっまだキャッシュ言いますかキャッシュと参照カウントは原理上無関係なので（>>106）忘れてよろしいかと、
（参照カウンタが0より大きいからキャッシュ上のデータを消してはいけないという法は無いし、
　参照カウンタが0になったからといってキャッシュ上のデータを消さなければいけないという法も無い

Webサーバというのは適用事例として好適だがダウンロード中かダウンロード完了か、という区分でしか考えないのはｲｸﾅｲ
ダウンロード中にも新規のクライアントがつないでくるかもしれない
そのときダウンロード完了時に画像を破棄すればいいやという単色の思考だと、新規のクライアントが繋いで来つづける限り
画像を永久に開放できないことになり、そればかりか>>120のように、画像をAからA'に差し替えることもできない

これは画像Aの開放を、画像Aのオブジェクト自身に面倒をみさせるしかない（自身を参照するセッションスレッドが0になったとき開放させる
サーバはそれとは並行して画像A'を新規のセッションスレッドに展開できる。
こんな芸当ができるのはスマポだけ！

122 ：
>>121
言いたいことは分かるが、
> 画像をAからA'に差し替えることもできない
これはない。
この場合はどのみちキャッシュを別実装するしかなく、

・キャッシュ内に画像Aへの参照が残っているか
・画像Aを掴んでいるセッションが存在しているか

が別問題になり、
画像の差し替えはキャッシュ内の画像Aを無効化することにより行われる。
だから、普通に差し替えは出来る。このとき、
それ以前のセッションは画像Aのまま、それ以降の新規セッションは画像A'になる。
ただまあ、これは本筋ではないし、内容見る限りそちらも分かっているようだからもういい。


多分、shared_ptrの使いどころは、

1. インミュータブルなインタフェースで、
2. 不特定多数がランダムに掴みに来て、
3. 解放タイミングがユーザー依存で読めない場合

なのだろう。アプリはWeb鯖はそうだが、それ以外に何があるかだな。
1,3はさておき、2がね。
少数しか来ないのならunique_ptrでいいし、
演算等CPUジョブなら結局は順に処理するだけなのでこちらもunique_ptrでいい。
I/O等の他要因で引っかかってスレッドが参照を掴んだまま待機させられることが必要になる。
ファイルサーバーも近いが、こちらの場合はロック機構が必要な為、
「どのファイルが今何人にどういった権限で捕まれているか」の管理が必要であり、該当しない。
（shared_ptrを使っても大して楽にはならない）

123 ：
一応簡単に俺の主張を纏めておくと、

・unique_ptrは従来C方式を文法的に強制させるだけで、コードの改善には繋がらない。
・shared_ptrの使いどころはWebサーバーしか思いつかない。

GC言語は基本的にshared_ptrなわけだが、あれって基本的に手抜き専用で、
GCがないと本質的に辛いって構造はあんまりない。
Rustも今更GC無しですかー、とも思うが、実際、無しなら無しでもいいか、程度ではある。

124 ：
>>123
その GC が大問題
現状 GC の最終手段は mark and sweep なので、これが嫌だ、という価値観はありだとおもう

125 ：
>>109
> 俺はunique_ptrは「C的リソース管理を文法的に示す」意味しかないと見てる。

その意味がすごく重要やん？
漠然としてたものに区別を与えてくれる最高の機能じゃんね。

126 ：
std::enable_ifを使いこなそう。

127 ：
>>95
期待して損した
そんな自殺コードを書かれるのを防ぐのは
スマポじゃなく人事部の仕事だ

128 ：
「バカよけ」機能に価値はない、無駄だから使わないしコードが長くなるから使わせない
っていう老害いるよね
そういう奴に限ってバグや脆弱性作り込むんだけど決して反省しない

129 ：
std::unique_ptrを導入すると人事部から一人削減できるってことじゃないか。

130 ：
まともな知的生命体なら迷わずユニポを使うだろう。

131 ：
>>128
まあ俺も老害とか言われることのある世代だが
価値がないのは「バカよけ」ではなく「バカ用」な
バカなふりをする達人をニヤリとさせるのではなく、
どうしようもない真性バカを延命する機能は有害なだけ

132 ：
>>127
期待するも何も、スタック巻き戻したらどうしてヒープ開放されると思ったのさ？

133 ：
>>132
デストラクタが実行されるからさ
スタック巻戻しとは何たるかわかってる？

134 ：
混乱を避ける為に先に質問しておきたいんだが、
上記A(82)の場合、つまり、
親関数から子関数にポインタを渡したいが、所有権を移動しない場合には、どう書くんだ？
ざっと探しても出てこないんだが。

引数に値渡ししたらムーブ、これは分かる。
ムーブしたくないが子関数に渡したい場合は？

135 ：
すまん、>>134はunique_ptrの場合。もう一度書き直すと、

親関数から子関数にunique_ptrを渡したいが、所有権を移動しない場合には、どう書くんだ？

136 ：
>>124
それはありだ。

ただし、俺は「循環参照の場合に回収出来ないGC」であってもいいと思っている。
循環参照が必要なケースはほぼ無いので、明示的に切ってから解放でいい。
これはweak_ptrと同じで、C++erなら同意してもらえると思う。

ついでにいうと、「コンパクションが出来ないGC」でもいい。
これなら**ptrにする必要なく、*ptrで行けるから速度低下も起きない。

つまり、仕様はC++どおりでいいが、
プログラマにやらせるな、自動でやれ、ということ。俺的には。

137 ：
>>135
なんだよ！所有権の複製もできないのかよ！？
やっぱりstd::unique_ptrダメじゃん！！！！

138 ：
>>137
まあそのネタはさておき、マジで探しているのだが出てこない。
知ってたら教えてくれよ。

これ、もしかしてget()してナマポ渡すしかないとかいうオチ？
ならunique_ptrなんてマジでゴミだぞ。
さすがにそれはないと信じて探しているのだが、マジで出てこない。

139 ：
>>138
参照で渡せばいいんじゃないのか？
そんなことして何の意味があるのか知らんが。

140 ：
std::unique_ptrに対するweak_ptrは無いぞ。
だからゴミだという場合は、>>137。

141 ：
>>139
俺も最初はそうかと思っていたんだが、実はそれも出てこないんだよね。

まあでもそれで、コンパイラが最適化をするのを期待する、というC++的オチか？
これはあり得るとは思うが。

142 ：
>>141
当たり前すぎて出てこないだけでは？
auto result = my_func(*my_unique_);
とすればいいだけなんじゃないの？

143 ：
std::unique_ptrを利用する主な動機は総称型を保持するためなんだよな。

144 ：
>>140
そういう意味ではないが、
> std::unique_ptrに対するweak_ptrは無いぞ。
この表現は分かりやすい。

>>142
それは実体を値渡ししてしまうだろ。

145 ：
>>144
lvalue_referenceだから仮引数側でどうにでもできるだろ。

146 ：
https://ideone.com/SEcQKq

こういうことがしたいんじゃないのか？

147 ：
参照だけするスマポ（と言いつつ何もしないアホの子スマポ）は次の規格で検討されてたでしょ
observer_ptrだかexempt_ptrだか名前コロコロ変わってるけど

148 ：
>>146
だから違うっての

>>147
多分俺が欲しいのはそれだ。
https://en.cppreference.com/w/cpp/experimental/observer_ptr
要するに、「ナマポだがdelete出来ない物」が欲しい。
unique_ptrは値渡しすると所有権が移動してしまう。
関数にはポインタの場合値渡しが最速だし、自明だから、グダグダ書いて最適化を待つ、とかやりたくない。
生成は常にunique_ptrからの値コピー（所有権は移動しない）でいい。

寿命管理は他に任せるが、ナマポと完全に同パフォーマンスの物、これが欲しい。

まあ、検討中ならよかった。

149 ：
deleteされたくないポインタと言えばこうだろ。
https://ideone.com/PvzDVY

150 ：
>>125
> 漠然としてたものに区別を与えてくれる最高の機能じゃんね。
俺の理解が正しければ、これはダウト。表現力が足りない。
今のunique_ptrはB用のインタフェースしか持っておらず、Aを最速では記述出来ない。
足りてないのは、既に言ったとおり、「ナマポと同速だがdelete出来ないスマポ」。

だからやっぱイマイチなんだな。
とはいえ確実に拡充されてるから、最終的にどうなるかは見物だが。
高位機能も最終的には追いつくだろうし。

ただ、C++はプログラマの努力で何とかしようとしているが、
そもそもＡにしてもBにしてもコールグラフの解析でfree忘れとか抜けるはずなんだよね。
Cの連中はこの辺には興味ないみたいだけど、
人手でやってる分、スマポみたいにコーナーぎりぎりを攻められないから、
ある程度わかりやすいところでfreeされてる。
当然、ツールにもかかり易いはずで。

151 ：
それ参照でいいだろ。
言ってる意味が全く分からない。

152 ：
私もはやく皆さんとお話したいのですが、内容が全くわかりません。
C++でRPG作れる程度の知識なのですが、何から学べば良いでしょうか。
おすすめの本、サイトがあれば教えてくださいが

153 ：
>>152
それならば
effective C++ / effective modern C++ がいいかと思います

154 ：
そりゃC++使ってる人が読んだって全く分からないだろうな。

155 ：
>>122
>1. インミュータブルなインタフェースで、
>2. 不特定多数がランダムに掴みに来て、
>3. 解放タイミングがユーザー依存で読めない場合
ちゃうねんそれでは表層的な観察にすぎなず、
shared_ptr（的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の必要性の1断面でしかないねん

>>121-122が言っているのは、
>こちらが実装上の都合で用意するオブジェクトの数と、未来のプログラマーに対して見せかけるオブジェクトの数が相違するケース(>>111)
において、未来のプログラマー（ユーザー）がオブジェクトをコピーしたつもりだが実装の内部ではコピーしていなくって、
ユーザー視点では自身のプログラムが保持する独立した1オブジェクトを開放したつもりが、実は内部の実装の都合において、
ユーザーまたはユーザー2のプログラムが保持する別のオブジェクトの開放と関係を持ってしまうケース（∵実体が同一）において
shared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理が必要ということなんじゃー

156 ：
.>>122
>画像の差し替えはキャッシュ内の画像Aを無効化することにより行われる。
これは>>121のケースでは問題の解決にならない。
なぜなら、仮にキャッシュ上に画像Aを用意してあり、最後まで画像Aを掴むことになったセッションXに対して
セッション開始時にメインスレッドが渡したのがキャッシュ上の画像Aだったとしても、
渡した瞬間にセッションとキャッシュの関係は切れるからじゃわ！（半切れ

>>121は、セッションXは自身のローカル記憶（のつもり）であるところのオンメモリの画像Aを使い、
セッション終了時に開放する、ということしか言っておらず、
セッション中に2回3回とキャッシュ上の画像Aを取りにいくとは書いては
いない
キャッシュとセッションXの関係がセッション開始時の一瞬でしかない想定な以上、
画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄。問題に影響無し。

157 ：
ちな「キャッシュの無効化機構」とは、新規セッションに見せかける画像をAで無くすしくみという意味であって（それ以外の読み方をせよというのは㍉）、
画像Aの実体の開放とは関係ありませんからぬ、
というわけで繰り返しになるが画像Aの実体の開放に関してキャッシュの無効化機構をどう別実装しても無駄で、
画像Aの実体の開放はshared_ptr的な、「オブジェクト自身に開放タイミングを決めさせる」(>>114)）処理の専任事項となる
（>>121の想定のように画像Aが複数に見えることもあるが実体は唯一、というときはそうする以外画像のAからA'への差し替えは㍉

158 ：
>>155-157
まず、俺の意図が正確に君に伝わっていることは分かった。
が、Webサーバーなんてそんなもんだろ。(…α)

画像『ファイル』Aを鯖からダウンロードしている最中に、鯖上で画像『ファイル』がA'に変更されたとしても、
ユーザーは画像Aをダウンロードし続ける。
それどころか、鯖は更新された画像A'に即座に対応することすら期待されていない。
2-3分の遅延なら許容されている。
この仕様においては鯖上のオンメモリキャッシュとファイルの同期は厳密にとる必要はなく、
俺の示した実装の通りであり、それは君にも正しく伝わっている。
この場合はshared_ptrでの実装の方が楽だ。(ただし厳密には問題があるが）

一方、ファイルサーバーはそうではない。(…β)
Webサーバほどの多人数が同じファイルを同時に掴みに来ることはほぼ無いが、
「どのファイルが今誰にどういった権限で捕まれているか」を完全把握しなければならず、
ファイルの更新、ファイルロックのリリースも即座に対応することが期待されている。
許容されるのは精々数秒でしかない。
この場合は上位の制御が必ず必要になり、shared_ptrが有ったところで大して恩恵はない。

違いは単純で、「厳密な同期が必要とされているか」だ。
だからもし、君がMMORPGのような多セッションでの
鯖上『オンメモリ』画像AからA'への切り替えを想定していたとしても、(…γ)
それはshared_ptrでの実装では楽にはならない。
画像A->A'への切り替えを同期させるなら、「誰が画像Aを掴んだままか」を鯖側が把握せねばならず、
上位の制御が必ず必要になる。shared_ptrを配って終わり、にはならない。

これは結局、Web鯖上の『ファイル』に対するキャッシュ条件がユルユルだから発生した特殊事例であり、
俺が言ったとおり、
> 手抜きデタラメ実装する場合は凄く便利だが、ガチで実装する場合にはあまり恩恵がない (105)
でしかない。
勿論それが許容されている世界であり、スループットを取っているだけだからそれでいいんだが。

159 ：
が、とにかく君は、
> オブジェクト自身に開放タイミングを決めさせる
事が必要だと思っているらしい。これの他具体例はあるか？

君が挙げてきた別例はGCだが、現実問題として、ほぼunique_ptrで事足りるのも事実だろ。
shared_ptrは機能的にはunique_ptrの上位互換だから、GCではそれが用いられているだけであって。
「ナマポ禁止、スマポ使え」なC++宣教師は、
次は「漢ならunique_ptr。shared_ptrは甘え」と言うと思うぜ。

それともあれか？smalltalk的OOP或いはアクターモデル的に
> オブジェクト自身に開放タイミングを決めさせる
ってのか？だったらもうそれは流行らない、というか、
今のところ無駄が多すぎて普通に組んだ方がマシ、ってことになってる。

160 ：
ワイ、低みの見物

161 ：
ワイ、今表示されてる倉田まおの母音を見物中

162 ：
長い独り言だ
いつ終わるんだ

163 ：
オブジェクト開放ってどんな機能なんだろう:-P

164 ：
「delete忘れないようにunique_ptr使いましょーね」「共有が必要ならshared_ptrがべんりだよー」
っていうだけの話の何がそんなに気に食わないのかさっぱりわからなくてついていけない

165 ：
相手するなよ...

166 ：
>>164
Q. 俺には必要性が分からない
A. 必要がないなら無理に使わなくていいよ
で済むお話。

167 ：
>>164
俺は何言ってるか分かったけど、この人に説明するのは無理だろな。
使ったことがないものを批判したい感じだし、std:unique_ptrは必要になってから使えば良いよと言ってあげれば良いのかも。

168 ：
まずムーブを活用して、総称性が必要になってから初めてunique_ptrを検討する感じがいいんじゃないのかな。
そしてshared_ptrは設計に時間をかけられないときに使うもので、ほとんど出番がないはず。

169 ：
20世紀最大の発明はレーザーと言われてるけど、21世紀最大の発明はムーブと言われてるからね。
俺に。

170 ：
なるべく (ポインタでなく) 値でやりとりすること、それを低コストで出来るようにムーブ対応にしておくというのは
上位レイヤを作るときに楽できる良い設計だとは思うけど、
実質的にはスマートポインタの機能をクラスに付け加えてるみたいなもんで、
それがクソ面倒くせえときに標準のスマートポインタを使うみたいな方針でやってた。

総称性を活用するときという観点は無かったけど、確かに必要な考え方だな。

171 ：
unique_ptrで内蔵しておけばnoexceptにしやすいので、ムーブが使われやすくなるというのはありますね。
とまあ、C++を使っていれば自然に有効利用するものですが、使う前に理解するのは難しいのではないでしょうか。
使ってみればなるほどとなると思うんですよね。

172 ：
机上の空論繰り返すより、使ってみればすぐわかるよ。
これがおじさんからのアドバイス。

173 ：
総称性ってなんだ？

174 ：
C++の基本概念ですかね。

175 ：
>>174
説明してくれる？

176 ：
https://ja.wikipedia.org/wiki/%E7%B7%8F%E7%A7%B0%E5%9E%8B
総称型（generic type）、あるいはパラメタ付型（parametric type）とは、
型付けされたプログラミング言語においてデータ型の定義と
それを参照する式（型式）の一部にパラメタを許すことによって
類似した構造を持つ複数のデータ型を一括して定義して、
それらを選択利用する仕組みである。

総称型は、暗黙の型変換（implicit type conversion）あるいは型強制（type coercion）、
多重定義あるいはオーバーロード（overload）、継承（inheritance）あるいは包含（inclusion）と並んで
プログラミング言語においてポリモーフィズムを実現するための一つの手段であると看做せる。
総称型が使われている言語の例としてC++のテンプレート、JavaやC#のジェネリクスがある。

へー

177 ：
総称型の説明は要らんよ
欲しいのは総称性って言う謎の言葉の方

178 ：
謎なんだ。

179 ：
個々のクラスの実装を工夫して値渡しとムーブで解決できないかをまず考えて、
複数の型について類似のコードが出てくるようなら unique_ptr や shared_ptr (や自作スマートポインターテンプレートクラス) の利用を検討する、
というようなことでは。

180 ：
シンシュンシャンソンショー

181 ：
>>178
そりゃ誰も説明できないから謎でしかないわ w

182 ：
なんかそれっぽく言っとけば暗黙の内にマウント取れるから

183 ：
「オマエ知らないんだ～」「でも教えてやらなーい」ってのは
元手ゼロでもできる安上がりなマウンティング

184 ：
悔しそうだねｗ

185 ：
オマエ知らないんだ～
でも教えてやらなーい

186 ：
>>158
>この場合は上位の制御が必ず必要になり、std::shared_ptrが有ったところで大して恩恵はない。
この言い分はずんねんながら成立しない

「プログラム、呼び出されなければただのデータ」という諺（今漏れが作った）からわかるとおり、
画像Aや画像A'のいかに巧妙な中央集権的なリソース管理のロジックを組んだところで、
画像Aや画像A'の開放タイミングで呼び出されなければ機能しない

で、この呼び出しというのは、std::shared_ptr<画像>で極めて確実に（呼び忘れが無い形で）行うことが出来る
すわなち、画像Aのデストラクタで目的の中央集権コードを呼び出せば（注1）良い
よって、C言語スキー野郎（敬称略）がいうところの「std::shared_ptrの恩恵が少ない」例は、
そのまんま「std::shared_ptrを使えばより良い実装になる」例である

注1: ここでの呼び出しとは、実行権を渡すことを意味する。
直接CALL、メッセージの送付、レジスタにパラメータを積んでソフトウェア割り込み、
インスタンス固有の管理テーブルに情報をセットしてイベントで待ち解除、（同）タスク起床、etc.etc...
原液PGならやり方を100万通りぐらい即答できるはず

187 ：
通知メカニズムを持つ画像より、通知メカニズムを持つリソースハンドルのほうが便利に違いないので、あまり使いどころがなさそう。

188 ：
>>187
リソースハンドルは味噌も糞も一緒のHANDLE型で型安全の観点から不安があるが
画像クラスでwrapすれば型安全になる
行いが良ければ空も飛べるはず

189 ：
>>188
禿4はSTLコンテナの類もリソースハンドルと呼んでるけどな。
std::shared_ptrに通知メカニズムをプラスしたようなものが実際に必要になるのではないだろうか。
オジサンはATL風の通知メカニズムを備えたコンテナを作りましたぞ。

190 ：
リソースを共有するということは、通知もセットで必要になると思うんだよなあ。

191 ：
>>170
お前、ﾜｯﾁｮｲ 81b3-8neNが一度もまともなことを言ってないのを理解出来ないのはヤバいぞ。
そもそもお前、>>125ってことは、observer_ptrの使いどころも理解してないだろ。

192 ：
まだ標準にも入ってないもんなんか使ったこともないし知らんわ。

193 ：
唐突にphoenix_shared_ptrとか言ってみる　解る人おるやろか
Lokiに始まるメタテンプレートプログラミング狂騒時代も15年以上昔か…

194 ：
>>192
そう言うだろうとは思っていた。
そしてそれが今の君の、またC++erの限界なのだと思う。

君は>>103によると、世代的に、
C言語の前にアセンブラをやった連中は誰一人としてポインタで躓くことはなかった事実を知っているだろ。
これは単純に、ポインタの意味は既に知っており、
単に、インデックスレジスタの使い方をポインタと命名したんですね、で済んだからだ。
俺は同様の見方でC++を見てる。
C++のスマポはCのナマポを「分類/命名」しただけで、「追加」してないから。
だから記述能力が足りないことにも気づく。

unique_ptr(ｷﾘｯなんてやってるC++erは馬鹿丸出しだ。
君らはそれがCへの回帰な事にも気づけてない。
そしてここにきてobserver_ptrを追加するのは、完全に敗北だ。
あれはA方式用に他ならないから。

とはいえ、良いトライであったとは思うよ。そして失敗した。
ただ、それを修正して来れている点は素晴らしいが。
shared_ptrも結局使いどころがないだろ。

アセンブラの件からも分かるように、「理解していること」と「書いていること」は別なんだ。
正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
君はobserver_ptrを知らないし、教えてもらわないと必要性に気づけない。
そこまで落ちぶれているって事だよ。
少なくともアセンブラ→Cの時のように、概念は理解しているがその言語での名前を知らないだけ、ではない。
対して、Cの連中は既にobserver_ptrを使っている。(ただし書いてない）
ここら辺の違いが、linusが一貫してC++erに冷めている理由だろうよ。無知な馬鹿にしか見えないから。

195 ：
>194
> 正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
> ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。

ああ、馬鹿にはわかんないよ。
だから書いてくれっての。

人間は度し難いほど馬鹿なので、クソみたいな間違いをする。
意識していたとしても間違う。
知っていても何度でも間違う。

そんなの当たり前だろ？

196 ：
で、おめぇは一流のC++erと自称したいのかい。

ほんとに糞な爺だわ。早く棺桶の中で寝ろ。この河童虫が

197 ：
>>195
まあ俺は書くこと自体には反対ではないんだが、

1. 足りないんだから書きようがない(observerが)
2. そもそも書くほどバリエーションがない

Cで使われているのはunique/observerで、shared/weakはほぼあり得ない。
制御が煩雑すぎてバグる。
だからこそsharedが生きる構造があればC++が勝ちきる可能性があったが、
shared撲滅みたいな今の風潮じゃあねぇ。

そして既に書いたが、大概は方式Ａだから、
ローカルのナマポはuniqueで、それ以外は全部observerでしかない。
わざわざ分けて書くほどバリエーションがないんだよ。

Cの連中は書くのが嫌なわけではなく、書く意味を見いださないのだと思うよ。
書いたところでコード構造が改善されるわけでもなく、速度が上がるわけでもない。
書かずともどうせＡ方式だし。

198 ：
shared撲滅の風潮ってどこ界隈の話なの？

199 ：
sharedはリファレンスカウンタがからんでくるからね

200 ：
shared は循環参照には無力だからね…

201 ：
依存性にかならず上流下流関係があってノードで循環を監視できれば
sharedでいいよね

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

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

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

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

206 ：
宿題は自分で頑張れ

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

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

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

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

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

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

知らんけど

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

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

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

214 ：
循環参照は甘え。

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

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

217 ：
>>216
どの部分ですか？

218 ：
>>209
kwsk

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

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

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

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

222 ：
と思って今作ったがあんま使い勝手の良いものにはならんかった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が裏で手を握る必要がある

223 ：
sumapoが酢マンポに見えた

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

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

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

225 ：
>>224
JavaScripterマジでRよ

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の巣に帰れ。邪魔でしかないから。

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

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

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

228 ：
C++って難しいの？

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

230 ：
>>228
難しい人が多いよ

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

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

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

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

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

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

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

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

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

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

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

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

240 ：
何かのネタ？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本題は、

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

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

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

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

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

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

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

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

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

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

252 ：
std::getline使え。

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

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

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

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

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

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

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

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

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

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

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

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

263 ：
訂正。
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*にアクセス。

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

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

266 ：
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>)
{

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

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

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

268 ：
>>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も基本的にないだろ。
実はあんまり使いどころなくね？って話。

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

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

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

272 ：
ビジネスで優秀な人材育成する上司は何を教えているのか？
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

273 ：
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)

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

275 ：
>>268
ないよ。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

290 ：
io_contextで世界が変わる。

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

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

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

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

295 ：
内緒な、約束だぞ

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

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

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

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

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

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

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

302 ：
if ( 0.equals(v=f()) )

こう書ければいい

303 ：
Cでは代入式はその結果値が左辺値にはならないから v = 1 = 2 みたいな表現は通らない
C++では左辺値になるので通る

304 ：
昔定数を先に書くことで防げるって聞いたことがあるが
0=(v=f())

305 ：
昔からこういう==での判定は
if (S_OK == (result = someApi()) {...}
と定数左で書けという作法もあるけど、
流行らないのは見た目が実行順と逆みたいで妙だからかねえ

306 ：
〇〇=0 はあるけど 0=〇〇 は違和感しかないからなぁ
バッドノウハウの筆頭だと思う

307 ：
数学でも 0 = x^2 + 3x - 2 とかあまり書かないな

308 ：
まあそんなクソな書き方するくらいならテストコード書けやって話にはなるわな。

309 ：
>>304-305
それいつの話だ馬鹿野郎
俺が新兵の頃には、そんなコード書いたら教官からブン殴られてたぞ！！

310 ：
バッドノウハウ……かなぁ…?
定数を左に書く利点は　テストより手軽にコンパイルエラーで止められる事だから
個人的には採用してるんだけど

int i = 0;

/* 想定した挙動 */
if ((i = 0) == 0) { printf("%i\n", i); } /* 定数 右: 出力 "0" */
if (0 == (i = 0)) { printf("%i\n", i); } /* 定数 左: 出力 "0" */

/* typo! == -> = */
if ((i = 0) = 0) { printf("%i\n", i); } /* !!! printfが実行されない! (Cでは通らない) */
if (0 = (i = 0)) { printf("%i\n", i); } /* コンパイルが通ら*ない* 助かった! */

/* () 忘れ */
if ( i = 0 == 0) { printf("%i\n", i); } /* !!! 出力 "1" (== (0 == 0) == true) 想定外! */
if (0 == i = 0 ) { printf("%i\n", i); } /* コンパイルが通ら*ない* 助かった! */

そもそも1文字の打ち間違いなんて テストコードの記述そのものでもやりかねないし
（「絶対に間違えない!」なんていう人がいたらコードどころか作文も書いたことない奴ですぜ）

まあ使用が推奨/禁止されてるかはチームに従うとして
ぱっと見で意図が解るようにはしておくとよいかと

311 ：
>>310
そういうのはもはや統合開発環境の仕事なのだよ。

ていうか if の中で代入を書くとか真正のキチガイ。
有　り　得　な　い

312 ：
すまんかった >>303 は "v = 1 = 2 みたいな" ではなくて "(v = 1) = 2 みたいな"
括弧忘れたら結合順が変わってしまう 訂正

313 ：
統合開発環境ってEmacsのことだっけ。

314 ：
EmacsのせいでUNIXはDOSに負けたんだっけ。

315 ：
単体テスト書くと処理時間出るから、何に時間かかってるのかわかっていいよね。

316 ：
やはり一番時間がかかるのはIOだから、IO少なくするのが一番よさそう。
std::vectorなんか全体コピーしても余裕の速さだから気にする必要なかったんや。

317 ：
楽な仕事で羨ましい限りです。

318 ：
IゾーンとOゾーンに時間をかけるのは楽しいじゃん

319 ：
>>310
まさか真顔で言ってないよね？

320 ：
>>319
まじかよ。おまえ真顔じゃないか。

321 ：
世の中いろんなコーディングルールがある

ifの中は副作用のあるコード禁止とか
goto禁止とか
3項演算子禁止とか
1個の関数は○○行以内とか
変数名は○○文字以内とか

実際に業務で書かない人が決めたりするからたちが悪い

322 ：
if の条件式の中で代入することは勧められない書き方だと思うけど、
「言語仕様に照らして完全に正しいけど間違いやすい書き方」にいちいち警告を出されるとうんざりする。
オプションで強めのチェックにしたときならともかく、デフォルトでだぞ。

かといって個別に警告の有効・無効のオプションを書くのも面倒くさいしなぁ。

323 ：
俺も定数との比較なら
if ( 0 == buf )
って定数を左に書くようにしてる
理由は>>310と同じ意図しない代入防止

324 ：
テスト書けば防げるよ。

325 ：
自動的に静的チェックツールかけとけば教えてくれるよ

326 ：
関数の戻り値を保存した一時変数を使わなかっただけで警告出されるのは地味につらい。かといって警告を抑止するのも悩ましい。
以下のような感じ。

void test()
{
int foo = bar();
return;
}

327 ：
コメントアウトしておくべし

328 ：
じゃなくて・・・、BARのreturnにブレークポイントだ。
VSのばあいだけど。
そんな出口の多い構造で大丈夫か。

329 ：
よくわからんのだが使わんものをなんで残しとくのん？

330 ：
>>326
戻り値ありということは普通は副作用なく作るだろ
その戻り値を無視したら計算資源だけ使って何もしないってことだよ
なんのためのコードなのそれ？

331 ：
副作用の試験モジュール

332 ：
副作用ありの関数で成功失敗その他を戻り値で返すのはごく普通にあることでは。

333 ：
だな

334 ：
>>328
barのソースが無いのかも

335 ：
このスレは、「風邪をひいたんだがどうしたらいい？」との相談に「風邪をひくな」と真顔で回答する良スレですね。

336 ：
相談する時は、「なんでそんなところ行ったんだ」などと“そもそも論”を始めて責任所在の確定に情熱を傾ける後ろ向きで生産性ゼロの人に相談することは避けなければならない。
これが私の設問の真意。以下が回答。

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\ItemTemplates\VC\Windows Store\1041\BasicPage\BasicPage.xaml.cpp:97
(void) sender; // 未使用のパラメーター

337 ：
>>321
同感

338 ：
Visual Studioなら不要な警告を非表示に出来るだろ

339 ：
>>324
if (buf = 0) {
}
を検出するためのテストってどんなものですか？

340 ：
補足すると、マクロ定義によって戻り値が使われなくなることがある場合の警告を想定。
>>336 であげた BasicPage.xaml.cppの事例は厳密には関数の仮引数を使わない場合の警告なので若干違うが、対処法は同じ。

#define OUTPUT(x)

void test()
{
int foo = bar();
OUTPUT(foo);
(void)foo;
return;
}

341 ：
性的解析ツールだな

342 ：
>>339
そのコードにエフェクトがあるならテストできるのではないでしょうか。

343 ：
>>339
そういうのはコンパイル時にWarning出るから本線にマージする前には見つかるでしょ

344 ：
変数で戻り値を受けとって使わないって言うのは確かに変だが
戻り値がある関数の戻り値を受けとらないって言うのは問題無いのか？

345 ：
>>342
>>339 に対する具体的なテストの方法を示してください

346 ：
>>345
それ単体テストやればカバレージ100%にならないから容易に検出できるだろ

347 ：
>>340
最初に書いとけよタコが
お前の想定など知るか

348 ：
>>339
if (buf = 0) { A }

・buf がゼロの時 A が実行されないと実行結果(出力など)が正しい結果にならない場合
・bufが非ゼロでここでゼロにされると以下同文

この2つの場合は結果がおかしいからテストで見つかる。
結果は正しいが見つけにくいリークが発生するとか
ここ間違えても結果は(常にではないが)多くの場合正しい
とかだと静的/動的カバレッジで見るしかないね。

349 ：
俺の中のうざい警告

使わない引数、変数、関数の警告
セキュリティ関連
演算にカッコを付けろという警告

350 ：
非適合コード: a = a + b + c;
適合コード: a = ( a + b ) + c;

351 ：
>>349
＞演算にカッコを付けろという警告

メンテしてるアプリのソース内のMD5だか sha だかのコード(問題なく動作中)で
「&とシフトの優先順位わかってんのか？括弧つけたら？」の警告が出るが、
&とシフトの優先順位など知る気もないし書き換えるとバグる気しかしないので放置している。

352 ：
セキュリティ警告無視する人とは仕事したくない

353 ：
質問です
std::unique_ptrはデストラクタで保持するリソースの解放処理を行うので、自明なデストラクタを持つことが出来ず、リテラル型になることが出来ないと思うのですが
デフォルトコンストラクタとnullptrを受けるコンストラクタはconstexpr指定されています、このconstexprにはどういう意味があるのでしょうか？

354 ：
>>353
https://stackoverflow.com/questions/30766103/why-declare-constrexpr-constructors-for-classes-with-non-trivial-destructors-e/30766445#30766445
によれば
constexpr でないコンストラクタよりも先に(恐らくはコンパイル時に静的に)初期化されるので、

例えばグローバル変数
foo apple;
unique_prt<T> orange;

とあるとき
初期化順を気にせず apple のコンストラクターの中で orange を使用することが出来る。

355 ：
>>354
リテラル型とまではいかないにしてもコンパイル時に初期化してくれるんですか、なるほど
ありがとうございます

356 ：
Scopeのついた#defineのような書き方ってないのでしょうか？
たとえば　Uart0.baud 115200を変数としてしてじゃなくてDefineで保持しておきたい
場合にScopeを整理しておきたい。

357 ：
template<int baud> class Uart0 {

358 ：
>>356
C++では#defineではなくconstを使うと習いました

359 ：
先生！プリプロセッサで完結する処理もconstを使うのですか？

360 ：
Constはラムに配置されますからダメですよ。
それからTemplateは型を変数にしたい場合につかえるだけです。Scopeのついた
定数がないとすると、、、、、なんか使いにくいですね。

361 ：
enum
static const

362 ：
名前空間 にconst定数を閉じ込めて、スコープ内で using namespace xxx; を宣言して名前空間を明示せずに定数にアクセス。

363 ：
defineをconstに書き換えるぐらいなら別の言語使いますよね。

364 ：
今どきdefine使ってる奴なんていたらクビだわ

365 ：
クビにできる立場の人がソースコードチェックしてる会社なんですね。労組がないとかただの派遣屋ですね^^

366 ：
整数に関しては遥か昔から enum がスコープ付き定数として使われてただろ

367 ：
>>360
組み込み向けとかでROM実行になっていなければ、どちらもRAMに配置されると思うよ。
もしもコンパイル時解決するかどうかということであれば、constでもちゃんとコンパイル時解決されるし、式（含関数）の場合はconstexprキーワードを使えばコンパイル時解決（可能なら）される。
あと、templateは型だけでなく定数も置けるよ。

368 ：
考えるべきなのは２つ

コードの即値として使われるのか
値がある番地にマッピングされるのか
その都度関数コールで解決するのか

と

マッピングされる場合、どのセクションにマッピングされるのか

369 ：
const定数は ヘッダーファイルで宣言するだけではダメでソースファイルでconst定数の実体を初期化しなければならないので、defineより使い勝手が悪い面もある。
最新のC/C++だとその辺どうなってんの？

370 ：
処理系依存させずソースレベルで終わらしたい。

371 ：
>>369
メンバ変数でも数値ならソース側に定義要らないから
struct SimpleMath {
const static int pi = 3;
};
でいい

実体がたくさんできるのを苦にしなければ
namespace n {
const static int pi=3;
};
でもいいし

372 ：
>>369
関連してついでに言うとよほど古いコンパイラじゃなければ

struct T {
int k=0;
};

というメンバ変数の初期化の書き方もできて
複数のコンストラクタがあるときとか楽できるよ

373 ：
>>371
ゆとり乙

374 ：
>>326
(void)bar()

375 ：
>>340

376 ：
実体が沢山出来るとか馬鹿かテメーは
それが事実ならリンク時にエラー大量発生しとるわ

377 ：
>>376
人をバカにしたい意識が強すぎるから static 変数は
外部リンケージを持たないなんて基本も忘れるんだよ。

378 ：
ほら試してやったぞ
アドレスが違うから2個あるのがわかるだろ？

MacBook-Pro:tmp$ cat a.h
namespace a {
static const int b = 8;
};

MacBook-Pro:tmp$ cat a0.cpp
#include <cstdio>
#include "a.h"
extern void foo();
int main() {
foo();
printf("main %lx\n", (long) &a::b);
}

MacBook-Pro:tmp$ cat a1.cpp
#include <cstdio>
#include "a.h"
void foo() {
printf("foo %lx\n", (long) &a::b);
}

MacBook-Pro:tmp$ c++ a0.cpp a1.cpp
MacBook-Pro:tmp$ ./a.out
foo 10925bfb0
main 10925bfac

379 ：
マカーのくせにC++使ってんじゃねぇ。

380 ：
ソース中で(アドレスは使われず)値しか用いられなければ実体が全く作られない可能性もあるが
オブジェクトファイル見なきゃ確認できなくて面倒だからそれは略

381 ：
クラステンプレートにしておけば (そして型引数が同じであれば) リンクのときにインスタンスが統合されるので、それを利用できるかもね。

382 ：
>>381
クラス使うなら普通に>>371の上の方で良いかと思う

383 ：
>>377
だからよう、なんでstatic付ける必要あるんだよ
付けなければ実体一つで済むだろ馬鹿かテメーは

384 ：
>>383
付けなかったらリンクエラー出るだろ

こういうとお前はバカだからヘッダーでは extern しておいて
どっかのソースに１つ実体を書けとか言い出すんだろうけど、
もともと>>371は>>369の「ヘッダーだけで済ませたい」への返事だからな。

まだ他に言いたいことがあるなら日記に書け

385 ：
>>384
出ねぇよ馬鹿かテメーは変数と扱い違ぇんだよ

386 ：
#defineが一番確実
最適化も一番期待できるしCとの互換性も保てる
ってことでいまだに#defineは使う
スコープ問題は昔ながらのプレフィックスで解決

小さな組み込みマイコンだと
C++でもこんな感じ

387 ：
と、クソ雑魚老害がさえずってます
せめてenumにしろよ雑魚

388 ：
フリースタンディング環境の話をこっそり忍ばせてくる技の名前なんだったっけ。

389 ：
逆に値を変えても1バイトしか変わって欲しくないときや
1バイトを無理やり変えると動作が正しく変わってほしいとき
は番地に割り当てられるようにする

PCプログラムしか書いたことがない人は気にしたことも無いだろうけど

390 ：
#defineアレルギー
gotoアレルギー
printfアレルギー

この板には多い

391 ：
mainと言う文字列見ると、猛烈に指先がかゆくなる

392 ：
WinMain

393 ：
_tmain

394 ：
もはやドライバ書くときしかC++使わないし、最近のC++機能は全部いらね
老害とか言ってる奴の用途なんて元々、JavaやC#で十分だろ

395 ：
内容あまり理解してないがconstexprは論外なのか

396 ：
定数意外の計算（変数なんかが含まれる）とコンパイルエラーになる。

397 ：
constexprは関数が返す内容が定数であることを保証する
コンパイル時はインラインでその関数を走らせて順次定数に置き換えてコンパイルが行われるということだ

398 ：
コンパイル時定数ということですよな

399 ：
constexprは変数も定義可能だから今回の内容なら名前空間にconstexpr変数を定義すればokかなと思ってたり...

400 ：
まあそういうこったな
どんだけ糞長い関数書こうとその関数を呼び出した時点で定数に置換されてコンパイルされる

401 ：
>>396
それc++11

402 ：
constexprだけど計算にとても時間がかかる場合はどうなるんだろう

延々とコンパイルが終わらないとかエラーになるとか勝手に実行時解決になるとか？

403 ：
constexprで学習した結果のみ実行時に用いるAI。

404 ：
結論が出たようなのでまとめる
１．＃defineは欠点が多い。スコープが効かないのでC＋＋では基本的に使わないこと。
２．代わりにconstexprを使う。constexprは、汎用的に定数式を表現するための機能である。
constexprは、「constant expression (定数式)」の略語である。

例１
#define BIT(n) (1<<n)
これは汎用性が高いので書き換える必要はないようにも思えるが、正しくは
constexpr int BIT(int n){ return 1 << n; }
このように書かなければならない。

例２
#define UART_A0_baud (115200)
#define UART_A0_stop (1)
#define UART_A0_bit (8)
#define UART_A0_parity (0)
#define UART_A1_baud (9600)
#define UART_A1_stop (2)
#define UART_A1_bit (8)
#define UART_A1_parity (1)
これをconstexpr　を使って綺麗に書いてみよう。任せる。

405 ：
C++書けるやつはかっこいいな-
ただ俺が書こうとしてないだけだけど

406 ：
>>404
お断り致します。

407 ：
でふぁいん　てんてきのしんにゅう　がちょくじゃないから　あんしんするじゃないかな


めいんすとりーとからいっぽんはいったほうが

408 ：

http://o.8ch.net/16nnn.png

409 ：
ｶﾁｸﾞﾐﾆﾁｶｲﾎｳｶﾞｱﾌﾞﾅｲﾖﾈここはあんぜんしゅうだんすとーかーにとっては

てんごく　あんじゅうのち

410 ：
適当
https://ideone.com/3pPDGA

411 ：
>>402
constexprはコンパイル時評価可能（評価するとは言っていない）なのでコンパイラ依存。
コンパイル時間が伸びるのが大半だろうけど。

412 ：
>>410
テンプレートクラスを使った変態バージョンを作ってみたわ
https://ideone.com/6i6un3

413 ：
>>411
確実にコンパイル時に解決されてるためには
別プログラムで計算して即値を#defineがベストって事だな

414 ：
>>411
「とても」ってのは例えば10年かかるとかそういうの
ある数学定数の計算とか固定データの暗号化を破るプログラムとか

適度にあきらめてくれないと
コンパイルが(事実上)出来なくなる

415 ：
>>413 そこは即値をconstexprにしようぜ。

416 ：
>>404
constexprならunsignedじゃなくても平気なのかな？

417 ：
>>385
リンカの挙動に付いては変数と扱いが違うせいじゃなくて
c++ では const 変数はデフォルトで static なくだけだよ

お前は正しい指摘をしている時でさえ必ず間違ったことを言う
このスレ読んでる人に嘘ついて喜んでる愉快犯か何かか

418 ：
現代においてdefineを使う利点がゼロ

419 ：
は？constをヘッダにstaticで定義しているバカが居たことに驚きなんだが
そりゃstaticで定義しまくったら実体増えるのは当たり前だろ
灯台下暗しでstatic記述するバカに気付かなかったわ
バカ過ぎて話にならんわｗ

420 ：
>>419
おっしゃることは確かにもっともなことですが、basic_string::npos についてはどう思われますか？

421 ：
なお、std::dec, std::hex なども static const。

422 ：
クラス変数は統合されるから問題ない
ネームスペースやグローバルのヘッダに書くstatic constと違って

423 ：
constexprをご存知でない人多すぎでは
入門書に1ページおきにこれを使えと書いてあるだろ

424 ：
一行おきになってから考える。

425 ：
>>418
アホ自慢？

>>423
入門書www
プロは知ってても、場合によって#defineを使う

426 ：
>>422
クラス変数に統合されるとなぜ問題ないのですか？
そもそも統合とはどういう状態でしょうか。
ネームスペースにstatic constを書くのとあまり違いはないように思うのですが、どう違うのか教えてもらえませんでしょうか。

427 ：
static constexprにするかstatic inlineにするかテンプレートクラスに書けば実体はただ一つになると思う
普通に書いたら分裂しそう

428 ：
cとの互換性を無視した場合のdefineの利点てあるのですか？

429 ：
>>425
プロはinline変数を使う

430 ：
>>428
ソースコードをプリプロセスしたいときに使う

431 ：
>>428
Boost.Preprocessor

432 ：
　　 _＿＿
　　/彡彡))
　 ｜彡(　>
　 ﾉﾉﾉ ヽ丿　＜プロでござい
　／￣￣￣＼　　n_
`/| _[]_ ｜/＼ (　)
∧|｜バ｜ Y＼ `/ /
＼|｜カ｜ |　＼_/
（| ￣￣　|
　|_＿＿＿|
　||_|i|_||
　| ー|ー |

433 ：
>>429
かならずインラインになる保証はないのでは？

434 ：
>>421 を訂正。

std::dec, std::hex はマニピュレータなので定数じゃなかった。
定数なのは、std::ios_base::dec、std::ios_base::hex。

435 ：
マニピュレータは関数だぜ？

436 ：
まじめにデザインパターンを学習したくて書籍を探しているのですが、Javaで
説明しているものばかりで困っています。Javaは全く知りませんし、覚えるつ
もりもありません(自分にとっては不要な言語なので)。

C++でデザインパターンを開設している書籍を教えてください。

437 ：
>>436
gofっていうわりとデザパタに詳しい人も本出してるから探してみて。

438 ：
サンプルがJavaで書いてあるかどうかって関係あるか？
デザパタの本ならJava特有のことはやってないはず
何をやっているのかを理解してそれをそのまま他の言語に当てはめればいい

439 ：
>>436
本じゃないけど
http://marupeke296.com/DP_main.html

440 ：
C++は反則技が多すぎるので勉強しても無駄。
常に速度やメモリ効率を重視するための言語。

高級言語でOOしたいなら素直にJavaを使うべし。

441 ：
反則技って言える位は覚えたい

442 ：
今日日、Java使うくらいならPythonを使うんじゃないの。

443 ：
IDがPS4って凄いなw

444 ：
JavaとPythonとC++って全部用途が違うじゃん
Javaと競合してるのはC#

445 ：
>>436
結城ならば簡単なJava だから、C++ の知識で Java の字面は追えますよ（なんとなくわかる）
私は結城 Java を C++ に書き直して習得しました

446 ：
C#やJavaが動くのにC++を使うのは辛い。非常につらい。絶対にやめたい。にも拘らず
未だにC++を進める人がいるのは残念だ。
一方C++は組み込みには非常に威力を発揮する。しかし組み込みではいまだに９０％
の人がCを使う。それはなぜなのか？
　CとC++ではスッポンと月ほどの違いがある。しかし残念ながらそれは
C++をフルに使える場合であって、フルに使える場合ならC#やJAVAを使った方がいいわけで
フルに使えないケースであるからこそ、C++を使うのが正しいのであるから、やはりC++は
Cに比べて月ほどではない。しいて言えば月というよりは牛だろう。ともすれば牛よりも
スッポン料理が高価なように、月になれるのに牛ではやはりかなり残念なのである。
どういう切り口でも残念な言語、それがC++だ。

447 ：
C++開発をした人がC++の本を書いていて、先輩に「読め！！！」と勧められたので読んで
みたが非常にわかり難い。こんな頭の構造をした人が作った言語だからきっとわかり難いの
だろうと思う。一言でいうと簡単なことを複雑に説明する。
C++という言語もアフォほど簡単なことをやたらと複雑に書かなければならないことが多い
という気がする。

448 ：
Headerファイルにメソッドを書かないスタイルは誤りだ。
理由
１．C++以外でそんなスタイルをとっているものはない。
２．なぜならメソッドも実体ではなく型だからだ。分離するメリットはないがデメリットは多い。

449 ：
>>446
コピペかと思ったけど違うのか
何でC#を使うべきケースとC++を使うべきケースを分けられない人が出てくるんだ？
インタープリタやC#やらがクソ簡単に書けるのはその下で煩わしいことをやってくれてる人がいるからだ

450 ：
最近の勘違いしたアホ機能テンコ盛りのC++。なんでも書けますよ。

451 ：
c++が複雑なのはわかるがどんどん簡単に書けるように進歩してるだろ。

autoとかrange-based for loopとかconstexprとかlambdaとか。

他の言語並みに簡単に書けるようになるのはまだまだかかるとは思うが。

452 ：
使う気ないですけどね。速度が速くならないならいらないです。
使い捨て、楽したいならC#で十分ですからね。

453 ：
>>449
相手するなよ...

454 ：
>>412
簡潔で綺麗だ。素晴らしいと思う。

455 ：
仕事で自作テンプレートライブラリ持ち込む奴

456 ：
>>454
今どきはtypedefじゃなくてusingだしconstは実体が増えるからconstexprにするべきだと思うのだがどうだろう？

457 ：
セットする値に singned int の範囲しか使わないなら、static const 定数じゃなくて enum でOK。
enum なら constexpr すら要らない。

458 ：
enum baseってlong long使えないんだっけ？

459 ：
>>455
関数作るのと同じだろうが

460 ：
>>444
Javaは高価な機器を買わせるためにデザインされた言語だから用途が違うけど、他はソフトウェアを作るためでは？

461 ：
普通に書いてればテンプレートだらけになると思うが

462 ：
C++やるのにテンプレート使わないなんてただのマゾプレイ

463 ：
小規模マイコンのソフト開発なんて
全てがマゾプレイみたいなもんだから
それでもCよりはC++の方が便利

464 ：
>>462は正しいと思うけど>>461のようにテンプレートだらけになるのはどうかと思う

465 ：
Expression templateでmatrix乗算、それが無理ならベクトルの内積
(それもコンパイル時計算じゃなくてコンパイラの遅延評価を利用して
一種の構文を記憶したもの)を計算するETを解説してるところしらないかな。

ベクトルのETによる遅延評価計算はC++テンプレートテクニックあるから
いいけどさ。

Matrixがわからんのよ。uBLAS、MET、TVMET探してもそれらしきソースコード
が特定できん。

466 ：
Expression templateは本命じゃない。難しすぎる。でも演算子オーバーロードの
弱点である一時オブジェクトによるロス(a*aみたいな乗算も含めて)を解決する
方法を20年以上前に考えたけど、それと速度を比較したい。

467 ：
http://eigen.tuxfamily.org/

468 ：
ユニバーサル参照で一時オブジェクトの問題は片付く？

469 ：
>>461 ←こういう車輪の再発明ばかりしてる奴

470 ：
レゴブロックしたいなら別の言語使えば

471 ：
売ってる車輪の中から探すよりも作った方が早かったり安かったりぴったりな車輪になったりする

472 ：
アプリ次第じゃね。
数値計算やアルゴリズムやってると、リソース、速度、必要精度に応じて、整数、浮動小数点、多倍長整数、有理数等々に対応できるように作るから、むしろテンプレしかない。

473 ：
>>470
うまい。プログラムがテンプレートだらけになってる奴は必死にマイレゴブロックを作ってる。
stl、boost、atl、既成レゴブロックは数多く提供され使われてるのだ。

そんなに理想の車輪がほしければ、
それこそ新言語を作ればいい。C++にアホ機能追加してる糞どもに言いたい。

474 ：
>>473
C++03を使い続けたいのなら使ってもいいんよ。

475 ：
>>473
何言ってるのかわからん
stlやboostはブロックを作るための材料くらいの位置づけだぞ
テンプレートがstlのような比較的低レイヤーなところでしか使わないとでも思ってるのか
レゴブロックと言ってるのは大量のモジュールを読み込んで継ぎ接ぎしてるようなJSやPythonのコードのことだ

476 ：
うちの会社にもなんでもテンプレで作りたがる奴いるけど、
調べたらほとんどのテンプレが一種類の型でしか使われてなかったｗ

477 ：
>>472
色々に対応できるライブラリは動作が遅い
スペシャル版が最強

478 ：
そして変更に弱いコードが量産されて最後にはお手上げになると
親の顔より見たわ

479 ：
>>474
過去の大量のC++コードを全否定する機能を追加するなら新言語にすべし。
Java、C#みなそれで成功している。C++の名前を借りないと使ってもらう自身がないならキミは向いてない。

480 ：
全否定する機能てなんだ？なんか追加されたか？

481 ：
提案書を読めば分かるが基本的には問題点を解決するためのものばかりなはずだがな

482 ：
クソみたいな汎用化はいいからまずは一つの機能の関数をまともに書けと言いたくなるバカは確かにいる。

483 ：
それ。C++は当初から問題ある欠陥言語だから、素晴らしい新しい言語を作るべき。
古い大量のコードはもうどうにもならない。誰も更新費用の予算を計上してくれない。
COBOLと同じなのだ。老人のおれはC++と心中する。

おまえら若者は新しい船で新しい世界に旅立ってくれ。俺の屍を越えてゆけ。

484 ：
>>477
そうならないのがc++のtemplateなんで。。
それでも型によってかき分けたほうがいいところはTMPなり特殊化なりすればいい。

485 ：
C++に取って代わろうとした言語はみんな死んだか別の路線を走ってるよ

486 ：
老人はC++03と心中してくれ。俺はC++14以降の船に乗る。

487 ：
>>486
スマートポインタは使わせてほしいのですが…

488 ：
vectorをスマポとして使え

489 ：
vectorはdata()が連続した領域を返さないといけないのが大きな制約になってるかも。

490 ：
それがなくなったら、もはや配列ではない
配列を使うべき用途で出番を失う

491 ：
一応連続した領域を返すと保証されたのはc++03から

492 ：
保証されてくれないと困るから保証されるようになったんだぞ

493 ：
>>484
テンプレートは魔法じゃない

同等の速度を出す為には結局全て特殊化することになるし、
インターフェースも型によって違う方が良いこともある

性能、リソース、...
突き詰めれば全て特殊化

テンプレートは妥協だ

494 ：
妥協というより補助だろう。
templateだけで解決しようとすれば特殊化だらけになるのは当たり前の事

495 ：
cstdio と STLの連携を深めて欲しいね。

・FILE* に basic_string をバッファとして渡してメモリに読み書きする機能が欲しい。
・fgets() で得られた文字列長を再計算するコストが無駄なので、文字列長も取得できる機能拡張関数が欲しい。

何らかの処理の過程で副産物として得た文字列長を捨てて、別の場所で文字列長を再計算する無駄は、かなり多いと思う。

496 ：
templateはポリモーフィズムを実現するための実装の一つです

>>495
c_str()で渡せばいいのでは

497 ：
>>496
基底クラスのポインタで複数の派生クラスのポインタとして振舞えるの？
template を使ってポリモーフィズムを実装できるとでもいうの？

498 ：
>>496
FILE*を使う関数にbasic_stringをc_str()で渡すのではなく、
setvbuf() のようにFILE*の内部で使うバッファを basic_string に置き換える意味で言いました。
fprintf() でbasic_stringに書き込むことが可能になるイメージ。
C++にはpopen()で開いたパイプFILE*に相当するiostreamがないのでこれで代用可能。

499 ：
>>497
コンパイル時にテンプレートパラメータでポリモーフィズムする

500 ：
>>499
template を使ってのポインタがポリモーフィズムを実現できるとは思えないのですが…

501 ：
templateはポリモーフィズムの実装ではなくポリモーフィズムの利用が仕事。

502 ：
ポリモーフィズムの意味が分かってないだけだろ

503 ：
>>497
ポリモーフィズム=継承ではない
継承もポリモーフィズムを実現するための手法の一つにすぎない
ざっくり言えば同じ名前で異なった振る舞いをするもののことを言う
関数オーバーロードもポリモーフィズム

504 ：
詐欺師が「○○を実現できます」と言った時、実際には「他人の作った○○に便乗します」という意味であることが多いから、あながち間違いでもない。

505 ：
>>498
boostで似たようなことができる
http://www.cplusplus.com/forum/general/16532/

これをうまいことラップして
pstream ps("ls");
ps >> str;

みたいに動作するstreamを作ればいい

506 ：
>>505
情報ありがとう。

欲しいのは逆パターン。CをC++でラップするのではなく、C++をCでラップする感じ。難しいか。

507 ：
>>503
＞関数オーバーロードもポリモーフィズム
関数オーバーロードはコンパイル時には（どこからどこへコールしているかが）確定しているものですね
そういうものに「ポリモーフィズム」を当てるのは抵抗があります

もっとも wikipedia をみると、私の考えているポリモーフィズムは「部分型付け」(subtyping/inclusion polymorphism) としてサブクラス化されています
これは私の認識を修正しないといけない…

508 ：
自然界には、収斂進化のように継承や派生と無関係な同質異像が存在します。

収斂進化 (convergent evolution)
https://ja.wikipedia.org/wiki/%E5%8F%8E%E6%96%82%E9%80%B2%E5%8C%96

多形 (polymorphism)
https://ja.wikipedia.org/wiki/%E5%A4%9A%E5%9E%8B

509 ：
意味の広い英単語を、ものすごく狭くて極端な用例の一つに限定して和製英語化しちゃう日本人のいつもの得意技
ポリモもその犠牲者の一つ

510 ：
Ad hoc polymorphismのページでは2つの要素を+演算子にかける関数がpolymorphicなものの例として書かれてるね
https://en.wikipedia.org/wiki/Ad_hoc_polymorphism

511 ：
拡大解釈すればできちまうものだからな
いくらでも俺様解釈し放題
それを聞かされている衆目がついていけないと言ったとき
強弁するやつと謙虚なやつでリトマス試験紙みたいになる

512 ：
もともとプログラミング言語の理論の方から出てきた言葉なので拡大解釈ではないでしょ
オブジェクト指向言語がそれらの理論から引用してオブジェクト指向におけるポリモーフィズムとは継承とオーバーライドによるサブクラス化のことだと言っているだけ

513 ：
>>486
その理屈だとc++20が出るからお前も十分老害だよ。
てか仕様が決まった言語使ってるのは老害ってことになるな。

514 ：
個人的にはどっちかというと「動物ってのはワンワン鳴く奴のことだろ？猫や馬まで動物と呼ぶのは俺様解釈の拡大解釈」
って言ってるような滑稽さを感じる

515 ：
>>513
「老人はC++03と心中しろ」が「仕様が決まった言語使ってるのは老害」になるて…
倫理ダメダメやな
それでプログラム書いてんの？だいじょうぶ？

516 ：
>>515
はいはい、お前はc+14と心中しろ。

517 ：
倫理・・・

518 ：
>>516
"以降"が解らないのにC++で判定文書けるん？

519 ：
C++11以降で書かれたコードがほとんど増えていないという現実。

520 ：
互換性考えるとね
素直に書けないというか

521 ：
GCCもClangも、VC++でさえ10年近く前からサポートし続けてるのにまだ足りないと申すか

522 ：
昨今の潮流はオブジェクト指向と関数型のハイブリッド
この二つをどう摺り合わせるか、どの言語もまだ明確な回答が出ていない
もちろんC++も

523 ：
OCamlがあるが

524 ：
アクセス権つき構造体とユニファイドコールシンタックスで疎結合オブジェクト指向だ。
と考えたのだが、ユニファイドコールシンタックスが死んでしまった。

525 ：
ifdefできるだけなしで
どんなｺﾝﾊﾟｲﾗでも通って同じ動作するｺｰﾄﾞを書けよ
ｺﾚは命令だ

526 ：
お前は本当にそんなにコンパイラを使い分けてるのか？

527 ：
最低限、実機で間違いなく動いて
ｼﾐｭﾚｰﾀｰで間違いなく動くようにｺｰﾄﾞ書きなさい

ｺｰﾄﾞはいろんな実機をｻﾎﾟｰﾄしないといけない
実機ごとにOSも違う

528 ：
ICE上でのみ動作するコード
MIRACLE ON ICE

529 ：
関数型も40年前からオワコンという現実を見ようよ。
2chのスレも全く伸びない。10年で1スレ消費できないレベル。

530 ：
スレが伸びないのは難し過ぎるからじゃないのか

オブジェクト指向なんかはニワカが口を挟みやすい
あれやこれやと語ることがあると自転車置き場のごとくスレが伸びるんだよ

531 ：
罵倒観音が居座ってるからな

532 ：
数学板とか物理板の質問スレで2chに失望し、それ以降2chで理系関連の質問はしないようにしてる

533 ：
>>512
日本語で頼む

534 ：
>>532
稀に神回答がつくのを期待するしかないのです

535 ：
クラス/構造体の非静的メンバ変数/関数へのポインタ宣言 ってのを初めて知ったんですが、
これはどういう活用方法があるんでしょうか？

struct S { int data; };
int S::*d = &S::data;

S s1 = {999};
s1.*d; // → 999
s1.*d = 123;
(参考: 改訂第3版 C++ポケットリファレンス p.39)

上の例だと、 s1.data の別名以外の使い道がないように見えます。
長い長い真名の時は局所的に略記できて便利とか？、まさかそれだけですか？

536 ：
なんか昔同僚がメンバ関数へのポインタ使ってて納得した覚えがあるが
なんで納得したのかはもう忘れた

537 ：
>>535
https://mevius.2ch.sc/test/read.cgi/tech/1434079972/22,23

538 ：
is_classの実装に使う

539 ：
>>535
動的に呼び出すメソッドを切り替えたいとかだね～

540 ：
>>535
そのとき S が int 型のメンバを持たなくても int S::*d という変数宣言が許される。
(無理矢理な型キャストをしない限りヌルしか入れられないけど。)
つまり、 S がプリミティブな型でなくクラスであるならば、メンバにかかわらず int S::*d は許容されて、
プリミティブな型だったらエラーになる。

この性質を利用して SFINAE で切り替えれば、与えられた型がクラスであるかどうか判定するものを作れる。
それが >>538 の言う is_class の実装に使えるって話ね。
まあ今なら is_class を使えよって話だから普通のプログラマ的にはどうでもいいけど。

回りくどい利用法なんだけど、まあ実際のところ実務の中で必要とする場面はそんなにないから、
この利用法が代表的なものとして紹介するしかない。

541 ：
初心者の質問に答えていただき有難うございます。
動的にメソッド切り替えは実際に動かして理解できました。
SFNAEで切り替えの方ははコンパイル通る形にはできてませんが概要は理解できました。

542 ：
メンバ関数ポインタがあの形になってるのはまあわかるから
変数もおまけで同じ形にそろえたのかな

543 ：
> 実務の中で必要とする場面はそんなにない

データメンバはともかくメンバ関数へのポインタは必須だろうが

544 ：
メンバ関数の参照はないんですか

545 ：
>>543
ないと困る局面があるという意味では必須だけどそんな局面は滅多にないって話な

546 ：
>>545
バインダ使うときどうすんだよ
そりゃあエンドユーザーは滅多にというか一生使わんが
そんな話してねえぞ

547 ：
じゃあどう言えばいんだ

548 ：
ある必須の用途で必要なら、その用途がいくら狭くて稀であったとしても
それは必要なんだよ

549 ：
メンバ関数ポインタ面倒だから出会ったら大体ラムダでラップしてしまう・・・

550 ：
std::stack や std::queue に begin() end() clear() などが無いのは何故ですか
begin() end() はともかく clear() は有ったほうが良いと思うのですが

551 ：
>>550
機能を絞っていることが彼らコンテナアダプタの唯一の存在価値なので許してあげてください。

552 ：
template<class ... Args>
void func1(Args ... args) {
outputs(buf, args...);
}
こういう可変長引数のテンプレートの場合に別のファイルで利用する場合には
どう宣言したらいいの？

void func1(???);

553 ：
ヘッダ書いてインクルード。

554 ：
>>546
> バインダ使うときどうすんだよ
だからバインダ使いまくるとか覚えたての初心者か
って話な

> そりゃあエンドユーザーは滅多にというか一生使わんが
誰もしてない話を勝手に始めて
> そんな話してねえぞ
とか、ギャグかよ w

>>548
>>545の日本語も理解できないのか？

555 ：
>>554
バインダ使えないアホか
マジになって悪かったな

556 ：
はいはい w
ようやく日本語理解できたんだな

557 ：
関数型テンプレートってのは、型でもなしに、実態でもない。不思議な存在だ。
型だとすれば、関数プロトタイプのように繰り返して宣言しても問題ないはずだ
が、そうするとエラーになる。実態かというと、これ自体では何のコードも生成しない。
利用するときに始めてコードが生成される。

558 ：
unsigned long address;
int dt;
*(char *)&address = dt;
コンパイラエラーにはならないが動作しない。ところが
uint8_t *address ;
*address = dt;
これだと動作する。なぜなんだ？　

559 ：
動作してないだろ。
メモリ破壊だ。

560 ：
=0x20000;を書き忘れていた。あとは上に同じ。

561 ：
それでもメモリ破壊だ

562 ：
>>559 俺の環境だと上の方でも動作するみたい。
dtの下位8bitがaddressの下位8bitに格納され、addressの上位24bitは不変。
期待通りと思える。

563 ：
前者はaddressの最初（または最後）の1byteだけを書き換えようとしているけど、それは意図通りなの？
後者は0x20000番地の値を書き換えようとしてるけど、そこは書き換えてもよい領域なの？

564 ：
おっと、未定義動作がらみで「何が起きても不思議じゃない」かも知れん。
リトルエンディアンの機械での素朴な予想レベルでの「期待通り」ね。

565 ：
くだらねぇ
初歩の初歩じゃねぇか

566 ：
uint8_t *address = 0x20000;
がコンパイル通るわけねえだろ質問したいならちゃんとしろ

567 ：
>>546
c++で閉じてるなら関数ポインタ渡すインターフェイスより、
クラスを継承してメソッド実装させるインターフェイスのが普通だろ。
まあcからの関数ならよくあるが。

>>557
単なる型付マクロだっつーの。

568 ：
マクロで再帰ができるか！！！！！！！１１１１！１！１１！１！１！

前半は同意
あと関数を単に差し替えたい目的ならファンクタとk

569 ：
そういう事言うとプリプロの怖い人達が来るからやめれ
本物の再帰じゃないけど再帰っぽいことはできるらしいぞ

570 ：
マクロで再帰？
出来るよ普通に

571 ：
今どきマクロなんて使うアホがいるのか

572 ：
スフィ姉を使った技についてスレッドがあってもいいかもしれない。

573 ：
これがアスペか>>571

574 ：
スフィ姉がいるならスフィ妹もいるかもしれない。

575 ：
「マクロ使う奴はアホ」とか言う奴は、goto文も絶対に使わなそう

576 ：
>>563
damecaseの理由がわからない。
void Test::clear(unsigned long baseadd, unsigned int dt, int leng)
{
#if(okcase)
uint8_t * addp = (uint8_t *)baseadd;
for(int i=0; i<leng; ++i){
*addp++ = dt;
}
#endif
#if(damecase)
unsigned long addp = baseadd;
for(int i=0; i<leng; ++i){
*(char *)&addp++ = dt;
}
#endif
}

577 ：
baseadd=0x20000でダンプすると初期値は全部ｆｆが入っている。
leng=100としてdt=0を書き込むとokcaseはOK100バイト０クリアされる。
damecaseは全く反応しない。

578 ：
>>566
とおるよ。頭の中でCastしてくれたら

579 ：
＞おっと、未定義動作がらみで「何が起きても不思議じゃない」かも知れん。
＞リトルエンディアンの機械での素朴な予想レベルでの「期待通り」ね。

どうして？
何処が、どういう理由で未定義なの？
リトルエンディアンが問題というのはバイトオーダーが関係するということ？
1バイトのエリアに代入するのにバイトオーダーが関係するはずはないでしょ。どいういうこと？
char*ｐのｐは1バイトデータのポインタ（アドレス）だよ。代入先が1バイトなのでエンディアンは関係ないと思うが、、、

580 ：
>>567
アンカー間違った？

581 ：
>>579
strict aliasing ruleでググるか死ぬかどっちか選べ

582 ：
>>576
&いらん

583 ：
>>576
damecaseの*(char *)&addp++ = dt;
&いるぅ？

584 ：
>>579
「ある型へのポインタの値をキャストで別の型へのポインタとして扱い、
その(キャストで得られた)ポインタに対して * 演算子で格納する」行為自体が
規格で未定義になってるかも知れんてこと。確実じゃないんだけど。

キャストの時点でか、*でアクセスしたときか、格納の時か、
どことは言えないけど何となく未定義クサい感じがする。

585 ：
↓addpをｲﾝｸﾘﾒﾝﾄとか頭悪いの？
*(char *)&addp++ = dt;
unsigned longのaddpをｲﾝｸﾘﾒﾝﾄしてる
addpはﾎﾟｲﾝﾀじゃないぞ。。。

きっとﾊﾞｶが動作しないといってるのは
落ちるということではない

動作はするが期待どおりの結果にならないということで間違いない
ﾊﾞｶはなにがやりたいのか意味不明

586 ：
unsigned long addr = 12345678;
char* pByte = &addr;
ならいけるﾊｽﾞ

*pByte++ = dt
で leng が sizeof(unsigned long)/sizeof(char) 回までの繰り返しなら
普通に落ちずに動作するﾊｽﾞ

ばああああああああああああああか
しかいないわこのｽﾚ

587 ：
std::addressof()。

588 ：
いやねcすら理解できてないﾔﾂﾗが
c++とか一億年早い

こんなﾔﾂﾗがc++でｺｰﾄﾞ組んでるかと思うと
ぞっとするわ。。。

ｼﾛｳﾄはおとなしくjavaにしときなさい

589 ：
for(int i=0; i<leng; ++i){
((char *)&addp)[i] = dt;
}

ﾊﾞｶ向けのｺｰﾄﾞを書いてやったぞ
ｺﾚでﾊﾞｶにとってはすべて解決

ｺﾚがなんのことか分からないなら
もう二度とﾌﾟﾛｸﾞﾗﾑなんかやらないほうがいい

ｾﾝｽない、むいてない

590 ：
>>586
strict aliasing ruleでググるか死ぬかどっちか選べ

591 ：
ぐぐったぞ

http://d.hatena.ne.jp/yohhoy/20120220/p1

> 文字型。規格ではchar*, signed char*, unsigned char*が別の何かを指すことが特別に許されています。
> これは文字型がメモリ上の任意のaliasになり得ることを意味します。

どうかしたのか
もうねﾊﾞｶばっかりで困るわﾏｼﾞで

池沼しかいないの？　このｽﾚ？

592 ：
ちなみになchar以外で変なﾒﾓﾘｱﾄﾞﾚｽ（ﾒﾓﾘ上有効なｱﾄﾞﾚｽあっても）の位置からcharより大きいｻｲｽﾞの数値を参照すると
memory wrapの切れ目の問題（つまりwrap over）で
bus errorを普通に起こす計算機がある

このｽﾚにいるようなﾏﾇｹたち以外にとっては常識だからな

593 ：
役に立つ情報ありがとう。
でも、半角カナは止めてね。

594 ：
＞&いらん

コンパイルエラーにはならない。ワーニングにもならん。という事実を書いている。
些末なことで糞ほどワーニングやエラー出すC++だ。ワーニングにならんということは正しい
ということか、コンパイラがアフォかさもなくば、何か別の意味があるということになる。
わかるか？　お前にも質問の意味が分かるように、そしてちゃんと回答ができるようにもう一度簡単に書いてやろう。
１．正しい
２．コンパイラがアフォ
３．意図とは別の意味になっている。
さあどれが正解だ。答え見ろ。

595 ：
>584
はあー、未定義かもしれんて？　未定義ならエラーになるだろ。

596 ：
＞＞５８９
理由を書いてごらん。理由がないと回答にならんよ。

597 ：
>>585
俺はやらないがそこは問題じゃない。
アドレス値が格納されている正数を1ずつ増分しているだけだ。

>>589
お前は>>576のコードをそれに書き換えて正しく動作すると思ってるのか？

>>582>>583で答えが出てるのに、馬鹿には理解できなかったのだろうな。
俺なら恥ずかしすぎて首吊って死ぬわ。

>>594
4. お前がアフォ

598 ：
なにが書いてごらんだ
ﾊﾞｶのくせにえらそうに。。。

addpはｱﾄﾞﾚｽじゃない

で、addpはどこのｱﾄﾞﾚｽをさしてる？
で、なにがｲﾝｸﾘﾒﾝﾄされてる？

ﾊﾞｶにはまだわからないらしいわ、、、

int hoge[10]
int boo = 1234;
char* hogeee = (char*)hoge;

ex1

for (int i = 0; i < 10; ++i) {
*((int*)hogeee) = boo;
hogeee += sizeof(int) / sizeof(char);
}

ex2

for (int i = 0; i < 10; ++i) {
((int*)hogeee)[i] = boo;
}

ex1とex2、この違いわかる？
わからないなら、もうすべてを諦めたほうがいい
ｵﾚはｵﾏｴを諦める

599 ：
＞>>582>>583で答えが出てるのに、馬鹿には理解できなかったのだろうな。
＞俺なら恥ずかしすぎて首吊って死ぬわ。

ではその理由を書いてごらん。理由がないと回答にならんよ。理由が説明できないなら試験も受からんだろ。

600 ：
＞で、addpはどこのｱﾄﾞﾚｽをさしてる？
＞で、なにがｲﾝｸﾘﾒﾝﾄされてる？

まず、どこをさしているのか？何がインクリメントされているのか答えてごらん。

601 ：
致命的に脳ﾐｿが足りないのは理解した
ｱﾝﾘｶﾊﾞﾌﾞﾙだ

602 ：
お前は解ったふりをしているだけだよ。言葉にして説明できないならな。

603 ：
ここまで説明して
なんで同じ結果にならないか
分からないならもうﾑﾘだからな

向いてない
諦めなさい
なにごとも諦めが肝心

604 ：
誤魔化して変なコードを追加するな。問題はこれだ。
unsigned long addp = baseadd;
for(int i=0; i<leng; ++i){
*(char *)&addp++ = dt;
}
このコードが何故動作しないか？　それを説明するのが問題なのだ。

605 ：
多分解っている人なら、直ぐに説明できる筈だ。
分からない人は説明できない。罵るのはさらに愚。

606 ：
同じ結果にならないことはすでに説明してるからな

ｱﾄﾞﾚｽを格納する変数を使わないで同じ結果にしたいならどうすばいいか
まで書いた
それに対する補足説明まで書いた

もうこれ以上書くことはない
ﾑﾀﾞ

607 ：
＞ｱﾄﾞﾚｽを格納する変数を使わないで同じ結果にしたいならどうすばいいか
＞まで書いた
＞それに対する補足説明まで書いた

思わせぶりな回答を書いて欲しいといっているのではない。頭がいいと思ってほしいのかもしれないが
それでは「思わせぶり」でしかない。説明としてきちんとした形式を備えた自信のある回答を書いてごらん。

608 ：
>>599
え、なんで？
礼儀を知らないおっさんに教えてやることなんて一つもないよ。

ちな>>597で馬鹿呼ばわりしたのは半角でﾊﾞｶﾊﾞｶ言ってるやつのことなんで。

609 ：
>608
「教えない」習性の人は成長しない。ということは知っているだろ。習性というくらいだから今に始まったこと
ではない。つまり嘗て勉強を始めた時点ですでに成長はとまっているということだ。

610 ：
俺は無償でお前等に考え方、回答の方法を教えている。教えることが一番勉強になる。
いままでのところ質問にたいして誰も合格点をあげることができるような回答がない。

611 ：
addpの値として期待されているのがアドレス値X。&addpは、アドレス値Xを格納している変数addpのアドレス値Y(ポインタの値)。代入によって期待されているのが、アドレスXへのdtの値の格納。
XはYではないから、間違い。

612 ：
というか&addp++の時点でエラーでるなこれ
コンパイラ何使ってるの?

613 ：
こんなに引っ張るほどのネタじゃないだろう

614 ：
炎上学習法ってやつ？

615 ：
>>612
正に初歩的な質問というものは質問自体に間違いが含まれている可能性がある。
そのことに先ず言及できたのは君が初めてだ。素晴らしい。

質問者が正確に質問できた時点で回答は既になされたも同然だといわれるが今回も
例外ではない。これで終わる。

616 ：
なめたことをしてくれたな。。。

558 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 469d-mzC7)[] 投稿日：2018年06月30日(土) 08時17分40秒24 [朝] ID:p5lz5e260 [2/19] (PC)
コンパイラエラーにはならないが動作しない。

594 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ 469d-mzC7)[] 投稿日：2018年06月30日(土) 22時22分23秒05 [夜] ID:p5lz5e260 [8/19] (PC)
コンパイルエラーにはならない。ワーニングにもならん。という事実を書いている。

　(ﾜｯﾁｮｲ 469d-mzC7)　 ID:p5lz5e260

ｵﾏｴを特定した
震えて眠りなさい

617 ：
ことさらに難しいコードを書いて得意がってる馬鹿がうようよ

1行に詰めるのがプロか？

新入社員が読めないようなコード書いて喜んでいるお前らが
バグを仕込む糞プログラマだわ

618 ：
有能なプログラマはこんな場所で遊んでいない
暇なプログラマっていうか、仕事が無いプログラマ？

619 ：
ﾌﾟﾛｸﾞﾗﾏにまともなｺｰﾄﾞ書いてもらうも仕事の一つだからな

まともなｺｰﾄﾞ書いてもらうには
こっちもﾌﾟﾛｸﾞﾗﾑが分かってないといけない

日本はｳﾝｺみたいな低品質低能のﾌﾟﾛｸﾞﾗﾏしかいない
いかに踏みとどまらないといけない最低限の一線のﾗｲﾝを越えさせないようにするか
そこが腕のみせどころになる

このｽﾚみれば分かる通り
日本のﾌﾟﾛｸﾞﾗﾏは低学歴低能しかいないことがよく分かるﾊｽﾞ

しかも相手がなにを期待してるかも読みとれない
ｺﾐｭﾆｹｰｼｮﾝ能力も著しく低い
こんなのに仕事をお願いするほうも大変だからな

可読性が高いｺｰﾄﾞを書くことは重要だが
それ以外にもｲﾛｲﾛなものが欠落している

620 ：
struct addp_t
{
int& operator ++ (int)
{
return a;
}
int a;
};

int main()
{
addp_t addp;
&addp++;
}

# アンカーつけるのももったいない
# ２ｃｈという狭苦しい箱庭の中で目撃したことが
# おまえの全てのようだな
#
# なぜ学歴が出てくるのかよくわからんが
# 高学歴のPGくらいどこにでもいるよ

621 ：
>>591 ありがとう。
(signed/unsigned)char* のポインタで他の型の格納領域にアクセスすることは
規格で許されてるんだね。char* だけ特別扱いってことか。

俺も >>581 の指摘を見て検索して同じページに到達したんだけど、
> 文字型。規格ではchar*, signed char*, unsigned char*が別の何かを指すことが特別に許されています。
> これは文字型がメモリ上の任意のaliasになり得ることを意味します。
の部分を見つけることができなかった。

すると >>558 のコードに未定義動作を引き起こす点はないのだな。

622 ：
>>619
最近文字コードスレで騒いでいる半角カナの人と同一人物かな？

623 ：
循環参照があっても無問題で解放するスマポ作ったけど何か質問ある？
http://codepad.org/Hu6vP4qR

いやまあ確かに解放に当たり（塗り潰しのアルゴリズムで）循環を検出するだけでは済まず、
　*(this->m_pRef)の解放条件が*thisの解放「だけ」である
ということの証明が必要やったわ；（訂正1）
ここで*thisはsumapo<T>インスタンス、*(this->m_pRef)は*thisが保持しているcounted_refオブジェクト
（T型のインスタンスに参照カウント等を付加してwrapしたもの）。
詳細はsumapo<T>::proveRoot()のコメント参照、

これ以外は訂正は無し

624 ：
>>225
Tのメンバを公開（publicにする）するだけで、
sumapo<T>の定義内のコードからTが保持するsumapo<*>にアクセスできるというなら
>>226の忠言に従ってコードを書いてみると良いんじゃー

一方リフレクションが使えるなら、sumapo<T>::setLandowner()メソッドは不要となる
（これのメソッド>>222において
>あんま使い勝手の良いものにはならんかったorz
>m_pCarやm_pCdrとptrが裏で手を握る必要がある
　が指していたﾌﾞﾂ。>>222の時点でtest01()が通るコードは書いていたんじゃわ；；

625 ：
>>624訂正
誤： これのメソッド>>222において
正： このsumapo<T>::setLandowner()メソッドが>>222において

626 ：
>>624
なんつうロングパスよ、と思ったが、コードを書いた姿勢だけは褒めてやる。
とはいえ、俺は最近「馬鹿が書いたコードは読む価値がない」と結論を出したので読まないが。
（大体において意味不明な制御を行っており、結果、
解読に時間がかかる割に得る物が全くない）

それ、アルゴリズム説明してみ。
そしてそれが正しく動くとして、何故C++がそれを採用しないかも説明してみ。

627 ：
地権者とはどういう意味なの？

628 ：
クラスTのオブジェクトを参照するスマポsumapo<T>のインスタンスpaが、クラスTのインスタンスaを参照している状況を
　pa→[a]
と書くとする。ここで、[a]は、aに参照カウントその他を追加してwrapしたもの。（>>623におけるcounted_refクラスに当たる。
[a]はインスタンスaにつき唯一だが、[a]を参照するsumapo<T>は複数有り得る。

で、paとpbが循環参照しているとは、次のような状況である。
　例1: pa→[a], pb→[a]、ここでpbはaのメンバ（paとpbが循環参照
　例2: pa→[a], pb→[b], pc→[a]、ここでpbはaのメンバ、pcはbのメンバ（pa、pb、pcが循環参照

例1では[a]がpaとpbから参照されていることになっており（参照カウント2
結果、paの解放時、paのデストラクタで[a]の参照カウントが1になるが0にはならないので、
参照カウントだけに頼るとその時点でpaのデストラクタは[a]が解放されない。（引き続きpbから参照され続ける。
一方、pbの解放条件は、[a]の解放である（∵pbがaのメンバであるため）。というわけで解放がデッドロックに陥る。

しかしpa→[a]==>pb→[a]、という参照関係（paのみが参照関係の根である）をpaの解放時に把握できていれば、
paの解放で[a]（とそのメンバpb）を解放して無問題であることがﾜｶﾙ
この参照関係のうち、「==>」をpb.setLandowner(&pa)とすることで設定し、-- (1)
paの解放時に全体として参照関係の根がpa自身「のみ」であることを証明する -- (2)
ことにより、安全に解放が行える。（(1)と(2)がshared_ptr<T>にたいしsumapo<T>で追加になった要素

標準ライブラリに入っていないのは、(2)の証明コストがｲﾏｲﾁかかるからだろうＪＫ

629 ：
>>627
pa→[a]==>pb→[a]、という参照関係において、pbの地権者はpa。
なお、ソースコードコメント内には「立地」という言葉も出てくるが、pb立地が[a]。

630 ：
>>628
まずそういうのはインタフェースを揃えろ。
（俺はスマポは使ったことがないが、俺の理解の範囲では）
お前はスマポの仕様を勘違いしている。

オブジェクト側をラップするのはソースコードの全面的書き換えが必要になるだろ。
だからそんなことはしてない。
スマポも普通のクラスでしかなく、スマポ側に制御に必要な情報全てを持っている。
オブジェクトと癒着はしてないんだよ。
> 一般的な実装では、 std::shared_ptr は2つのポインタを保持します。
> 格納されたポインタ (get() で返されるもの)
> 制御ブロックへのポインタ
> https://ja.cppreference.com/w/cpp/memory/shared_ptr

が、まあ、言いたいことは分かるし、ここは本質的には重要ではないので、
今回はお前のオレオレ用語のままでいい。


さて本題だが、(1)は誰が管理するんだ？
プログラマが明示的に手動で管理するのなら、現行のshared_ptr/weak_ptrと手間が変わらない。
だから自動的に出来る必要があるが、これは出来るのか？

具体的に言えば、お前が言っている「参照関係の根」をshared_ptrで、
「pa→[a]==>pb→[a]、という参照関係」のpbをweak_ptrで実装しろというのが現行の仕様だが、
これに対して何が便利になってるんだ？

631 ：
コストを考えなければ自動化は可能

632 ：
>>631
それはC++的には意味がないだろ。

結局、現行の仕様が何故そうなのかを理解出来ない馬鹿が吠えただけだろ。
まあJavaScripterなんて所詮こんなもんだが。
「スクリプト言語使いをプログラマと呼ぶな」というのは、多少は当たってる。
彼らが書けるのは「動けばいい」程度のコードまででしかない。

633 ：
適材適所
言語は上から下まで色々と使えた方が良い

634 ：
他の言語を見下すプログラマーにはなりたくない

635 ：
pythonしか使えないやつが作った特定のサイトから画像を大量にダウンロードするだけのツールが
クソ遅いうえにメモリ4GBも使ってたので頭pythonってクソだなって思った

636 ：
使える言語を聞かれてC++含めて複数答えたら
確かPHPあたりで「それプログラムじゃなくてスクリプトだよね」って言われたことはあるな
そこまで上から目線で突っ込むことか？とイラッとした記憶があるな

637 ：
いるよね、やたら偉そうに
自分を大きく見せようとするやつ

638 ：
c++,c,sh,bash,zsh,csh,tch,screen,glsl,php...

639 ：
>>635
それはその使えない奴の問題だろ
言語の問題とプログラム固有の問題の切り分けもできないアホなら黙っとけ

640 ：
>>636
PHPは言語自体の性能が低いので使いこなすのはかなり難しい。
Javascriptも同じ。
つまり、楽に性能を出せるC++に乗り換えた方がいい。

641 ：
乗り換えるも何もここはC++スレじゃないか。

642 ：
>>635
その程度のもの、文句言うなら自分で作れや。

643 ：
>>635
wgetはサイトから再帰ありで指定のファイル取得できるよ。

644 ：
お前らは知らないからそんな呑気なことが言える。
実際、JavaScriptはマジでゴミコードの山だ。
商用サイトでも糞重いしリークしまくりだ。

PHPはJavaScriptに比べ露出は低いが、OSSを見る限りやはり糞だ。
とはいえコードの質はPHP>>>JavaScriptだが。
DB接続があり、初心者にもコードの質が見える所が違うのだろう。
PHPerは虐げられているが、その分勘違い野郎は少ない。
最悪なのはJavaScripterだ。

一般のスクリプト言語(Python, Ruby含む）とC++等のプログラミング言語の違いは、
前者は圧倒的に「一回動作させれば終わり」な使われ方をすること。
だから、メモリリーク？何それ美味しいの？
コードが美しい？そんなことよりちゃっちゃと書いて実行させた方が早いでしょ、となる。
長期的保守の必要がない使い捨てコードばかり書いているから、
保守に耐える品質のコードを書けるようにならないだけ。

だから正確には、
「保守に耐える品質のコードを書けない馬鹿をプログラマと呼ぶな」であり、
それがほぼ「スクリプト言語しか使えない馬鹿」と一致する、というだけ。
一般的に(JavaScript除く)スクリプト言語は圧倒的に遅く、
味見ではなくガチならC/C++に書き換えるケースも多々発生する、というのも
これを後押ししている。

とはいえ、JavaScripterやPHPerみたいな馬鹿揃いでも
何とかるように出来ているのがWeb系()の凄いところ。
あれは学ぶ価値あると思うぞ。
色々C++では無駄に難しく考えすぎていたな、ということに気づかされるから。

今更導入されたラムダもしかり。あれは手抜きにはかなり便利だ。
コルーチンもそうでしょ。無しで同じ事をやろうとするとそれなりにエグくなる。

645 ：
>>630
>さて本題だが、(1)は誰が管理するんだ？
いやすまん>>628の最後の一文ではそれをすっかり失念してたわ；；
標準ライブラリにsumapo<T>が入りえない最大の理由は、(1)の管理を手動でせねばならない、という使い勝手の悪さのが最大の理由
（>>222で書いた「使い勝手の悪さ」のことじゃわ

これを自動化するにはリフレクションが要る

それはそうとして、
　1. オブジェクト側をラップする
というのと、
　2. オブジェクトと癒着
は別の話じゃわ；

1は標準的なshared_ptrの実装ではそうなっている（counted_refという名前のクラスは実在の実装から拝借したものであって漏れの独創ではない
だいたい
>[a]はインスタンスaにつき唯一だが、[a]を参照するsumapo<T>は複数有り得る。 (>>628)
なので、参照カウンタを所有するのはオブジェクト側をラップした[a]以外ありえんのじゃわ
[a]を参照する全てのsumapo<T>は、[a]より長く生き長らえることは無い

2はsumapo<T>にとっては必要だが、shared_ptrには要らん

646 ：
ちなご興味のお有りの方にカミングアウトすると、>>623のコードのSUMAPO_ONマクロを0にすると
sumapo<T>は普通のshared_ptr<T>になりぬ
動作やコードを比べて見られるのも一興かと、

647 ：
ちな(2)、
>「pa→[a]==>pb→[a]、という参照関係」のpbをweak_ptrで実装しろというのが現行の仕様だが(>>630)
これは、ちげう

weak_ptrを使って[a]の解放の根がpaのみであることを証明できるのは、実際に[a]を解放したときに限られるが
もし[a]の解放の根がpaだけではないと反証されたら[a]を解放してしまった後で藻前責任とれんの…？

一方sumapo<T>はそんな迂闊なことはせず、解放「前」に証明を試みるんである

648 ：
>>639
だから頭pythonだと言ったろ
俺がこれ遅くねえかって言ったら頭ひねった結果理由がわからんと言ってきた
俺が作り直してやったら速度が倍増したけどHTTPリクエストするだけでメモリを数十MB使われたからPythonもクソだわ

649 ：
>>648
> 俺が作り直してやったら速度が倍増したけどHTTPリクエストするだけでメモリを数十MB使われたからPythonもクソだわ
頭の悪い知ったかに絡まれるPython可哀想 w
低能しかいない職場なのかよ

650 ：
>>645-647
なるほどお前が何も理解してないのは分かった。

> これを自動化するにはリフレクションが要る
これは違う。
仮にリフレクションがあったとして、何をどうするか説明してみろ。
お前には出来ないから。

> weak_ptrを使って[a]の解放の根がpaのみであることを証明できるのは、実際に[a]を解放したときに限られるが
> もし[a]の解放の根がpaだけではないと反証されたら[a]を解放してしまった後で藻前責任とれんの…？
これも違う。
お前はweak_ptrの仕様を理解していない。
お前の言い分だと、「現行の仕様では循環参照を実装出来ない」事になるが、
これは明確な間違いだろ。
お前はこんな当たり前の事すら理解出来ないほど馬鹿なんだよ。

そもそも、
> 標準ライブラリに入っていないのは、(2)の証明コストがｲﾏｲﾁかかるからだろうＪＫ (>>628)
これ自体が間違ってるんだが。


もう君は相手にする価値のない馬鹿ということでいいかな？
JavaScripterなんてこの程度の馬鹿しかいないし、お前もそうだ、でしかない。

651 ：
unique_ptrの所有権ってnewとdeleteは任せろ、アクセスはご自由にどうぞという解釈でいいですか？

652 ：
MFE

653 ：
よくわからんがﾘﾌｧﾚﾝｽｶｳﾝﾀがｾﾞﾛになったら解放するしょうもないﾌﾟﾛｸﾞﾗﾑか
MSのCOMもそんなんだったような覚えがあるわ

654 ：
10年ぶりにC++に戻ってきました。
C++11/14/17なんて出てたんですね。
これってもうstableですか？
普通に使っても大丈夫？

655 ：
なにを基準にstableなんだか
古い時代のコンパイラ使っていたら一生stanbleにはならんよ

656 ：
>>654
stableにはさせん、させんぞぉ！
という層でC++は出来てる

常に進化するので、それに付いていけないB級はいらない
なので、あなたは使わなくていい
使いたいか、そうでないか、人に聞く前に自分の欲望で決めるのがC++だ

657 ：
>>656
C++0Xと騒がれていた時代のC++03のように
スタンダードなレベルに普及しているかという
趣旨の質問でした。

調べてみたらC++11くらいなら主な実装系で
サポートできているっぽいですね。
新規案件では採用してみたいです。

Web界隈は新し物好きの若者が多くて
勝手に栄枯盛衰していくコミュニティですが、
C++は化石みたいな人が多い空気があるので、
C++11以降、コミュニティが追従しているのか
ちょっと心配ではあります。

658 ：
>>657
最新をどんどん使うという雰囲気ではないけど、C++11 は人権というくらいには言ってよいと思う。

659 ：
出口の見えない長いトンネルをやっと出た
それがC++11だね

660 ：
トンネルを抜けるとそこは針地獄でした。これまでの法則は通用しません

661 ：
どこが針地獄なんだよ

ちょっと想像しにくいが
C++11の新機能がまったく使えないという
想像を絶するアフォいるのか？

662 ：
このスレにいる気がする

663 ：
良く、拡張子cppでCのコードしか書いてないファイルあるけど、あれってC++のコード書いても動くもの？
コンパイラはC++だよね？

664 ：
配列初期化子が書けるかな？

665 ：
仮引数リストが空の場合の解釈が違ったりとか、
文字リテラルや文字列リテラルの型が違ったりとか、
地味な非互換はいくつかある。

そのあたりを踏まなければおおよそ大丈夫。

666 ：
>>657
お前含めてWeb界隈、特にJavaScriperには馬鹿しかいないけどな。
これは印象ではなく、事実な。

何を使うかはお前が決めればいいだけ。
実際、Go/PHPではstableですか？なんて聞く馬鹿はいないだろ。
この違いを理解出来ないのはJavaScripterが馬鹿な証拠。

667 ：
>>663
動くと思うけど、
標準仕様にファイル名の規定はなく、どのコンパイラが使われるかはあなたのプロジェクトのビルドスクリプトの設定次第だよ

>>666
私はjs使えませんアピールしてんの？

668 ：
657が煽りっぽいからしょがない
C++使えてJS使えない奴なんかいないだろ

669 ：
>>667
> 私はjs使えませんアピールしてんの？
そりゃお前だろ。

お前が本当にJavaScriptを使えるなら、今のJavaScripterがどれだけ酷いか知ってるはず。
そしたらそんなことは到底言えないだろ。
実際のサイトのコードも大半がゴミだし、JavaScriptのスレで定期的に盛り上がる話題は

・変数の初期化前の挙動を理解するべき　←　そんな必要ない、C#ならSyntaxError
・セミコロンはどこに打つべきか　←　アホか？C++ならSyntaxError

なんだからな。
あいつらがデータ構造について議論した試しがないし、それ以前にOOPも理解していない。
だからあいつらの定義では、

・上級者＝新しい文法を使いこなせる人

となり、657や667みたいな投稿が発生する。
(要はJavaScripterは657,667含めて全員ゴミってだけだが)
C++の連中はそんなこと思ってないから、新文法も必要なときに使うだけであって、
必要ないと判断してるから使わないだけ。
積極的に使わないといけないと考えること自体が間違ってる。
C/C++の歴史は長いから、最低限必要な物は既に整備され尽くしてる。
(JavaScriptやPHPみたいなヘルパースクリプト出身ではない)

670 ：
必要最低限はCだけでも既に整備されているので正しい

671 ：
>>669 新文法を必要ないと判断しているということはautoやrange-based forとか使ってないの？

672 ：
古参でも理解できるプログラム書かないと仕事にならない場合もあるから
最悪C++使わないでC言語オンリーになる場合もある
というかC++自由に使える仕事の方が少ないよ

673 ：
C++の仕事にCしか書けない人が参加するのはありなのか？

674 ：
>>666
あなたが無知すぎるでしょ。
趣味で使うのならばなんでも好きなの使えばいいが、
実務で使う場合は周りのことも考慮する必要があるのです。

PHPやPythonでStableというのは
公式インタプリタが正式リリースされたということ。
コミュニティも追従して最新に対応する。

C++の場合、影響力ある実装系がたくさんあるせいか
Stable化するタイミングが分かりにくく
コミュニティも追従してこない。

675 ：
>>669
あなたのいうJSはどのJSですか？
ES5ですか、ES6ですか、ES2016ですか2017ですか
はたまたCoffee Scriptですか、Type Scriptですか

一括りに語ってる時点で何もわかっていない。

676 ：
JSとC++では処理系が多数あるという点では状況が似ていると思う。
C++にもトランスパイラが必要かな。

677 ：
>>674
> 趣味で使うのならばなんでも好きなの使えばいいが、
> 実務で使う場合は周りのことも考慮する必要があるのです。
じゃあここで聞くなよメンドクセエ奴だな。

お前が決められる立場なら勝手に決めろ。
ただ、その程度で実務でグループ開発する際に決められる立場にあるとは思えないし、
仮にそうならよほど酷い職場だとしか。

> コミュニティも追従して最新に対応する。
Python3やPerl6見てそう思うのなら頭おかしいだろ。
PHPもいまだに5.4とかだったりするのも俺には謎だが。
(まあ何か理由はあるのだとは思うが)

> C++の場合、影響力ある実装系がたくさんあるせいか
ダウト。組み込み等で選べない場合はそれを使うしか無く、
選べる場合はMSVC/gcc/Clangの3つしかないだろ。

> コミュニティも追従してこない。
だからそういう問題じゃねえんだよ。
お前がどのコンパイラを使うか、それを決めればいいだけなんだよ。

逆にお前が勘違いしている「コミュニティの追従」があったら何が嬉しいんだ？


>>675-676
スレチ

678 ：
>>677
お前世界狭いな
本当に仕事してんのか？

679 ：
>>677
お前もダウトだがな。
>MSVC/gcc/Clangの3つしかない
こいつらバージョンが違えば全然違う実装と言っていいくらい違うぞ。
最近はもうバージョン違えば動作違うなんて当たり前なんだから使う方が気を使えやって
立場が多いのかね。

680 ：
>>679
> 最近はもうバージョン違えば動作違うなんて当たり前なんだから使う方が気を使えやって
> 立場が多いのかね。
自前でガチで組むならコンパイラのバージョンは基本固定だろ。（必要ない限り上げない）
OSSなら基本は最新バージョン追従で、逆に旧バージョンなんてシラネでいいだろ。
(そもそもコンパイラのバージョンが上がって問題になるケースも希だが)

むしろお前はどんな環境でやってるんだ？

681 ：
＞そもそもコンパイラのバージョンが上がって問題になるケースも希だが

そ・れ・が、
cuda9 はコンパイラ(VS2017) のバージョンが上がって、さっぱりコンパイルできない有様なんです…

682 ：
>>681
それはcudaの問題で、C++側の問題ではないのでは？

もっとも、cuda環境なら俺なら当然コンパイラもcudaのバージョンも固定、
可能であればディスプレイドライバも固定で行くが。

cudaのOSSなら、それは最新版追従しかないし、
それで旧コードが駄目ってのなら、それはstableではないとしか。
ただcudaの場合はかなり特殊だからなー。
DirectXも「互換性？なにそれおいしいの？」状態だったらしいし。
あの辺は抽象化されてないからどうにもならんでしょ。
むしろ抽象化コストを嫌っているわけだし。

683 ：
>>682
VS2015 を今でも使わせてもらえるのなら、もう VS2015 は固定されているので、それでいいのですけれども…今はVS2015は「一般には」公開されていないようです
VS2017 は、なにかを追加するために MS にアクセスすると、ついでにコンパイラのバージョンもあげてしまうのです
もとに戻すのを繰り返しましたが、もう疲れました…

というか、Linux では cuda は gcc を使っているようですから、Windows でもそうしてほしいのですが…

684 ：
>>683
> VS2017 は、なにかを追加するために MS にアクセスすると、ついでにコンパイラのバージョンもあげてしまうのです
なるー。自動アップデートR、って奴か。
それはかなり厳しいね。

回避するには、自前でVS2015マシンとVS2017マシンを分けるのが一番手っ取り早いだろう。
これが無理なら、試しにユーザアカウントを別にしてみればどうだろう？
(VS2017のアップデートも別人に対しては有効化されないだろと予想）

無理なら、、、確かnVidiaはdockerを用意するとか言ってなかったっけ？
Win10ならdockerはデフォで対応してたはずだし。

(つっても俺はcudaは2.2-4.xの頃しか使ったことがないので、現在の状況は詳しくは知らない。
まあ君なりに努力しての結果なんだろうとは思う。話が全然ずれてたらすまん）

685 ：
関数に引数として渡せるような多次元配列ってどうやってこしらえるのがベストプラクティスなの？
eigenとかは使いたくない
STLなら使える


サイズがコンパイル時に決まってたりはしない予定

686 ：
vector配列の配列はどう？

687 ：
>>686
みんなそうしよるん？

688 ：
>>687
目的によるんじゃね？
行or列が揃わなくていいならvector<vector<…　でもいいわけだし

689 ：
結論としては場合によるとしか言いようがないでしょ。
だいたいの場合にこれを使っておけばベストだわって言える方法はないと思う。

コンパイル時には決まらないって言ったって、
オブジェクトを構築した段階では決まるのか、
後から拡張 (縮小) することもあるのかでも判断は変わるだろうし。

ライブラリがユーザに見せる API なら抽象化されたクラスを用意した方がいいけど、
そうでもない内部的なものならポインタひとつと整数ふたつを渡すデザインでも用は足りるし。

690 ：
>>687
そもそも行列がスパースかどうかで実装が異なるのが普通。
密で、行も列も長さが変わらんのならどんな持ち方しても大して変わらん。

691 ：
配列って書いてあるのにスパースとか

692 ：
物によってはunorded_map使うのもありかも。

693 ：
>>691
世の中にはスパース配列という用語があるんだが w

694 ：
だからなに？

695 ：
>>688
vector でやるという人は多いようです
真似してみます


>>690
スパースでないです

696 ：
>>694
ああ、指摘されてもわからない人なのか
それとも引っ込みつかなくなった人なのか

697 ：
1ﾚｺｰﾄﾞが可変長の列でもない限り
vectorのvectorとか愚の骨頂
頭ﾜﾙｲ

698 ：
ﾚｺｰﾄﾞ作るたんびに激しいﾌﾗｸﾞﾒﾝﾃｰｼｮﾝがおこるﾋｰﾌﾟをﾎﾟｺﾎﾟｺ作るとか
頭が超ﾜﾙｲﾊﾞｶがやることです

よいこのみんなはｺｺにいるﾊﾞｶなﾔﾂﾗのﾏﾈはしないようにな

699 ：
サイズが決まってないなら可変じゃね？

700 ：
はっきりいってな
行列ならvector1個で十分だからな

ﾊﾞｶ以外にとっては常識

701 ：
vector使う事を否定はしないんだね？

702 ：
否定はしてない

行と列が可変な行列は
vector1個で十分といってる

m*nの列数の列を最初に先行してﾒﾓﾘｱﾛｹｰｼｮﾝしたほうがいい
そのあとdata()で戻ってきたﾎﾟｲﾝﾀつかっていじくり倒せばいい

とりあえず行毎にﾋｰﾌﾟを作る意味がまず皆無

703 ：
すいませんめんどくさがりなんです。

一次元配列を二次元以上の配列に見せかける形にするという事か。
width * y + xみたいなアクセスね

704 ：
>>673 C言語オンリーのリナスとかめっちゃ有能やろ
言語習得能力と技術力はまた別の次元の話や

705 ：
トーパルズ君は孤高の天才だからな
同レベルでもなきゃチーム組んでもうまくいかなさそう

706 ：
array<array<int, 3>, 4> dimdim;

707 ：
片方の長さが固定ならvector<array>でいいしだいたいそれで事足りる

708 ：
無駄が多い
メモリは1次元で確保しようぜ

709 ：
valarray[slice]

710 ：
C++標準ライブラリに多次元配列が無いのが悪い

711 ：
boostのmulti_arrayが標準ライブラリに入るのまだ？

712 ：
まだ

713 ：
それぞれの用途ごとにクラスを作るのがいいのかもね
パフォーマンスを考えると

714 ：
>>710
なければ作れよ
http://d.hatena.ne.jp/pknight/touch/20100330/1269945131

715 ：
パフォーマンスを考えると

の書き込みの後にパフォーマンス最悪なコードを貼る神経

716 ：
アンカーも知らんのか w
お前になんてレスしてない

717 ：
誰へのレスとか関係あるかなあ
初心者コードを貼る神経

718 ：
鬱憤晴らししているんだろう

相手して欲しいだけだよ

719 ：
機能拡張しろとか言う前に自分の頭が足りないのだから素直にJavaでも使うべき。

とくに自分でリソース管理できない馬鹿は。

720 ：
javaは大嫌い

721 ：
>javaは大嫌い

本当にひでぇ回答だなw

722 ：
>>717
だからお前にレスしたわけじゃねーからいちいち絡んでくるなよ、気持ち悪いわ

723 ：
自分がコード貼らない言い訳してるだけだろ
気にすんな

724 ：
>>714のコードは[y][x]式の要素アクセスをしたいというだけのために
arraysクラスにarrayクラスのメンバを持たせているあたりがｲﾔｿ
これがために、[y][x]式の要素アクセスがたとえリードアクセスであってもスレッドセーフでなくなる
パフォーマンスは>>702案と比べて言うほど悪くはないが、

725 ：
言うほど悪くない？
悪すぎだろ

ボロいコンパイラだと特に

726 ：
パフォーマンスを気にするときは
乗算すら除きたいわけで

727 ：
>>725
ちょっ乗算なら>>702案にもwidth * y + xみたいなアクセスという形で含まれる件について：
widthを定数だとコンパイラが認識した場合は、単純な>>702案の方が最適化が効いてシフト演算なりになる可能性が高いが

728 ：
>>724
まあ、かなり無理矢理感があるのは事実
俺には他にいい方法も思いつかないけど

>>726
メモリーアクセスに対して乗算が問題になるケースってかなり減ってると思うけどな

729 ：
>>728
そうか？画像を90度回してみてくれ

730 ：
スペック上げて殴れ

731 ：
殴らなくてもモニターを横にすればいいだけじゃ

732 ：
画像を90度回すつもりで
for (py=0; py<height; py++) {
for (px=0; px<width; px++) {
dst[px][py]=src[py][px]
}
}
と書いたとしたら、ループ内ではwidth、heightともに定数とみなせるからループ最適化が効いて
dst、srcとも要素特定演算が加算のみになる可能性が微ﾚ存、
この点>>702案に対して>>714のoperator[]はボロいコンパイラの場合は最適化機会を見逃す危険性は高いが
コンパイラからみてarrayに対する副作用がわからない関数呼び出しは含まれないから、原理的に最適化不可能というほどではない。

733 ：
ていうかこれで良くね？
ttp://codepad.org/2sMvNgye

734 ：
>>729
何を言いたいのかさっぱり

>>733
だからそれでいいかどうかは>>689も書いてる通り要件による
メモリーが連続でないとヤダっていう要件があるかも知れんし

735 ：
ていうか>>706にすでに書いてあったorz
ただ行や列の追加をしたいという場合は>>706では済まなくて、相応のコピコンを備えた独自クラスでのwrapが多分必要
（データを引き継ぎつつ、異なる行数や列数のオブジェクトを新たに作るコピコンを設ける

736 ：
やっぱりな知恵遅れのﾊﾞｶどもはなにも分かってないわ。。。

演算処理で一番ﾎﾞﾄﾙﾈｯｸになるのはﾒﾓﾘｱｸｾｽだからな
高速な演算をしたいのにﾒﾓﾘをあちこちﾊﾞﾗﾊﾞﾗに配置する知恵遅れはいない

局所参照性を無視して乗算がどうこうといってるﾚﾍﾞﾙだからな。。。
知恵遅れたちにはCPUのｷｬｯｼｭという概念がない

vector1個のほうが
ﾒﾓﾘﾌﾗｸﾞﾒﾝﾃｰｼｮﾝもおきにくいし
このｽﾚのﾊﾞｶどもがどうこういってる演算においても激しく有利だからな

良い子のみんなはこのｽﾚのﾊﾞｶどもがいうことなんか
ﾏに受けたりしたらﾀﾞﾒだからな

ｵﾚの書き込みだけ信じればいい

737 ：
ttp://codepad.org/2sMvNgye
↑ｱﾎが書いた典型的なｻﾝﾌﾟﾙ

良い子のみんなはﾏﾈしないようにな
こんなｱﾎがいるというｻﾝﾌﾟﾙになってる

http://d.hatena.ne.jp/pknight/touch/20100330/1269945131
↑同じｱﾎでもまだこっちのがﾏｼ

あいかわらずｵﾚのﾚｽは
いつでも針の穴を通すようなｶﾝﾍﾟｷなﾚｽだ

738 ：
つ valarray

739 ：
>>736
行列のrowを個別のstd::vector<T>とすることによる局所参照性の劣化は
ラスタスキャン順アクセスにおいて第i行から第i+1行に改行する時のみに限られる
（特にたまたま行列の横幅がキャッシュラインサイズの倍数でありかつ行がキャッシュラインに整列しているならば、何のペナルティーも生じない
ランダムアクセスならどっちもどっちになるからでかい配列の場合は言うほど気にしなくて良いんじゃ…

740 ：
パフォーマンス優先なら

メモリは連続
要素へのアクセスはシンプルに

[][] にこだわる必要はない
(x, y) や [座標] なども考える

乗算が遅い環境なら
要素数は2^nの形にするとか位置をキャッシュするとか
固定座標の処理で良いものはコンパイル時に決定出来るようにとか

741 ：
コンパイラをあてにするなら
生ポが一番最適化が効く
このスレだと拒否反応を示す人がいるだろうマクロを使うとか

742 ：
MTPでコンパイルタイムに押し込めー　わぁい！

と、5,6年前にやったときは8x9行列ぐらいで
gccのテンプレート展開の限界になった記憶がある

743 ：
LINUXで15GBくらいのテキストファイルを読み込みこんでGUIを作ろうとしています。
ファイルが大きいため速度が出せる言語で、かつGUI作成は情報量が多いと調べやすいので、まあまあメジャーな無料のGUIライブラリを使用したいと思っています。

perl>>python>>>>C++　の順で経験があり、C++はあまり詳しくないですが、速度重視でC++で行こうと検討しています。
GUIライブラリを調べているのですが、C++のGUIはあまり情報を見つけられず、めぼしいのはQtくらいしか目に付きませんでした。
会社のサーバのローカルディレクトリにQtをインストールしてみましたが、必要なライブラリが古かったりで、インストールできませんでした。

他に何かおすすめなGUIライブラリはありますでしょうか？

744 ：
公開しないならQtしかないしいつまでも古いライブラリを入れておくな

745 ：
imguiはどう？

746 ：
GUIはTkライブラリをPerl/Pythonで作り、重い処理はC/C++プログラムとプロセス間通信と行うのがいいんじゃないですかね。

747 ：
15gbのデータはguiでeditするの？
それともread onlyな入力データ？

748 ：
個人的にはwxWidgetsを推す

749 ：
どんなテキスト？
完全な自由フォーマット？

750 ：
15GBだと読み込みだけで分単位の時間がかかる

UIも難しい
巨大テキストからどうやって表示箇所を選ぶ？
スクロールバーとページめくりだけじゃ目的の箇所を探せないよ
行番号指定ジャンプ？

15GBだとメモリコピーでも秒オーダーの時間がかかるから
1文字入力するごとに後ろをずらすなんてことも出来ないから
データの持ち方も工夫しないと
そもそもメモリに収まりきるのか？
RAMは何ギガ？

751 ：
サーバーって事だから、いっそ使いやすい型式でDBに格納し、
Web画面で表示するっていうのはどうだろう
グラフィック表示はクライアント側に任せてしまう

752 ：
全部で15GBのテキストじゃないの？
流石に1個で15GBは…　円周率のテキストファイルとかならあり得るか

753 ：
mmapかねえ

754 ：
>>744-753
色々な情報ありがとうございます。

>>744
gccなど単体でインストールできるものはローカルディレクトリに最新をインストールしたのですが、
Qtに必要な何かのライブラリの最新版をインストールするのに文字コードがc.utf8が必要なのですが、
今はja_JP.UTF-8しか選択できず、新しい文字コードを使うにはrootでの文字コード再生成が必要なため全体への影響を考え一旦保留としています。

>>745,748
候補としてちょっと調べてみます。

>>746
PythonならCython＋Kivyで直接取り込もうと検討しています。
その場合、CythonがどこまでC++の速度に迫れるかの調査から始める必要があるのですが…
少し調べたらCython内で直接C++コードを書ける云々とあったからそれだと速度はクリアできるのかなぁ？というところで一旦ストップしています。
これは深い話するとちょっとスレチな内容になってきますね。。
ちなみに今回作ったものをTCP通信で別のプログラムに接続して使用する予定です。

>>747
Read Onlyで読み込み時に演算したりarray、unordered_map、構造体などに放り込んだりして加工して取り込んだあとは参照のみです。
751さんの話は一旦形式をDBで保存しそれを参照ですが、それに近い感じで使いやすい形式に変換したものをメモリに格納し参照するイメージです。

755 ：
つづき

>>749,750
固定フォーマットです。
メモリはサーバなので数百GBはあります。

>>752
1ファイルなんです。。
解析ソフトから出力された結果です。

>>753
mmapぐぐったらI/Oがネックなときに効果が期待できるものなんですね。
今調べてわかったところでは、

[1-1] fgetsのみ→30秒以下
[1-2] ・fgets, sscanf, fscanfを組み合わせてフォーマットに沿って読み込む→約5分

だったので、scanの変数格納が支配的になりそうなので、次は下記を調査しようと思っています。

[2-2] freadでバイナリで読み込んで空白、改行を判定しながら必要なところだけ文字列や数値に変換すると早いか？
[2-3] fgetcで空白、改行を判定し直接charに入れて行くと早いか？↓
char a[1024];
i=0;
while ( (a[i]=fgetc(fp)) != EOF){
　if(a[i] == " "){
　　a[i] = "\0"; //\0を入れるとそこまでをcharの文字列として扱ってくれる？？
　　break;
　}
　i++;
}

756 ：
あとは下記URLの「ファイルは一括で読み込め」の読み込み速度はどうかも調べてみる予定です。

ttps://qiita.com/kotauchisunsun/items/84e01c6fb621fcc1a647

それと下記も高速化のコーディングの参考にしようかと。

ttps://heavywatal.github.io/cxx/speed.html

757 ：
読み込みと解析は別スレッド
解析はマルチスレッド
関数は専用化
AVXなどのリッチな命令を活用する
キャッシュを効率的に使う(何度も全体スキャンしない)

一般的な効率化技術

758 ：
fgetc, scanf, printfのような激遅関数は使わない
ファイルは大きな単位で読み込む (MB以上)

759 ：
>>758をまずやって
>>757はそのあと考える

760 ：
ssd使え

761 ：
15GB 30秒ってことは
HDDから読んでるわけではなさそう
キャッシュかSSD

762 ：
まずは激遅でもいいからperlのGUIとDLL呼び出しで一通り動くものを作った方が良さそう

763 ：
メモリ数百あるんなら、展開した後のデータ構造工夫しろ。
数ギガ読めるテキストエディタを夢想してみれ。

764 ：
数ギガを一気読みでオンメモリとか蹴り入るな

765 ：
コンバート系アプリだと専用端末だったりするしよくある

766 ：
まず固定長なら1行のﾊﾞｯﾌｧから読みこむだけの仕組みを作ってからの話になる
はっきりいって固定長のﾚｲｱｳﾄに従って読みこむだけだからな

読みこみ処理の最適化なんかその後の話になる

固定長でなにをそんなに手こずってるのか意味が分からないしな
ﾚｺｰﾄﾞのｻｲｽﾞはきまってるのに

fscanfとか書いてるということは末尾に改行が入ったﾚｲｱｳﾄなのはなんとなく推定できる

ﾚｽを読んでもそもそも1ﾚｺｰﾄﾞのｻｲｽﾞが何ﾊﾞｲﾄなのか分かってて作ってるのかどうかすら怪しい
ﾌｧｲﾙｻｲｽﾞをﾚｺｰﾄﾞｻｲｽﾞで割ってちゃんと整数になってるかとか確認してるのかどうかすらも怪しいからな
ﾌｧｲﾙｻｲｽﾞだけ書いてﾚｺｰﾄﾞ数すら書いてないしな

とにかく頭悪いﾔﾂがしょうもないことで四苦八苦してるのは分かる

767 ：
色々ご意見ありがとうございます。

まずは>>759さんのおっしゃるように、>>758さんのケアをしようと思うのですが、今のfgets+sscanfの組み合わせは下記URLを参考にしたのですが、
どれが激遅でどれが高速かの情報はどこかにあったりしますでしょうか？
（試そうと思っていたfgetcは遅いんですね…）

ttp://d.hatena.ne.jp/s-yata/20100726/1280138663

読み込み時に必要なのは、改行の判定、文字列の判定、int型で読み込んで0.025や0.1などを掛けてfloat型で保持（おそらくこれが一番多い処理）、と考えています。
ちなみに入力フォーマットは、ここから何行は文字列、ここから何行は数字の列(intに掛け算しfloatで保持したい)、という感じになっています。
最適な関数はどんな組み合わせが考えられますでしょうか？

STRING 2
AAA BBB
CCC
INT_TO_FLOAT 10
100 100 110 110
101 101 200 200
～あと8行

768 ：
知恵遅れはそれを固定長とかいってんのか
なるほどな

まず知恵遅れとは語彙の一致が成立してない

769 ：
一行に存在する文字数は固定されておらず、文字列の方は文字数や空白は関係なしに単純に行数分読み込むだけで良いです。
数字の方も桁数は固定されていませんが、空白区切りの4カラムと固定されています。

STRING 3
This is pen.
hoge piyo
hello world.
INT_TO_FLOAT 9
12345 1000 10 12
101 101 999999 444
～あと7行

770 ：
少しは自分で考えろよこのバカ

771 ：
>>768
固定長フォーマットとは言ってないな

772 ：
1行目はisspaceでぐりぐり回して
SPを\0でおきかえればｵｼﾏｲ
ｺﾚでﾊﾞｯﾌｧの先頭のﾎﾟｲﾝﾀで文字列が拾える
行数は\0のﾎﾟｲﾝﾀを1ﾊﾞｲﾄ分進めて
そのﾎﾟｲﾝﾀをstrtolに渡せば拾える

2行目以降の数字は
strtolやstrtodで空白に到達したら、
その到達した位置のﾎﾟｲﾝﾀが引数で拾える
数値も拾える

2行目以降の文字列は省略　
池沼でも拾える

ここまで書けばどんなﾄﾞｶﾀでも作業はできるﾊｽﾞだ

773 ：
テキストのパースなんてそれこそperlやpythonにやらせろよ
そんなところが速度にクリティカルに効いててゴリゴリ高速化しなきゃいけないのは作りがおかしい

774 ：
>>768
質問者が固定長なんて書いてた？
固定長と言い出したのはあなたでしょ？

775 ：
>>767
読み込み以外、ライブラリなんか使わずに全て自分のコードにしてみようか
そうすれば色々とわかるはず
読み込みは16MBずつとかにすれば速い

出力先はファイル？メモリ上？
数値は32bit floatで保存するとして
文字列は？
そのままの形で使う？
読み飛ばす？

776 ：
>>772
お前何年前のゴミSEだよ
古代文字解析みたいな手法揚げやがって
lexical analyzer 系統使うだろ

777 ：
SQLite はメモリ上にDBを構築できるので試してみるのもいいでしょう。
起動時のテーブルの初期化が大変だけど、あとはサクサク。

778 ：
な、知恵遅れたちはﾃｷﾄｰなことばっかりいってる
こんなｺﾞﾐみたいなｺｰﾄﾞで速攻でかけるのに

779 ：
ｺﾞﾐはめちゃくちゃしょうもない簡単なｺｰﾄﾞを
いちいち複雑にする

そしてもだれもﾒﾝﾃﾅﾝｽできなくなる

780 ：
自分への間違い指摘は全部無視するのが半角スタイル

781 ：
ｵﾚはなにも間違ったこと書いてない

782 ：
数値の行は以下みたいなドロくさい処理を4回繰り返せば良い

unsigned int n = 0;
do {
unsigned char ch = (unsigned char)(*data++ - '0');
if (ch <= 9)
{
n = n * 10 + ch;
}
else {
break;
}
} while (true);

783 ：
サーバーなんだから、普通にDB使えるだろう

784 ：
だいたい分かるわ
やっぱりなPGなんか低学歴しかやらない

785 ：
単に統計情報が知りたいだけならわざわざ重くしてから処理をする必要もないし
DBに入れるにしても解析しないとダメだろ

786 ：
たとえば1行目なんかこんなしょうもないのでとれる

int get_type(unsigned char const* buf, t_baka_type_t* pt_baka_type_t, unsigned char const** pct_next) {
unsigned char const* c_buf = buf;
for (; !isspace(*c_buf); ++c_buf) ;
if (!::strncmp((char const*)buf, TYPE_STRING, c_buf - buf)) {
pt_baka_type_t->baka_type = BAKA_TYPE_STRING;
} else if (!::strncmp((char const*)buf, TYPE_INT_TO_FLOAT, c_buf - buf)) {
pt_baka_type_t->baka_type = BAKA_TYPE_INT_TO_FLOAT;
} else {
fprintf(stderr, "Rｳﾞｫｹ\n");
return -1;
}

pt_baka_type_t->u_records = strtoul((char const*)c_buf, (char**)&c_buf, 10);
++c_buf;

*pct_next = c_buf;
return 0;
}

はっきりいってな、2行目以降の数値も文字列もやりかたなんか同じだからな
ﾄﾞｶﾀ作業

787 ：
ｺﾞﾐは口だけは達者
しかもｱﾘｴﾅｲ頭ﾜﾙｲことばっかりいうからな

788 ：
わざわざ標準ライブラリを使うために小細工しなくても良いんじゃないの？
何がどういう順番で書いてあるかはわかってるようだし無駄に重くしなくても

789 ：
きっとなｵﾏｴが書いたｺﾞﾐｺｰﾄﾞより標準ﾗｲﾌﾞﾗﾘのほうが
ﾊﾞｸﾞもないし早いと思うわ

790 ：
いかにもバッファはみ出してそうなきったねえコードですね
いまどきポインタで文字列処理すんじゃねえよ老害

791 ：
な、知恵遅れはこんなとこで書いたｻﾝﾌﾟﾙに
ｴﾗｰ処理が入ってると思ってる

もうねｺﾚだから低学歴は困るわけ

792 ：
日本のPGは低学歴しかいないのが
このｽﾚで何度も証明されてる

793 ：
学歴コンプか？

794 ：
低学歴に反応してるということは
図星なんだろ

もう分かってるからな

悪いけどなﾚｽみれば低学歴なのは
残念ながらすぐに分かってしまう
低学歴特有のﾚｽというのがある

隠そうとしてもﾑﾀﾞ

795 ：
ポインタいじくり回してメモリ境界踏み壊すコードを書くのが大好きなすうぱあぷろぐらまあ様は
無駄な高学歴の方が多いという個人的な印象

796 ：
あのﾚﾍﾞﾙでﾎﾟｲﾝﾀいじくりまわしてる？
どんだけｵﾂﾑが弱いねん・・・

797 ：
ようするにﾎﾟｲﾝﾀが理解できてない
こんなのがﾌﾟﾛｸﾞﾗﾏさまきどってるのが日本だからな

そらなこんなのがｺｰﾄﾞいじくってたら
障害ばっかりおきるﾊｽﾞだわ

798 ：
未だにこんな化石みたいなヤツが居たことに驚きなんだが

799 ：
>>786みたいに、何度も何度もスキャンするような無駄の多いコードが速いわけないだろ

800 ：
低学歴は自分を大きく見せようとするからな
5f34-M0Jq　←　ｺｲﾂなんか典型的といっていい

わかってしまう
きっとｺｲﾂは専門卒
残念なことにﾚｽみればすぐに分かる

だてにいままでいろんなｺﾞﾐを相手にしてきたﾜｹではない

801 ：
何度もｽｷｬﾝ？
一回しかｽｷｬﾝしてないぞ

まずｺｰﾄﾞがよめてない
ﾎﾟｲﾝﾀは後ろにしか進んでないのに

802 ：
strncmpが中で何やってるか知らないんだねかわいそうに

803 ：
あ
もしかして
必要な1回の文字列判定を何度もｽｷｬﾝとかいってるの？

804 ：
低学歴によると
通常の字句解析と構文解析を一緒にするのか
なるほどな

805 ：
たくさんの情報大変参考になります。
サンプルコードもありがたいです。
実際に動かしながらどう動いているのか調べてみます。

>>775
読み込みを16MB単位でやってみます。
ファイルに出力することはなくて、読み込んだ情報をGUIでクリックして、
こっちをクリックするとこんな結果になっている、こっちだとこの結果、
というようなビューアを作ろうとしています。
文字列も重要な情報なので、
struct info{

806 ：
それならそもそもファイル全体を解析しておく必要もないのでは？

807 ：
よしｵﾏｴはいい子のようだから
STRINGの部分をとるｺｰﾄﾞもあげよう

int get_data_string(unsigned char const* buf, t_baka_type_t const* ct_baka_type, unsigned char const** pct_next) {
　　unsigned char const* c_buf_b;
　　unsigned char const* c_buf_e = buf;
　　for (uint32_t i = 0; i < ct_baka_type->u_records; ++i) {
　　　　c_buf_b = c_buf_e;
　　　　for (; *c_buf_e != '\x0a'; ++c_buf_e) ;
　　　　// c_buf_b から始まる c_buf_e - c_buf_b の長さが取得する文字列
　　　　fprintf(stdout, TYPE_STRING":%.*s\n", c_buf_e - c_buf_b, c_buf_b); // ←　ｺｺでとれる
　　　　++c_buf_e;
　　}

　　return 0;
}

808 ：
>>786
入力が不正の場合にメモリフォルト起こすコードは絶対受け付けられない

809 ：
だね

810 ：
ﾊﾞﾘﾃﾞｰｼｮﾝﾁｪｯｸは自分で入れるにきまってるだろ
ｱﾎちゃうかｺｲﾂﾗ

811 ：
そういうﾚｽしかできないからな
程度が知れるわけ

低学歴らしい

812 ：
言い訳が見苦しい

813 ：
いいわけ？
ﾏｼﾞでいってるわけ？

ﾎﾝﾄな頭悪い

814 ：
典型的な低学歴のﾚｽといっていい

815 ：
コードでも学歴でも何でも良いけど
勝負するなら受けるよ

816 ：
ﾊﾅｸｿがｵﾚとなんの勝負すんの

817 ：
日本語も読めないのか

818 ：
職場もこんな雰囲気？

819 ：
ﾊﾅｸｿは
学歴も書いてないし
ｺｰﾄﾞも書いてない

で？

820 ：
低学歴知恵遅れは
ｺﾐｭﾆｹｰｼｮﾝ能力もｾﾞﾛに近い

そもそも唐突に
なにがしたいのか
なにがいいたいのか
意味が分からないﾜｹ

821 ：
いまどき自前の字句解析処理をCでポインタ使って書くなんて
バッファ境界のチェックとか面倒だし絶対ミスるからやめた方が良いって話なのに
いきなりエラー処理完全無視したコード出されてドン引きです

822 ：
どんびきするとかしないとかは
ｵﾏｴの勝手だからな

823 ：
>>821
ポインタも扱えないようなレベルならC++は使わない方が良い

824 ：
あんまりゴミだから自信満々なc1VUAguL0がコード貼ってるのに気が付かなかったな、ログ読み直しちゃったよ
学歴は書いてないみたいだけど

825 ：
>>820
勝負する気があるの？
ないの？
あるなら方法を決めるけど

826 ：
scanと解析に時間がかかるとかいってるから
ｵﾚはﾍﾞｽﾄﾌﾟﾗｸﾃｨｽをだしてる

827 ：
まず目的が理解できてないからな

828 ：
あれでベストか

829 ：
ﾍﾞｽﾄじゃないと思うなら
ﾍﾞｽﾄな方法はれよ

臆病者なんか

830 ：
勝負に目的ねえ
まあ別にやらなくても結果はわかるけど

831 ：
はよﾍﾞｽﾄなもんはれよ

832 ：
>>767を読めば>>786が糞なのがわかる

833 ：
やっぱりﾊﾞｶの限界というやつだな
ｵﾐﾔｹﾞだけはって寝よ

1行目とるﾔﾂ
さっきとかわらず

int get_type(unsigned char const* buf, t_baka_type_t* pt_baka_type_t, unsigned char const** pct_next) {
　　unsigned char const* c_buf = buf;
　　for (; !isspace(*c_buf); ++c_buf) ;
　　if (!::strncmp((char const*)buf, TYPE_STRING, c_buf - buf)) {
　　　　pt_baka_type_t->baka_type = BAKA_TYPE_STRING;
　　} else if (!::strncmp((char const*)buf, TYPE_INT_TO_FLOAT, c_buf - buf)) {
　　　　pt_baka_type_t->baka_type = BAKA_TYPE_INT_TO_FLOAT;
　　} else {
　　　　fprintf(stderr, "Rｳﾞｫｹ\n");
　　　　return -1;
　　}

　　pt_baka_type_t->u_records = strtoul((char const*)c_buf, (char**)&c_buf, 10);
　　++c_buf;

　　*pct_next = c_buf;
　　return 0;
}

834 ：
2行目以降のSTRINGとれるﾔﾂ
※　次のﾊﾞｯﾌｧの継続ﾎﾟｲﾝﾀの格納をしてなかったので追加

int get_data_string(unsigned char const* buf, t_baka_type_t const* ct_baka_type, unsigned char const** pct_next) {
　　unsigned char const* c_buf_b;
　　unsigned char const* c_buf_e = buf;
　　for (uint32_t i = 0; i < ct_baka_type->u_records; ++i) {
　　　　c_buf_b = c_buf_e;
　　　　for (; *c_buf_e != '\x0a'; ++c_buf_e) ;
　　　　// c_buf_b から始まる c_buf_e - c_buf_b の長さが取得する文字列
　　　　fprintf(stdout, TYPE_STRING":%.*s\n", c_buf_e - c_buf_b, c_buf_b); // ← ｺｺでとれる
　　　　++c_buf_e;
　　}

　　*pct_next = c_buf_e; // ← たりなかったので追加
　　return 0;
}

835 ：
2行目以降のTYPE_INT_TO_FLOATとれるﾔﾂ

int get_data_int_to_float(unsigned char const* buf, t_baka_type_t const* ct_baka_type, unsigned char const** pct_next) {
　　unsigned char const* c_buf_e = buf;
　　int32_t i_val[4]; // とりあえずのﾃｷﾄｰにいれた一時ﾊﾞｯﾌｧ

　　for (uint32_t i = 0; i < ct_baka_type->u_records; ++i) {
　　　　for (uint32_t j = 0; j < 4; ++j) {
　　　　　　i_val[j] = strtoul((char const*)c_buf_e, (char**)&c_buf_e, 10);
　　　　}
　　　　++c_buf_e;

　　　　fprintf(stdout, TYPE_INT_TO_FLOAT":%d,%d,%d,%d\n", i_val[0], i_val[1], i_val[2], i_val[3]); // ← ｺｺでとれる
　　}

　　*pct_next = c_buf_e;
　　return 0;
}

836 ：
とりあえずのﾃｷﾄｰな宣言

#define TYPE_STRING "STRING"
#define TYPE_INT_TO_FLOAT "INT_TO_FLOAT"

typedef enum __ENUM_BAKA_TYPE {
　　BAKA_TYPE_STRING,
　　BAKA_TYPE_INT_TO_FLOAT,
　　BAKA_TYPE_UNKNOWN
} BAKA_TYPE;

typedef struct __tag_baka_type_t {
　　BAKA_TYPE baka_type;
　　uint32_t u_records;
} t_baka_type_t;

int get_type(unsigned char const* buf, t_baka_type_t* pt_baka_type, unsigned char const** pct_next);
int get_data_string(unsigned char const* buf, t_baka_type_t const* ct_baka_type, unsigned char const** pct_next);
int get_data_int_to_float(unsigned char const* buf, t_baka_type_t const* ct_baka_type, unsigned char const** pct_next);

837 ：
ｺﾚでとりあえず動かせる

int main(int argc, char** argv) {
　　unsigned char const* buf = (unsigned char const*)
　　　　"STRING 3\x0a"
　　　　"This is pen.\x0a"
　　　　"hoge piyo\x0a"
　　　　"hello world.\x0a"
　　　　"INT_TO_FLOAT 9\x0a"
　　　　"12345 1000 10 12\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a"
　　　　"101 101 999999 444\x0a";
　　unsigned char const* c_buf = buf;
　　t_baka_type_t t_baka_type;

　　// 実際の処理ではt_baka_type.baka_typeをswitchで分岐しながら処理することになる
　　get_type(c_buf, &t_baka_type, &c_buf);
　　get_data_string(c_buf, &t_baka_type, &c_buf);
　　get_type(c_buf, &t_baka_type, &c_buf);
　　get_data_int_to_float(c_buf, &t_baka_type, &c_buf);
}

838 ：
ろくなエラーチェックもしてないと自分で白状してるゴミコードを誰が動かすと思うのか

839 ：
2chに貼ってしまった以上、権利的にジムしか動かせないなーw

840 ：
__の後に大文字は予約されてるはずでは？

841 ：
そこ突っ込むなら他にも色々あると思うが
なんでC++でtypedef struct/enumなの、とかなんで文字列がunsigned charなの、とか
メタプログラミングじゃない構造体の型名に_tとか付けるな、とか

842 ：
ざっと見たけどすごいスレだな

10年ぐらい前だったらこういうこともありかなって思った時期があるけど今はもうそんな時代じゃない
で大部分レスができてしまう

843 ：
名前の付け方はどうせそれぞれの環境に合わせるだろうからどうでもいいけど
中途半端な最適化が良くないな

今回は用途もデータ構造もわかっているし
目的が高速化なわけだから

844 ：
>>842
多次元配列 (boostを使わない場合) は？

845 ：
boostを積極的に使っていこう。

846 ：
ほらよ
https://goo.gl/uAcy7u

847 ：
壮絶ゲームズ株式会社。

848 ：
http://sozetsugames.jp/about.html

849 ：
ご連絡おそくなりすみません。
たくさんのサンプルありがとうございます。
今日はファイル読み込みの対応ができなかったので明日このスレを見ながら試してみようと思います。

ちなみにフォーマットはSTRING行が先にきて、次にINT_TO_FLOAT行がきます。
STRINGで始まり、INT_TO_FLOATで最後は終わります。
後出しの情報になり申し訳ありません。
>>786　でどっちが来るかの判定までしていただいていたので一応ご連絡しておきます。

STRING 2
This is pen.
hello world.
INT_TO_FLOAT 1230
100 100 110 110
101 101 200 200
～あと1228行
STRING 5
hoge piyo
foobarbaz
It is a July 9 today
It rained all day today
INT_TO_FLOAT 830
100 100 110 110
101 101 200 200
～あと828行

850 ：
すみません、　>>849　のSTRING 5の部分は4行になってますね。
この場合　STRING 4　になります。。

851 ：
作って実験してみたよ
一行に4個の数字がある行を
適当な数値を乗算して構造体のvectorに入れていく
ファイル上の位置も格納するので
間の文字列も必要な時に表示出来る

うちの環境だと
読み込みだけで77.9秒
解析だけで24.3秒
読み込みと解析合わせて78.1秒
アプリはシングルスレッドだけど
勝手にOSが先読みしてくれてるのかな？

読み込み単位は2次キャッシュに確実に収まる1MBくらいが良さそう

852 ：
STRINGとINT_TO_FLOATは何か関連性はあるの？

853 ：
2次じゃなくて3次

struct LOG {
float num[4];
uint64_t line_start;
uint64_t line_end;
};

こんな構造体に入れていくようにしてみた
文字列はクリックした時にファイルを読みに行けば良いよね

854 ：
STRING n の後にn行文字列
INT_TO_FLOAT n の後にn行数値
これが交互にくる
ってことでしょ

855 ：
数値に対応する何か(グラフ？)をクリックすると
その周囲の文字列と数値が表示出来れば良いのかな？
と思った

856 ：
文字列の解析は速く出来そうだから
あとはUIに凝ってくださいな

857 ：
数値も文字列も数行ずつかと思ったけど
1000行とかになるのか

数値ブロック、文字列ブロックは
それぞれ平均何行くらい？

858 ：
メモリが大変な事になりそうなのでstringとint_to_floatの行のアドレスだけ取得して、
必要になった時に読みに行ってintからfloatに変換すれば？

859 ：
floatの配列は別に用意して

struct LOG {
uint32_t str_start;
uint32_t str_end;
uint32_t str_line;
uint32_t num_start;
uint32_t num_end;
};

みたいな、
ブロックごとの構造体に入れていく方がいいのかな？

860 ：
vector<pair<size_t, size_t>> baka;//stringの開始位置とint_to_floatの開始位置をペアで管理。

861 ：
適切なデータの持ち方はUIの全体表示の仕様次第と言うことになる

862 ：
>>806に対して反応が無いから
数値情報が事前に必要なのかと思ったが

863 ：
あと気になったのはGUIに表示するのはstringの一行目？

864 ：
1ブロック平均500行
1行平均30文字
でも100万ブロックある

全体画面で文字列は表示しないんじゃ？

865 ：
初回DBに突っ込む
初回レコードのインデックスを作る

866 ：
最低限のパースを実施して各レコードのオフセットを配列に入れて必要になった時に解析して表示すればいいだけかと

867 ：
同じ事を何度も書かなくて良い

868 ：
やっとおまえらもXMLが糞遅い理由を理解したか。

869 ：
>>776
構文的に難しくも無いのにわざわざ遅くする理由がわからん…
ていうかそもそもlexとかyacc使いでも滅多に使わん希ガス

今回の文字列処理の件はﾜｯﾁｮｲ 0780-Rmg1の圧勝

870 ：
>>851
テストまでしていただいだきありがとうございます。
1分ちょっとならとてもいい感じです。
なるほどDRAMよりも高速なCPU内のキャッシュを有効に使うと効果的ってことですね。
そんなこと今まで考えたこともなかったです。勉強になります。

>>854
ご推察の通りです。

>>857
文字列の方はせいぜい10行～20行です。
数値の方は何万行にもなったりします。

>>858
メモリは10GBつかっても問題にならないくらい潤沢に使えると思うので、まずは速度重視で行こうと思っています。

>>861,862
すみません昨日書き込みエラーになって書き込めなかったのでそのままでした。
クリックするたびに毎回int->float演算したら1項目で何万行もあったりするので
読み込み時に演算しておいた方がよいかなと思っていました。

＞つづきます

871 ：
>>863
全部のフォーマットは複雑になってくるので簡易的なフォーマットをと思って出していましたが
説明していくと細かい話になってきましたのでもう少し具体的なものを書きます。
テストまでしてもらっているのに変わってすみません。。
-------------------------------
SECTION_NAME　①
11200 11200 2 Jun 9 23:23:00 2018　②
This is pen.　③
hello world.　③
x 1 2　④
100 1 -2000 10
101 10 -2001 10
y 2 4
-100 10000
-101 10100
x 3 28
QQ subname -1 0 0 1 -21000000 600000 2　⑤
100 100 110 110
100 100 110 110
～あと26行～
SECTION_NAME　⑥

①GUI表示する
②11200がx or yの個数、3カラム目がテキスト行の個数、それ以降は捨てる。11200のところは1の時もあれば100万超えることもある
③GUI表示する
④これが非常に多く、ひたすら繰り返される。x,yはランダムでくる。
1カラム目はx or y固定。x=次行に来る数値は4カラム。y=2カラム
2カラム目は1からインクリメントしていき、②の11200回出てくる。カウント数値
3カラム目は次行から始まる数値行が何行かの数値
⑤x or yの次の行にたまにこの行があります。この行も使いますが、ちょっと複雑なのでまずはスキップで。
⑥ここからまた①の繰り返し、要するにファイルの最後は④のところで終わる。
-------------------------------

872 ：
すみません、上記QQはQQという固定文字です。
行頭が"Q"のときはこの行という判定で良いと思います。

>>859,860
格納先は構造体に入れようと思っていて、下記のようにテキスト行も入れようかなと思っていました。

struct x_or_y{
　char type; // x or y
　int num; // ④の2カラム目
　float list;
};
struct elem{
　char section_name;
　char comments;
　array系の何かの型 x_or_y_array; // 配列にしておくと（④の2カラム目-1）で簡単にアクセスできそう
};

873 ：
なんかのログなんだろうけど、ログ吐く時に読み込みやすいように出し方考え直した方がいいよ
大本が変えられないならパイプ繋いでフィルタ噛まして、読みやすいように直したファイルを並行して吐くとかさ

というかまず単にSECTION_NAMEごとにファイルぶった切っておくだけで良かったりしない？難しく考えすぎてない？

874 ：
どういうGUIが必要なのかわからんから的外れかもしれないけど
ワイならSECTION_NAMEごとに集計したHTMLファイルかなんかを出力するプログラムをワンパスかけてから
後でそのHTMLをブラウザで見ることを考えたくなるんだけどそれじゃダメなの？

875 ：
>>869
> 今回の文字列処理の件はﾜｯﾁｮｲ 0780-Rmg1の圧勝

>>851の圧勝
>>851は0780-Rmg1みたいな遅いコードとは違う

876 ：
>>815の勝負はどちらも私の勝ち

877 ：
>>871
UIの表示内容はどういう感じを考えてる？

878 ：
②
1カラム目と2カラム目は同じ数字？
1カラム目がxの個数、2カラム目がyの個数？

④
y 2 4 の後、データ行が2行だけど4行の間違い？
データ行の値の範囲は？

879 ：
section_nameは重複しますか？

880 ：
初めて開くファイルは使いやすいように変換して(キャッシュとして)保存しておいて
次回以降それを使うか
全ファイルバッチ処理で事前に変換しておくか

かな

ファイルを開く度に分オーダーかかるのは使いづらい
どちらが良いかは使い方次第で

881 ：
15GBオーダーのファイルがすでにいつくかあって
今後も増えるってことで良いんですよね？

882 ：
①の行は1ファイル何行くらい？

883 ：
>>873,874
ソフトが出しているログなので変えられず、並行で吐くこともできないんです…

> ワイならSECTION_NAMEごとに集計したHTMLファイルかなんかを出力するプログラムをワンパスかけてから
これも考えたのですが、元ファイルと加工したファイルが常に等価ではないので、
間違って古いままの加工ファイルを参照する事故を、全員が気にする必要が
出てくるため今は保留とし、どうしてもできない時の最終手段と考えています。
こういうご意見も新しい視点が見えたりするんでありがたいです。

>>877
こんなのをイメージしています。
====================
項目名　　　|　個数　※各カラムの説明行
====================
-SECTION1　 |　11200
　subname1　|　8800　※subnameがあれば折り畳みツリー形式。なければ折り畳みなし
　subname2　|　2400
+SECTION2　 |　　1
+SECTION3　 |　666
====================
This is pen.　※SECTION1を選択するとそれに対応するテキストをここに表示
hello world.
====================
1　2　3　4　5　6　7　※上と同じくSECTIONに対応した数値を特定できる番号を表示
8　9　10 11 12 13 14　※ここはHTMLぽいものにし、数字クリックでその数値をprint
....
====================

884 ：
>>878
> 1カラム目と2カラム目は同じ数字？
2カラム目が何の数字かまだ把握できていません。
とりあえず1カラム目と2カラム目の数値比較を行い、違う場合はエラーにしようと思います。
> y 2 4 の後、データ行が2行だけど4行の間違い？
ご指摘の通り4行の間違いでした。
> データ行の値の範囲は？
intの範囲を超えるか？ということですか？
int（-2147483648～2147483647）で大丈夫と思います。

>>879
ユニークな名前で重複しません。

>>880
仰る通りどちらも一長一短で、今回は874さんに回答した通り、古いキャッシュを参照する事故を防ぐため、まずはテンポラリファイルを作らないことを考えています。

>>881
ファイルは毎回更新されて新しい15GBのファイル1つをインポートします。
15GBも現在のMAXサイズなのでそのうち20GBとかのものが出てくる可能性はありますが、
そこは「読み込みをひたすら待つ」と割り切りで考えています。

>>882
①の行→100行以下
②の行→SECTIONごとに1行出るので同じく100行以下
③の行→SECTIONごとにせいぜい20行程度。(20行*100行=20000行)
④の行→SECTIONごとにたまに数千万のSECTIONあり(全SECTIONだと数千万～億超えも出てきそう)
1つのSECTIONで数千万や億になり、それ以外のSECTIONは1000以下だったり、
1千万のSECTIONが複数SECTIONになることもあります。
そして④に対して数値行が1行～数十行、場合によっては数百行がくるので、④とそれにかかる数値行が支配的になると思われます。

あと忘れていましたが、テキスト行は日本語がくることもあります。
それ以外は1byte文字です。

885 ：
キャッシュせず
変換して保存しないとなると
ほとんど読み込み時間
解析はそれに比べれば速い

なので
もし高速化したければ
全読みしない方法を考えるしか

全読みの時間くらいは待てるっていうならその方が簡単だけど

読み込み15GB 30秒って異様に速いな
うちの8TB 7200rpmのHDD(内側の方) だと78秒
SSD？ RAID？ キャッシュ？ RAMディスク？

886 ：
>>885
HDDだと思います。
サーバ用なので高速なんですかね。
ちなみに　cat /proc/cpuinfo　でCPUも調べたらXeonで20コア以上ありました。
（ハイパースレッドかもしれませんが）
～次キャッシュも民生用CPUより多いと予想されます。

887 ：
>>885
あと、全読みの時間は >>851 を参考にすると2分くらいにはなりそうなので、それくらいなら全然待てます。
fgets, sscanfの時は5分かかっていて、それで我慢するしかないのか、と諦めかけていたので。

評価もscanfもしないでfgets()だけで78秒なんですかね？
大きな違いはCPU、CPU内臓キャッシュ、HDD、メモリあたりと思いますが、それだけで本当に半分以下になるのか少し気になりますね。

888 ：
とりあえずみなさんのコードを眺めましたが初めて目にする関数だらけで自分のレベルでは全くついていけてないです。
一つ一つの関数がどんな動作をするのか調べていきます。

>>782,833　を見るとcharのポインタをインクリして読むやりかたとか昔ちらっと読んだことある。程度のレベルなので。。

今833-837の動作確認ができたので、まずはこれがどう動いているかと、バイナリ読み込みの手法について調べていきます。

889 ：
>>887
fgetsじゃなくて
freadで1MBずつ読むだけで78秒
庶民の普通のHDDはこんなもんです
解析入れてもほぼ同じなので
読むのに30秒なら解析入れても30秒で終わるよ
もちろんうまく作ればだけど

890 ：
>>833をマネしたら30秒じゃ無理だろうけどね

891 ：
ここはC++スレだからstd::regex使いなよ
>>833よりは速いし安全だぞ

892 ：
速いわけが無い
コードを書いて時間を測ってみなさい

893 ：
脳高速

894 ：
sscanfが遅くてなんとかしたい
っていう話題なのに
DBだとかhtmlだとかregexだとか
頭がおかしいのが多いな

895 ：
何度も表示させたいなら、解析結果をDBに格納しておくというのもいい方法だと思うが
事前にできるなら、見かけ上の実行時間も節約できるんだし

896 ：
ちょっとは要望を読んでから書けよ

897 ：
エアプ野郎が多いからねこのスレ
何の意味があるのかは知らんが

898 ：
DBって要望がチャンと出てくる前の話だろう
サーバーで動かす位しか条件書いて無かったぞ

899 ：
>>892
ループごとにregexオブジェクト作り直して時間測ってりゃ遅くなるわな
あれは使い回すもんだよやり直し

900 ：
(ぴこーん!) boost::spiritだな!

901 ：
うん、regexよりはspirit::qiだよね
ﾜｯﾁｮｲ a781-UVFsは的外れにも程がある
そしてそれ以前にregexもspiritもC++初心者に勧めるようなものではない

902 ：
要件が全部出ていたわけじゃないのに
エスパーが登場して的当てたのか？そりゃスゴイな

903 ：
>>743の時点で低レベルな記述が適していることくらいわかるだろ
15GBのテキストだぞ

904 ：
>>899
>>894

905 ：
遅いから早くしたい
どんなに頑張っても無理なら
遅くてもよい仕組みにするという手もある

906 ：
そういう事は頑張ってから言え

907 ：
わざわざ遅い方法を選んで「無理」とか
ただの無能

908 ：
やっぱりな低学歴しかいないわ

909 ：
>>908
糞コードの負け犬君の登場ですね

910 ：
そもそも最初のﾌｫｰﾏｯﾄと全然違うやんけ
普通にfgetsでとって、必要最低限の位置をﾏｰｷﾝｸﾞするほうが
ﾒﾓﾘに入れるのはそれだけ

位置からﾒﾓﾘﾌﾞﾛｯｸをとって、>>834>>835みたいなやりかたで表示が必要になったときに解析

911 ：
そもそも解析ｱﾌﾟﾘが出力してる規定されてるﾌｫｰﾏｯﾄなのに
いちいち形式をﾁｪｯｸする必要すらない

ﾎﾝﾄな知恵遅れはなにをいってんのか意味不明だからな
ｸｿﾆｰﾄのｴｱﾌﾟﾛｸﾞﾗﾏがﾃｷﾄｰなことばっかりいってんのは分かる

912 ：
スケジュールを開始するボタンに名前をつけたいけどいい名前が思い浮かばない
できれば6文字以内で
開始とか実行はダメ

913 ：
>>912
とりあえずC++は関係ないな

914 ：
ちなみな
fgets()は知恵遅れのｷﾐﾗが考えてるよりぜんぜん速い
このｽﾚの知恵遅れが書くようなｸｿｺｰﾄﾞより全然速い

書式付の標準関数は書式解析のｵｰﾊﾞｰﾍｯﾄﾞがあるからｸｿ遅い

915 ：
ちなみにな手で入力したときは
fscanfやsscanfは使えない
書式より引数が少ない場合簡単に死ぬからな

手で入力してるﾃﾞｰﾀの場合fgets()でﾃﾞｰﾀとって丹念に解析するしかない
つまりfscanfやsscanfの使用も想定する=間違いなく妥当な形式の入力がある
ことを意味する

916 ：
同じ事を何度も書かなくて良い
>>758

あとfgetsよりfreadの方が速い
当たり前ですが

917 ：
ﾒﾓﾘﾌﾞﾛｯｸとるときは
普通にfreadでいい
どうせ改行位置は解析しないといけないから
fgetsにやらせとけばいい

知恵遅れはTPOにあった関数の使い方がわかってないからな

918 ：
知恵遅れはなにをどういった場面で使うのか分かってないからな
そもそも話がかみあうﾜｹがない

知恵遅れにありがち
電車みて電車の型番いえるだけみたいな頭悪いのが
このｽﾚにはｳﾖｳﾖいる

919 ：
わざわざ改行検索だけの為にメモリスキャン
ガチガチにチューニングするつもりならあり得ないですね

920 ：
適度なチューニングで妥協するんであれば
fgetsで良いかも知れませんが

921 ：
freadで読む時間とほぼ同じ時間で解析まで終わるので
中途半端な解析で止める必要もなくて
直接使いやすい形にすれば良い

あとは>>885

922 ：
>>889

なるほどですね。
解析入れてもあまり変わらないのか。
scanfって本当に遅いんですね、嬉しい誤算です。

話題に出ているregexですが、↓ここを見た感じ、

ttps://www.sejuku.net/blog/25962

下記のように感じました。
perlやpythonの正規表現と似た感じなので使えるかもしれません。
1文字づつシフトしてスペースや改行を判定しながら抽出するより早いのであれば試して見ようと思います。

regcomp　→正規表現オブジェクト？の作成。()でグループ化。読み込み前にすべてのフォーマットパターンを生成して使い回す。
regexec　→正規表現オブジェクトを使ってパターンマッチ
rm_so、rm_eo　→マッチの先頭、終端が取れるので文字列が拾える。こんな感じ？→strncpy(&str, data+match[i].rm_so, match[i].rm_eo - match[i].rm_so);
regfree　→読み込み終了後にすべてのオブジェクトをこれで開放すればいい？

spirit::qiはググりましたがまったくわかりませんでした。。

923 ：
15GBともなると
関数を呼ぶ時間でもトータル時間に影響するんでね
fgetsの関数コール回数だってバカにならんでしょ

全てのfloatをvectorにpush_backするだけでも
結構な時間ですよ
この辺も工夫しないと

924 ：
正規表現なんか使ったらｺﾝﾊﾟｲﾙ済の正規表現でも
ｸｿ遅いにきまってるやんけ

そんなもん使うならｽｸﾘﾌﾟﾄでやったほうがいい

925 ：
ディスク読むより遅いでしょうか。

926 ：
>>922
だからregexもspiritも使わなくていいってばｗ
すでに実例出してくれてるような昔ながらのC言語的な書き方でいいと思う
まともな実例も示さずに「○○使え」は無視していいよ

927 ：
頭使え

928 ：
ちなみに gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0 だと、 C++がちゃんとしてて、std::getline()はfread()と同じくらい速い。
各自で実際に試してみるとよいだろう。

Visual Studio だとstd::getline()はfgets()よりも遅い。
コンパイラによって性能に極端な差がでるのがC++のiostream周り。iostreamが地雷扱いされる主因。

929 ：
15GB なんて、もし画像ファイルなら、触った途端に、メモリ不足でフリーズするレベル。
普通、8GB ぐらいしか、メモリを積んでいないだろ

1行毎に、読んでは捨てる方式じゃないと無理。
それか、ファイル分割する

Ruby で、HTML, Node.js などが良さそう。
それか、DB

930 ：
順番にアホが書き込むスレ

931 ：
>>929
>>743から読んで出直してきなさい

932 ：
色々な言語で速度比較とか面白そう

933 ：
>>871のフォーマットでC++で作ったら
解析15GBで8.6秒
1バイト平均2クロック！

これを越えるには
マルチスレッド / AVX命令 /アセンブラ / GPU
に手を出さないと無理かな

----
Haswell
3.4GHz固定
シングルスレッド
C++で1文字ずつ15G文字解析
普通の命令のみ使用(SIMD命令は使用しない)
数値の合計のみ計算して結果を最後に表示
固定4KBを繰り返し解析、トータル15GB分の時間を計測
----

934 ：
1ブロック内に数値が数万あってどうUIで表示すんのか気になる

935 ：
数値ならグラフにするとか画像にするとかフィルターを通してから間引くとか音声にして鳴らすとか
まあ色々とあると思う

936 ：
>>926
おとなしく1文字づつ評価します。

>>933
8.6秒早いですね。

自分はまず初バイナリ読み込みなので勉強から始めてとりあえず1行読みができましたが、
アスキー読み込みのfgetsの方が早かったです、、
コードを載せるのでどこが悪いか見てもらって良いですか？

対象=13GBのファイル（約8億行）。

○fgets版　→約17秒
if((fp=fopen(file_path,"r"))==NULL){
　　printf("file not open %s\n", file_path);
　return 1;
}
while( fgets(buf,MAX,fp) != NULL ){
　buf;
}

次にバイナリ読み↓

937 ：
○バイナリ読み版　→約44秒
struct CCC {
　FILE *fp ;
　bool read(char* file_path);
　t_read_db read_db;
};
bool CCC::read(char file_path[]){
　FILE *fp;
　if((fp=fopen(file_path, "rb"))==NULL){ printf("ファイルを開けません。%s",file_path); return 0; }
　unsigned char buf[BUF_SIZE];
　int newline_index;
　while( !feof( fp ) ){
　　size_t size = fread( &buf, sizeof(buf[0]), sizeof(buf), fp );
　　// 終端処理。最大値で取得されてなければそこを末尾にする
　　if( size != BUF_SIZE ) buf[size] = '\x00';
　　// 取得bufの最後尾が改行でなければfpを改行まで戻す
　　if( buf[size-1] != '\x0a' ){
　　　newline_index = -2;
　　　for(; buf[size+newline_index] != '\x0a'; --newline_index);
　　　fseek(fp,newline_index+1,SEEK_CUR);
　　　// bufの最後の改行の次にx00(null)を入れてそれ以降をカット
　　　// 「配列参照はポインタの移動より遅い」とあったがbufは実体で移動できないので[]参照で代入。
　　　buf[size+newline_index+1] = '\x00';
　　}
　　unsigned char const* c_buf = buf;
　　while( c_buf[0] != '\x00' ){
　　　print_line(c_buf, &c_buf);
　　}
　}
}

938 ：
bool print_line(unsigned char const* p_buf, unsigned char const** pct_next);
bool print_line(unsigned char const* p_buf, unsigned char const** pct_next){
　unsigned char const* c_buf = p_buf;
　//改行位置を検索
　for(; *c_buf != '\x0a'; ++c_buf);

　char line[LINE_SIZE];
　strncpy( line, (char const*)p_buf, c_buf - p_buf );
　// nullで区切らないと過去に代入した文字数より少ないときにゴミが残る
　line[c_buf - p_buf] = '\x00';

　++c_buf;
　*pct_next = c_buf;
　return true;
};

939 ：
○fgets版　→約17秒
○バイナリ読み版　→約44秒

両方ともとりあえず文字列の読み取りまでしていて、条件は同じではないかと思うのですが、freadのほうが倍以上遅いです。。

940 ：
>>936
setvbufはしないの？

941 ：
>>935
fgetsで悩んでる人がそのハードル超えることできるか心配してるんですよ

942 ：
すみません、44秒はfreadの読み込みサイズ（BUF_SIZE）が512byteでした。
16MBにすると34秒になりましたが、それでも倍の差があります。

943 ：
>>942
mmapがいるかなぁ
BSD grep のソースのコメントにこの辺りの高速化の
コツが書いてあるので一読されたし

944 ：
>>943
mmapですか。
要チェックですかね。
でもそれだけで数倍早くなるとも思えないし、　>>933　さんの8.6秒は圧倒的パフォーマンスですね。
シングルスレッドで特殊なものは使ってないようだし、たった4KBの繰り返しだし。
根本的なところから違いそう。。

>>933
もし可能であれば、テストしたコードを見せていただくことはできませんでしょうか？

945 ：
あのな
そこまで読みこみ速度を気にするなら
そもそもFILEﾎﾟｲﾝﾀ使う関数なんか使うなよ
そもそもFILEﾎﾟｲﾝﾀ使う関数はﾊﾞｯﾌｧﾘﾝｸﾞしてるから
いちいちﾒﾓﾘｺﾋﾟｰしてんのに

そこまでｶﾞﾀｶﾞﾀいうなら
openとreadで普通にﾒﾓﾘﾌﾞﾛｯｸ読みこむ処理にしろよ
ﾊｹﾞ

946 ：
>>940,941
setvbufも初耳です。
941さんのコメントからすると、これまた難しそう。。

色々と情報ありがとうございます。

947 ：
ちなみになFILEﾎﾟｲﾝﾀは構造体にﾌｧｲﾙﾃﾞｽｸﾘﾌﾟﾀもってる
fopenでopenを呼び出してﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀ生成して構造体に保存してる
ﾌｧｲﾙ読むときはﾌｧｲﾙﾃﾞｨｽｸﾘﾌﾟﾀでread使ってﾊﾞｯﾌｧﾘﾝｸﾞしながら読みこんでる

このｽﾚの低学歴どもはこういう基本的なことわかってんの

948 ：
そのsetvbufというのが
ﾊﾞｯﾌｧﾘﾝｸﾞするﾊﾞｯﾌｧのｻｲｽﾞだ
つまり、ﾊﾞｯﾌｧにたまったﾒﾓﾘをひたすらｺﾋﾟｰしてる

949 ：
filenoとfdopenの理解はデフォ

950 ：
32bit越えるmmapとか
そんなやばそうなもん使うのか
まずちゃんと動作するか確認することになるわ

951 ：
休日にｵﾚのｴﾚｶﾞﾝﾄなﾌｧｲﾙ読みこみ処理作ってやるから
楽しみにしてなさい

952 ：
HDDの一番外側15GB
セクタ直読みで60.1秒
平均 250MB/s でした

7200rpmの8TBのHDDです

953 ：
>>851の77.9秒はHDDの内側の方でfreadでの読み込み
どちらもHDDの限界と思います

954 ：
>>944
解析時間のほとんどが>>782のようなコードです
ちょっと変えましたが

955 ：
改行を探す為だけにスキャンする必要はありませんし、コピーする必要もありません

ほとんどをしめる数値の行は
>>782の処理で区切りまでポインタが進みます

956 ：
>>951
ありがとうございます。楽しみにしています。

>>933,952,953
解析と読み込みを分けているんですね、8.6秒は解析で、読み込みがHDDのハード限界の60秒（高速な外側）、77.9秒（低速な内側）。
そこで　>>851　の読み込み、解析合わせると78.1秒でほとんどがHDD律速ということか。

>>954,955
ご説明ありがとうございます。　>>782　の動作を調べてみます。
freadの扱いで質問なのですが、byte単位で取得すると最後尾が改行ではなく途中で終わることがあるので、
改行区切りになっているdata変数がだと思って、937に書いたコードでは、自分がわかる知識で考えて、
freadで読み込んだあとに改行のところまでfseekで戻しているんですが、この考え方はあっているのでしょうか？

957 ：
data変数がだと思って　→×
data変数が必要だと思って　→○

958 ：
>>952
すみません、あと、 >>936 に書いているfgets版のコードだとどれくらいの速度が出ていますでしょうか？
fgetsで回したものと　fread + >>782　のコードでどれくらいの比率になるのか気になりました。

959 ：
MS製の金毘羅でfgets(), fgetc()を試す場合は、_CRT_DISABLE_PERFCRIT_LOCKS 必須で。

960 ：
無能な働き者が書いた半角スクリプトなんて誰も走らせたくない

961 ：
毎回fseekで改行位置まで戻してたら意味ねー

962 ：
>>956
読み込みの境目の処理方法はいくつかあります

A. 1行全体が連続してバッファに存在しなくてもいい作りにする
B. リングバッファ
C. fseekでファイルポインタを戻してから読み込む
D. あまりをmemcpyでバッファの先頭にコピーしてから読み込む
E. ほか

読み込み単位が大きければ C. or D. のコストは無視出来るので C. D. で
読みこみ単位が小さければ A. B. なども考える
といった感じかと思います

今回私は解析処理が簡単に作れて、HDDの読み込みに一切影響を与えない、D.で作りました

963 ：
>>958
fread
fgets
ReadFile

読み込みだけだとどれも78秒

964 ：
>>959
ttp://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-8.1.0/gcc-8.1.0.tar.xz
これを使ってるので、まずはMSのオプションは関係なさそうです。
でもMSのコンパイラは早いという記事をこの前読んだのでそっちの方に乗り換えた方がいいのかな。
完成した後に両方テストして良好な方を検討しようと思います。

>>962,963
A,Bは難易度高そうですね。
Cは自分がやった手法のようですが、Dはポインタを戻す分の再取得が無いのでCより良さそうに見える。
Dを検討してみます。

fgetsもfreadも同じ時間ですか。
となるとfgets 13GB 17秒だから、そのレベルの速度は出るはずなのか。

今782のコードを調べて動作がわかってきました。
char演算で文字コードを数字の始点に移動させ9以下で数字以外（スペースor改行）を判定。
*10で桁を表現し、文字コードの番号で演算。(文字→数字変換していない！！)
このファイルで支配的な数字行が文字→数字変換が一度もないおかげですごく効きそう。
原理がわかるとなるほど！となるけど、1桁ずつ演算、文字コード演算は自分がやってたら絶対にたどり着かない発想です。

965 ：
text/byte stream は異なる。
文字列はバイトじゃなく、テキスト

バイトは構造体など、構造が決まっているもの

改行区切りで、改行の位置が変わるものは、テキスト処理

966 ：
>>965
お前ちょっと黙っとけ

967 ：
可変長構造体なんてのもあったりして

968 ：
通信データなどは、可変長構造体

ヘッダーなどは固定サイズで、データ部分は可変サイズ。
可変部分のサイズが、ヘッダーなどに書いてある

969 ：
gcc拡張でサイズ0の配列定義うんたら

970 ：
>>969
C99なら規格化されたのでgcc拡張は要らなくなった

971 ：
C99の可変長配列はC++には取り入れられなかったし、
C11ではオプションに格下げされたんじゃなかったっけ?

年式でフラフラする機能の典型例のような記憶がある。

972 ：
おまいらスレタイ

973 ：
>>971
可変長配列(VLA)については、そのとおり
しかし >>970 >>969 で指しているのは、構造体内の 0 長配列メンバ、または C FAQ 2.6

974 ：
>>971
VLA のことと誤解してないか？
ここで言ってる「可変長構造体」は構造体の最後の要素が不完全型であることを許すルールのことだと思う。

struct a {
int a;
int b[];
};

このとき sizeof(struct a) は要素 b を含まない大きさを返す。
malloc(sizeof(struct a)+(bの大きさとして確保したい大きさ)) とすれば b が可変長な構造体として使える。

このルールが出来る前 (C89) は仕様に沿ってこのようなことをしようと思うと
配列 b の大きさを便宜上 1 として指定しておく、
つまりは

struct a {
int a;
int b[1];
};

としておいて malloc のサイズ指定のときに要素一個分の大きさを差し引いて調整するようなことをしていた。

975 ：
どうでもいい機能

976 ：
すまん、皆の言う通りだ。ちゃんと読めば
構造体の末尾メンバの0サイズ配列の話だと分かる流れだったのに、
なんでか裸の配列の要素数だと思いこんでしまった。

977 ：
GCC拡張をしたとして
struct a {
　int b[0];
};
のsizeof(a)はいくつなんじゃろうか…

978 ：
>>977
ゼロが返ってきたぞ。

ただし、 C/C++ におけるオブジェクトはメモリの一部を占有するものでありポインタで示せるものという要求があるので、
それと矛盾なく使うには色々と気を付けないといけないかもしれない。

ちなみに、クラスのメンバにストレージを割り当てないこと (要するにサイズゼロのオブジェクト) を許す [[no_unique_address]] という属性が C++20 で追加されてる。

979 ：
そんなクソみたいな使い方しかされない機能入れるなよ。。

980 ：
複数回allocateを抑制するための機能(関数)はc++にもたくさんあるじゃない

981 ：
>>979
非staticなメンバを一つも持たない上、そのクラスのポインタを扱わない(=多態性を必要としない)のに
継承したりメンバとして持ったときに1バイト追加されるのがうざいからだろ

982 ：
>>978
ええー！！！
struct c {
};
のsizeof(c)は1だった（と思った！）が！！

983 ：
最適なプログラムを書く必要のない立場の雑魚は黙ってろよｗ

984 ：
>>981
static なメンバしかない、しかもポリモルフィズムしない(interfaceな使い方でもない)
ってそもそも継承するのが設計として間違いじゃねーの？

985 ：
c++つかってるとロジックやアルゴリズムなどの本来の目的より
こういう横道にそれた話題ばかりになることが多い
手段が目的化するので困る

986 ：
関心の集中の先はプログラムで実現できることになるべきだけど
c++はそっちより言語自信や仕様や実装に目が向く
時間が無駄に費やされやすい

987 ：
最適なプログラムを書くのもC++の目的だ
ロジック以外のことに目をそらしたいなら他の言語を使え

988 ：
c++は幅広い書き方ができてしまうのが一番困ったところ
10年前のコードが完全に動いてるにも拘わらずゴミに見えてしまう

989 ：
>>984
非staticなメンバが無い、ってのはメンバ変数ね(非staticなメンバ関数はあっても関係ない、つまりインターフェースも含む

990 ：
次スレ作成のルールってどうなってますか？

991 ：
>>985
2chが異常なだけ

992 ：
linuxと聞いてた(>>743)のになんでMSのｺﾝﾊﾟｲﾗの話がでてんねんと

まず実機でｺﾚ走らせて試験をしなさい

①　下のｿｰｽをｺﾝﾊﾟｲﾙしてbaka_testという名前の実行ｵﾌﾞｼﾞｪｸﾄをつくりなさい

　linuxなら↓こっち
　https://ideone.com/e9iA5m

　windowsなら↓こっち
　https://ideone.com/D4T1zh

②　で、こんな試験をする
　https://ideone.com/82BnFZ

ちなみにwindowsはﾊﾞｯﾌｧｻｲｽﾞを
ｾｸﾀﾊﾞｲﾄ数の倍数でないとちゃんと動作しない
それはwindowsの仕様だからな（ﾒﾓﾘｱﾄﾞﾚｽはmallocで返ってくる先頭のﾎﾟｲﾝﾀｵﾌｾｯﾄで問題ないことは分かってる）

ﾊﾞｯﾌｧｻｲｽﾞを何ﾊﾞｲﾄにするのが読みこみで効果的か
決めたほうがいい
試験結果をちゃんと報告するようにな

　あとOSは64bitでいいんだな
　それによっても話がかわってくる

993 ：
ちなみにwindowsでopenとかread使うのはｸﾙｸﾙﾊﾟｰだからな
msのﾗﾝﾀｲﾑがｳﾝｺなのは有名だからな

msｳﾝｺﾗﾝﾀｲﾑのopenでCreateFile呼び出してる
msｳﾝｺﾗﾝﾀｲﾑのfopenでopen呼び出してる

msｳﾝｺﾗﾝﾀｲﾑのreadでReadFile呼び出してる
msｳﾝｺﾗﾝﾀｲﾑのfgetsやfreadでread呼び出してる

わかった？

994 ：
>>993
ありがとうございます。

g++ -o baka_test $file_name
echo 512,`./baka_test $input 512` > baka_result.txt
echo 1024,`./baka_test $input 1024` >> baka_result.txt
～

上記を13GBのファイルで試したら下記結果が出ました。

512,13
1024,7
2048,5
4096,3
8192,2
16384,2
32768,2
65536,2
131072,1
262144,3
524288,2
1048576,2
2097152,2
4194304,2
8388608,2
16777216,3
33554432,2
67108864,3
134217728,3
268435456,3
536870912,3
1073741824,3

995 ：
これは一度に読み込むサイズは4KBを超えると速度に影響はなく、
>>962　のC,Dパターンの場合だと、最低1行分のバッファが必要なので、
その場合、一行のバイト数のMAX値で決めれば良い。
ということでしょうか？

996 ：
どんだけ速いHDDやねん。。。
すでにｷｬｯｼｭされてんのか

その13とか7とか5とかいう数字は
ﾃﾞｨｽｸ読みこみ（ﾃﾞｨｽｸの内容をﾊﾞｯﾌｧにｺﾋﾟｰ）にかかった時間は秒だぞ
ちゃんとｺｰﾄﾞ書いてmsecにして計測したほうがよかったのかもな

暇だったら、ｼｪﾙで精度の高い計測値だせるように工夫しなさい
数十秒はかかると思ってたからmsecなんか考えてもなかったわ

で、実機のOSは64ﾋﾞｯﾄでいいのか
ここ結構重要だからな

997 ：
めんどいから128Kで2秒かからない
でいいや

998 ：
すみません忘れてましたlinux 64bitです。

> 128Kで2秒かからない
これのことですね。　→131072,1

昨日の夜（今日の朝5時）までやって　>>962　のCパターンでようやく一通りファイルを
読み込めるようになりましたが、やはり速度が出ていません。

13GBファイルで確認

fgetsのみ解析なし　→17秒
freadで各文字列解析、数値行の演算を行ったもの　→1分超え

コード書いてて気になる箇所がいくつかあるので質問しようと思ったけどもう1000になりますね。
次スレで質問させてもらいます。

999 ：
なんかよく分かってもらえてないようだが
この値はﾌﾞﾛｯｸで読みこむ固定のﾊﾞｯﾌｧﾘﾝｸﾞｻｲｽﾞ
1行分とか関係ない

ﾌﾟﾛｸﾞﾗﾑではきっと
ﾊﾞｯﾌｧﾘﾝｸﾞされたﾒﾓﾘを解析することになる

とりあえず今回は、必ず128K単位で読みこむ
128K単位のﾒﾓﾘを
正直もっと増やしてもいいとは思う

あととりあえず行の最大ﾊﾞｲﾄ数は256ﾊﾞｲﾄで十分でいいや

1000 ：
ぬるぽ

1001 ：
2ch.scからのレス数が1000に到達しました。

テストしにくいコードをテストする方法 その2
安価でプログラミングの教科書を作るスレ
Visual Studio 2019 Part3
テストしにくいコードをテストする方法 その2
●●●●TCL/TKなら俺に聞け 4●●●●
次世代言語21 Go Nim Rust Swift Kotlin TypeScript
【分散型バージョン管理】 Mercurial 2【hg】
Pythonのお勉強 Part62
StackOverflowについて語るスレ
C言語なら俺に聞け 155
--------------------
BORUTO～NARUTO NEXT GENERATIONS～ 14 　ﾜｯﾁｮｲ無し
純喫茶⌒゛★銀の雨
　　　ガンバ大阪 Part3081
山下智久のせいで最悪の「コード・ブルー」に
[AHO931] 東京の若者に風呂なし物件が人気！「銭湯あるしなくても困らない」文化住宅化進む。
石破茂「日本の設計図を書き換える！」→具体的には？→石破「これから考える」　ネット「民主党そのもの」「どうみても野党」
広瀬すずって最強だよな
【Gunners】 Arsenal F.C.【part1252】
【バーチャル】ぽんぽこ&ピーナッツくん【YouTuber】 Part3
ヤマノススメの雪村あおいちゃんの2018年を見守るスレ
孤男って中性的な奴が多いと思うんだよ
NHK連続テレビ小説 「べっぴんさん」 part91
アシッドジャズあたりを語れ
ガチのヤマト社員だけど疲れた
藤本美貴って人に嫌われる天才だよな
関東気象情報 Part867【2020/1/30～】
【復活】午前三時に書き込むスレ　其５？【集合】
○○○○Audi A4S4RS4 part59○○○○
コロナ専用スレ
【逮捕】韓国慰安婦少女像展示に「ガソリン携行缶持って放火」示唆する脅迫FAX送信容疑で男逮捕　愛知
TOP カテ一覧 スレ一覧 100～終まで 2ch元 削除依頼