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

■ このスレッドは過去ログ倉庫に格納されています
2018/03/02(金) 22:48:03.65ID:2Cs+DkMh0
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
127デフォルトの名無しさん (ｱｳｳｨﾌ FFeb-NsMu)
垢版 |
2018/10/14(日) 12:52:43.56ID:G4e8iFcgF
やっぱwindowsは糞だな
2018/10/14(日) 13:31:35.13ID:p/Li638e0
>>126
書き換えた所はどこ？
2018/10/14(日) 13:57:45.50ID:m0LzoO8+0
頑張ろうと思ったんだが、暇つぶしでやるには長すぎて挫折した。すまん。
2018/10/14(日) 13:58:41.27ID:b97yHnkE0
>>126
IntCharSetFromCodePage の for の中のひとつ目の if は削除して、for に入るまでに
if( uCodePage == 0 ) return DEFAULT_CHARSET;
をやる。
for に入るまでの if は 確率が高い順に並べる。

とか？
2018/10/14(日) 15:07:42.66ID:p/Li638e0
>>126
表面的になぞっただけで、意味は読んでいないから参考程度で。

L924-931、FW_*のenumに揃えられるのなら揃えた方がいい。あと、ベタで書くよりはループが良いかも。
L946関数他、InterLockを外部的に明示的に行っているけど、俺ならアクセス関数内に押し込む。
ただこれは以前揉めたから、他の流儀の奴もいるのかもしれない。
俺の考えとしては、enumやdefineする理由は、変更箇所を１ヶ所に留める(同期させずに済む)事だと考えているので、
外部的に明示的にInterLockをその都度行うのは、変更時に全ての場所を同期させる（同様に書き換える）必要があるという意味で悪手。
敢えてInterLockしていることを誇示したい等の他の理由がなければ、アクセス関数内に押し込む。
L2024,L2040,L2052,L2135、同じ事を4回書いてる。
おそらく全体的に低レベルまで全部触りに行く、ある意味Cに典型的なコードになっている。
嫌う人もいるとは思うが、俺ならこの4回をどうにか1つに纏めて抽象度を上げていく。
4つの*NameWを常に同時に使うものなら、普通はstructにする。
L2879とL2888で、FT_Done_GlyphとDPRINT1の順序が逆。
お互い干渉しないから問題なしなのだろうけど、可能なら順番は揃えた方がいい。
しかもL2926とL2934でも順番が逆なので、L2869-とL2923-ってコピペしてるだろこれ。
そういうのはマメにサブルーチンとして切り出すべし。でないと抽象度が上がらない。
L3567-L3581、同じ事を4回やってる。サブルーチンに切り出して xx=sub()の形で書くべし。
あと、リテラル（初期化構文）使えるのならリテラルで書いた方がすっきりすると思うが。
L5081-5112、悪いとは言わないが、どうにかならんのか？
失敗系の速度が大して必要ないなら、ReleaseAllResources()で if (NameInfo1!=0) ExFreePoolWithTagの様にして纏めるとか。
なおL5153、"WithTag"が無いバージョンを呼んでいるが大丈夫なのか？
可能であればL5162で関数切って2つの関数にした方がいいと思う。（リソース確保/失敗系と成功系を分ける）
L5889とかもそうだけど、おそらく全部のメンバを初期化してるだろ。だったら初期化構文使った方が見た目分かりやすい。
2018/10/14(日) 15:08:04.46ID:p/Li638e0
ただし、上記は「ソースを綺麗にする方法」であって、通常は速度は落ちるので注意。
酷い話、ベタで書きまくっている方が速いのも事実。
あと、既に言ったが、上記はなぞっただけであり、関数内しか見てないので注意のこと。
本当に問題なのは関数間であり、それはガチで時間をかけて読まないと分からないから、そこまではやる気無い。
ただ、この雰囲気なら、2割くらいの関数は整理（削除）出来るのではないかと思うけど。

