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/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秒で終わる

**デフォルトの名無しさん** · 2018/07/25(水) 00:09:01.02

>>249,250

＞すべてﾒﾓﾘにのせるDBの発想に近いが、そういうDBMSでも起動時のﾛｰﾄﾞにはものすごい時間がかかる

まさにこの発想で考えていました。
すべて構造体に格納しようかと…

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

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

アドバイスありがとうございます。

1stステップ　→上記①のセクション名、次行にあるx/yの個数、その次のテキスト行を取得しGUI表示
2ndステップ　→GUIから　セクション内の数値全部　or　x/yの任意の番号　のどちらかを選択し表示（上記②③をその都度fseekでピンポイントに取得）

の2段階で検討してみます。
支配的なのは③の部分なので、そこを分離すれば負荷はかなり減るのではと思います。

>>251

8秒ですか。。
そのようなハイレベルな解析は日曜大工レベルの自分には当分作れそうにないです…

**デフォルトの名無しさん** · 2018/07/25(水) 01:22:39.02

>>252
何をする気か知らんし、読み返す気もないが、
> 日曜大工レベル
なら他言語使えよ。今のC++は君向けではない。
一通りも出来ないのだから、普通はPerl/Ruby/Pythonのどれかだと思うが。

あとここは「ぼくのさいきょうのそふとうぇあ」のスレではないから、
実際埋め立て状態だし、全く終わる気配もないし、
別スレ立ててやるのがマナーだと思うぞ。

**デフォルトの名無しさん** · 2018/07/25(水) 05:58:28.01

A.exeがB.exeを立ち上げる

A.exeがB.exeの起動時に共有メモリ先を渡すのに
その空間を指定するのはどうすれば良いんでしょうか

**デフォルトの名無しさん** · 2018/07/25(水) 06:13:44.62

共有メモリの名前を渡す

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

winAPIのmemorymapedfileを調べてみたけど
winAPI便利だが触ったことないと敬遠しちゃう

**デフォルトの名無しさん** · 2018/07/25(水) 13:33:42.64

>>253
日曜大工とか書いてるけど、サーバー使ってやるとか言ってたから実務だと思うが
あまり初心者を弾くようなことを言うな

>>252
速度は実用レベルになりゃそれでとりあえずいいんじゃないの
ドヤりたいやつや喧嘩したいやつに惑わされるな
回答は参考にとどめて、自分でやってみてどうしてもわからないところだけ聞きに来い
スレを私物化するな

**デフォルトの名無しさん** · 2018/07/25(水) 17:57:43.34

>>254
プロセス間共有メモリはプラットホーム依存でありC++の範疇ではないので、続きは以下スレでどうぞ。

>>256
あなたも。

Win32API質問箱 Build124
ttps://mevius.5ch.net/test/read.cgi/tech/1510395780/

**デフォルトの名無しさん** · 2018/07/25(水) 19:13:03.63

>>257
この程度のことを延々と続けられては、迷惑行為でしかないだろ。
実務なら上司に聞け、でしかないし。

最近アホが大量流入して、このスレは一気にレベルが落ちたよな。
お前らがそれについてどう思っているのかは知らんが。

お前は「プログラミング初心者」をここで飼いたいのか？
「C++初心者」はいいとして、C++は「プログラミング初心者」向けの言語ではない。
そもそも組み方も根本的に間違っている気がするが、
俺はこんな奴に教えてやる気はないし、
他の誰も指摘しないところを見ると、まあそういうことなんだろ。
（俺はソースは見てないが)

**デフォルトの名無しさん** · 2018/07/25(水) 19:15:56.59

確か上級者スレってあったはず
上級者はそちらに移動し、ここを見ないで

**デフォルトの名無しさん** · 2018/07/25(水) 19:32:17.67

空気読めないド初心者と、ド初心者相手にマウント取ってイキってる半角雑魚オヤジが二人で傷を舐め合ってるだけ
その二匹をNGすれば平常運転よ

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

>>260
乗っ取るのではなく、お前が移動しろよ馬鹿タレ

【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

**デフォルトの名無しさん** · 2018/07/25(水) 20:01:29.95

>>259
いやそもそもは速度が必要なのでC++選んだ(C++については素人なので、何故自分のコードが遅いかわからない)、という話
最初の質問は何もおかしくなかったよ
前スレはもう読めないかもしれんが。

もういい加減自分で進められるだろうからいちいち報告しないでほしいが

