C++相談室 part137

**デフォルトの名無しさん** · 2018/07/14(土) 17:53:02.14

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2018/07/17(火) 17:51:00.62

悪いと思って無いだろ

**デフォルトの名無しさん** · 2018/07/17(火) 18:31:14.54

消えろ

**デフォルトの名無しさん** · 2018/07/18(水) 18:38:21.90

ハイ、謝罪と賠償の要求いただきました！
みんなー、謝罪と賠償の要求出たぞー！

**デフォルトの名無しさん** · 2018/07/18(水) 19:24:54.30

ごめんなさい
100円

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/07/18(水) 19:48:18.30

パーサーもパーザーも間違いではない。

**デフォルトの名無しさん** · 2018/07/18(水) 19:51:38.49

はいはいwww

**デフォルトの名無しさん** · 2018/07/18(水) 22:02:52.32

int a;
if( hoge ){
const a = 1;
}
else{
const a = 2;
}

とすると不安定な動きをするのですが、
このコードは許されないのでしょうか。

**デフォルトの名無しさん** · 2018/07/18(水) 22:17:00.15

許される

**デフォルトの名無しさん** · 2018/07/18(水) 22:28:45.28

const a = 1;　ってなんぞ？？と一瞬思ったがintが省略されてるのか
それブロック内ローカル変数だから、外のint a;には関係しないよ
>157に書かれてるところは許されるけど、
書かれてないところでint a;を使ってたらそりゃ不安定だろうね

**デフォルトの名無しさん** · 2018/07/20(金) 17:29:54.53

不安定な動きはしないと思うが
ルールがわかってないだけで

**デフォルトの名無しさん** · 2018/07/20(金) 18:06:32.94

外側のaを初期化してないから不安定になる可能性はある。

**デフォルトの名無しさん** · 2018/07/20(金) 18:38:08.70

aを不定なまま使えば不安定になるかも知れないが
>>157のコードだけならなにも問題ない

>>157の回答としては
「許される」が正解

**デフォルトの名無しさん** · 2018/07/20(金) 21:07:42.21