自分でも気になっているところがあるのなら、それを先に言うべし。見るから。
2018/10/14(日) 15:31:36.33ID:7zcwA4Ik0
気になってることと言えば、TextOutでOPAQUEモードのときに背景を塗り潰さないといけないのだが、それを一個の長方形でいっぺんに出来ないかな。
2018/10/14(日) 15:35:42.20ID:p/Li638e0
>>133
とりえあず行番号と関数名を言え。
それとも、そのソースではない一般の話？
(Ctrl-Fでは6ヶ所引っかかるが)
2018/10/14(日) 15:44:21.77ID:p/Li638e0
ちなみに、これって、実際にフォントをレンダリングしているんだよな？2次ベジエ等で。
なら、OPAQUEの場合は先に塗りつぶしておいた上に描いた方が楽だと思うけど。
再帰等の条件に描画情報を使っていてそれが出来ない場合、反転でAND取ってORすれば昔のPSETにはなる。
(フォントの黒部分にもAlpha値があるのなら全面的に計算するだけだから、これではなさそうだし）
2018/10/14(日) 15:45:29.84ID:7zcwA4Ik0
>>134
GreExtTextOutW関数のL5847...L5954です。
2018/10/14(日) 15:47:47.17ID:7zcwA4Ik0
>実際にフォントをレンダリングしているんだよな？2次ベジエ等で。
FreeTypeというフォントレンダリングライブラリでビットマップとアウトライン曲線を取得しています。

>OPAQUEの場合は先に塗りつぶしておいた上に描いた方が楽だと思うけど。
そうしてます。
2018/10/14(日) 15:51:46.90ID:7zcwA4Ik0
>>130
それはないかな。すみません。
139さまよえる蟻人間 ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ 67b3-7Kxw)
垢版 |
2018/10/14(日) 16:02:11.24ID:7zcwA4Ik0
>>131
WithTagの指摘、助かった。ありがとう。
https://github.com/reactos/reactos/pull/941
他の件については後程、検討する。
2018/10/14(日) 16:16:37.97ID:7zcwA4Ik0
4つの*NameWの件、修正してみた。ありがとう。
https://github.com/reactos/reactos/pull/942
2018/10/14(日) 16:28:37.53ID:p/Li638e0
>>137
> それを一個の長方形でいっぺんに出来ないかな。
L5853のfor文が気になっているのなら、多分このCountは文字数で、
英文の場合は文字種類間ごとにピッチを変えるからこうなっているのでは？（いわゆるプロポーショナルフォント）
1回の操作に纏めたければ、文字単位でビットマップを生成して重ねるのではなく、
あらかじめ全体のビットマップを作ってそこにレンダリングしていけばいいのだけど、
速度的には速くなりそうだけど、後々面倒だから文字単位にしているのではないかと。

ここを文字単位でしこしこやるのは、悪いことではないと俺は思うけど。
気になっているのは被る部分が2度レンダリングされるって事かな？
幅5pxで1px被ってたら20%高速化だから地味に大きいのも事実だけど。
書き換えたいのなら後述参照。

なお、本筋とは異なるが、L5885-5887, L5926, L5938は正常系でもDPRINTしてるが大丈夫なのか？
DPRINT自体がリリースビルドでは消される仕様なら問題ないが。

>>139
正直なところ、指摘は参考に留めて、必要ない限りあまりいじらない方が良いとは思う。
これは昔の「動いているコードを触るな」であり、今風の「積極的にリファクタしろ」ではないが、
リファクタはデグレードをガッツリ検出出来る環境があればこそであって、
例えばchromeとかはそれをガチガチにやっているから出来るのであって、
検証環境のサポート無しなら、バグだと分かったところだけ修正し、そのついでに書き換える程度の方がいいと思うよ。

それで、該当部分を書き換えたいのなら、俺なら以下の手順でやる。（自己でデグレードチェックをする）
1. 対象部分、5847-5954を関数に切り出す。
2. その関数と全く同じ出力を生成する新関数（書き換えて1回でレンダリングするもの、おそらく20%程高速）を作る。
3. 両方とも呼び出す形でデバッグビルドし、結果を常に比較する状態でしばらく動かす。
　具体的には、旧関数出力と新関数出力のビットマップを全比較する。
　フォントのレンダリングなんてものすごい回数行われるので、バグっているようなら大抵これで検出出来る。
高速化は結構すると思うから、書き換える意味はあるとも思うけど。やるなら頑張れ。
2018/10/14(日) 19:15:26.67ID:p/Li638e0
>>139
はえーよ

>>140
第一段階としてはそれで良い。