**デフォルトの名無しさん** · 2018/07/25(水) 20:20:05.41

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

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

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

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

#include <stdafx.h>
後死ね。

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

いつまでこの糞テンプレ張り続けるんだおい

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

>>263
なんだかんだでこのテンプレが馬鹿よけとして素晴らしく機能してたって事だよ。
それを嫌う奴が無理に剥がそうとした結果、このザマだ。
このテンプレはこのスレを極めて的確に表現しているし、C++のノリはこれだよ。
しかし、スレ検索するとC++スレって40もあるのな。正直びびったわ。
適切なスレを探すことも出来ない馬鹿にはC++なんて無理だってことでしかないが。

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

>>263
これか？
(専ブラでは読めないが、今はdat落ちしないので、通常ブラウザなら過去スレは基本読める)

> 743デフォルトの名無しさん (ｱｳｱｳｳｰ Sa0b-sule)2018/07/07(土) 23:53:17.73ID:HbEbhDY0a
> LINUXで15GBくらいのテキストファイルを読み込みこんでGUIを作ろうとしています。
> ファイルが大きいため速度が出せる言語で、かつGUI作成は情報量が多いと調べやすいので、まあまあメジャーな無料のGUIライブラリを使用したいと思っています。
>
> perl>>python>>>>C++　の順で経験があり、C++はあまり詳しくないですが、速度重視でC++で行こうと検討しています。
> GUIライブラリを調べているのですが、C++のGUIはあまり情報を見つけられず、めぼしいのはQtくらいしか目に付きませんでした。
> 会社のサーバのローカルディレクトリにQtをインストールしてみましたが、必要なライブラリが古かったりで、インストールできませんでした。
>
> 他に何かおすすめなGUIライブラリはありますでしょうか？
> https://mevius.5ch.net/test/read.cgi/tech/1528382412/

ならC++選んでいる時点で間違いだろ。
理由は教えてやらないが、当然そうだからこそ、適切なライブラリがない。
というか、本当に初心者でないのなら、
適切なライブラリがない＝みんなやってない＝地雷臭を感じとれっての。
C++で書けば何でも速くなると思っている馬鹿、最近増えたよな。何故かは知らんが。

**デフォルトの名無しさん** · 2018/07/25(水) 20:52:15.60

くだらない選民思想はやめた方がいいよ、C++をベターCとしてしか使えない人でも
素晴らしいソフトを書き上げてる人は腐るほど居る

大体選民思想に走るやつってC++を実用してないやつなんだよなぁ・・・

**デフォルトの名無しさん** · 2018/07/25(水) 20:54:27.06

>>265
読めるなら読んでから言えよ

＞適切なライブラリがない。
＞みんなやってない＝地雷臭を感じとれ
俺ゲーム屋なんだけど、居た会社はどこもみんな自社でライブラリというかフレームワーク作ってる
全部地雷なのか？
お前アマチュアだろ？

**デフォルトの名無しさん** · 2018/07/25(水) 20:55:36.48

>>253,257

ご意見ありがとうございます。
自分にはもったいないくらいの洗練されたコードまで出して頂いてとても感謝しています。

アドバイスの通り、頂いたコードを元に自分で調べて見ます。
また色々やってわからないことろがありましたらご相談させてください。

あと、このスレはこれからも拝見させていただきたいと思います。

**デフォルトの名無しさん** · 2018/07/25(水) 21:34:44.04

共有ポインタがC++に正式採用されたことで、JavaなどGC機能を持った他言語の優位性が薄れたわな。
コンパイル速度も上がったし、開発機のメモリも増えたしで、昔よりC++を使うストレスが軽くなった。
なので皆、C++に回帰してくる。

**デフォルトの名無しさん** · 2018/07/25(水) 21:47:04.47

>>265
うわっ
なんだこの初心者丸出し野郎

>>266
> C++をベターCとしてしか使えない人でも
使えない
じゃなくて
いろいろと判断してそういうコードに意図的にするんだよ

そう判断する理由の例としては
互換性
パフォーマンス
コードサイズ
開発工数 / 評価工数
等々

**デフォルトの名無しさん** · 2018/07/25(水) 21:52:55.17

>>267
話の内容から読む価値が全くないと分かるから読まないんだよ。
つか、初期はみんなまともな指摘してるじゃねえかよ。
ガン無視して今の有様のようだが。

