C言語なら俺に聞け 142 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
はあ、そうですか
共有リソースの排他アクセスのためのAPIなのに、ロック対象がわからないからロック無視して最適化しますと
それが真実ならWinAPIとVCが腐ってるんじゃないですか メモリバリアを跨いでオブジェクトへのアクセス命令を最適化するとか
そんな頓珍漢なことを言う腐った奴がいるとは思わなかったわ
volatileを何だと思ってんだか CreateSection の使い方ぐらい調べてから書けばいいのに...
まあ他人事だしどうでもいいけど w CriticalSectionの話のつもりだったんだけど、CreateSectionに変わったの？
それならごめんだわ、>>378で唐突に出てきて誤字だとばかり
さすがにそんなアホな話題転換があるとは思わなかった >>385
ああすまん、予測変換で間違えてたわ
で、CriticalSection について調べたのかな？ >The following synchronization functions use the appropriate barriers to ensure memory ordering:
>Functions that enter or leave critical sections
>Functions that signal synchronization objects
>Wait functions
>Interlocked functions
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686355(v=vs.85).aspx
調べたけどCriticalSectionだけで十分そうだよ
Internallockedとかのほうが手軽そうだけどね https://teratail.com/questions/39986
これの投稿 2016/07/04 10:48の例にあるように
最適化で変数の効果が消えてしまう場合でも
volatileじゃなく変数書き込みや参照の部分に
CriticalSectionでロックしておけば最適化で消える事はないということ？ Cのコンパイラはクリティカルセクションなんて知らない。単なる構造体かなんかのtypedefとして実直にコンパイルするだけ。
スレッド関連の関数についても単に関数の一種として扱うだけ。
従ってスレッドやクリティカルセクションを扱っているかどうかが最適化の結果に影響することはない。
一方volatile指定はコンパイラが認識するキーワードで最適化に影響する。 ということは今回の事例だと排他制御しても不具合は解消できなかったという事かな？
volatile付けて最適化を無効にすることが正しい解決策だったということになる？ >>387
だからそれはメモリーバリアの話で最適化の話とは別だよ
繰り返しになるけど CriticalSection は排他制御するリソースを知ることはできないしコンパイラも CriticalSection のことを知らない >>390
どう言うことをやりたいのかよく見てないけど排他制御と最適化の話は別だから必要なら両方やらないとダメ >>389
それ、スレッドまわりが規格化されてなかった C99 までの話だよね？ こんな感じ。
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf
5.1.2.4/5
"The library defines a number of atomic operations (7.17) and operations on
mutexes (7.26.4) that are specially identified as synchronization operations.
These operations play a special role in making assignments in one thread visible
to another. ..." >>394
おおごめん、規格自体には詳しくない
しかし…
pthread関連の標準関数や定義を仮にコンパイラが特別扱いしたとすると、標準関数をラップしたり自作ライブラリで代替した場合に最適化の結果が変わるのかな？
そんな風にコンパイラ作るものなんだろうか。 posix-thread 関係については C++11 で追加されたが，
あくまでも言語処理系の中で定義された識別子（関数とかクラスとか）を使わないと，コンパイラには分かりえないよ．
CreateThread() とか CriticalSection とかの W32API の用語を，無指定でコンパイラが理解できるわけがない． >>390
コンパイラは基本的に問答無用で最適化するけど、それだとマルチスレッドではプログラマの意図しない最適化が起こってしまう
だから、メモリバリアを挟んだアクセス命令を入れ替えないことにしている
言い換えると、メモリバリア前に読み込んだ値をメモリバリア後も使うような最適化はしない
よって、バリア＋ロックで十分
共有リソースは全部volatile付けるなんてしてたら、kernelのソースとかvolatileまみれになるでしょ 当然、ローカル変数とか他から変更されないことが明らかなオブジェクトであれば最適化が起こる可能性は否定しない
グローバル変数の場合は、最適化されない
やってみればわかるけど、CriticalSecltionの有無でアセンブル結果が違う CriticalSectionに限らず未知の関数が呼ばれたのであれば、その中でグローバル変数やらが変更される可能性を考慮しなければならない
他にも、ある関数の引数にローカル変数のアドレスを渡すと、以降の別関数内でそのアドレス経由でローカル変数を変更される可能性がある
よって、場合によってはローカル変数であっても関数呼び出しを跨いで最適化できなくなることがある
わからないからこそ、最適化してはならないんだよ >>390
ならない。君のソースコードだけの問題だ。同期機構の使い方が悪いだけ。
スレッドなんてここ20年間バリバリに使われてる。
VC等の小慣れているコンパイラなら、最適化ありで全く問題なく動く。
(マルチスレッド向けのデバッグは完了している）
Debugでは動くがReleaseでは動かないケースに遭遇した初心者は、君のように
「最適化の問題であり今回はDebugを使うこと」を正当化したがるが、これは間違いだ。
ただしDebugビルドでもバイナリは出来るから、問題ないのならそれを使う手もある。 ちゃんと排他処理が出来ていないことに気付かず、デバッグオプション付きとか
遅いマシンとかで正常動作してしまい、何年後かに速いマシンにリプレイスしたら
丁度良くバグが顕在化するようなタイミングになってしまった、
なんてことが以前本当に起きた。
サーバ用とかでソフトが長期間使われる場合は要注意だ。 歯痛制御のバグ
珍しくない
発見しづらく、再現性も乏しく、解析に手間がかかりがち
レベルの低い開発者が混ざると大変 マルチスレッドは、たまたま動いているだけで、
ちょっとしたタイミングで、バグる
初心者は、たいてい、コンパイラのバグのせいにする。
それか、リリースビルドの最適化がおかしいと言う
プロは、Elixir などの関数型を使う いや、ちゃんとロックすりゃなんとかなるってw
もちろん最初から考慮されてる言語は何も考える必要ないからうまく行って当然。 初心者です。エラーでまくりでコンパイルすら出来ません。アドバイスお願いします。
■やりたいこと。
マウス入力にrawinputを用いるアプリのWndProcをフックし、rawinput(WM_INPUT）を強制オフにし、DirectInputを使用するように指定。
↓ソース
// FuckRawInput.c
#include <windows.h>
LRESULT CALLBACK WinProc(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam)
{
switch(Msg)
{
case WM_CREATE:
{
RAWINPUTDEVICE Rid[1];
Rid[0].usUsagePage = 0x01;
Rid[0].usUsage = 0x02;
Rid[0].dwFlags = RIDEV_NOLEGACY;
Rid[0].hwndTarget = hWnd;
RegisterRawInputDevices(Rid, 1, sizeof(Rid[0])) == FALSE) ;
break;
}
-----
また、この方法が最適なのかも不明です。ほかの方法等もあったら教えてください >>414
そのままの意味でC言語初心者ですけど？
rawinputを消し去りたいがためにプログラム未経験ながらＣ言語入門書を読み、
Visual studio2013でハローワールドのコンパイルに成功した所です。
他スレで聞いたら、
DLLインジェクションでAPI関数を置き換えといわれたんですが、
まぁ、それと同じような事をしようとして書いたソースが>>412
目的達成するためにどこが悪いのか教えてくださいよ どうやってWndProcをフックするつもりなのか知らんが、初心者のやることじゃない >>412
とりあえず文法エラーのないソースを出せよ >>415
windowsプログラムでFuckファックは初心者がやるものではない
何故かと言うとFuckファックは非常に拙いからで、これはご存じの通りにFuckファックつまりはセクロスとかセックスを意味する
FuckRawInputなどと書かれると非常に面食らうので、動作には全く関係ないがFuckファックの箇所をHookフックとする
Fookという間違いならまだしもFuckが出てくるのは途轍もなく拙い
windowsプログラムは入門書を一通り終えた後にようやく手を出せる程度に面倒くさい C++の標準でWindowsのCOMみたいなのはできるの？
モジュールがあれば動的リンクできて、向こう側の関数の形式とエントリポイントがわかるような。 >>418-422
WndProcフックでは目的の動作できなくて、APIフックしか手がないと分かりましたので、
MSのdetourとかいうの使ったAPIフックに変更されました。改めて、見てください。
@やりたいこと
Rawinputマウス関数が呼び出させられる代わりDirectInputマウス関数を呼び出し、強制的にマウス操作をDirectInputにする
ソース↓
// APIhook_RawInput.c
#include <windows.h>
#include "detours.h"
hoge target = NULL; // ターゲットポインタ
hoge tp = NULL; //トランポリンポインタ
// 関数生成
BOOL WINAPI Direct_Input(HWND hWnd, UINT Msg, WPARAM wParam, LPARAM lParam) {
return tp(hWnd, Msg, wParam, lParam);
}
// user32インスタンス
HINSTANCE xxxxx;
case WM_CREATE:
//user32.DLLをロード
xxxxx = LoadLibrary("user32.dll");
//Raw Inputポインタ取得
target = (hoge) GetProcAddress(xxxxx, "WM_INPUT");
// WM_INPUTフック、"WM_INPUT"→"Direct_Input"置き換え
tp = (hoge) DetourFunction((PBYTE) target, (PBYTE) Direct_Input);
break;
// 終了時の処理
case WM_DESTROY:
// フック削除
DetourRemove((PBYTE) tp, (PBYTE) Direct_Input); >>426
で、お前が聞きたいのは「C言語」に関するどんな質問なんだ？ 会話にすらなってないな。
こういうのホントにいるんだよなあ。、。 >>415
> どこが悪いのか教えてくださいよ
頭と態度。
APIスレも見たけど、君には無理。 これ無理だろうWindowsプログラムの言語を理解してないと直せないっしょ 勘所がすぐつかめる人ならそうでもない
知らんOS知らん言語知らん環境でもデバッグできちゃうんだぜ
あいつら宇宙人だろ >16 ：デフォルトの名無しさん：2006/03/10(金) 22:15:19
>>>10
>> こんな変数名があちこちに散らばっているのがPerl
>
>大学の研究室のボスは、特殊変数の表をふ～んと2分ほど眺めて完全に暗記した。
>
>そういうレベルの人たちのための言語なんだなと思って、トイレで血の涙を流した。 お助けください。
自作コードにおいて、以下の部分でmemsetの際にsegmentation faultになってしまいます。
int n = 2;
char charList[n+1][32]; // 32文字の文字列をn+1確保・・・①
func(charList); // charListに書き込む関数
for (int i = 0; i < n; ++i) memset(charList[i], ' ', 32); // 空白で埋めたい
funcを省いたりmemsetの前に適当にcharListをプリントしたりすると何故か問題なく動きます。
この部分だけ切り出したテストコードでは全く再現しませんでした。
この手のエラーでよくあるのは未初期化領域へのアクセスだと思いますが、
①で領域の確保はできているからこれは原因ではないですよね？
どこがエラーの原因でしょうか・・・？ 配列サイズ 32要素で 32個 空白で生めてるが
文字列 という用語を使ってるあたり func は一般の文字列操作してそうだけど
終端記号 '\0' の分の考慮が落ちてるんでないの？ 「文字列」で32文字を取り扱いたいのなら 33要素の器が必要ってことで
文字の配列なら問題ないけどねー >>437
＞char charList[10000][10000]; // 32文字の文字列をn+1確保・・・①
くらい確保して実行すれば動くだろ int n = 2;
char charList[n+1][32];
C言語的に、これってOKだっけ？ char charList[n+1,32]こうしないとダメだよね？なにかっこ二つ使ってんだよ読み込めねえよって昔2次元配列で怒られたな 最近どころか、20年近く前からだし
>>448みたいな文法は存在しないんだけど、どこの世界のC言語なんだろ iOS11にしたらまともに入力できない
このクソOS iOS11にしたらまともに入力できない
このクソOS 返事が遅れてすみません。レスありがとうございます。
再現性の乏しい質問で申し訳ないです。
>>438
nは変わらないです。
>>441
文字列操作ではあるんですが終端記号は書き込みません（全部文字だけ）
>>444
OSはCentOS 6.9、言語はc++、コンパイラはgcc7.1.0です。
さっぱり原因が想像できないのですが、考えられる可能性としては、funcの中でメモリがずたずたに壊れたものの
偶然エラーにならずに戻ってきてmemsetでやっと死んだ、というパターンでしょうか？ >>452
存在するだろ
char charList[32]と等価になるぞ 二次元配列の宣言についての話で合って
コンパイルが通るかどうかだけの話なんてしてねーぞ ってか二次元配列と二重配列間違ってねーか？
それとfunc呼んでからmemsetしたらfunc呼ぶ意味あるの？
memsetもループさせるんじゃなく一回で全部fillした方がよくない？
とかとか。 >>467
1行目 イミフ
2行目 意味があるから呼んでるんだろ
3行目 明確な利点があるならそれを書け >>468
ポインタの配列と二次元配列を間違ってるのではないかってこと。
書き込んだあと空白で埋めたら意味なくないか？funcが何してるか知らんけど >>469
funcの中身を知らないのに「意味無い」とか「意味あるの？」とかっていう書き込み、意味あるの？
それを聞けば問題の解決になるの？
少なくとも空白を埋めてない部分があるし
問題が発生する範囲で簡略化したのかもしれないし
当然意味があるから呼んでるんだろうと思うのが普通 最近オブジェクト指向が入り口で、C言語がわからんっていう子が多いからなあ 再現する最小限のコードに削ってるうちに問題点を自ら発見して終了 つーかfunc()以外の部分で特に問題が見当たらないならfunc()のせいで確定という単純明快な話
自作コードならfunc()もうｐできるっしょ >>470
出されたソースのコメント見ると、配列の考え方が間違ってるように感じるけどね。それを示唆したかっただけだよ。 >>462
ふと疑問に思ったんだが、
＞func(charList); // charListに書き込む関数
関数を呼び出す際に、nの値を教えなくて良いのか？ >>475
例外とは関係ない
合コンじゃないんだから無駄に話を広げる必要はない
問題の解決が遅くなるだけ あとはfuncの中身を見ないとなんとも
組み込みのショボい環境だとスタックオーバーフローって可能性も無いことは無いが ■ このスレッドは過去ログ倉庫に格納されています