(以下は改変後の行番号として）
ただ、オブジェクト指向的にはL2033-2036の中身をいちいち見せてNeededに足すのは悪手で、
可能なら AllLengthというプロパティを作りたいところ。
Cなら関数FONT_NAMES_get_all_length()とかで「中身を知らなくても全部の長さが分かる」様にして疎結合化する。
（後々fontNamesにメンバが追加されても struct FONT_NAMES の変更だけで済むようになる）

それで、L2125-L2141でご丁寧に全部Otm(の後ろ)にコピーしてるだろ。
これだと、多分、本来はOtm内に FONT_NAMES 構造体を持ち、そこに構造体のコピーで済むように書けるはず。
具体的には、

Otm->FontNames = FontNames; // --- (α）

みたいな。
2018/10/14(日) 19:15:52.58ID:p/Li638e0
ただこれ、データ埋め込みだから Otm->otmFamilyName等はオフセットで管理し、
不要なUNICODE_STRING構造体部分は破棄して文字列実体だけコピーするケチケチ作戦か？
なら、普通は文字列実体のコピー関数をメンバ関数として用意する。Cなら、

char* UNICODE_STRING_copy_string(UNICODE_STRING* ustr, char* Cp){ // --- (β）、一応thisを第1引数にした
wcscpy((WCHAR*) Cp, ustr.Buffer);
return Cp + ustr.Length + sizeof(WCHAR);
}

そしてL2124-2126を

Otm->otmpFamilyName = (LPSTR)(Cp - (char*) Otm);
Cp = UNICODE_STRING_copy_string(FamilyNameW, Cp); // --- (γ）

として、実装をはがしていく。（疎結合化する)
これで UNICODE_STRING 内にメンバ Buffer と Length があることを知らなくてもコピー出来るようになった。
同様に、Otm内に直接FontNames（または文字列実体だけコピー済みのchar*)を持つようにして、
FontNamesと同じ型を使い回せるようにすれば、もっと記述は少なくて済むし、疎結合化していく。(α）

ただし、ここら辺がLinusが嫌う、C++が逆に結合していく部分であって、
コード上の静的コールグラフでは疎結合化するが、型を通して知識的に密結合してしまう、というところ。
具体的には、FontNamesで綺麗に書こうとすれば OUTLINETEXTMETRICW に FONT_NAMES を持たせるべきだが、
これをやると、OUTLINETEXTMETRICWを使う人は全員FONT_NAMES構造体を知っていけないといけなくなる。
今のところ FONT_NAMES 構造体はオレオレ構造体であり、これは避けるべきだ。
逆に、UNICODE_STRINGはおそらく全体で使われている構造体なので、
（β）の関数を用意したら他でも色々使い回せ、全体的に記述を減らせるはず。
だから、次の手としては(β）+(γ)で記述を減らすべきだ。
ただし、もし仮に、型 OUTLINETEXTMETRICW を使うときには常に FONT_NAMES 構造体を知っているべきだ、というのであれば、
（α）の方向に変更していった方が最終的には綺麗になる。

てゆーか、頭大文字でも変数なのかー、まあそういうルールならそれでいいが。
2018/10/14(日) 19:38:11.68ID:p/Li638e0
>>143訂正
× .
○ ->
見れば分かるとは思うが。
2018/10/14(日) 20:06:34.30ID:kaj6ZYWld
https://github.com/reactos/reactos/pull/945
若干の改良。
2018/10/14(日) 20:21:41.00ID:kaj6ZYWld
OUTLINETEXTMETRICS構造体はwin32apiで定義済みだから、我々はそれを変更できない。
2018/10/14(日) 20:35:16.55ID:p/Li638e0
>>145
ご苦労様。

俺は書き換え後の方が断然いいと思うが、
3回+αだったから意外に効果が少なく、評価は分かれるかもね。
なにげに「書けばいいだろ」方式のべた書きって記述量は意外に少なかったりするし、今回もそうだった。


>>146
なるほど。
なら俺なら（β）+（γ）で主関数(IntGetOutlineTextMetrics)を4行減らす。
ただし、実際はサブ関数(γ）で4行増えるので、全体の記述量は変わらず、これも評価が分かれるかも。
UNICODE_STRING構造体も、変更があり得ないほどなら、ベタに密結合させて書いても問題ないからね。
2018/10/14(日) 21:51:10.52ID:p/Li638e0
>>140
すまん、見落としてた。
その場合、普通は4つのIntGetFontLocalizedNameもIntInitFontNamesに突っ込む。

というかな、一応オブジェクト指向を意識して書いた方が分かりやすいと思う。
FONT_NAMES構造体に纏める＝そのメンバはほぼ常にセットで使う、という意味なのだから、
初期化も常にセットで行うべきなんだよ。それがコンストラクタであって。
だから、構造体に纏めた時点で、出来る限り「構造体」でアクセスすべきであって、
構造体の「メンバ」をいちいち無駄に参照するべきではない。
その場合、

IntInitFontNames(&FontNames, SharedFace, gusLanguageID);

としてしまって、メンバ全部を一度に初期化してしまうべき。

void FASTCALL IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace, ... ) // てか gusLanguageIDってどこからくるんだオイ？
{
RtlInitUnicodeString(&Names->FamilyNameW, NULL);
IntGetFontLocalizedName(&Names->FamilyNameW, SharedFace, TT_NAME_ID_FONT_FAMILY, gusLanguageID);
// その他*3
}

てな感じ。
2018/10/14(日) 22:44:56.36ID:p/Li638e0
で、さらについでに言うと、最後のコピーもメンバ関数として切り出して終わりだ。
つまり、FONT_NAMES構造体は、

void FASTCALL IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace, unkownType gusLanguageID); // コンストラクタ
void FASTCALL IntFreeFontNames(FONT_NAMES *Names); // デストラクタ
void FASTCALL SetFontNameAddresses(FONT_NAMES *Names, LPSTR **FamilyName, LPSTR **FaceName, LPSTR **StyleName, LPSTR ** FunnName); // コピー部分

の3つをメンバ関数として持ち、外部からは4つのメンバ変数

FamilyNameW, FaceNameW, StyleNameW, FullNameW;

をアクセスする必要が無くなるからprivateにしてしまえ、というのがオブジェクト指向になる。
結果、上位関数IntGetOutlineTextMetricsは、

IntInitFontNames(&FontNames, SharedFace, gusLanguageID);
で初期化して、駄目なら
IntFreeFontNames(FontNames);
を呼び、成功なら
SetFontNameAddresses(&FontNames, &Otm->FamilyName, &Otm->FaceName, &Otm->StyleName, &Otm->FunnName);
を呼んで終わる、と単純化される。


ところで、この書き方だと RtlInitUnicodeString と IntGetFontLocalizedName でも
alloc失敗で0が返ってきて落ちる様な気がするのだが、
これに対して対策されてないのは大丈夫なのか？
2018/10/14(日) 23:00:29.98ID:p/Li638e0
>>149
自己レス。
RtlInitUnicodeString と IntGetFontLocalizedName については大丈夫っぽい。


IntGetFontLocalizedNameは元のL2408で

Status = STATUS_INSUFFICIENT_RESOURCES;

を食らう可能性があって、この場合は FONT_NAMES.FamilyNameW等は正しく初期化されない可能性がある。
プログラムフロー的にこれがないと言えればいいが、そうでない場合は

Needed += FontNames.FamilyNameW.Length + sizeof(WCHAR);

でいきなりLengthを見に行くのはそれなりに危険。

ただ、見たところ常に RtlFreeUnicodeString を先に呼んでて、
(これは無いから正確ではないが、)
名前やフローからするとおそらく Length = 0 してくれてるから多分大丈夫だね。
誰か探してくれば見ますが。
2018/10/16(火) 19:22:32.13ID:Fb63Sgww0
https://github.com/reactos/reactos/pull/942/files/13fe63ede025c7a802676b4d95fc9287c95fa8be
見たぜ。割といいね。

俺なら RtlInitUnicodeString と IntGetFontLocalizedName は元のように交互にする。
それの方がこれらは「セット」だと分かりやすいから。

あと、gusLanguageID がグローバルを掴むのはちょっといやなので、コンストラクタで与える。
必要なら（今回は要らないはずだが）内部で保持して、それを使い回す。
2018/10/16(火) 19:22:49.09ID:Fb63Sgww0
一般的にいうと、今は FONT_NAMES 構造体がグローバル変数 gusLanguageID に依存してしまっている。
つまり、 gusLanguageID を変更すると即座に動作が変わってしまう。
今回はコンストラクタ IntInitFontNames 内でしか使ってないから問題ないはずだが、
後々 gusLanguageID を使うようなメンバ関数が追加されたりしたら挙動がおかしくなる。
それは外面的に見えるものでもない。
例えば、（今回は違うが） RtlInitUnicodeString のような、
引数に gusLanguageID を用いないが、内部的に使っている関数や構造体があったとして、
それをメンバ関数で使うと、「初期化時の gusLanguageID と違う ID を途中から使う」事になり、挙動がちぐはぐになる。
しかし、これはコード上では見つけにくい。
だから、これを防ぐ為に、普通はグローバル変数に直接依存することは避け、コンストラクタで与え、
必要なら内部で保持して、それを使い回す。
これにより、初期化時と同じIDで動作するようになり、ちぐはぐな動作は避けられる。

同様に、今は FONT_NAMES 構造体が グローバル変数 gusLanguageID に依存していることは外面的（引数的)には見えない。
だから、FONT_NAMES 構造体を使い回すと、使う側が gusLanguageID への依存を意識出来ず、バグの温床になる。
そうではなく、コンストラクタ引数で gusLanguageID も与え、
IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace, unknownType gusLanguageID)
とすれば、gusLanguageID への依存は明示的だから、この辺が避けられる。そして
IntGetFontLocalizedName( ... , gusLanguageID);
が gusLanguageID を引数にいちいち積んでいるのもそのため。
直接依存は避け、明示的に gusLanguageID を与えることにより、バグの温床を潰してる。
(動けばいいだけなら、グローバル変数を引数に積むのは無駄でしかないし）
2018/10/16(火) 19:23:14.27ID:Fb63Sgww0
コード全体のポリシーとして、 gusLanguageID にそれぞれが直接依存し、
その変更一つで瞬時に全体の動作を切換え、引数の数を減らして高速化し、引数の伝言ゲームを減らしてコードもすっきり、
というのはありだし、実際にCのコードでは結構見かける。
ただ今回の IntGetFontLocalizedName はそうなっていない。
こちらは普通のポリシー「グローバル変数には闇雲に依存しない」という方針で書かれている。
（だから引数でグローバル変数を積んでいる）
今回の FONT_NAMES 構造体は後発だし、当然既存のルールに合わせるべきだから、
IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace, unknownType gusLanguageID)
として、グローバル変数への依存を切る、という既存のルールに合わせるべきだ。