> お前アマチュアだろ？
お前も無駄マウントするのではなくて、実力は投稿で示せよ。
そもそもC++用ゲームエンジンはありまくりだろ。
C++はその用途に向いているからみんな使ってる。だからそういう現実がある。
俺はそういうことを言ってるんだよ。
(日本の会社は何故かプロプライエタリに拘っているのも事実だが)

**デフォルトの名無しさん** · 2018/07/25(水) 22:11:44.07

>>271
＞お前も無駄マウントするのではなくて、実力は投稿で示せよ。
俺は半角のコードでいんじゃね？と思ったんで何も言わんかったｗ
＞C++はその用途に向いているからみんな使ってる
あーそういうことか
でも構文解析をC++でやるのは決して間違いではないと思うけどな

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

単純な構文解析を大量に行う
なんて処理はCやC++がぴったりと思う

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

まあ新しい機能がバンバン入る言語やライブラリってのは選民思想が湧きやすいもんよ。
昔からこの業界のそういうところは変わらん。
そしてそういうものがレガシーコードを量産するという現実も変わらん。

**デフォルトの名無しさん** · 2018/07/25(水) 23:04:43.31

>>272
> でも構文解析をC++でやるのは決して間違いではないと思うけどな
大昔：yacc/lex
昔：bison/flex
最近さらに何か出てたと思ったが、使う気がないので忘れた。

そもそも元が15GBあって、それを全部目で見るわけないだろ。
単純には grep -i error とか、複雑ならいちいちperl等で切り出して眺めるもの。
やってることが最初から見当違いなんだよ。
仮に15GBのテキストを開けるテキストエディタを作ったとして、
スクロールバー長が1500pxあったとしても10MB単位でしかなく、
ドラッグアンドドロップでのスクロール操作は使い物にならない。
当然、マウスホイールで数行単位、クリックで１画面単位でスクロールしても埒が明かない。
結果的に行数じか打ちのジャンプしかないんだから、sedでいい。

俺が教えてやらねえ、って言ったのはこの件ではないけど、
「誰もそういうことをやらないからそういうもの（ライブラリ等）がない」ってのはあるから、
初心者なりにちゃんと考えろって事だよ。
上記は初心者でも理解できるだろ。気が付かないのは考えてないだけ。
そんな奴は勝手に死んでよし。

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

＞単純には grep -i error とか、複雑ならいちいちperl等で切り出して
確かそれはやりたくないって言ってたと思う
まぁ、俺もテキストのまま扱うのはどうかとは思ったけども

別に内容書き換えるわけじゃないんだしトータルでもメモリ上に残す情報は
大した量にはならないだろうから全部読めばいいじゃん、テキストは内容を理解したそばから捨てていいんだから
（用途が俺もわかってないからどっちがいいか不明だけど、初めて使うウインドウを開いたときに
ファイルアクセスと構文解析のラグを許容できるか、それとも立ち上げ時のラグを許容できるかどうか）

ってまぁ、さんざん既出なんでこのネタはもうやめようｗ

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

ｵﾚのｺｰﾄﾞのｴﾚｶﾞﾝﾄさが分かるようならまだ芽はある
ｵﾚのｺｰﾄﾞのｴﾚｶﾞﾝﾄさが分かるなら、もう一人でｺｰﾄﾞが書ける
これからも頑張り精進したまえ

低学歴知恵遅れﾆｰﾄのいうことなんかほっとけばいい

>>275 ← こういう低学歴知恵遅れを見れば分かるとおり
相談してる相手がまずなにがやりたいのか全く理解できてない
まず知能に著しい欠陥があるからまずなにごとであれ
要件というもんが理解できないのは間違いない

ｵﾏｴも人に仕事をたのむだけの立場になったらな
>>275 ← こういうﾊﾞｶには仕事を頼んではﾀﾞﾒだ
ということもこのｽﾚで学べたﾊｽﾞだ
ｺﾚもこのｽﾚで得た貴重な体験だ

ｺﾐｭﾆｹｰｼｮﾝ能力がｾﾞﾛのﾆｰﾄみたいなﾔﾂだからな

こういうﾔﾂは
間違いなくこっちがお願いしたもんとまったく違うもんあげてくる
つまりこんなﾔﾂには最初から仕事頼んだり関わらないのが吉
こっちの余計な手間と時間だけがかかるからな

このｽﾚは、色々学ぶことができる
これからもちゃんとこのｽﾚ読んで精進しなさい

**デフォルトの名無しさん** · 2018/07/25(水) 23:28:31.94

