C言語相談室(上級者専用）

2018/03/02(金) 22:48:03.65

C言語の話題のみ取り扱います。C++の話題はC++スレへ。
上級者専用です。10,000行程度のソースを扱えない人は以下スレへ。

C言語なら俺に聞け
https://mevius.5ch.net/test/read.cgi/tech/1519046038/

適宜以下を使用してください。
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

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

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

2018/10/16(火) 22:05:32.39

頭にFT_が付くのはfreetypeの識別子だ。freetypeライブラリそのものは、設定項目以外は編集できない。

2018/10/16(火) 22:26:02.42

>>155
ああなるほどね。

それなら freetype -> win32API の変換関数群をひとまとめにしておきたいところだが、
それが freetype.c そのもの、というわけか。
なら、freetype.c 内で1回グダグダコピーするのは致し方ないし、そのコードで妥当だ。

ただまあ、正直なところ、コードのリファクタは将来への投資であって、
実利自体はないし、やり出すとキリがない。
気になってるところがあるのだから、さっさとそこに取りかかった方がいいと思うぜ。
フォントエンジンが速くなれば、地味にOSのレスポンスも上がるはずだし、喜ばれると思うよ。

2018/10/29(月) 22:10:10.28

https://gist.github.com/katahiromz/36f7135d3afe9fe6d2b7b28816be0f30

Can you read this ReactOS codes?

2018/10/30(火) 21:47:14.89

>>157
読める/読めないなら、読めるだろう。
リソース確保して実行して解放する、上位コードに見える。
ただし、何をやっているかは正確には分からない。（部外者だからだが）
パスを取って、広げて、レクタングルのリージョンにして、クリップして、ペイントしているから、画像系の何かだろう。

ただ、前から思っているのだが、（君のせいではないが）
リソース確保、普通にネストにした方が良くないか？

retval = false;
a = malloc(...);
if (a) {
b = malloc(...);
if (b) {
c = malloc(...);
if (c) {
retval = true;
free(c);
}
free(b);
}
free(a);
}
return retval;

それ、ネストを嫌うあまり、PATH_Delete(pPath->BaseObject.hHmgr); を3回もコピペしてるだろ。
それじゃ逆に意味無い。バグの検出が難しくなり、コードの品質が下がる。
（同じ努力でデバッグした場合、比較的コード品質が低いままになる）

2018/10/30(火) 21:47:51.74

上記のコード、freeは1回ずつしかないから、忘れてたら『常に』リークする。
だから、バグの検出が容易となる。（すぐ検出出来る）
GitHubのコード、3つ目のPATH_DELETEは正常系だからここを忘れたらすぐに検出出来るけど、
1つ目のところで忘れたら、容易には検出出来なくなる。
結果的に、バグっててもなかなかヒットせず、バグを残してしまう。
「バグを検出しやすい構造」ってのも、コード品質を上げる為には重要だよ。
前も思ったけど。前は4回コピペしてたでしょ、確か。

正しく全部書ききればいい、それは事実だけど、実際それが難しいからバグになるのであって。

この意味ではGo言語も糞だ。
JSONの定義をしたら、定義、仕様、タグ、と3回「同じ事を文法的に書かなければならない。」
俺は早々にそれに遭遇して、もうGoは使わないと心に誓った。
俺は上記のように、コードを重複させないことに重きを置くから。
このコードのように、何度べたべた書いても平気な人は、Goも許せるのだろうけど。
ただこんな書き方だと、細かいバグが永久に取りきれないと思うけどね。

オブジェクト指向の、メソッドを集中使用するやり方は、実は地味に効いてる。
あれだと、メソッドのバグは速攻検出されるので、コード品質は上がりやすい。

2018/10/31(水) 18:43:08.64

リソース確保はループかプールで必ず成功するようにできんか？

2018/10/31(水) 18:56:15.53

ループでは無理だろ
ここでプールを使うのも最悪だ

2018/11/01(木) 20:00:57.97

クリティカルコンテキストでもないのにプールは無駄。
ループでリソース確保するのはプロジェクトのポリシー次第。

2018/11/02(金) 12:02:06.04

ReactOSのバグ案件がまた来た。
以前に「Fix font metrics」というコミットをしたわけだが、、、
https://github.com/reactos/reactos/commit/35f62fc5ba0b69e7335ff41400cb3b45660f4557
これがどうやらguilty commitらしい。
一つ目の案件。https://jira.reactos.org/browse/CORE-15303
二つ目の案件。https://jira.reactos.org/browse/CORE-15166
ちなみにrappsというのは、ReactOS Applications Managerのことだ。
現在の実装は以下の通り。
freetype.c: https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/freetype.c
text.c: https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/text.c

2018/11/02(金) 14:54:13.53

>>163
見た。今まさに対処中か。

> Shall we use a strategy of partly restoration of commit 35f62fc?
やり方はあってると思うぜ。まずそれで絞るべきだ。もっとも、

> the font size is just unbelievably tiny, teeny-weenee!
これでほぼ確定的に分かるはずだし、実際そんな雰囲気だが。

2018/11/06(火) 17:28:59.17

https://jira.reactos.org/browse/CORE-11944
いわゆるゴーストウィンドウを実装している。ウィンドウに反応がないときに白くなるやつ。

2018/12/27(木) 23:32:15.82

背景描画はリファクタ終わった。
アドバイスありがとう

2018/12/27(木) 23:45:14.41

おお、まだやってたんか。お疲れ。
地味に喜ばれると思うぜ。

2018/12/28(金) 01:01:43.75

次は文字列描画位置の微調整と、文字列の回転だ。多分、回転行列の知識が必要になる。いくつかテストプログラムを書いて、実証サンプルを作るだろう。

2018/12/29(土) 00:21:34.30

回転行列なんて高校数学で必修やん。

てゆうかあれ、結局はWin32APIのwrapperを整備しようって事なんでしょ。
文字列の回転とかAPIにあるんか？いや、あるから言ってるんだろうけどさ。
つっても普通にOS使ってて回転されてる文字ってほぼ無いし、優先順位は低くていいのでは？
どういう状況なのか知らんけど、適当にエミュするとか。

2018/12/29(土) 15:23:25.36

まあ、こういうことだよ。
https://jira.reactos.org/browse/CORE-11848

2018/12/29(土) 16:34:13.08

15319の方も見た。なるほどサイドバーのメニューか。
TextOut/ExtTextOutではなくてLOGFONTA structureに角度があるのか。
となるとフォントの参照点を直接回転させてレンダリングするのだろうけど、
確かにItalicとかも同時に出来るからこの方がいいのか？

Italic実装済みならあっさり行くのでは？
Italic未実装なら先にItalicを実装した方がいい気がするが。

90/180/270°優先で良ければ、0°でレンダリングしたビットマップを回転させてもいい。
ただしこの場合は斜め(例：45°）とかだとジャギーになる。
正当には広めにとって直接レンダリングで、この場合はジャギー無しになる。
後で直すのも面倒だし、大して手抜きも出来ないから、最初から真っ当に実装した方が良さそうだね。
まあ頑張れ。

2018/12/30(日) 14:37:19.63

https://github.com/reactos/reactos/pull/1207

片付けた。

2018/12/30(日) 20:00:13.41

おお、お疲れ。
「斜めの時は…」はいい割り切りだと思うぜ。

仕様とソースを見る限り、「背景」はETO_OPAQUEのことだよな？
https://msdn.microsoft.com/ja-jp/library/cc428620.aspx
長方形領域を塗りつぶすだけなら大した問題でもないし、
ソースコードの該当箇所を覚えているうちに片づけてしまった方が「後々の為」だと思うが。
リファクタも結局は「後々の為」の投資であって、
それをやるのに無駄に後々の手間を残すようなのは悪手だぜ。

塗りつぶし関数はレンダリング部分に当然持っているはず。
（アウトラインフォントの内部は塗りつぶさないといけない）
とりあえずはそれを探し出して呼ぶのが順当だろう。

手抜きなら文字■（全面塗りつぶし）で描画して背景とも出来る。
この場合はその上に書き直すので多少遅くなるが、実際は斜めなんてほぼ使わないし、問題ないはず。
ただこれはコントロールフローが意味不明になるから、やっぱり上記のように実装するのが妥当だろう。
（つか検索だとIntUpdateBoundsRectが2回引っかかるし、もしかしてもう既にこれやってる？）

ぱっと見、IntUpdateBoundsRect(dc, &Rect); はrectをつないでいるだけだし、
eng/bitblt.c内のIntEngBitBlt関数実体でもクリッピングをやっているだけのようだし、
実際の塗りつぶしは EngBitBltｊか？
見た目、brushのビットパターンをコピーしてるだけのようだし、
斜めでそのまま背景描画したら大枠の全域が塗りつぶされるとかいうオチ？

2018/12/30(日) 20:43:50.92

次はオバケをやるぞ。

2018/12/30(日) 21:16:57.54

いや、悪いが意味が分からん

2018/12/30(日) 23:12:14.65

ゴーストウィンドウの実装だ。
https://github.com/reactos/reactos/pull/1178

結構難しいぜ。

2018/12/30(日) 23:27:38.22

ServiceTag = (ServiceTag % 0xFFFFFFFF) + 1;
これはゼロを避けるための超絶テクニックさ。今日教えてもらった。

2018/12/30(日) 23:49:50.53

>>176
やるのは自由だが、正直割とどうでもいい機能な気もする。

>>177
-1での剰余を取るって事？
剰余でマイナスってありなんだっけ？
あと、そこら辺は無駄にこだわらない方がいいよ。
後で読んだときに意味が分からなくなるから。
自分だけのプロジェクトではないのだし。

2018/12/31(月) 08:31:41.69

普段の蟻の人の投稿内容からして、本気で喜んでるとも思えないけど、
と言って、ワザと煽って反応を引き出そうとする芸風の人でもないよなぁ。

ifなり三項演算子なりで「値が0だったら1にする」と
素直に書く方が明確じゃないかな。
整数のビット数にまつわる移植性の穴になりうるとか、
割り算するより0判定の方が速いじゃろとか、可読性以外の理由もあるけど。

剰余の計算が常に一定時間で行われるし、しかもこの部分の処理が
条件判定によってタイミングが変化してはいけない、という状況なのかな。

2019/01/03(木) 05:55:20.15

文字の回転の件だけど、座標変換を完璧にやれ、ってダメ出しが来た。
論理座標変換、文字幅変換、文字の傾き変換、世界変形を全部完璧にしないとOKが出ないみたい。
変形はアフィン変換も含むらしい。

2019/01/03(木) 10:12:26.72

いや意味が分からん。これのことか？
https://jira.reactos.org/browse/CORE-15319
90度を実装したら表示されるはずだが、表示されないと言うのだから、追わなければ分からんね。

或いは、
本来： https://jira.reactos.org/secure/attachment/36563/correct%20font%20rendering.png
現状： https://user-images.githubusercontent.com/2107452/50544530-bae9d080-0c3b-11e9-8028-200a4b9a8840.png
> lfWidth parameter was ignored.
> MS Sans Serif shouldn't be rotated.
IfWidthが無視されているのはテンポラリの実装ならありではあるが意味不明、
MS Sans Serifが回転している＝回転にフォント依存があるのは全く意味不明、といったところか。

てかマジな話、どんな実装したらこんな事になるんだ？

俺はフォントのことは詳しくは知らないが、PostScriptと同様に2次ベジエの再帰でレンダリングしているとすると、
各ストロークの参照点を回転行列に突っ込めば回転するし、y=ax的に平行移動すればイタリックが得られる。
だからイタリックと回転は同じコード（アフィン変換）で実装出来るはずで、そこを言及した。
この場合、当然IfWidthやフォント種類と回転/イタリックは直交しているので、
○○フォントの場合は回転がおかしくなる、なんて事は発生し得ないし、IfWidthを無視するような事も逆に難しい。

ただし実際にそうなっているのなら、それはおかしなコードが紛れ込んでいるはずだ。
それを除去して、正しい場所にアフィン変換を突っ込むのが正当なやり方だと思うぜ。
つか、今のコードもアフィン変換してないのか？それで回転してるってのも凄いとは思うが。

2019/01/03(木) 10:51:29.12

玄奘の方が綺麗に見える

2019/01/03(木) 14:19:47.79

scriptなんかは明らかに書体が違うし回転する以前に
同じフォントが同じ書体、同じサイズで表示されるのか
環境を揃えて比較できる状態なのかが怪しい

2019/01/03(木) 15:15:51.87

MS Sans Serifは、Windowsではビットマップフォントだから、回転は無視される。ReactOSでは代替フォントとして実装されていて、ビットマップフォントではない。
だれかが、MS Sans Serifのクローンを作れば解決する問題だが、まだ未解決。

2019/01/03(木) 15:18:40.27

ReactOSにはSagoe Scriptフォントは存在しないし、実装する予定もない。

2019/01/03(木) 16:13:03.62

https://jira.reactos.org/browse/CORE-15554

これをやれ、とのこと。

2019/01/03(木) 16:15:41.88

変形行列の指定には、FreeTypeライブラリのFT_Set_Transformを使うこと。これ以外の方法はない。

2019/01/03(木) 18:17:11.70

>>184,185
それ(ビットマップフォントは回転しない）が仕様ならそれで構わないと思うが、問題は、
A. windowsがビットマップフォントでReactOSで非ビットマップフォントの場合、回転する
B. windowsが非ビットマップフォントでReactOSでビットマップフォントの場合、回転しない
で、おそらく
https://jira.reactos.org/browse/CORE-15319
についてはBが該当して表示されていないのだろう。(これは確認してみた方がいい)
対策としては
B1. 辞書を作って名前で対応
B2. ビットマップフォントも回転させる
のどちらかだが、B1でもどのみち「ビットマップフォントを回転させる」機構は必要だから、
最初からB2で対応するのがいい。
(この場合、
C. windowsもReactOSもビットマップフォントで、回転しない
ケースで非互換になるが、問題にはならないはず）
ここで、選択肢は、
α：　ビットマップフォントでも常に回転する
β：　90/180/270°の時のみビットマップフォントでも回転する
の2つで、βでも実質問題はないはず。

>>187
lfWidthもFT_Set_Transformで対応出来そうだし、問題無いように見えるが。
少なくとも現状の回転がそれで機能しているのだから、APIは正しく機能しているし。

2019/01/03(木) 18:43:36.12

FT_Set_Transform関数は、現在の変形行列と平行移動を指定するもの。この他にFT_Matrix_Multiply、FT_Vector_Transform関数が使える。
変形行列と平行移動を合わせて仮にTransMatrix構造体として表すものとすれば、
typedef struct {
FT_Matrix mat;
FT_Vector vec;
} TransMatrix;
さらに、TransMatrix同士の積TransMatrix_Multiplyを定義する。

2019/01/03(木) 18:48:00.87

論理座標変換用のTransMatrix_LPtoDP、
lfWidth変換用のTransMatrix_Width、
lfEscapement変換用のTransMatrix_Escape、
さらに世界変形用のTransMatrix_Worldを定義し、
それぞれを掛け合わせれば、変換後の座標が定義できる。。。

といった感じなんだが。

2019/01/03(木) 18:50:26.82

TransMatrixは結合則を満たすだろうか？

2019/01/03(木) 18:54:46.64

結合則を満たすように積を定義する方法はないだろうか？

2019/01/03(木) 19:00:38.66

何かを中心に回転移動するというのが一つのTransMatrixでは表現できないように思える。
中心点まで平行移動して回転移動してまた中心点を戻すというやり方じゃないといけないような。

2019/01/03(木) 19:02:50.09

行列は非可換であって、結合規則自体は満たしていたと思ったが。
それ以前に結合する意味はなくて、単なる積だとも思うが。
http://www.geisya.or.jp/~mwm48961/kou2/mobile/matrix3_m.html

2019/01/03(木) 19:08:42.35

>>193
何か大幅に勘違いしていると思うが。

2x2の行列(=FT_Set_Transform)なら原点は移動出来ないから単なる一次変換であり、斜体/回転までだ。
つまり仕様としては字毎にレンダリングしろ、という事だろ。これも問題ないと思うが。
(平行移動（原点移動）が必要なら3x3行列でアフィン変換となる)

2019/01/03(木) 19:08:48.72

ならば、
typedef struct {
FT_Vector vec1; // 平行移動
FT_Matrix mat; // 変換行列
FT_Vector vec2; // さらに平行移動
} MatTrans;
これでどうだろうか？

2019/01/03(木) 19:19:22.47

論理座標変換と世界変形は、平行移動が必要になる。FT_Vector_Transformと平行移動の計算は使わないといけないのか。

2019/01/03(木) 19:21:04.79

完全に理解した。テストプログラム作成とコーディングに入る。

2019/01/03(木) 19:29:38.69

>>196
いや何が？

元々フォントは字毎であり、つまり字毎にベジエ曲線が定義されており、
それは各字の左下なり左上なり（どちらかは知らん）を基点として参照点が指定されているわけだろ。
そしてそれが今現在正しく回転してレンダリング出来ているんだから、
今現在も平行移動部分は出来ているんだよ。それをわざわざ持つ意味はない。
例えば、

ABCDEF

を90°回転して表示するケースを考えてみる。
Aは原点移動無しで回転するだけだ。ここまではいいだろ。
Bも原点移動無しで回転すると、当然Aの上に上書きされてしまうから、これが

F
E
D
C
B
A

の並びになる時点でBの原点移動（つまり平行移動）は今でも実装出来ていて、動いている。
これは理解出来ているか？

>>197
SetWorldTransformについては仕様に行列も書かれているだろ。（何故か転置されているが）
https://msdn.microsoft.com/ja-jp/library/cc428788.aspx

つってもここで詳細を問答しても埒が明かないし空回りを誘発するから、実装を優先してくれ。

2019/01/04(金) 12:11:01.67

https://jira.reactos.org/secure/attachment/50483/TypeTest2.zip

テストプログラムが出来たよ。

2019/01/06(日) 23:24:01.97

ゴーストと座標変換、今週中に片付けなきゃ。

2019/01/11(金) 17:39:39.83

https://twitter.com/katahiromz/status/1083642458771152896?s=19

実証コード作成中。。。
https://twitter.com/5chan_nel (5ch newer account)

2019/01/11(金) 18:33:44.24

行列のrankって何やねん。

2019/01/11(金) 19:57:11.86

次元みたいな

2019/01/11(金) 20:18:06.89

>>203
ggrks
https://ja.wikipedia.org/wiki/%E8%A1%8C%E5%88%97%E3%81%AE%E9%9A%8E%E6%95%B0

2019/01/11(金) 22:09:00.22

二次正方行列の階数を判定する簡単な方法は？

2019/01/11(金) 22:13:03.22

>>206
ggrks
http://senkei.nomaki.jp/rank.html
というかそもそもそんなもの必要ないだろ。何をやっている？

2019/01/11(金) 22:14:15.55

>>206
https://risalc.info/src/rank-calculation.html

2019/01/11(金) 22:37:15.43

ということは、逆行列の存在はフルランクの正方と同値。
逆行列がないとき、無変形で表示すればいいのかね。たぶん。

2019/01/11(金) 22:42:28.74

何が言いたいのか、何をやりたいのか、さっぱり分からん

2019/01/12(土) 11:32:18.24

とりあえず対角化汁

https://www.wakaba.ouj.ac.jp/kyoumu/syllabus/PU02060200211/initialize.do
BS231 2019-01-12 15:00 入門線形代数
BS232 2019-01-16 20:00 入門線形代数
https://www.ouj.ac.jp/hp/bangumi/nenkan/bangumi_2/2018/bangumihyo.pdf

2019/01/12(土) 13:21:52.88

https://jira.reactos.org/secure/attachment/50653/TypeTest3.zip

OnFreeTypeDraw関数を編集して、FreeTypeの場合とFreeTypeではない場合のレンダリングをなるべく一致させなさい。

難しい。

2019/01/12(土) 13:28:55.77

レンダリング先のy座標が下向きというのがややこしい。
TA_BASELINEではない場合、描画開始位置をずらさないといけない。

2019/01/12(土) 14:59:59.65

アマゾンギフト券3000円。早い者勝ち。

2019/01/12(土) 15:41:56.58

5000円に増額。さぁ、誰が大金を手に入れるか！？

2019/01/12(土) 15:43:45.84

あげ

2019/01/12(土) 16:41:49.08

自己解決しました。どうも。
https://jira.reactos.org/secure/attachment/50654/TypeTest3.zip

2019/01/12(土) 17:08:43.61

次は、SetWindowExtExとSetViewportExtExによるスケーリングを有効にする。

2019/01/12(土) 18:23:54.55

蟻人間が休み明けまでに実証コードを完成できると思う人は赤いボタンを、できないと思う人は青いボタンを押して下さい。

2019/01/12(土) 18:47:03.36

5ちゃんねる新機能「投票箱」

赤いボタン [投票] 58
青いボタン [投票] 12

さあ、あなたも投票してみよう！

2019/01/12(土) 20:54:11.60

マッピングが全く分からん。
優先順位、変換式、、、

2019/01/12(土) 21:02:02.49

世界変形と論理座標変換が組み合わされるとややこしい。マッピングモードがMM_ANIISOTROPICの場合と仮定してもいいんだが。

2019/01/12(土) 23:14:26.31

どこかに変換式が書かれてないかな、んばば。

2019/01/13(日) 13:58:43.05

変換式
http://yamatyuu.net/computer/program/sdk/gdi/mapmode/index.html

発見！デデデデーン！

2019/01/13(日) 20:34:16.93

疲れた休む

2019/01/14(月) 08:56:42.64

https://jira.reactos.org/secure/attachment/50739/TypeTest4.7z
実証コード完成。

2019/01/14(月) 19:32:57.41

https://github.com/reactos/reactos/pull/1238
プルリクエストにこぎつけた。

2019/01/19(土) 00:42:08.80

三千円報酬もらった。やったー。

2019/01/19(土) 16:46:58.96

コンパイラエラー C2872 あいまいなシンボルです。

コンパイルエラーが解消出来ません。
ご教授下さい。

■コンパイルエラー内容
error C2872: 'MarketplaceWebServiceProducts' : あいまいなシンボルです

■やりたいこと
AmazonのAPI「Marketplace Web Service API (MWS)」のHello world

以下ページの右上オレンジ色の「Download」ボタンから入手できる
「MWSProducts_2011-10-01_v2017-03-22.dll」の使用
https://developer.amazonservices.jp/doc/products/products/v20111001/cSharp.html

■DLLの使用
Visual Studioの対象プロジェクトのプロパティから、
上記DLLの参照を追加しました

■コーディング
using namespace MarketplaceWebServiceProducts;//←ここはコンパイルOK
using namespace MarketplaceWebServiceProducts::Mock;//←★ここで上記コンパイルエラー

■ご質問
上位の「MarketplaceWebServiceProducts」が正常なのに、
下位の「Mock」を付けるとあいまいなシンボルになるのはなぜでしょうか。
解決策をご教授ください。（可能であれば実装をご提供ください）

■環境
Visual Studio
.Net 4.0
C++/Cli

2019/01/19(土) 16:58:07.77

>>229
https://mevius.5ch.net/test/read.cgi/tech/1547326582/66
マルチ死ね

2019/01/19(土) 17:04:01.25

>>229
それCではなくてC++の話だよね？だったらスレチだよ。

2019/01/19(土) 17:10:18.93

なおURLはものすごくC#

2019/01/19(土) 17:14:29.80

>>230
ご回答ありがとうございます

>>231
>>232
言語関係ないコンパイルエラーなので、
上級者のみなさまなら回答できるかと存じます

ご回答引き続きお待ちしております

2019/01/19(土) 17:25:37.61

>>233
namespace はCにはないものなのでCの上級者でも他の言語知らなかったら答えられないよ。

2019/01/19(土) 17:28:06.30

C++/CLIってC++ですらないからな。
そりゃともかく、ネームスペースで迷ってるんだから、ヘッダ追ってけばわかるのでは

2019/01/19(土) 17:39:49.16

>>234
ご回答ありがとうございます
そうなのですね。Ｃにもinculude やname spaceあったように記憶しています。

>>235
ご回答ありがとうございます
C#と同じです。
ヘッダとはDLLの中身でしょうか？
DLLはバイナリなので中身が追えません。

とても困っているのでご教授引き続きお待ちしております

2019/01/19(土) 18:08:35.17

>>233
マジで死ね
お前らみたいなのが質問出来る環境を壊して行っているのを自覚しろ

2019/01/19(土) 18:20:45.50

>本当にありがとうございます！！！！！！！！！！！！
>キモヲタ万歳！！！！！！キモヲタ役に立つ！！！！！！！！

この質問者は、荒らしだから、無視しろ！

2019/01/19(土) 19:44:47.14

>>229
凄いなこいつ
https://qiita.com/kakusuyo/items/7c2b619adde3c7232c9a
https://teratail.com/questions/169698
https://okwave.jp/qa/q9579293.html

2019/01/19(土) 20:17:57.44

https://jira.reactos.org/browse/CORE-15000
現在、ドットネットアプリのフォントレンダリングの問題に直面している。
恐らくビットマップの問題かフォントキャッシュか、データ破壊の問題と思われる。

2019/01/19(土) 21:32:10.76

ドットネットはレンダリングにGDI+(gdiplus)を使っている。
Gdipで始まる名前の関数はGDI+の関数だ。添付のログファイルを参照。

2019/01/20(日) 18:15:56.58

>>236
Cにはnamespaceはありません。
includeはプリプロセッサの問題なのでC++と同じなのが普通でしょうが、言語そのものとは無関係なテキスト変換処理です。

2019/01/20(日) 19:06:42.04

https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/bitmaps.c

SetBitmapBits関数にバグがあるかも、と疑っている。間違いを発見したら、ご報告願う。

2019/01/20(日) 19:11:17.24

ここで、NtGdiSetBitmapBits関数は、SetBitmapBits関数と同じです。

2019/01/23(水) 03:35:01.17

i5-8600 のキャッシュラインのデータサイズを知りたいんですが、参照すべき文書等教えてくれたら助かります。
並列処理の開発中で、色々難儀してます。
難しいですが、面白いトピックで興味をそそられます。

2019/01/23(水) 22:34:06.08

>>245
>>1,13を読め

基準を言うなら、「それってCの10年選手が悩むこと？」かな
即答出来るような質問はここでは荒らしでしかない

2019/01/24(木) 00:14:17.02

>>246
普通にCやってるだけなら10年やろうとCPUのキャッシュラインなど意識しないことも珍しくはないだろ。
つまらんこと書いてないでドキュメントへのリンクでも貼ってやればすぐ終わるじゃん。

2019/01/24(木) 00:15:40.93

インテルかAMDの公式マニュアルじゃね？

2019/01/24(木) 01:12:20.09

>>247
ならお前が書けよ
そもそも非上級者スレで間に合う話をこっちに持ってくるな、でしかない

それ以前にキャッシュライン長が見えるプログラミングなんてそうそう出来るものではないし、
その辺も分かってないのだと思うよ
それがつまりお前が知らない理由でもあるわけでさ

2019/01/24(木) 01:58:08.65

ここですね。文書探すくらいはすべきでした。

https://www.intel.com/content/www/us/en/products/docs/processors/core/core-technical-resources.html

2019/01/24(木) 09:40:07.71

>>250
マジで死ねよ
俺達はお前らのそういうところが無理なんだよ

2019/01/24(木) 09:50:35.52

更年期障害かこいつ

2019/01/24(木) 11:54:05.06

>>249
ようはキャッシュラインの意識は上級者の技術なんだろ？
ならここでいいじゃん。
「俺達」とかお前ビョーキか

2019/01/24(木) 11:54:49.11

幼年期から障害者でしょ
ひまわり学級からたまに授業受けに来る障害者とか、常時こんな風に健常者にキレていた

2019/01/24(木) 12:29:56.05

>>253
上級者ならキャッシュライン云々を質問するならプロセサを特定しないとダメ
ってことぐらいはわかるはず
なので彼はこのスレで質問する資格がない