(逆に、敢えて高速化等の為に依存する、というのなら、
IntGetFontLocalizedNameUsingGlobal(&Names->FamilyNameW, SharedFace, TT_NAME_ID_FONT_FAMILY)
として、 IntGetFontLocalizedName もグローバルに直接依存するべき。そうしないと効果がないから。
外面的（コンストラクタ引数）では依存せず、内部的には IntGetFontLocalizedName 関数で依存している、というのは、
単にバグの温床でしかないから、どちらかに揃えるべき。普通はグローバルへの依存は切る。)

そもそもオブジェクト指向的に「実装を切り離す」のは、実装の中身（コード）を読まなくてもよくする為。
だから、見た目依存してなさそうなところに依存する構造にするのは間違いだし、バグの元。
コンストラクタで与える変数のみに依存する、というのが一番分かりやすいでしょ。
だから普通はそうする。

君もだが、一般的にCのコードはこの辺が甘い。
これはCでは「実装」を記述する為で、
つまり「グローバルなんて積んでも積まなくても動くんだから、どっちでもいいでしょ」な訳だ。
対してオブジェクト指向のコードは、「設計」を記述する為、引数に何を積むべきで、何を積んではいけないか、
或いはその関数が本来どこに存在すべきなのか、この辺に厳しい。
この辺は勉強になるから、Cでもオブジェクト指向は知っておいた方がいい。
ただ、Javaとかのはかなり暴走しているから、「本来の」オブジェクト指向の範囲に留めた方がいいのも事実だが。
2018/10/16(火) 19:23:33.27ID:Fb63Sgww0
纏めると、コードはつまり、