sqliteはメモリ上にデータベースを構築できる。
どうせやるならsqliteに勝てるような車輪の再発明を期待したい。

**デフォルトの名無しさん** · 2018/07/25(水) 23:31:38.85

ramdiskで良くね？というのもある。

**デフォルトの名無しさん** · 2018/07/26(木) 00:14:32.88

>>276
ってかまじな話、正解だと思えるレスも散見されてるぞ。
無視してるんだからどうしようもないが。何がやりたいんだこの馬鹿は？
なお、俺的に正解と思えるのは、以下。（見落としあるかも）
----
773デフォルトの名無しさん (ﾜｯﾁｮｲ e7c3-WPlw)2018/07/08(日) 23:16:50.92ID:w/p0hjmq0
テキストのパースなんてそれこそperlやpythonにやらせろよ
そんなところが速度にクリティカルに効いててゴリゴリ高速化しなきゃいけないのは作りがおかしい

866デフォルトの名無しさん (ﾜｯﾁｮｲ 5fb3-C8Iw)2018/07/09(月) 22:41:30.68ID:Xc+Rjkat0
最低限のパースを実施して各レコードのオフセットを配列に入れて必要になった時に解析して表示すればいいだけかと

873デフォルトの名無しさん (ﾜｯﾁｮｲ e7c3-WPlw)2018/07/10(火) 01:34:56.63ID:C7bP6ErJ0
なんかのログなんだろうけど、ログ吐く時に読み込みやすいように出し方考え直した方がいいよ
大本が変えられないならパイプ繋いでフィルタ噛まして、読みやすいように直したファイルを並行して吐くとかさ

というかまず単にSECTION_NAMEごとにファイルぶった切っておくだけで良かったりしない？難しく考えすぎてない？

874デフォルトの名無しさん (ﾜｯﾁｮｲ e7c3-WPlw)2018/07/10(火) 01:46:08.72ID:C7bP6ErJ0
どういうGUIが必要なのかわからんから的外れかもしれないけど
ワイならSECTION_NAMEごとに集計したHTMLファイルかなんかを出力するプログラムをワンパスかけてから
後でそのHTMLをブラウザで見ることを考えたくなるんだけどそれじゃダメなの？

880デフォルトの名無しさん (ﾜｯﾁｮｲ 4750-SFkP)2018/07/10(火) 07:31:15.21ID:wSs+8Os00
初めて開くファイルは使いやすいように変換して(キャッシュとして)保存しておいて
次回以降それを使うか
全ファイルバッチ処理で事前に変換しておくか

かな

ファイルを開く度に分オーダーかかるのは使いづらい
どちらが良いかは使い方次第で

**デフォルトの名無しさん** · 2018/07/26(木) 00:15:01.25

まあ、俺ならperlで15000のファイルにあらかじめパースしてぶった切って、lessで見るね。
テンポラリファイルの有効/無効はタイムスタンプをチェックすればいいだけだし。

初心者は(選択肢を思いつけないから)無駄に難しい選択をしてはまることはよくあるけど、
正解をガン無視しているんだから死ねでしかないね。
これではお前ら的にもどうしようもないわな。