許すのは誰なのかというところから(ry

**デフォルトの名無しさん** · 2018/07/20(金) 21:08:02.97

コンパイラ様

**デフォルトの名無しさん** · 2018/07/20(金) 21:15:25.57

int a; // 未初期化
if (hoge) {
const a = 1; // if の中だけで使える変数aを新たに宣言
const int b = 1; // こう書いてbを使うのと同じ
} else {
const a = 1; // else の中だけで使える変数aを新たに宣言
const int c = 1; // こう書いてcを使うのと同じ
}
int i = a; // 未初期化のままaを使おうとして「不安定な動きをする」

**デフォルトの名無しさん** · 2018/07/21(土) 03:52:30.13

コンパイラ様は、代金を支払うお客様より偉いのか。

**デフォルトの名無しさん** · 2018/07/21(土) 07:09:59.33

機械は偉さで動いてはいない

**デフォルトの名無しさん** · 2018/07/21(土) 07:12:46.06

そのうち褒める褒めないで動作が変わるようなAIコンパイラが出てくる

**デフォルトの名無しさん** · 2018/07/21(土) 07:16:56.35

もうしわけない。金毘羅様に言及すべきだったのにそうしなかったのが情けない。

**デフォルトの名無しさん** · 2018/07/21(土) 11:56:28.78

警告オプション有効にして助言をもらおう
> warning: variable 'a' is uninitialized when used here [-Wuninitialized]

**デフォルトの名無しさん** · 2018/07/21(土) 12:20:29.40

C++勉強するたびに嫌いになってきて草

**デフォルトの名無しさん** · 2018/07/21(土) 12:23:02.98

そんなのは道楽でC++やってるあまちゃんのたわごとだ
俺なんかは最初からC++以外に用意されてなかった

**デフォルトの名無しさん** · 2018/07/21(土) 12:34:14.56

c++はできるだけの範囲で出来るだけのことをやればいい
意欲があればさらに進めばいい
むりして難しいことをやらなくてもいい
c関数での文字列の処理が嫌ならstring使えばいい
楽なところは楽でいい

**デフォルトの名無しさん** · 2018/07/21(土) 13:42:42.85

template <typename TypeA, typename TypeB> void TempSet(TypeA* Obj, void (TypeB::*Method)())
{
*Obj->*Method;
}

これがエラーでコンパイルできないんですが、
TypeBのメンバ関数呼び出すのはどうやればいいんでしょうか？
TypeAはインスタンスのオブジェクトポインタです

**デフォルトの名無しさん** · 2018/07/21(土) 13:44:42.66

でも++が一番ストレスなく組めると思う。

**デフォルトの名無しさん** · 2018/07/21(土) 13:53:05.91

>>174
TypeA はTypeBの間違いで、
Obj->Method();
でないの？

**デフォルトの名無しさん** · 2018/07/21(土) 14:00:56.99

おっとこうか
(Obj->*Method)();

**デフォルトの名無しさん** · 2018/07/21(土) 16:20:10.80

>>177
なるほどそれですね、ありがとうございます。

**デフォルトの名無しさん** · 2018/07/21(土) 18:50:32.76

VMWare使ってLinux入れてみた
貧弱なPCでめちゃくちゃ重すぎるがｺﾚで普通にｺﾝﾊﾟｲﾙはできる
いままで黙ってたがMSのｺﾝﾊﾟｲﾗでｺﾝﾊﾟｲﾙしてたからな

やっとｵﾚの芸術的なﾊﾟｰｻﾞをｺﾋﾟﾍﾟで作る準備が整った

**デフォルトの名無しさん** · 2018/07/21(土) 19:53:50.78

やっぱﾜｯﾁｮｲ必要だな　これ

**デフォルトの名無しさん** · 2018/07/21(土) 19:54:08.06

コンパイルするためだけにVMWarewwwwwwwwwwwwwwwww

**デフォルトの名無しさん** · 2018/07/21(土) 20:17:49.81

>>179
DELLのPC安いから買うといいよ

**デフォルトの名無しさん** · 2018/07/21(土) 20:18:57.06

ubuntu on windows は、ウィルス対策ソフトのウィルス・バスターがubuntu上のプロセスを監視対象として認識しないらしく、きびきびと起動・実行できる。
それがいいことか悪いことかは、さておき。

**デフォルトの名無しさん** · 2018/07/21(土) 21:04:13.24

>>181
何かおかしいか？

**デフォルトの名無しさん** · 2018/07/21(土) 21:05:35.42

botに反応するなよ

**デフォルトの名無しさん** · 2018/07/21(土) 21:08:08.82

botがそんな反応するか
そういうことにしたいのなら
見逃してやるが

**デフォルトの名無しさん** · 2018/07/21(土) 21:18:01.24

見逃してもらえないとどうなっちゃうの？

**デフォルトの名無しさん** · 2018/07/21(土) 21:23:00.95

何がおかしいのか聞こうか

**デフォルトの名無しさん** · 2018/07/21(土) 22:50:00.50

32bitのlinuxしか入らんから
それでもいちいちめんどくさいことは分かった

**デフォルトの名無しさん** · 2018/07/21(土) 23:13:14.47

macならdockerでlinux環境作るのもありかなと思ったが、
winだとまだdockerインストールめんどくさげだね。

**デフォルトの名無しさん** · 2018/07/22(日) 12:08:37.73

>>179

自分もvmwareでlinux入れてましたが、メモリ4GB(有効なのは約3GB)の初代i3ノートPCで、vmware割当メモリ700MBくらいで使ってましたが
かなり重かったけど立ち上がったらそこそこスムーズに使えてました。
メモリ8GBくらいあればvmwareに1GB～2GBくらい割り当てれば、そこそこストレスなく使えそうな気がします。

ちなみにすでに知ってるかもしれませんが、win10だとubuntu？っぽいのを直接インストールできます。
windows内にゴミがたくさんできそうだから個人的には躊躇しますが。

ttp://www.atmarkit.co.jp/ait/articles/1608/08/news039.html

**デフォルトの名無しさん** · 2018/07/22(日) 14:07:01.86

それは入れないほうがいいよ
互換性問題があるしかなり機能を絞られてる
使ってみてわかる誰得機能
容量も十数G必要

VirtualBoxを普通にいれたほうが使い勝手がいい

**デフォルトの名無しさん** · 2018/07/22(日) 20:18:52.55

> 容量も十数G必要
いや1GBも要らんよ、どこ確認したんだｗ

WSL丸ごと%LocalAppData%\Packages\CanonicalGroupLimited.*.ならんちゃらに突っ込まれる形式だから
ホストOSにゴミが残るってのも杞憂

最近はDocker Engineがそれなりに動く程度には互換性も高まってきてるみたいね
エクスプローラのアドレスバーからbashで窓側をカレントディレクトリにして起動できるのが良い

**デフォルトの名無しさん** · 2018/07/22(日) 20:20:13.96

>>192
> 互換性問題があるしかなり機能を絞られてる

WSL(Windows Subsystem for Linux)は、C++やLinuxシステムコールを使ったGNUプログラミング環境としては必要十分だと思うけど、具体的にどんな問題あるの？

**デフォルトの名無しさん** · 2018/07/22(日) 20:26:16.94

>>194
サービス書くときかな。
他はWSLが楽だと思う。

**デフォルトの名無しさん** · 2018/07/22(日) 20:28:26.39

Linuxを使う意図はサーバーか組み込みなので、WSLで足りない場合もあると思うんだけど、ひな形があれば済む話かもしれんね。

**デフォルトの名無しさん** · 2018/07/22(日) 20:31:49.81

サーバ系がサポートされてない
使うならVM使ったほうがいいよ
ファイルシステムもwindowsのものの上に作られてるのであれこれ問題が出る

>>193
1Gというのが笑えるｗ
コンパイルしないのかｗ

**デフォルトの名無しさん** · 2018/07/22(日) 20:34:24.26

>>197
VMは大げさすぎるかな。
使えるときはWSLを積極的に使っていきましょうよ。
とてもいいものですから。

**デフォルトの名無しさん** · 2018/07/22(日) 20:41:37.63

VMは一つのパソコンで複数のOSを動かすのでOSの数だけメモリーを食うんですよね。
その点、WSLはWindowsがLinuxのようにふるまうだけなのでWindows分のメモリーしか食いません。
そんなわけなので、お財布にやさしいんです。
それでいてサービスの開発以外では全く遜色在りませんし、そもそもサービス開発だって、大詰めを迎えるまではdaemonとして起動することはないでしょう。

**デフォルトの名無しさん** · 2018/07/22(日) 20:42:00.95

bash使うだけならわかるけどコンパイルも含めて何か使おうとするなら
既知の問題や互換性に問題もあるものを選ぶのはクレバーだと思わない

**デフォルトの名無しさん** · 2018/07/22(日) 20:44:34.92

WSL上のバッドノウハウをひたすら集めたいとか
縛りのある環境のほうが燃えるというなら止めはしない

ただわからない人に勧めるものじゃないなって思う
不具合があった場合それがどこ由来なのか特定できない人間には特にすすめちゃダメ

**デフォルトの名無しさん** · 2018/07/22(日) 20:45:31.78

>>200
ディストリビューターが開発する本物のディストリビューションですからまったく問題ありませんね。
Canonicalが開発した本物のUbuntuがWindowsで動くのです。
もちろんDebianであっても同じことです。

**デフォルトの名無しさん** · 2018/07/22(日) 20:50:22.91

>>199
>>202
ディストリビューターが提供しようが
WSLはlinuxでもないwindowsでもない不思議な物
両方の制限の積　windows ∩ linuxでありわざわざ苦労することはないよ

windows上の疑似linuxであってかなりニッチな物
どこかおかしくても不思議じゃない

**デフォルトの名無しさん** · 2018/07/22(日) 20:56:04.07

WSL、CMake、VCPKGがお勧めキーワードです。
C++ユーザーにはUbuntuをお勧めします。
gcc-7を導入してC++-17をご利用ください。

**デフォルトの名無しさん** · 2018/07/22(日) 20:56:30.30

どこかおかしくても不思議じゃない(どこがおかしいのかは知らない)

**デフォルトの名無しさん** · 2018/07/22(日) 20:57:52.61

今のWSLはLinuxのdaemonもサポートしてるから問題ないと思うんだけど、具体的にどんな問題起きたの？

**デフォルトの名無しさん** · 2018/07/22(日) 20:58:04.83

Visual Studio 2017にはLinux DebugとLinux Releaseというターゲットがあり、標準でLinuxをサポートしていますよ。

**デフォルトの名無しさん** · 2018/07/22(日) 20:58:48.25

c++使うような厳格さを求める人間がWSL使ってるとは思わなかった
WSLで動いたとして他の環境で動くとは保障されないのに
どこがおかしいのか推定もできない仕組みの上で何故ごみを作るんだ

**デフォルトの名無しさん** · 2018/07/22(日) 21:01:33.45

>>206
init機構がWSL用だから。
それを言い出すと、RedhatとUbuntuだって違うじゃないかということになるけど、Redhatに配備するものはRedhatで開発してたのが今までのスタイルなので、VMのほうが良いという人はその点を指摘してるんじゃないのかな。
それ以外にWSLを使わない理由がないので。

**デフォルトの名無しさん** · 2018/07/22(日) 21:04:40.18

まあ逆に言うと、WSLで動かないのであれば、Linuxディストリビューション間でも可搬性が無いよね。

**デフォルトの名無しさん** · 2018/07/22(日) 21:05:04.20

>>208
実機Linuxならどこがおかしいか推定できるという根拠はないでしょ。
むしろ、WSLのような抽象化された環境でさえ動かない稚拙なものを実機に持っていく気なの？と言い返すことさえできるのだけど。

**デフォルトの名無しさん** · 2018/07/22(日) 21:07:21.30

違う違う
普通のlinuxで動くコード書いててもWSL上では動かせない場合があるのが問題だろ

**デフォルトの名無しさん** · 2018/07/22(日) 21:09:42.72

>>212
そういうものがあるのかどうか知らないけど、あるならなおさらWSLで開発したほうが可搬性を担保できてよいのでは。

**デフォルトの名無しさん** · 2018/07/22(日) 21:10:55.12

>>211
根拠とかそんなんじゃない
考慮すべきことが多すぎる

自分のコードがおかしいのか
linuxのそもそもの仕組みがおかしいのか
MSのWSLがおかしいのか
ディストリビューターの提供してるイメージがおかしいのか

それぞれが組み合わさっておかしくなってるのか考慮する条件が増えすぎる

**デフォルトの名無しさん** · 2018/07/22(日) 21:11:03.95

>>212
問題なんてほぼないでしょ。
VM上で動いて喜べるレベルならWSLでも同じだから。

あなた、WSLで動作確認したことあるの？もしや憶測で書いてない？

**デフォルトの名無しさん** · 2018/07/22(日) 21:11:34.45

clはかなり寛容なコンパイラなので、gccでコンパイルできるかチェックしとくとより良いコードが書けますよ。
そんな用途でもWSLは素晴らしいと思います。

**デフォルトの名無しさん** · 2018/07/22(日) 21:13:06.02

>>214
それたぶん、自分のコードが悪いと思いますよ。
Linuxは十分安定してるので、Linuxの問題を真っ先に疑うのは、自信ありすぎだろって感じます。

**デフォルトの名無しさん** · 2018/07/22(日) 21:14:34.32

>>215
最初のころはめちゃくちゃだったのでもう入れてない
ハードリンクの仕組みもおかしいし
タイムスタンプもおかしいし
TCPなど制限も山盛りあった
すでにあるコードも何故か動かないことが多かった

**デフォルトの名無しさん** · 2018/07/22(日) 21:16:43.51

開発環境はWSLがいいんじゃないですかね。

**デフォルトの名無しさん** · 2018/07/22(日) 21:19:27.33

>>214
抽象化されていると問題特定が容易と考えるのが一般的だと思っていたのだけど、
抽象化された環境は問題特定が難しくなるという考え方は画期的ですね。

**デフォルトの名無しさん** · 2018/07/22(日) 21:21:02.02

linuxが安定ってジョークか
linuxカーネルは常にバグがボコボコ出てるよ

**デフォルトの名無しさん** · 2018/07/22(日) 21:22:41.34

クロスプラットフォームを標榜するなら、開発環境としてWindowsを選択するとよいです。
Visual StudioはWindowsとMacで使えます。
WSLによってVisual StudioからLinuxバイナリを構築できます。
MSBuildとCMakeは悩みどころですが、MSBuildはサポートが手厚く、CMakeはVisual Studioが無くても構築できます。
そこらへんで選択するとよいのではないでしょうか。

**デフォルトの名無しさん** · 2018/07/22(日) 21:28:34.40

まあ僕はVisual Studio、WSL、VCPKG、CMakeプロジェクトを使っているので、わかることはお答えしますよ。

**デフォルトの名無しさん** · 2018/07/22(日) 21:56:04.01

悪いことは言わないので、LinuxプログラムはWSLで動くことを優先して書くことをお勧めする。
他人のために時間を使いたくないのは誰でも同じ。おのずと楽に評価できる環境に流れるのは止められない。

**デフォルトの名無しさん** · 2018/07/22(日) 22:35:05.45

イスラームの救貧制度がかえって免罪符の役割を果たしてないか。
イスラームの救貧制度があることで、かえって商業上の強欲が横行していないか。

**デフォルトの名無しさん** · 2018/07/22(日) 22:37:37.06

誤爆したけど、謝罪はしない。

イスラム教は野蛮な宗教である ★4
ttps://lavender.5ch.net/test/read.cgi/whis/1525163440/

**デフォルトの名無しさん** · 2018/07/22(日) 23:57:15.36

だいたいでけてきたわ
ｺｰﾄﾞ修正をすることによって効果を簡単に計測できるように修正してる
こっちのが結構大変だったわ

**デフォルトの名無しさん** · 2018/07/23(月) 01:50:38.00

というわけでうｐした
長い戦いだった
http://fast-uploader.com/file/7087832585811/
baka_source.zip

build.shを実行すると、3つの実行ﾓｼﾞｭｰﾙができる

3つとも少し修正した（解析処理はﾌｧｲﾙがものすごい増えたから大きく修正したように見えるﾊｽﾞ）

　・ﾃｽﾄﾃﾞｰﾀｼﾞｪﾈﾚｰﾀ（ﾃﾞｰﾀの出力個数の出方を少し修正した）
　・ｽﾄﾚｰｼﾞ能力計測ﾌﾟﾛｸﾞﾗﾑ（I/OのｱﾄﾞﾊﾞｲｽをOSに与えるように修正）
　・解析処理（1. 解析の処理方法自体は一切かわってないがｺｰﾄﾞの構成をﾊﾞｶでも分かるように変更　2. I/OのｱﾄﾞﾊﾞｲｽをOSに与えるように修正）

**デフォルトの名無しさん** · 2018/07/23(月) 01:56:28.48

で、ﾊﾟｰｻﾞｰは基本に則った作りになってる
ｸﾗｽに分ける意味があるかどうかはおいといて
一般的な再帰下降ﾊﾟｰｻﾞｰになってる

BNFを構文解析する要領と同じといっていい
ﾊﾞｶでもﾁｮﾝでも分かるﾊｽﾞ

baka_parser_all
┣baka_parser_title
┗baka_parser_sections
　┣baka_sub_parser_section
　┣baka_parser_section_stat
　┣baka_parser_text
　┗baka_parser_elem
　　┣baka_sub_parser_xy
　　┃┗baka_sub_parser_qq_value
　　┣baka_parser_numbers_x
　　┃┣baka_sub_parser_qq
　　┃┃┗baka_sub_parser_qq_value
　　┃┣baka_sub_parser_rr
　　┃┗baka_sub_parser_number_x
　　┗baka_parser_numbers_x
　　　┣baka_sub_parser_qq
　　　┃┗baka_sub_parser_qq_value
　　　┣baka_sub_parser_rr
　　　┗baka_sub_parser_number_y

詳細な解析処理をする前に
簡易な解析処理をしたい場合（ﾌﾞﾛｯｸの位置情報やｻｲｽﾞ情報なんかだけを先に取りたい場合）、
そのｸﾗｽにそのﾚﾍﾞﾙの処理を突っ込んどけばいい
解析処理の詳細さの粒度はそこでﾃｷﾄｰにきめればいいと思う

**デフォルトの名無しさん** · 2018/07/23(月) 02:11:50.60

一応、parserとsub_parserの違いだけ捕捉しておく
結論からいえばﾃﾞｰﾀの形式がくさってるからそういうのを入れた

parserｸﾗｽは最初に一行読んで、必ず次の行頭（LFの次）でﾎﾟｲﾝﾀが停止するようになってる
sub_parserｸﾗｽは行は読まずに、与えられたﾎﾟｲﾝﾀから行の途中でﾎﾟｲﾝﾀが停止するようになってる

※ 例外はあるがsub_parserｸﾗｽは大体 LF の上（行末）で停止する
※ 停止しない例外は、sub_parserｸﾗｽが連続してる箇所が間違いなく該当することになる

**デフォルトの名無しさん** · 2018/07/23(月) 20:33:09.90

ｺｰﾄﾞの記述に一箇所誤りがあった
動作に影響は一切ないが記述ﾙｰﾙに問題があるから
修正しといたほうがいい

削除
　baka_sub_parser_section.h
　　(L34) ++c_buf_p_; // skip LF

追加
　baka_parser_sections.h
　　(L48)++c_buf_p_; // skip LF

ひたすら元のｺｰﾄﾞをｺﾋﾟﾍﾟして貼り付けてたから
気付かなかったわ

このｽﾚで相談してたﾊﾞｶはちゃんと動作確認してんのか

**デフォルトの名無しさん** · 2018/07/23(月) 20:39:12.44

ちなみにｵﾚのpcのosはvistaだからな
まずwslなんか動くﾜｹがない

あと、ｵﾚのpcは32bitの計算機だから
32bitのlinuxしか動かない
pcが32bitだからな

512MBのﾒﾓﾘでvmware動かして
slackwareのlinuxで動作確認をした

ちなみに64bitのwindowsは一切考慮してない
考慮不要だからな
32bitのlinuxと32bitのwindowsで動作確認はできてる

つまり64bitのlinuxでは動作確認はしてないが
一応、64bitのlinuxにも対応できてる想定になってる
きっと動く
※ baka_common.hぐらいの考慮で十分なﾊｽﾞ

**デフォルトの名無しさん** · 2018/07/23(月) 20:41:46.46

しょぼ

**デフォルトの名無しさん** · 2018/07/23(月) 20:47:36.06

実行速度は？

**デフォルトの名無しさん** · 2018/07/23(月) 20:53:16.24

ほとんどｽﾄﾚｰｼﾞの読み込み時間
ﾊﾟｰｽﾞはばっちり
これ以上ないﾃﾞｷだ

解析する量を減らせばもっと速くなる

動かせば分かる

印字されるｽﾙｰﾌﾟｯﾄを
どうすれば最大化できるか考えるのはこのｽﾚのﾊﾞｶだ
道具はほぼすべて揃ってる

**デフォルトの名無しさん** · 2018/07/23(月) 21:36:54.74

>>231
ブーメラン投げてんじゃねえよﾊﾞｶ

**デフォルトの名無しさん** · 2018/07/23(月) 21:41:33.21

パーズ

**デフォルトの名無しさん** · 2018/07/23(月) 21:56:50.52

>>228
I/Oのアドバイスとか何言ってるのか分からない。日本語でOk

**デフォルトの名無しさん** · 2018/07/23(月) 22:01:24.41

>>228

ありがとうございます。
なぜか下記修正をしないとコンパイルエラーで怒られました。
gcc-8.1を使っているけどそのせい？

baka_common.h
　PRIu64を有効にするため27行目に行追加：#include <cinttypes>

baka_spec.cpp
　107, 111, 125行目を修正：%d → %zd

build.sh
　clock_gettimeを有効にするためコンパイルオプションに-lrtを追加

少しコードを見ましたが、クラスのオブジェクト生成時に&があるのが
何を意味しているのかよくわかってなかったり、classのpublic内に関数名だけでなく
関数の中身も直接そのまま記述できるのを初めて知ったりと
色々新しい所があるのでじっくり見て勉強したいと思います。

つづけて実行結果を書きます。↓

**デフォルトの名無しさん** · 2018/07/23(月) 22:02:12.57

他でやれって何度も言われてなかった？

**デフォルトの名無しさん** · 2018/07/23(月) 22:03:34.73

取り急ぎ新しいgenツールで13GBを作り、読み込んでみました。
※ >>231 の修正ままだしてませんが大丈夫ですかね？

## spec(ハード性能チェック？)
LINUX% ../baka_spec ./aaa_13GB
Mon Jul 23 18:14:22 2018 : starting... 14107393277 bytes read (read block size = 131072 bytes) ./aaa_13GB
～
Mon Jul 23 18:14:24 2018 : done... 14107393277 bytes read (read block size = 131072 bytes) ./aaa_13GB
read_block_size ::= 131072 bytes, file_size ::= 13453.86 MiB, turnaround_time ::= 2.27 sec, throughput ::= 5920.39 MiB/sec

※複数回実行でだいたい5500～6000 MiB/sec

## parser
LINUX% ../baka_par ./aaa_13GB
"./aaa_13GB" : size = 14107393277 bytes
Mon Jul 23 18:15:19 2018 : starting... ../baka_par ./aaa_13GB
Mon Jul 23 18:15:19 2018 : section_count = 1, offset = 144275554 bytes, size = 144275513 bytes, turnaround_time = 0.21 sec, throughput =
646.15 MiB/sec
～
Mon Jul 23 18:15:39 2018 : section_count = 79, offset = 14107393277 bytes, size = 176862384 bytes, turnaround_time = 0.25 sec, throughput = 662.80 MiB/sec
Mon Jul 23 18:15:39 2018 : done... ../baka_par ./aaa_13GB
turnaround time : 20(secs)

ついでに前回のコードでも試しました。↓つづく

**デフォルトの名無しさん** · 2018/07/23(月) 22:04:55.29

## ついでに　https://ideone.com/E6QH2r　で同じファイルを読み込んだ時間
LINUX% time ./a.cpp aaa_13GB

strat... ./a.out /mnt/home2/pjupm/dbl/work/kinoshit/rve/cpp/final2/baka_source_kino/temp/aaa_13GB (null)
done... ./a.out /mnt/home2/pjupm/dbl/work/kinoshit/rve/cpp/final2/baka_source_kino/temp/aaa_13GB (null)

real 0m16.243s
user 0m14.024s
sys 0m2.199s

↑の実行時間約16秒と >>241 の約20秒の約4秒の差分はざっくり言うと
文字や数値をt_all_db構造体に格納するのに要した時間ということでしょうか？

**デフォルトの名無しさん** · 2018/07/23(月) 22:09:26.85

読み込み2秒
全部で16秒

ほとんどが読み込み時間？
嘘つき

**デフォルトの名無しさん** · 2018/07/23(月) 22:18:11.65

>>243

これは >>242 のことですか？
それぞれは下記のようですが、sys＝読み込みのみの時間　となるんですかね。

real プログラムの呼び出しから終了までにかかった実時間（秒）
user プログラム自体の処理時間（秒）（ユーザCPU時間）
sys プログラムを処理するために、OSが処理をした時間（秒）（システム時間）

**デフォルトの名無しさん** · 2018/07/23(月) 22:23:23.05

続きは半角とLINEでも交換してやれよ

**デフォルトの名無しさん** · 2018/07/23(月) 23:09:13.26

ｵﾚのとこでは
baka_parもbaka_specも
どっちも30～32MiB/secだから同じだ
つまりほとんど読み込み時間
どっちも8分ぐらいかかる

で、そっちのは

　baka_spec
　　turnaround_time ::= 2.27 sec　← 2秒で読み込めてる！

　baka_par
　　turnaround time : 20(secs)

そっちでは明らかに解析処理が足をひっぱってる
つまり初回の解析処理をさぼればもっと速くなるﾊｽﾞ

**デフォルトの名無しさん** · 2018/07/23(月) 23:24:47.71

http://man7.org/linux/man-pages/man2/posix_fadvise.2.html

posix_fadviseを追加したからな
ｼｰｹﾝｼｬﾙﾘｰﾄﾞであると

ちゃんと日本語になってるわ

**デフォルトの名無しさん** · 2018/07/24(火) 00:12:21.91

>>246
par, specともにほぼ同じですか。

すみません。話についていけてないです。。
初回の解析処理をサボるとはどういうことですか？

自分が書いたら40～50secだったので20secですでにかなり速いと思ってるんですが、まだ高速化の余地があるんですね。

**デフォルトの名無しさん** · 2018/07/24(火) 01:27:55.10

普通に考えたらこんなもん全部ﾒﾓﾘに格納しようというほうが
普通に考えて狂ってると個人的には思うからな、それ専用の計算機ならともかく

ちなみに全部ﾒﾓﾘに格納しようとすれば、その格納のｵｰﾊﾞｰﾍｯﾄﾞで
さらに時間がかかることになることは予見できてる
すべてﾒﾓﾘにのせるDBの発想に近いが、そういうDBMSでも起動時のﾛｰﾄﾞにはものすごい時間がかかる

かりにな全部ﾃﾞｰﾀをﾒﾓﾘに格納しないなら
全部解析する必要はない

過去にｾｸｼｮﾝは100個ないぐらいといってたと記憶してる
仮定の話になるが、例えば1ｾｸｼｮﾝ読みこむのにどれぐらい時間がかかるかということになる

いまぐらいの速度がでるなら
ｾｸｼｮﾝの位置とｻｲｽﾞだけを先に取得して
後で必要な部分のﾃﾞｰﾀを再度読みこんでｵﾝﾃﾞﾏﾝﾄﾞで解析しても
十分な速度がでるような気がしないでもない
（最初にどこまで解析して取得するかはとりあえず今はおいといて）

**デフォルトの名無しさん** · 2018/07/24(火) 01:32:16.00

で、やりたいことは、これまでのﾚｽを読むかぎりでは
でっかいﾌｧｲﾙの内容を画面に表示するだけだと思う

それだけのことなら実機の高い処理能力を考慮すれば
ﾄｯﾌﾟﾀﾞｳﾝ方式で必要な箇所をｵﾝﾃﾞﾏﾝﾄﾞでﾛｰﾄﾞして取得する方法で十分な気がする
そのほうが計算機にも優しいし、15Gのﾃﾞｰﾀを全部眺めるﾊﾞｶなんかまずいないだろうしな

こんな感じのことをやるのかなあとは思ってる

Ex.

　ﾃﾞｰﾀ取得の要求が3段階でされると仮定してる

　　①ｾｸｼｮﾝの列
　　②XY with QQ、RRの列（入力：ｾｸｼｮﾝのSEQ）
　　③数値の列（入力：XYのSEQ）

　A) 画面の初期表示では①で十分
　B) ｾｸｼｮﾝを展開して表示するときは②の取得で十分
　C) X、Yを展開して表示するときは③の取得で十分

**デフォルトの名無しさん** · 2018/07/24(火) 06:39:30.18

>>246
解析処理が足を引っ張ってるのは
お前の解析処理が遅いから

>>248
まともに作れば解析自体は8秒で終わる