A:
IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace, unknownType gusLanguageID) {
IntGetFontLocalizedName(&Names->FamilyNameW, SharedFace, TT_NAME_ID_FONT_FAMILY, gusLanguageID);
}

B:
IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace) {
IntGetFontLocalizedName(&Names->FamilyNameW, SharedFace, TT_NAME_ID_FONT_FAMILY, gusLanguageID);
}

C:
IntInitFontNames(FONT_NAMES *Names, PSHARED_FACE SharedFace) {
IntGetFontLocalizedNameUsingGlobal(&Names->FamilyNameW, SharedFace, TT_NAME_ID_FONT_FAMILY);
}

の3種類のどれかになる。普通はグローバル変数 gusLanguageID への依存を明示的に切るAにする。
対してCは「意図的にグローバル変数に依存する」コードであり、これも場合によってはありだ。
君のコードはBで、これは最終的にCを目指す過渡的なコードとしてはありだが、
そのつもりがない場合、ここでBを持ってくるのは間違いで、Aにするべきだ。

OtmSize を FONT_NAMES 構造体のメンバに持ったのはいい。これが綺麗だろう。
IntStoreName が長さを返すというのもいい。
(正直、俺も長さを返す方がいいかとも思ったが、その場合、ナマポに直接足し算が必要になるのでこれを避けた。
ただ、Cだし、コピーの場合は長さを返す方が常識的だし、これの方がいいだろう。)
マクロでやるべきかはともかく、 (+32)>>6 もうざかったから掃除したのはいい。
が、それも本来は、 copy_scales(Otm, pOS2, Face); とかにしておさらばしたいところだね。
それ、同じような名前のをグダグダコピーしないといけないのは、本来は継承関係があれば防げた話だ。
Otmはwin32APIだから変更不可として、pOS2の方も駄目なの？
(仮に出来たとしても大手術になるだろうから先送りでいいが）
2018/10/16(火) 22:05:32.39ID:gb9oBO7dd
頭にFT_が付くのはfreetypeの識別子だ。freetypeライブラリそのものは、設定項目以外は編集できない。
2018/10/16(火) 22:26:02.42ID:Fb63Sgww0
>>155
ああなるほどね。

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

ただまあ、正直なところ、コードのリファクタは将来への投資であって、
実利自体はないし、やり出すとキリがない。
気になってるところがあるのだから、さっさとそこに取りかかった方がいいと思うぜ。
フォントエンジンが速くなれば、地味にOSのレスポンスも上がるはずだし、喜ばれると思うよ。
2018/10/29(月) 22:10:10.28ID:PActy/D6d
https://gist.github.com/katahiromz/36f7135d3afe9fe6d2b7b28816be0f30

Can you read this ReactOS codes?
2018/10/30(火) 21:47:14.89ID:jbTXNLFK0
>>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.74ID:jbTXNLFK0
上記のコード、freeは1回ずつしかないから、忘れてたら『常に』リークする。
だから、バグの検出が容易となる。（すぐ検出出来る）
GitHubのコード、3つ目のPATH_DELETEは正常系だからここを忘れたらすぐに検出出来るけど、
1つ目のところで忘れたら、容易には検出出来なくなる。
結果的に、バグっててもなかなかヒットせず、バグを残してしまう。
「バグを検出しやすい構造」ってのも、コード品質を上げる為には重要だよ。
前も思ったけど。前は4回コピペしてたでしょ、確か。

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

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

オブジェクト指向の、メソッドを集中使用するやり方は、実は地味に効いてる。
あれだと、メソッドのバグは速攻検出されるので、コード品質は上がりやすい。
2018/10/31(水) 18:43:08.64ID:Gx8awWOCM
リソース確保はループかプールで必ず成功するようにできんか？
2018/10/31(水) 18:56:15.53ID:f1tmQgGe0
ループでは無理だろ
ここでプールを使うのも最悪だ
2018/11/01(木) 20:00:57.97ID:1k1Ne2fSa
クリティカルコンテキストでもないのにプールは無駄。
ループでリソース確保するのはプロジェクトのポリシー次第。
163さまよえる蟻人間 ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ 8bb3-PRUr)
垢版 |
2018/11/02(金) 12:02:06.04ID:pL4zzXZg0
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.53ID:/QNT6Qir0
>>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.17ID:koMt5OtTd
https://jira.reactos.org/browse/CORE-11944
いわゆるゴーストウィンドウを実装している。ウィンドウに反応がないときに白くなるやつ。
2018/12/27(木) 23:32:15.82ID:xEoyai350
背景描画はリファクタ終わった。
アドバイスありがとう
2018/12/27(木) 23:45:14.41ID:VBX3IQRR0
おお、まだやってたんか。お疲れ。
地味に喜ばれると思うぜ。
2018/12/28(金) 01:01:43.75ID:NxVVTuaOd
次は文字列描画位置の微調整と、文字列の回転だ。多分、回転行列の知識が必要になる。いくつかテストプログラムを書いて、実証サンプルを作るだろう。
2018/12/29(土) 00:21:34.30ID:k8mIifua0
回転行列なんて高校数学で必修やん。