嘘を嘘と(ry　は当然だが、
正解を正解と(ry だな今回は。

**デフォルトの名無しさん** · 2018/07/26(木) 00:27:42.26

やっぱりなｺﾚが低学歴底辺の限界
わかるわ

所詮、低学歴底辺のﾄﾞｶﾀ
低学歴底辺のﾄﾞｶﾀは自分でﾛｸﾞ見るらしいからな

すぐに分かるのが恐ろしい
このｽﾚにはそんなのしかいないわ

**デフォルトの名無しさん** · 2018/07/26(木) 00:30:53.03

ｸｿﾆｰﾄの趣味のぱちょんこん講座の邪魔されて
ｸｿﾆｰﾄどもがｲﾗｲﾗしてるのはわかるわ

ｸｿﾆｰﾄのﾂｰﾙなんかｸｿﾆｰﾄしか使わないからな
ｸｿﾆｰﾄらしい発想といっていい

まず自分がどうするありきだからな
自分以外の人間なんか関係ない

ｸｿﾆｰﾄ臭がﾌﾟﾝﾌﾟﾝする

やっぱりなﾆｵｲは隠せないわ

**デフォルトの名無しさん** · 2018/07/26(木) 05:31:33.95

自己紹介乙

**デフォルトの名無しさん** · 2018/07/26(木) 07:10:18.33

前スレからID追うと、このスレ立てたの15Gテキストの質問者で
ﾜｯﾁｮｲとテンプレを失敗してる

いっそﾜｯﾁｮｲ付きで立て直して、ここは放棄するのもありじゃないかな…

**デフォルトの名無しさん** · 2018/07/26(木) 08:02:19.67

失敗してるワケねーんだよなぁ
ワザとだろ
俺TUEEするためだけに立てられたクソスレだよｗ

**デフォルトの名無しさん** · 2018/07/26(木) 08:03:29.18

やってることがTUEEとDANZAI、アホなSS未満のクズだろ
だからﾜｯﾁｮｲは無いｗ

**デフォルトの名無しさん** · 2018/07/26(木) 15:23:01.83

世の中のパーサーは入力としてストリームを想定する場合が多い。
一方、OSはストリームを想定しなくなってきている。
IOCP、epoll、kqueue等を想定するプログラムにとって、必要なものは、一文字入力すると状態が変わるようなプッシュ型パーサーではないだろうか。

**デフォルトの名無しさん** · 2018/07/26(木) 22:05:05.87

文字列変換を質問したい

**デフォルトの名無しさん** · 2018/07/26(木) 22:11:39.16

途中で送ってしまった...
キャラポインタをビーストリングに変換したいです
マルチバイトトゥーワイドキャラでよい？
今やってるのだけど一切できなくて辛い

環境はウィンドウズです
エヌジーワードのためカタカナ混ぜてます

**デフォルトの名無しさん** · 2018/07/26(木) 22:43:19.63

>>290
C++的な回答をするなら、BSTRをラップしたCComBSTRクラスを使ったほうが楽だしドキュメントも多くていいと思うよ。

**デフォルトの名無しさん** · 2018/07/26(木) 22:54:29.47

>>291
そんなのがあるんですね

コム使うのは良いのかわからんな...

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

>>292
すでに知らないうちにCOMを使っているはずなので、今更COMを使ってよいか気にしなくていいよ。

**デフォルトの名無しさん** · 2018/07/26(木) 23:23:33.36

>>285
俺は賛成。STLのテンプレもありでよろしく。
(まあ俺が賛成しても大局に影響はないが…)

◆QZaw55cn4c · 2018/07/26(木) 23:29:25.64

>>294
別にテンプレがあろうとなかろうと、スレに投稿される内容に変わりはしない、と思うのですが？
もしかして「おまじない」とかが好きなんですか？

半角氏は連続して投稿する傾向にあり、IDだけで割合に弾けるのでﾜｯﾁｮｲは要らないと思っています

**デフォルトの名無しさん** · 2018/07/26(木) 23:42:18.00

あんなテンプレいらんだろ…
まさか自分が作ったとか？

**デフォルトの名無しさん** · 2018/07/26(木) 23:55:55.79

>>295
> テンプレがあろうとなかろうと、スレに投稿される内容に変わりはしない
ならあってもいいって事になるが、それに対する反論は？

俺はワッチョイもあのテンプレも機能してたと見ている。
実際、もう初心者要らないんじゃ、って話になってたのは事実だろ。
お前がそれに反対したのも事実だが。

**デフォルトの名無しさん** · 2018/07/26(木) 23:59:13.70

>>280

ご意見ありがとうございます。

SECTIONごとの切り替え目安は下記の時間でSECTIONを切り替えながら別のGUIソフトでマウスを使って改善していきます。

①数値の数が一桁～二桁程度だと数分で切り替え、
②数百～数千レベルだと数十分～数時間で切り替え、
③そしてまた再実行しファイルを読み込み①に戻る

初期の小さい規模ではSECTION数が数十個で、各SECTIONの数値の個数はせいぜい数百レベルなのでSECTIONの切り替えが頻繁に発生します。
そして①～③を回すのが数十分～数時間くらいでそれをくるくる回します。
数ギガレベルになるのは終盤になってからです。

という感じなのでファイルの再生成が頻繁に行われ、かつGUIでマウスで改善していくので
マウスが手放せず解析表示もGUI操作が必須になる、という感じになっています。

小さい規模では特にSECTION切り替えが頻繁に発生するのでファイル分割で管理がわずらわしくなるのを避けたい。
まずここに重点を置き、そうすると大きい規模では読み込み時間がネックになるので高速化で対応しよう。
という状況で現在に至っているところでした。