てゆうかあれ、結局はWin32APIのwrapperを整備しようって事なんでしょ。
文字列の回転とかAPIにあるんか？いや、あるから言ってるんだろうけどさ。
つっても普通にOS使ってて回転されてる文字ってほぼ無いし、優先順位は低くていいのでは？
どういう状況なのか知らんけど、適当にエミュするとか。
2018/12/29(土) 15:23:25.36ID:2U219VsL0
まあ、こういうことだよ。
https://jira.reactos.org/browse/CORE-11848
2018/12/29(土) 16:34:13.08ID:k8mIifua0
15319の方も見た。なるほどサイドバーのメニューか。
TextOut/ExtTextOutではなくてLOGFONTA structureに角度があるのか。
となるとフォントの参照点を直接回転させてレンダリングするのだろうけど、
確かにItalicとかも同時に出来るからこの方がいいのか？

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

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

片付けた。
2018/12/30(日) 20:00:13.41ID:VD8xLYQ00
おお、お疲れ。
「斜めの時は…」はいい割り切りだと思うぜ。

仕様とソースを見る限り、「背景」は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.92ID:v5/l/oUG0
次はオバケをやるぞ。
2018/12/30(日) 21:16:57.54ID:VD8xLYQ00
いや、悪いが意味が分からん
2018/12/30(日) 23:12:14.65ID:KcpheNgcd
ゴーストウィンドウの実装だ。
https://github.com/reactos/reactos/pull/1178

結構難しいぜ。
2018/12/30(日) 23:27:38.22ID:S3Gvs6pcd
ServiceTag = (ServiceTag % 0xFFFFFFFF) + 1;
これはゼロを避けるための超絶テクニックさ。今日教えてもらった。
2018/12/30(日) 23:49:50.53ID:VD8xLYQ00
>>176
やるのは自由だが、正直割とどうでもいい機能な気もする。

>>177
-1での剰余を取るって事？
剰余でマイナスってありなんだっけ？
あと、そこら辺は無駄にこだわらない方がいいよ。
後で読んだときに意味が分からなくなるから。
自分だけのプロジェクトではないのだし。
2018/12/31(月) 08:31:41.69ID:g1mCMThq0
普段の蟻の人の投稿内容からして、本気で喜んでるとも思えないけど、
と言って、ワザと煽って反応を引き出そうとする芸風の人でもないよなぁ。

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

剰余の計算が常に一定時間で行われるし、しかもこの部分の処理が
条件判定によってタイミングが変化してはいけない、という状況なのかな。
2019/01/03(木) 05:55:20.15ID:Lt7qYVyo0
文字の回転の件だけど、座標変換を完璧にやれ、ってダメ出しが来た。
論理座標変換、文字幅変換、文字の傾き変換、世界変形を全部完璧にしないとOKが出ないみたい。
変形はアフィン変換も含むらしい。
2019/01/03(木) 10:12:26.72ID:NOMEwXEr0
いや意味が分からん。これのことか？
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を無視するような事も逆に難しい。

ただし実際にそうなっているのなら、それはおかしなコードが紛れ込んでいるはずだ。
それを除去して、正しい場所にアフィン変換を突っ込むのが正当なやり方だと思うぜ。
つか、今のコードもアフィン変換してないのか？それで回転してるってのも凄いとは思うが。
182デフォルトの名無しさん (ﾜｯﾁｮｲ 997c-aDDJ)
垢版 |
2019/01/03(木) 10:51:29.12ID:GFK4C2Tk0
玄奘の方が綺麗に見える
2019/01/03(木) 14:19:47.79ID:bUSBCT+/M
scriptなんかは明らかに書体が違うし回転する以前に
同じフォントが同じ書体、同じサイズで表示されるのか
環境を揃えて比較できる状態なのかが怪しい
2019/01/03(木) 15:15:51.87ID:Lt7qYVyo0
MS Sans Serifは、Windowsではビットマップフォントだから、回転は無視される。ReactOSでは代替フォントとして実装されていて、ビットマップフォントではない。
だれかが、MS Sans Serifのクローンを作れば解決する問題だが、まだ未解決。
2019/01/03(木) 15:18:40.27ID:Lt7qYVyo0
ReactOSにはSagoe Scriptフォントは存在しないし、実装する予定もない。
2019/01/03(木) 16:13:03.62ID:Lt7qYVyo0
https://jira.reactos.org/browse/CORE-15554

これをやれ、とのこと。
2019/01/03(木) 16:15:41.88ID:Lt7qYVyo0
変形行列の指定には、FreeTypeライブラリのFT_Set_Transformを使うこと。これ以外の方法はない。
2019/01/03(木) 18:17:11.70ID:NOMEwXEr0
>>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.12ID:GkQ/2uWAd
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.87ID:GkQ/2uWAd
論理座標変換用のTransMatrix_LPtoDP、
lfWidth変換用のTransMatrix_Width、
lfEscapement変換用のTransMatrix_Escape、
さらに世界変形用のTransMatrix_Worldを定義し、
それぞれを掛け合わせれば、変換後の座標が定義できる。。。

といった感じなんだが。
2019/01/03(木) 18:50:26.82ID:GkQ/2uWAd
TransMatrixは結合則を満たすだろうか？
2019/01/03(木) 18:54:46.64ID:GkQ/2uWAd
結合則を満たすように積を定義する方法はないだろうか？
2019/01/03(木) 19:00:38.66ID:GkQ/2uWAd
何かを中心に回転移動するというのが一つのTransMatrixでは表現できないように思える。
中心点まで平行移動して回転移動してまた中心点を戻すというやり方じゃないといけないような。
2019/01/03(木) 19:02:50.09ID:NOMEwXEr0
行列は非可換であって、結合規則自体は満たしていたと思ったが。
それ以前に結合する意味はなくて、単なる積だとも思うが。
http://www.geisya.or.jp/~mwm48961/kou2/mobile/matrix3_m.html
2019/01/03(木) 19:08:42.35ID:NOMEwXEr0
>>193
何か大幅に勘違いしていると思うが。

2x2の行列(=FT_Set_Transform)なら原点は移動出来ないから単なる一次変換であり、斜体/回転までだ。
つまり仕様としては字毎にレンダリングしろ、という事だろ。これも問題ないと思うが。
(平行移動（原点移動）が必要なら3x3行列でアフィン変換となる)
2019/01/03(木) 19:08:48.72ID:GkQ/2uWAd
ならば、
typedef struct {
FT_Vector vec1; // 平行移動
FT_Matrix mat; // 変換行列
FT_Vector vec2; // さらに平行移動
} MatTrans;
これでどうだろうか？
2019/01/03(木) 19:19:22.47ID:GkQ/2uWAd
論理座標変換と世界変形は、平行移動が必要になる。FT_Vector_Transformと平行移動の計算は使わないといけないのか。
2019/01/03(木) 19:21:04.79ID:GkQ/2uWAd
完全に理解した。テストプログラム作成とコーディングに入る。
2019/01/03(木) 19:29:38.69ID:NOMEwXEr0
>>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.67ID:BtBvG2UO0
https://jira.reactos.org/secure/attachment/50483/TypeTest2.zip

テストプログラムが出来たよ。
2019/01/06(日) 23:24:01.97ID:bzgJpAnCd
ゴーストと座標変換、今週中に片付けなきゃ。
2019/01/11(金) 17:39:39.83ID:RqYQhJM20
https://twitter.com/katahiromz/status/1083642458771152896?s=19

実証コード作成中。。。
https://twitter.com/5chan_nel (5ch newer account)
2019/01/11(金) 18:33:44.24ID:EAu7TXxbd
行列のrankって何やねん。
2019/01/11(金) 19:57:11.86ID:z9WOdpwNa
次元みたいな
2019/01/11(金) 20:18:06.89ID:PrGvvTlD0
>>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.22ID:EAu7TXxbd
二次正方行列の階数を判定する簡単な方法は？
2019/01/11(金) 22:13:03.22ID:PrGvvTlD0
>>206
ggrks
http://senkei.nomaki.jp/rank.html
というかそもそもそんなもの必要ないだろ。何をやっている？
2019/01/11(金) 22:14:15.55ID:PrGvvTlD0
>>206
https://risalc.info/src/rank-calculation.html
2019/01/11(金) 22:37:15.43ID:EAu7TXxbd
ということは、逆行列の存在はフルランクの正方と同値。
逆行列がないとき、無変形で表示すればいいのかね。たぶん。
2019/01/11(金) 22:42:28.74ID:PrGvvTlD0
何が言いたいのか、何をやりたいのか、さっぱり分からん
211デフォルトの名無しさん (ﾜｯﾁｮｲ c17c-Iup+)
垢版 |
2019/01/12(土) 11:32:18.24ID:uvKv7UXV0
とりあえず対角化汁

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
212さまよえる蟻人間 ◆T6xkBnTXz7B0 (ﾜｯﾁｮｲ e501-4MHR)
垢版 |
2019/01/12(土) 13:21:52.88ID:7KwgHC6s0
https://jira.reactos.org/secure/attachment/50653/TypeTest3.zip

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

難しい。
2019/01/12(土) 13:28:55.77ID:7KwgHC6s0
レンダリング先のy座標が下向きというのがややこしい。
TA_BASELINEではない場合、描画開始位置をずらさないといけない。
2019/01/12(土) 14:59:59.65ID:7KwgHC6s0
アマゾンギフト券3000円。早い者勝ち。
2019/01/12(土) 15:41:56.58ID:7KwgHC6s0
5000円に増額。さぁ、誰が大金を手に入れるか！？
2019/01/12(土) 15:43:45.84ID:7KwgHC6s0
あげ
2019/01/12(土) 16:41:49.08ID:7KwgHC6s0
自己解決しました。どうも。
https://jira.reactos.org/secure/attachment/50654/TypeTest3.zip
2019/01/12(土) 17:08:43.61ID:7KwgHC6s0
次は、SetWindowExtExとSetViewportExtExによるスケーリングを有効にする。
2019/01/12(土) 18:23:54.55ID:ztd/2QH5d
蟻人間が休み明けまでに実証コードを完成できると思う人は赤いボタンを、できないと思う人は青いボタンを押して下さい。
2019/01/12(土) 18:47:03.36ID:ztd/2QH5d
5ちゃんねる新機能「投票箱」

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

さあ、あなたも投票してみよう！
2019/01/12(土) 20:54:11.60ID:ztd/2QH5d
マッピングが全く分からん。
優先順位、変換式、、、
2019/01/12(土) 21:02:02.49ID:ztd/2QH5d
世界変形と論理座標変換が組み合わされるとややこしい。マッピングモードがMM_ANIISOTROPICの場合と仮定してもいいんだが。
2019/01/12(土) 23:14:26.31ID:7KwgHC6s0
どこかに変換式が書かれてないかな、んばば。
2019/01/13(日) 13:58:43.05ID:op1ojGMw0
変換式
http://yamatyuu.net/computer/program/sdk/gdi/mapmode/index.html

発見！ デデデデーン！
2019/01/13(日) 20:34:16.93ID:nk+eydfgd
疲れた 休む
2019/01/14(月) 08:56:42.64ID:cZMKPFci0
https://jira.reactos.org/secure/attachment/50739/TypeTest4.7z
実証コード完成。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況