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

1 ：デフォルトの名無しさん ：2018/03/02(金) 22:48:03.65 ID:2Cs+DkMh0.net

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

2 ：デフォルトの名無しさん ：2018/03/02(金) 22:50:03.02 ID:PBdn8yjo0.net

修正部分について

老害が来てもウザイので「10,000行程度のソースを扱えない人は」と現在状態に変更した。
上級者には一朝一夕ではなれない。
初心者は文法事項にばかりに目が行きがちだが、
今日覚えれば明日から使える文法事項で練度を測るのはナンセンスだ。

3 ：デフォルトの名無しさん ：2018/03/02(金) 23:46:23.75 ID:zrkhMBv60.net

チムポから膿が出てるんだけどやっぱ病院行ったほうがいいかな？
1週間くらい前に天神でナンパした女から貰ったらしい・・

4 ：デフォルトの名無しさん：2018/03/03(土) 19:53:06.03 .net

エンディアンとアラインメントとメモリバリアについて完全に理解していることが最低条件です

5 ：片山博文MZ ：2018/03/03(土) 22:37:45.12 ID:YArqddrc0.net

>>3
泌尿器科、内科、性病科

6 ：デフォルトの名無しさん ：2018/03/04(日) 01:16:08.51 ID:6LJJRQUTa.net

言語の上級者じゃなくて
ハード知ってるかどうかだけじゃね

7 ：デフォルトの名無しさん ：2018/03/05(月) 00:58:42.58 ID:udBqLrh50.net

年齢制限はあるんですか？

8 ：デフォルトの名無しさん ：2018/03/07(水) 00:48:41.98 ID:qZwEfbWa0.net

>>7
年齢制限自体はないが、実質的には30前後になるだろう。

プログラミングにおいても「10,000時間の法則」は当てはまる。
勿論こなせばいいというものではないが、ある程度こなすことも絶対的に必要だ。
この点において、学生が「上級者」の域に達していることはほぼあり得ない。
一般的には、10,000時間=１日8時間*週休2日で50週*5年だから、
実働率の低さ、あるいはその分の残業等も含めて、職業マなら5-10年でここに至る。

これは主要なプロジェクトの公開時の年齢を見ても分かる。
BASIC: Bill Gates (20)
Linux: Linus Torvalds (21)
Turbo Pascal: Anders Hejlsberg (23)
PHP: Rasmus Lerdorf (27)
Java: James Gosling (30)
GNU Emacs: Richard Stallman (32)
Ruby: Matz (32)
C++: 禿 (33)
JavaScript: Brendan Eich (34)
Python:: Guido van Rossum (35)
Pascal: Niklaus Wirth (36)

ゲイツ、リーナス、ヘルスバーグは天才と称される人々で、確かに早い。
ただこれらは「実装」しただけであり、新しい「仕様」を考えたわけではない。
それ以外は軒並み30前後からだ。
これはつまり、いい仕様を考えられる人(≒上級者)が2周目に開発した結果だということ。
1周目は何かのプロジェクトに混ぜ込まれてそこで10,000時間こなしているか、
或いは1周目から新規プロジェクトを立ち上げたがゴミで終わった、ということ。
（１周目の未熟者が立ち上げたプロジェクトは物にならなかった、ということ）
なお、ラスマスはいろいろと語録が有名だが、こう並べると実は凄い。

9 ：デフォルトの名無しさん ：2018/03/07(水) 00:49:42.00 ID:qZwEfbWa0.net

会社に入って惰性でやっている奴も多いが、
もし職業マになっても学生の頃の情熱を持ち続けて日々努力を重ねるなら、
多分30前後で「ああ、大体分かっちゃったな」と思えるときが来る。
そのときには、10,000行は普通に扱えるようになっている。
逆に、10,000時間をこなしていない状態で、10,000行を扱えないのは当たり前。
それは絶対的に練習が足りないだけ。そして学生はこれに該当する。
練習すればいいわけではないが、練習もしないと上手くはならない。
お前らが今一生懸命書いているコードも、数年後に見直せば全くのゴミだと分かるだろう。

そして問題なのは、その2周目に何をするかで、
まあ大体会社にガッツリ組み込まれ、公私とも忙しくてそれどころではないが、
そのときにOSS方向にも立ち上げればMatz位の立ち位置は狙えるということ。

日本の問題は「プログラマ35歳定年説」の通り、
せっかく10,000時間こなした熟練者がマネージャになり、全くコードを書かなくなってしまうこと。
結果、未熟者だらけでコーディングしており、当然生産性は低く、給料も低くなる。
だから給料を上げる為にはマネージャに昇格するしかない、という悪循環となっている。
一方、海外では、プログラマの人件費は高く保たれており、（日本の2倍）
結果、熟練者もコーディングし続けることが可能で、生産性も高く保たれ、給料も高く保たれている。
これじゃ海外に勝てないのは当たり前だ。
詰まるところ、日本ではヘボが、海外ではエキスパートがコード書いてるんだから。

ただこんな愚痴言っても始まらないのだが、とにかく俺がお願いしたいことは、
お前ら初心者がここを読むのは勝手だが、投稿はして欲しくない、ということ。質問も含めて。
君らだって、大学の研究室に幼稚園児が乱入してこられても困るだろ。
上級者/熟練者も、上級者/熟練者のみで効率よく話せる場を必要としていて、
初心者が乱入してこられると困るんだよ。
ただ逆に、俺は初心者が初心者なりの考えでワイワイやることも必要だと思うから、
君らが従来スレでやり合う分には文句を言わない。（このスレが続いている限り）
俺は自ら進んで隔離されるのだから、お互い棲み分けって事でよろしく頼む。

10 ：デフォルトの名無しさん ：2018/03/07(水) 00:50:24.22 ID:qZwEfbWa0.net

今現在、また今後とも、Cが使われるのは極めてプロフェッショナルな領域のみだ。
つまるところ、「Cみたいな開発効率の悪い言語を使う理由は、Cじゃないと駄目だから」でしかない。
C以外の言語も充実している今、
「プログラミング初心者」が「独学」でCを始めるのは俺は全く勧めない。他言語にしとけ。
学校等でCを選択しているのなら、それは教師側の都合だから、（知らない言語を教えられないだけ）
逆に言えば、その先生に聞けばいい話であって、俺らに質問してくること自体が間違い。
つまり、
・直接聞ける相手がいるならそっちで聞け、それの方が絶対早い
・プログラミング一般について質問があるようなら、まず他言語で一通り学んでからCに挑め
・C特有事例で質問があるのなら、従来通り質問スレを使え
でしかない。敢えて匿名掲示板上の上級者に回答を求める場合は、例えば
・自分としては一通り出来るつもりである
・ところが上司の方針に全く納得できない。これ本当にそうなのか？ただの老害か？
という場合であって、具体的には
> 職場の人がみんなそうで、毎日変数一つにまとめろとかクラス一つにまとめろとかいろんな人から怒られたりして気が狂いそう
> javaから入ってオブジェクト指向学んだんだけど、javaと同じようにオブジェクト指向で作っちゃいけないの？
> 戻り値列挙型で定義したら戻り値二択にしてboolで返せって、戻り値によってswitch文で処理書いてたんだけどそれも全部捨てろって
> 俺そんなにおかしいもの書いたのかな？
> 共通化したりするとわかりづらい読みづらいって言われる
> https://mevius.5ch.net/test/read.cgi/tech/1467992113/10-
これとかだね。彼は非常に上手く2chを使った。さすがにこれを職場でやるわけには行かんし。

11 ：デフォルトの名無しさん ：2018/03/07(水) 02:36:38.66 ID:Tq6bvCAq0.net

ム板じゃなくマ板でやれって内容だな

12 ：片山博文MZ ：2018/03/17(土) 18:32:08.61 ID:6umCop+Md.net

上級者は自己解決できるから、このスレは洋ナシなんじゃね？

13 ：デフォルトの名無しさん ：2018/03/17(土) 20:14:25.06 ID:l8GUgwob0.net

>>12
その指摘は当たっている。
上級者がわざわざ質問する事はほぼ無い。当然流れない。

でも俺はそれでもいいと思っているんだよ。
上級者が集える場所がある事が重要。

何であれ、人数は初心者>>>中級者>>>上級者だから、
Web上のあらゆる場所は初心者で埋め尽くされてる。
例のコピペ「コミュニティの一生」で言えば、上級者は常に迫害される側だ。
だからこそ俺は上級者用の場所を確保しておきたい。
歴史的経緯から、上級者が人数的に一番多いのはCだと思うし、まずはお試しだ。
回答者の人数も揃っているし、俺はちょっと俯瞰しようと思っている。


C言語スレ、元々は見るからに年齢層が高かったのだが、
ここに来てド初心者が押し寄せてるのは何なんだ？春休みが理由とも思えないし。

あとやっぱり、話題になっているのは例外だけど、
あれって結局の所、今現在他言語でもいい解を見つけられてないよな？
Goは一周回ってCっぽくなってるし、
C++の「例外安全も型に含める」ってのもC++っぽいやり方だが、
相変わらず「そこまでやるか？」だし。

14 ： ：2018/03/17(土) 20:17:23.08 ID:qqOQsVrX0.net

上級者のおこぼれに預かろうというやましさを感じています

15 ：片山博文MZ ：2018/03/17(土) 20:23:13.35 ID:6umCop+Md.net

プログラミングは実装の手段に過ぎない。それは問題解決、「ソリューション」でなければならない。
プログラミングが複雑になるほど、全体を俯瞰する視点や、問題解決するための理論や設計が重要になる。
あなたは、C言語で何の問題を解決するのか。

16 ：片山博文MZ ：2018/03/17(土) 20:25:46.92 ID:6umCop+Md.net

というわけで、、、みんなで、C言語で実現できることを考えてみよう。。。

17 ：片山博文MZ ：2018/03/17(土) 20:33:08.59 ID:6umCop+Md.net

マイクロソフト関係者がChecked Cなるものを作っている。セキュリティが向上するらしい。#includeの代わりにコードをモジュールで管理するようだ。

18 ：デフォルトの名無しさん ：2018/03/17(土) 20:40:36.67 ID:l8GUgwob0.net

>>16
ちなみに俺はそれは逆だと思っている。
他言語で出来ることは他言語で、CでしかできないことをCで、だ。

スクリプト言語は本当に色々楽なんだよ。だから俺はJavaScriptが気に入っている。
例えば、以前出ていたオセロの盤面とかも、
多分20-30行で割り込みハンドラ含めて用意できる。
勿論ブラウザに乗っているからだが、Cではこの量では無理だ。
https://mevius.5ch.net/test/read.cgi/tech/1519046038/211

だからアプリ全体やGUI（=速度が要らない）をCで組むのはただの馬鹿で、
速度的に問題がある部分だけCのDLLを呼ぶ方向にソフトウェア全体がなっていくのではないかと思っている。
cythonやNumPyとかがまさにそうだが。

19 ：デフォルトの名無しさん ：2018/03/17(土) 20:47:39.89 ID:l8GUgwob0.net

>>17
型チェックかと思いきや、境界チェックか！これは行けるかも？
現状Cの最悪なところはそこだからね。

20 ：片山博文MZ ：2018/03/17(土) 21:54:17.01 ID:6umCop+Md.net

文章を単語に分け、文字に分け、それをラティス(lattice)、網目構造にする。それのn-gramと意味構造と発音記号とアクセントと音声データを結び付け、
深層学習を真似て関係性をマッピングする。それで、word2vecみたいなことができないだろうか。

21 ：片山博文MZ ：2018/03/17(土) 21:56:53.09 ID:6umCop+Md.net

word2vecよりも優れた成果を求めている。ここに機械学習の理論家は居ないだろうか。

22 ：デフォルトの名無しさん ：2018/03/17(土) 22:21:56.06 ID:/yJWANaR0.net

>>16
それは発想が逆なのでは？何かを解決する道具の内の一つとしてプログラミング言語が作られているわけだから。

23 ：デフォルトの名無しさん ：2018/03/19(月) 22:59:10.03 ID:R1Gqx9A70.net

片山博文って、ググって最上位に来る人？
本物？

24 ：デフォルトの名無しさん ：2018/03/20(火) 02:37:08.41 ID:PXcTmg8I0.net

ここの中の人か
http://katahiromz.web.fc2.com/

25 ：デフォルトの名無しさん ：2018/03/20(火) 20:53:25.44 ID:k7gB50HA0.net

>>24
見た。
すげー香ばしい…。
真正の「自称」研究家だわ。

26 ： ：2018/03/20(火) 20:59:08.03 ID:PD8yAuaT0.net

>>24
「フォルダでプロンプト」を便利に使わせていただいています
http://katahiromz.web.fc2.com/fdprompt/index.html

27 ：デフォルトの名無しさん ：2018/03/21(水) 09:30:04.70 ID:qwFXdNpt0.net

shift＋右クリックはやっぱりめんどくせーの？

28 ：デフォルトの名無しさん ：2018/03/26(月) 07:53:47.49 ID:F4vKabPYM.net

http://mevius.2ch.net/test/read.cgi/tech/1519046038/587
これは正しい？

29 ：デフォルトの名無しさん ：2018/03/26(月) 09:20:39.77 ID:jNg5MzcL0.net

N1570 と整合する。

30 ：片山博文MZ ：2018/03/26(月) 16:07:25.48 ID:42MV7MT1d.net

>>27
最近のWin10のは、コマンドプロンプトじゃなくてPowerShellになるらしい。

31 ：デフォルトの名無しさん ：2018/03/26(月) 23:15:54.45 ID:dq/Lcz740.net

>>28
知らん。
というかお前らも無意味だと思いつつ続けてるんだろ？
元気なのはいいことだとは思うが。

32 ：デフォルトの名無しさん ：2018/04/20(金) 23:17:01.07 ID:c2Z2eqef0.net

あれ？そういえばこのスレ、過疎ってね？

33 ：デフォルトの名無しさん ：2018/04/20(金) 23:46:35.26 ID:sdtFgYaG0.net

上級者が初心者/中級者と比べて圧倒的に少ないのは自明だし、過疎るのは仕様。

34 ：デフォルトの名無しさん ：2018/04/21(土) 00:30:37.73 ID:Oxipuy330.net

てか、どの程度からを上級者と言っていいのか決まっているわけでもないし、
そもそもそういう人がこのスレを見に来るとは限らず、また見ても何かを書きたいと
思うとは限らない。

35 ：デフォルトの名無しさん ：2018/04/21(土) 00:52:21.32 ID:2gRYaRc50.net

で？

36 ：デフォルトの名無しさん：2018/04/21(土) 02:29:14.56 .net

こんなところで相談する時点で上級者じゃないしｗ

37 ：デフォルトの名無しさん ：2018/04/21(土) 09:05:28.55 ID:2gRYaRc50.net

>>36
>>12

38 ：デフォルトの名無しさん ：2018/04/21(土) 16:33:14.08 ID:Zke6MJB80.net

老人ホーム

39 ：片山博文MZ ：2018/04/21(土) 16:41:37.10 ID:9EumPI9yd.net

雪ホーム

40 ：デフォルトの名無しさん ：2018/04/21(土) 16:57:32.96 ID:V+d3uri50.net

お達者クラブ

41 ：デフォルトの名無しさん ：2018/05/02(水) 04:40:30.63 ID:bwD+G84h0.net

Cのnull安全がRustだと聞いたがRustはそもそもC++の後継であってCは念頭に置いてないと思うんだが
詭弁かな。

42 ：デフォルトの名無しさん ：2018/05/03(木) 00:23:25.54 ID:ZDR22COS0.net

そりゃ認識を間違ってるだろ。

https://techacademy.jp/magazine/8735
https://www.tiobe.com/tiobe-index/
C++erはCの後継はC++だと思っているし、俺もそうだと勘違いしていたが、
実際はCとC++は別枠で扱われていることが多いし、その方が妥当だ。
今のスマポ(ｷﾘｯなC++とCは別物だ。
文法的な点については、全言語の半分くらいはC後継だし。
C->ObjectiveC->swiftこそが正統Cの系統だ！と彼らが考えていても不思議ではないし。

Rustを触ったことはないが、通常議論されているのは、
・RustはCを代替できるか？
であり、「C++を代替できるか？」なんて言っている奴はいない。理由は、
・C++は現在も旺盛に進化中であり、後継を必要としてない(C++XXの後継はC++YY)
・C++ではCを代替できないのは確定済み(Linux等）
で、どうにかしたいのはあくまでCであり、C++ではないからだろ。

43 ：デフォルトの名無しさん ：2018/05/03(木) 09:56:19.82 ID:+ocIQVM3d.net

実装や機能を見る限りについてはRustはCよりC++に寄ってると思うよ
Cにこの抽象度の機能をもたせると必然的にそうなるという説はあるけども

何が言いたいかと言うと後継という立場について、そうであったC++は少なくともCの領域を完全にはカバーしなかった訳で、そのカバーしなかった領域を(C++に寄っている)Rustがカバーしたかと言われるとNoだと思っているからRustはCよりC++の後継という方が妥当に思えるという話

44 ：デフォルトの名無しさん ：2018/05/03(木) 13:18:42.35 ID:ZDR22COS0.net

申し訳ないが俺自身がRustを知らないのでつっこんだ議論は空回りしてしまうが。

> そうであったC++は少なくともCの領域を完全にはカバーしなかった訳で、
> Cの領域
これをどう捉えるからだよ。
少なくともC++の連中は「カバーしている」と思っている。
そしてLinusは「C++は全くのゴミだ」と思っている。

良くも悪しくも、Cはミニマムで美しく完成している。全く無駄がない。
そして各後継言語はこれに対して、「便利機能」を追加しようとしてきた。

C++は「クラス」「型検査」「例外」を導入した。
結果、CならCキャストやマクロですぱっと書けるところをグダグダとテンプレートを引き回したり、
或いは間接呼び出しでいちいち実行速度が遅くなったり、
はてまたスマポ(ｷﾘｯでGCの再実装を盛大にやらかしている有様だ。
Linusの意見はごもっともだ。

Rustの謳い文句は、「実行速度」「ゼロコスト抽象化」等であり、
C++の失敗を見て学んでいることは明白だ。
だから、後継になろうとしている相手はCなんだよ。C++ではなくてね。
とはいえ、そちらの指摘の通り、実際の仕様がCよりもC++に近くなるのは必然だ。
普通にやれば、C++で成功したところはそれをもらって、
C++で失敗したところは新たな方法を提案して、となるだろうからね。

Rustはぱっと見、スマポがデフォで生ポは例外的使用か？
C++は歴史的経緯から「言語的には」生ポがデフォでスマポが追加されている。
これは、「『アプリケーション用の』プログラミング言語」としては間違いだ。(Linusもそう言っている）
結果、C++erは「デストラクタ」「スマポ」「=のオーバーロード]をこねくり回して苦労しているが、
本来はこれらは言語側で完全に隠蔽すべき物だ。（ユーザが書く必要なんてない）
そしてRustはそれをやり、結果的にnull安全なんだろ。
正しい方向への進化だよ。(分岐元がCかC++かは何とも言い難いが）
C++はアプリケーションの動作と関係ないところで無駄に苦労するでしょ。俺はあれが嫌い。

45 ：デフォルトの名無しさん ：2018/05/12(土) 15:19:25.30 ID:V7PQOWmO0.net

>>44
その言い方、Rustを結構使っているように見えますが、違いますか？
Cが「ミニマルだ」ということには——少なくともISO C99規格を見るに——あまり賛同できないんですが、
それはまぁ、置いておいて、私がRustを触った限り、あれはC++の代替に見えます。
C++が現在も（規格を拡張する方向に）積極的に開発されているのは分かっていますし、
「だからRustが取って代わる必要はないのだ」という理論的帰結も理解できますが、
ポインタの安全性ややはり名前空間の宣言あたりを見ると（あくまで触りですが）どうしてもC++の文法を彷彿とさせるの
構造が多いように思いますね。

46 ：デフォルトの名無しさん ：2018/05/12(土) 15:20:29.04 ID:V7PQOWmO0.net

あ、すいません。一行目で使ったことがないと断られていました。
いや、なぜ確認しなかったんだろう、失礼しました。

47 ：デフォルトの名無しさん ：2018/05/18(金) 23:11:30.66 ID:qSToTkUZ0.net

>>45
> あれはC++の代替に見えます。
それは正しい。
というか、「後継」と「代替」はこの場合明確に区別して使われるべきだ。

・「○○の後継」---○○言語を発展させたもの。
　上位互換であり、○○言語と共に使うことを考慮されている。
・「○○の代替」---○○言語の代わりに使うもの。
　基本的に○○言語と一緒に使うことはない。排他的使用となる。

Rustの謳い文句は、「効率的なCバインディング」であって、
「効率的な『C++』バインディング」ではないんだよ。
CのDLLは当然呼べるが、C++のDLLを呼べるように出来ているか？
C++の「後継」と言うのなら、基本的にはC++の資産を全活用できる方向になってないといけない。
ただしそもそもC++は「後継」用のAPIを整備して無いと思うんだが。

C++の例外「実装」についてググッても、まともな文献が出てこないだろ。
おそらくあれは「実装」まで言及した仕様ではなく、「言語としての動作規定」しかされてないんだ。
(元々C++はそういうノリだし）
だからtry-catchを含んだ関数をDLL化できて他言語から呼べるかはかなり疑問だ。
勿論、昔からの課題だから今は解決されているかもしれんが。
> Throwing C++ exceptions across DLL boundaries is only possible when all modules use the same C++ runtime,
> in which case they share a heap as well. But this can be a maintenance burden,
> especially when libraries from multiple vendors are involved, so it is discouraged.
> https://stackoverflow.com/questions/5107948/throwing-c-exceptions-across-dll-boundaries

だからCのDLLは他言語(Rust/Ruby/C++/C#)等から直接呼べるが、
C++のDLLを呼べます、と謳っている奴はいないだろ。
この点において、C++は後継言語の存在を許していない。

だからRustはCの「後継」であり、C++の「代替」というのが妥当な見方なんだよ。
実際、RustがあればC++を使う意味がないだろ。

48 ：デフォルトの名無しさん ：2018/05/18(金) 23:12:06.97 ID:qSToTkUZ0.net

Cは大規模コードに対するサポートが全くない。
とはいえ、「やれば出来るだろ by Linus」なのは事実だが、実際それでは辛いわけで、
コンパイラに任せられるところは任すという方向で上手く手抜きできるように進化させたのがC++だ。
Rustも同じ方向なのだから同様の物になるのは当たり前。
当然、どちらかを使用すれば事足り、RustとC++は排他関係になる。
つまり、RustはCの「後継」であり、C++の「代替」だ。おそらくここまでは大体の人が納得するはず。

問題はCの「代替」にもなり得るか？という点であり、だからそこが議論されているわけだ。
今現在もCを使うメリットは速度面しかない。したがって速度面のデメリットがなければ良く、
「ゼロコスト抽象化」等、速さにこだわっているのはそこなんだよ。

ただ俺個人としては、全体を一つの言語で書く必要なんて全くなくて、
NumPyのアプローチ、つまりどうでもいいところ（9割以上）はスクリプト言語で書き、
必要なところだけCのDLLを呼ぶ、というのが正しい気がするが。C#もこの方向だね。
この場合、リソース管理をGC言語側に任せられ、
また個別関数単位での切り出しになり、
DLL内関数はお互い独立(非依存)で行っても1,000行とかでしかなく、
Cでも全く問題にならないんだよ。
だからRustも微妙に中途半端な方向だとは思うが、
もし仮にCを代替できるのなら、それは素晴らしいと思うよ。

49 ：デフォルトの名無しさん ：2018/05/23(水) 19:34:50.63 ID:Au5e7VGg0.net

僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法　モニアレフヌノ』

8UTJJ

50 ：デフォルトの名無しさん ：2018/05/24(木) 16:09:00.92 ID:6FiN0bsr0.net

114.149.223.252

51 ：デフォルトの名無しさん ：2018/07/02(月) 19:57:22.74 ID:tgZxuU9E0.net

RustはCの「後継」であり、C++の「代替」
これでRust周りの（宗教戦争じみた）論争の理由が理解できた。

52 ：デフォルトの名無しさん ：2018/07/04(水) 22:51:20.65 ID:gFgZc5FG0.net

NTB

53 ：デフォルトの名無しさん ：2018/07/09(月) 23:31:02.20 ID:bV3eVpry0.net

NTR

54 ：デフォルトの名無しさん ：2018/07/26(木) 02:18:42.03 ID:BvZq73xc0.net

ポインタってさ、「指示子」と和訳したら分かりやすいと思うんだが
そうしなかった理由ってなんだろ

それとも俺の感性がおかしいだけか

55 ：デフォルトの名無しさん ：2018/07/26(木) 02:38:35.19 ID:rK3i9Ft7a.net

昔、筧先生ってひとがいて…

56 ：デフォルトの名無しさん ：2018/07/27(金) 01:03:48.10 ID:GvW3yrkV0.net

>>55
kwsk

57 ：デフォルトの名無しさん ：2018/07/27(金) 03:35:26.85 ID:O4NPrPXG0.net

ちょっと10回言ってみ

言い辛いよな

58 ：デフォルトの名無しさん ：2018/07/27(金) 17:21:35.88 ID:GvW3yrkV0.net

え？ なに？ もしかして昔なにか荒れる原因になった ANDOR 問題のある人が使ってた用語なのか。
若いもんで知らなかったわ すいません。

59 ：デフォルトの名無しさん ：2018/07/28(土) 09:57:54.67 ID:VMG9DnUG0.net

「指示子のgcc拡張」みたいな早口言葉モドキができて面白いかも。

60 ：デフォルトの名無しさん ：2018/07/28(土) 13:58:33.27 ID:39ICzHjEa.net

指示子の指示子
指示子の配列
配列の指示子
配列の指示子の指示子
指示子の配列の指示子
ダブル指示子
配列の指示子の配列 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)

61 ：デフォルトの名無しさん ：2018/07/28(土) 15:05:25.84 ID:BHZfW2WL0.net

>>60
なんかおこられてやんの

62 ：デフォルトの名無しさん ：2018/07/28(土) 15:08:57.51 ID:39ICzHjEa.net

こんなので目玉付くんだなω

63 ：デフォルトの名無しさん ：2018/08/05(日) 00:49:09.36 ID:fZk3Cg460.net

C99（ISO/IEC 9899:1999）で，main()関数の型がintな理由ってどこかに書いてあるっけ。
今ふと，リターンコードって0から255の整数なんだから
uint8_t main(...
としても問題ないよなと思ってさ。

64 ：デフォルトの名無しさん ：2018/08/05(日) 00:50:03.59 ID:fZk3Cg460.net

すまん。途中で送信してしまった。
そうするとコンパイラにmain()の型はintだと怒られた。

65 ：デフォルトの名無しさん ：2018/08/05(日) 01:34:55.28 ID:/g7t90jda.net

型がintというのは決まってる。
実際の範囲は実装依存。windowsだと違ってなかったか？

66 ：デフォルトの名無しさん ：2018/08/05(日) 07:12:37.38 ID:cdvogGHQ0.net

main()が戻す値は呼び出す側の問題だとは思うが、その部分(crt0とか)は普通はC言語に合わせてintを
返してくると想定して作られていると思う。しかしその部分まで自作するというのであればなんでもアリではある。
https://en.wikipedia.org/wiki/Crt0

67 ：デフォルトの名無しさん ：2018/08/05(日) 08:37:27.73 ID:5+7WSxVZ0.net

シェルが受け入れるコマンドの終了ステータスの値が0-255の範囲、
てのはUNIX系もDOS系も(珍しく)一致してるのね。
unsigned char の外に出ないことは間違いないわね。

ANSI以前の古いCでの「宣言なしに使われた外部関数はintの値を返す」
という仕様が、規格化したときに互換性の問題を生まないように
main()の返り値はintと決めたんじゃないかしら。

68 ：デフォルトの名無しさん ：2018/08/05(日) 12:29:08.02 ID:fZk3Cg460.net

なるほど。まあ過去互換性は重要だしね。
ただ，CはPOSIXというOSの標準規格を定めてる団体が関与して設計されてるから「リターンコードは0--255。よってmain関数の型はuint8_t」と割り切ってくれてもいいのになぁ。
とか勝手に思ったりしてる。

69 ：デフォルトの名無しさん ：2018/08/05(日) 13:13:57.79 ID:/g7t90jda.net

まあintが妥当だろう。
しかし、_exit()に渡すのがintでwait()した時も一応exit statusはintだよな。
どこで上位ビット欠落させてんだ？

70 ：デフォルトの名無しさん ：2018/08/05(日) 18:30:06.69 ID:cdvogGHQ0.net

>>69
OSの中だ。_exit() はシステムコールだし。
まあでも UNIX 系 OS じゃないならこれは違っているかも知れない。

71 ：デフォルトの名無しさん ：2018/08/06(月) 01:15:24.28 ID:/d0+B2Ty0.net

ちょっとCの範疇を越えた話になるけど
リターンコードが0--255ってどういう段階で決定されたんだろう。
DOSとUnixが同じ範囲のリターンコードを持ってるって、偶然とは考えがたいんだけども

72 ：デフォルトの名無しさん ：2018/08/06(月) 02:07:20.39 ID:xc/1a6k50.net

unix等の先行者を参考にDOSを作ったんだから

73 ：デフォルトの名無しさん ：2018/08/06(月) 07:45:24.26 ID:1aQ1rnwf0.net

DOSの終了ステータスはUNIXの仕様をそのまま使用だと思う。

UNIXの方は、子プロセスを作って別の仕事をさせるって定型処理で、
「親プロセスで子プロセスの終了を待つ」ためのwait()系の関数が、
・子プロセスが正常終了した場合は子プロセスの終了ステータス
・子プロセスが割込みで中断された場合は割込みの種類
という2つの情報を1個の返り値で戻すことと関係あるのじゃないかな。

1個の整数値を上位と下位のビット群に分けて別の情報として使うために
それぞれの情報量を1バイトずつに制限した、と。

74 ：デフォルトの名無しさん ：2018/08/06(月) 08:23:05.65 ID:jTWGCXc00.net

UNIX板のおじさんに聞いてみたら

75 ：デフォルトの名無しさん ：2018/08/26(日) 08:24:46.45 ID:dLFVucRz0.net

auto変数で char配列を可変長で動的に確保する方法は無いかな。
アセンブラレベルならスタックポインタを操作すれば可能だと思うが。
文字列処理の内部バッファとして入力に合わせたサイズを確保したいんだが、とりあえず今は固定長バッファとそれを超える場合は malloc でやってる。

76 ：さまよえる蟻人間 ：2018/08/26(日) 09:09:31.40 ID:Vxoswi+gd.net

alloca

77 ：デフォルトの名無しさん ：2018/08/26(日) 09:18:39.26 ID:O9adGcKd0.net

>>75
gcc使うなりalloc()使うなりすればいい
とりあえず
vla c言語
で、ぐぐれ

78 ：デフォルトの名無しさん ：2018/08/26(日) 09:29:28.31 ID:ik1BtrwR0.net

>>75
alloca
標準ではないけどほぼ標準扱い。（殆どの環境で使える）
ただし realloca は無いので注意。

79 ：75 ：2018/08/26(日) 09:31:08.30 ID:dLFVucRz0.net

>>76-77
ありがとう、まさにぴったり。
言語レベルでの可変長配列は C11 から（オプションだけど）入ってるんだね。
90年代からメンテされてるコードだからそっちは使えなそうだけど、alloca を検討してみる。

80 ：デフォルトの名無しさん ：2018/08/26(日) 10:56:05.32 ID:O9adGcKd0.net

>>79
環境わからんからなんとも言えんが組込みとかWindowsとか意外にスタックサイズがしょぼい環境あるから気を付けてね

81 ：デフォルトの名無しさん ：2018/08/26(日) 11:49:56.37 ID:hQMrm9ZNa.net

いやいや、C99からだよ。C11でオプションになった。答える方はそのくらい知っとけよ。
まあ入力が小さいのが予め分かってないと使いにくい機能だよ。

82 ：デフォルトの名無しさん ：2018/08/26(日) 13:04:10.92 ID:HHP/3bjy0.net

>>75
その入力というのがファイルからの1行入力みたいなものならば getline() 使ってしまえば
自分で考える必要がなくて楽だ。
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/getline.3.html

83 ：デフォルトの名無しさん ：2018/08/26(日) 15:51:52.71 ID:0Dyu3Dip0.net

発端の >>75 の意図次第だが、free()しなくても安全に蒸発して欲しいとか、
ヒープの確保と解放の処理時間を嫌っての話ならgetline()はちょいと違うね。
文字数の予測が難しい入力を扱うにはとても便利なんだけど。

それにしても「上級者専用」って看板が架かってることを意識すると
このスレッドは書き込みにくいな。気後れしちゃう。

84 ：デフォルトの名無しさん ：2018/08/26(日) 16:14:52.46 ID:tQPCeAJ90.net

alloca

85 ：デフォルトの名無しさん ：2018/08/26(日) 16:21:37.62 ID:hQMrm9ZNa.net

動的確保が無難なんだよね。最後にfreeすればいいだけだし。
最近まで知らなかったんだけどscanfで%msで動的確保してくれるの便利だな。scanf自体はなかなか難しくて使いづらいが…

86 ：75 ：2018/08/26(日) 17:31:54.88 ID:dLFVucRz0.net

>>81
あ、C99で入ったのをC11でオプショナルに格下げ(?)されたってことか。
処理系によっては厳しい実装なのかな。

やりたいことってのは文字列のエスケープを含んだ組み立てなんだけど、使用するエスケープ関数がありものでその仕様は入力文字列長に対して2倍以上の出力バッファを与えないといけないことになってる（出力サイズを指定して打ち切らせることができない）。
実際に2倍に膨らむことは稀だし、エスケープするのも文字列中の一部なので、自分の処理で最終的に出す出力結果は論理最大よりかなり小さくなる（自分の処理は指定された出力長で打ち切る）。
まず来ることが無い事態のために論理最大の配列を取っておくのもどうかと思い、いい方法があるかここで相談させてもらった。
しかし想定外のことが起きちゃった時にどうなるべきかを考えてどうするかを決めるから、もしかしたら動的配列の意義が無くなって別の方法にするかもしれない。
この処理自体は高頻度で呼ばれるから、高速で省メモリそして内部的な都合での打ち切りは極力避けた作りにしたいって感じ。

いろいろコメントありがとう

87 ：デフォルトの名無しさん ：2018/08/26(日) 17:43:02.62 ID:tQPCeAJ90.net

あらかじめプールしておいて使いまわす
足りない時だけ臨時で増やす

88 ：さまよえる蟻人間 ：2018/08/26(日) 18:09:50.26 ID:Vxoswi+gd.net

ReactOSというOSでフォントエンジンの改良を行っているが、
Google Chromeというブラウザでおかしくなる。
何故かEIPレジスタがゼロになって、初回例外が発生する。KDBという付属のデバッガでトレースしたが、
どこの関数で例外が発生しているかわからない。
たすけて。。。

89 ：さまよえる蟻人間 ：2018/08/26(日) 18:15:57.28 ID:Vxoswi+gd.net

これがイシュー。
https://jira.reactos.org/browse/CORE-14926

これが問題のコミット。
https://github.com/reactos/reactos/commit/35f62fc5ba0b69e7335ff41400cb3b45660f4557

90 ：さまよえる蟻人間 ：2018/08/26(日) 18:22:22.54 ID:Vxoswi+gd.net

晒しあげ

91 ：さまよえる蟻人間 ：2018/08/26(日) 18:39:01.79 ID:Vxoswi+gd.net

スタック破壊の可能性か。。。

92 ：デフォルトの名無しさん ：2018/08/26(日) 19:04:13.59 ID:ik1BtrwR0.net

>>85
> 動的確保が無難なんだよね。最後にfreeすればいいだけだし。
結局の所、結論としてはそうだね。

>>86
多分素直にmallocする関数をラップして使う方がいい。

仕様の動向自体は知らんが、
> 処理系によっては厳しい実装なのかな。
技術的にはこれはない。alloca相当（ポインタ相当）にすればいいだけなので。
ただ、間接アクセスになるから速度は落ちるし、
mallocに対しての利点は『自分で』freeしなくて済むことくらいしかない。
（『自分で』ソースに書かなくてよくなるだけで、速度上のメリットはない。
reallocaが無い為、最初のバッファ（＝サイズが不明）はヒープ上に動的確保するしかなく、
自分で書いてなくてもどこかでfreeされてるだけだから。なら最初からgetlineでもいいし)

ただ、そちらの実装は(おそらくバッファオーバラン対策で)一旦固定長バッファに取り込み、
その後alloca領域に対してのコピーか？
ならまあ一応freeしなくていい速度上のメリットは残るが、
一般的にはスタックサイズ管理のコストが増える方が問題とされ、その実装はないとも思うが。

結局、allocaもイマイチなんだよ。だから標準にもなりきれない。

93 ：デフォルトの名無しさん ：2018/08/26(日) 19:12:21.53 ID:ik1BtrwR0.net

>>83
>>1,13読んで以下にどうぞ。
C言語なら俺に聞け
https://mevius.5ch.net/test/read.cgi/tech/1534430162/

>>12
>>89
それがこのスレの正しい使い方かもしれんね。
ぱっと見て分かるものでもないけどさ。

94 ：デフォルトの名無しさん ：2018/08/26(日) 19:20:25.22 ID:uLlG7vHAa.net

allocaとか動的サイズ指定の配列はスタックだから基本的にはmallocするよりは速いよ。頑張っても同等。
繰り返して呼ぶなら差が出るかもね。

95 ：デフォルトの名無しさん ：2018/08/26(日) 19:53:34.99 ID:ik1BtrwR0.net

ああ、言い直しておくよ。
allocaとmallocなら、

確保：allocaの方が速い
使用：同速(ただし初回からキャッシュが当たる分allocaの方が速い）
解放：freeの必要が無い分、allocaの方が速い
　（ただし実装によっては上位でfreeしてるだけであり、同速）
管理：通常、ヒープサイズ>>>>>>スタックサイズの為、サイズ管理が必要

速度差が見えるような使い方が出来るのなら、ある意味大したもんだと思うよ。

96 ：デフォルトの名無しさん ：2018/08/26(日) 20:17:14.11 ID:iSNBdVUGa.net

スタックって確かスレッド毎に肥大化してくよね？
で、肥大化してもスレッドが停止するまで縮小しない

あってる？

97 ：さまよえる蟻人間 ：2018/08/26(日) 20:19:54.25 ID:r4V1HxTD0.net

関数から戻るとき(エピローグ)にスタックは縮小することがある。

98 ：さまよえる蟻人間 ：2018/08/26(日) 20:26:06.20 ID:Vxoswi+gd.net

実際のx86 CPUでスタックポインタを表しているのが、ESPレジスタの値。スタックサイズの増減はESPの書き換えに過ぎない。

99 ：75 ：2018/08/26(日) 20:30:48.56 ID:dLFVucRz0.net

流れのついでに聞いてみたいけど、malloc はスレッドセーフでしょ。
てことは内部で排他をかけてると思うけど、となるとマルチスレッド下で malloc や free を多発させるとパフォーマンス的に良くなかったりしないかな。
言ってなくてごめんだけど、今回の処理はマルチスレッドで動くんだ。
なのでバッファはスタック上に取れると都合がいいという事情もあるし、特別な初期化手順や終了手順も用意したくないから事前に malloc して使い回すってのもやりづらい。

ちなみに動作環境は x86 linux だから、alloca は SP をズラすだけの非常に高速な実装になってるんじゃないかと想像してるから、関心は高い。
でも、最悪でもスタック上に収まるバッファという前提にするなら最初から論理最大サイズ固定のバッファで良くね？なんて話もあるから、実際にどうするかはこれから検討。

100 ：デフォルトの名無しさん ：2018/08/26(日) 20:39:55.03 ID:QMrmo6TZM.net

glibcのmallocならサブarenaから獲得してくるから性能問題にはならないらしい

101 ：デフォルトの名無しさん ：2018/08/26(日) 21:03:16.49 ID:KvfxyzVvF.net

そうだよ
条件後出しω

102 ：デフォルトの名無しさん ：2018/08/26(日) 21:06:39.43 ID:ik1BtrwR0.net

>>99
サイズの問題がないのならallocaを使うことに問題はない。
mallocより遅くなる理由もないので。

ただ、普通に組めば分かるが、
> malloc や free を多発させる
ってのがあり得ない。
仮にこれがallocaで有効に代用出来るとするなら、再帰下降パーサ等、「再帰」が必要になるが、
再帰下降パーサの場合はインミュータブルでよく、元の文書をオフセット付きで参考して終わりだ。
再びallocaすることはない。
同様に、ループでパースするのなら、ループの外でmallocして十分な領域を確保し、
そこに上書きで使うことになる。だからmalloc/freeは１回ずつで済む。

もう一度言うが、allocaはスタックだから、「再帰」しないと領域を追加出来ない。
この使い方は普通無いし、君もやって無いと思うよ。
でも、普通のmallocを全部allocaで代用しても、サイズ以外の問題は無いから、可能ならそれでもいい。

103 ：デフォルトの名無しさん ：2018/08/26(日) 21:08:26.06 ID:ik1BtrwR0.net

> alloca は SP をズラすだけの非常に高速な実装になってるんじゃないかと想像してるから
これはその通り。

> 最初から論理最大サイズ固定のバッファで良くね？
これもその通り。上記ループなら普通これで行く。
それがスタック上で問題になるサイズならmalloc/freeが１回ずつ必要になる。
だから君の今の実装>>75もさほど悪いわけでもない。

今風の「実装を外に漏らさない」方針なら子関数でmalloc/freeやallocaすることになる。
おそらくそれで考えているのだと思うが、元々のCの思想はそれとは違い、

char* buff = (char*)malloc( ... );　// または char buff[2048]; 等
while (....) {
parse_func(buff, .... );
}
free(buff);

として外側で確保し、それをparse_funcに渡す。
これにより、変数の寿命とスタックの動作を一致させ、freeし忘れもなくなる。
この方法だと、allocaで毎回「SP をズラすだけ」すらする必要なく、parse_func内は最速になる。
(allocaを毎回繰り返すよりも速い）

104 ：デフォルトの名無しさん ：2018/08/26(日) 21:12:44.54 ID:uLlG7vHAa.net

あくまで処理系依存の話として…
マルチスレッド固有の問題はほぼない気がしますね。malloc/freeは単に別の領域確保していくだけだしスタックの場合はスレッド生成時に確保すると。
で、まあmallocの実装はそこまで悪くないと思うけどスタックが速いし、さらに静的領域の方がちょっと命令数は少なくなるでしょう。

105 ：75 ：2018/08/26(日) 21:36:27.43 ID:dLFVucRz0.net

>>102-103
いろいろありがとう。材料は揃ってると思うので、最終的にどうするかはこれから決めるよ。

>>104
malloc は内部的にはヒープから領域を切り出してくるわけで、切り出したチャンクは恐らくリンクかなにかで管理してるはずでしょ。
これはプロセス単位で一式だから、マルチスレッドでよってたかってこの構造を更新するには排他は欠かせないと思うんだがどうなんだろ？
切り出されたメモリがマルチスレッド下でどうかという話ではなく。
>>100 の内容はちょっと分からないから調べてくるが、結局は誰かが排他してるんじゃないのかな。

106 ：デフォルトの名無しさん ：2018/08/26(日) 21:52:41.59 ID:QMrmo6TZM.net

>>96
実行環境依存だが、win/linuxならその認識で良い
allocaは便利だがスタックの肥大化を加速させるので
環境によっては注意が必要

>>105
興味があれば
https://youtu.be/0-vWT-t0UHg

107 ：さまよえる蟻人間 ：2018/08/26(日) 22:03:50.42 ID:r4V1HxTD0.net

>>97-98 間違いです。すみません。

108 ：デフォルトの名無しさん ：2018/08/26(日) 22:07:11.30 ID:ik1BtrwR0.net

>>105
以下読め。マルチスレッドに関する疑問点については全部書いてあるから。
https://linuxjm.osdn.jp/html/LDP_man-pages/man3/malloc.3.html

109 ：デフォルトの名無しさん ：2018/08/26(日) 22:08:38.19 ID:uLlG7vHAa.net

>>105
ナイーブなmallocの実装はそうです。中央集権的。同時に動くのは1個だけ。でもクリティカルセクションはそんなに広くないかも？
まあ実装はいろいろあります。

110 ：75 ：2018/08/26(日) 23:49:28.30 ID:dLFVucRz0.net

>>106
すげーおもしろかった！
マルチスレッドでどうやってるかについても分かったよ。
過渡期の性能を犠牲にして使っていくうちにいい状態に収束するようにしてるのね。
しかし malloc のコードが 5000行てｗ
ただ、mmap すればメモリ管理のコストが小さい的な言いぶりはどうかなって気はするな、動画の中でもツッコミ入ってるっぽいけど。
結局カーネルだって何らかの形でアドレス空間の空きを検索するし、アドレス空間を割り当てる処理にしても排他はかけてるはずだから、それなりのコストはかかるし競合の問題もあるよね(ユーザーがやる処理よりも高効率だろうと思うけど)。

>>105
malloc の話を持ち出したのは、排他とかで結構遅いんじゃね？ってのが出発点なので、
排他はしてるって言うし mmap だからという説明じゃ解決って話でもないかなって感じ。

>>109
>>75 の頃の時点では K&R アロケータ程度の認識だったからマルチスレッド下ですげー遅そうな印象だったけど、さすがによく考えられているということは分かったよ。


ちなみにこれも読み始めてた。
https://www.valinux.co.jp/technologylibrary/document/linux/malloc0001/
>>106 の動画を見てだいぶ見通しがよくなった。

111 ：デフォルトの名無しさん ：2018/08/27(月) 00:24:32.33 ID:+HD/yYG+0.net

>>63
5.1.2.2.1

112 ：デフォルトの名無しさん ：2018/08/27(月) 04:36:47.89 ID:y2YT/eYl0.net

>>111
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf#page=24
ここか

113 ：デフォルトの名無しさん ：2018/08/28(火) 10:01:58.54 ID:AJzSIbICa.net

>>106
サンクス

114 ：デフォルトの名無しさん ：2018/09/01(土) 15:23:05.79 ID:Z9gelboG0.net

POSIX準拠を念頭にC言語を書かれている方に訊きたいのですが、機能検査マクロって実際どのように使われていますか
#define _POSIX_C_SOURCE 200112L
#define _XOPEN_SOURCE 600
↑僕はこのくらいであればシステム互換性は担保されると思ってるんだけど
未だにPOSIX 1998にしか対応してないOSやコンパイラとかあるんですかね。
少なくとも_XOPEN_SOURCEが600以上じゃないと<math.h>においてM_PI定数が扱えないので
数式処理のプログラムをよく書く身としてはちょっと困るんですけども……。

115 ：さまよえる蟻人間 ：2018/09/01(土) 15:25:50.73 ID:AtDk99X7d.net

>>89
解決。ヌル文字忘れ。

116 ：デフォルトの名無しさん ：2018/09/01(土) 16:42:41.27 ID:PErE712pa.net

好きな人が古い環境を使っているという事情でもなければ、単に無視すれば良いのでは

117 ：さまよえる蟻人間 ：2018/09/01(土) 16:56:39.73 ID:AtDk99X7d.net

>>114
CMakeで環境を判定して、マクロを定義するのが王道だと思う。

118 ：デフォルトの名無しさん ：2018/09/01(土) 18:20:25.47 ID:vZp6TokWM.net

#ifdefでM_PIがないときだけ自分で定義するのが手っ取り早いと思うけど。

119 ：デフォルトの名無しさん ：2018/09/01(土) 18:57:55.32 ID:uNlfHVUP0.net

>>115
乙。てかreactOSって使い物になるのか？
無理してWindows使うよりは、素直にLinuxに逃げるのが順当だと思うが。

120 ：さまよえる蟻人間 ：2018/09/04(火) 02:12:16.08 ID:I66W1B5fd.net

>>119
使い物にするのが、依頼人の要望だから、私はそれを、果たすのみ。。。

121 ：デフォルトの名無しさん ：2018/09/24(月) 03:37:05.87 ID:1deJaFMg0.net

上級者ではないんだけど 経験豊富な人に訊きたいのでここに書きます
https://git.musl-libc.org/cgit/musl/tree/include/stdlib.h
↑ここなどを見るとEXIT_SUCCESSは0で固定されています（OSによる場合分けがない）。
ということは少なくもMusl LibCプロジェクトは正常返り値を0と決めてかかっているということでしょう。

WindowsやUnix系のOSでは正常返り値は0ですが、ほかの値は絶対に考えなくていいのでしょうか
みなさんはいままで正常返り値が0でない処理系（というかOS）を見たことなどありますか。

122 ：デフォルトの名無しさん ：2018/09/24(月) 04:02:22.36 ID:bIT2p0fxa.net

0が成功を示すと規格で決まっております。

123 ：デフォルトの名無しさん ：2018/09/24(月) 12:40:59.88 ID:indqm+5q0.net

>>121
もしプロセス終了コードの具体的な数値（数値かどうか）が異なるシステムがあるなら、
正常終了を示す main() の戻り値 0 をその環境用の終了コードで成功の値にマップするのは
そのシステム向けの処理系の仕事になる。

成功・失敗の区別以外に興味がない限りCのコードを書くプログラマが気にする必要はない
と規格は想定している。

124 ：デフォルトの名無しさん ：2018/09/24(月) 13:59:06.82 ID:KzNCIBHJ0.net

>>121
おまいWindowsでexe実行したとき必ず戻り値みてるか？
BATとかあるけどさ

125 ：デフォルトの名無しさん ：2018/09/24(月) 17:18:25.80 ID:1deJaFMg0.net

>>123
なるほど crt0あたりでmainから0が来た場合の本当の成功判定を処理してるってことですね。
ありがとうございました。

126 ：さまよえる蟻人間 ：2018/10/14(日) 11:56:24.75 ID:7zcwA4Ik0.net

せっかく上級者が集まっているんだし、評論でもやりましょう。
https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/freetype.c
このソース、俺の担当なんだけど、ひまだったら
喧嘩上等で悪い所・直すべきところを全部指摘してくれ。頼むよ。

127 ：デフォルトの名無しさん ：2018/10/14(日) 12:52:43.56 ID:G4e8iFcgF.net

やっぱwindowsは糞だな

128 ：デフォルトの名無しさん ：2018/10/14(日) 13:31:35.13 ID:p/Li638e0.net

>>126
書き換えた所はどこ？

129 ：デフォルトの名無しさん ：2018/10/14(日) 13:57:45.50 ID:m0LzoO8+0.net

頑張ろうと思ったんだが、暇つぶしでやるには長すぎて挫折した。すまん。

130 ：デフォルトの名無しさん ：2018/10/14(日) 13:58:41.27 ID:b97yHnkE0.net

>>126
IntCharSetFromCodePage の for の中のひとつ目の if は削除して、for に入るまでに
if( uCodePage == 0 ) return DEFAULT_CHARSET;
をやる。
for に入るまでの if は 確率が高い順に並べる。

とか？

131 ：デフォルトの名無しさん ：2018/10/14(日) 15:07:42.66 ID:p/Li638e0.net

>>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とかもそうだけど、おそらく全部のメンバを初期化してるだろ。だったら初期化構文使った方が見た目分かりやすい。

132 ：デフォルトの名無しさん ：2018/10/14(日) 15:08:04.46 ID:p/Li638e0.net

ただし、上記は「ソースを綺麗にする方法」であって、通常は速度は落ちるので注意。
酷い話、ベタで書きまくっている方が速いのも事実。
あと、既に言ったが、上記はなぞっただけであり、関数内しか見てないので注意のこと。
本当に問題なのは関数間であり、それはガチで時間をかけて読まないと分からないから、そこまではやる気無い。
ただ、この雰囲気なら、2割くらいの関数は整理（削除）出来るのではないかと思うけど。

自分でも気になっているところがあるのなら、それを先に言うべし。見るから。

133 ：さまよえる蟻人間 ：2018/10/14(日) 15:31:36.33 ID:7zcwA4Ik0.net

気になってることと言えば、TextOutでOPAQUEモードのときに背景を塗り潰さないといけないのだが、それを一個の長方形でいっぺんに出来ないかな。

134 ：デフォルトの名無しさん ：2018/10/14(日) 15:35:42.20 ID:p/Li638e0.net

>>133
とりえあず行番号と関数名を言え。
それとも、そのソースではない一般の話？
(Ctrl-Fでは6ヶ所引っかかるが)

135 ：デフォルトの名無しさん ：2018/10/14(日) 15:44:21.77 ID:p/Li638e0.net

ちなみに、これって、実際にフォントをレンダリングしているんだよな？2次ベジエ等で。
なら、OPAQUEの場合は先に塗りつぶしておいた上に描いた方が楽だと思うけど。
再帰等の条件に描画情報を使っていてそれが出来ない場合、反転でAND取ってORすれば昔のPSETにはなる。
(フォントの黒部分にもAlpha値があるのなら全面的に計算するだけだから、これではなさそうだし）

136 ：さまよえる蟻人間 ：2018/10/14(日) 15:45:29.84 ID:7zcwA4Ik0.net

>>134
GreExtTextOutW関数のL5847...L5954です。

137 ：さまよえる蟻人間 ：2018/10/14(日) 15:47:47.17 ID:7zcwA4Ik0.net

>実際にフォントをレンダリングしているんだよな？2次ベジエ等で。
FreeTypeというフォントレンダリングライブラリでビットマップとアウトライン曲線を取得しています。

>OPAQUEの場合は先に塗りつぶしておいた上に描いた方が楽だと思うけど。
そうしてます。

138 ：さまよえる蟻人間 ：2018/10/14(日) 15:51:46.90 ID:7zcwA4Ik0.net

>>130
それはないかな。すみません。

139 ：さまよえる蟻人間 ：2018/10/14(日) 16:02:11.24 ID:7zcwA4Ik0.net

>>131
WithTagの指摘、助かった。ありがとう。
https://github.com/reactos/reactos/pull/941
他の件については後程、検討する。

140 ：さまよえる蟻人間 ：2018/10/14(日) 16:16:37.97 ID:7zcwA4Ik0.net

4つの*NameWの件、修正してみた。ありがとう。
https://github.com/reactos/reactos/pull/942

141 ：デフォルトの名無しさん ：2018/10/14(日) 16:28:37.53 ID:p/Li638e0.net

>>137
> それを一個の長方形でいっぺんに出来ないかな。
L5853のfor文が気になっているのなら、多分このCountは文字数で、
英文の場合は文字種類間ごとにピッチを変えるからこうなっているのでは？（いわゆるプロポーショナルフォント）
1回の操作に纏めたければ、文字単位でビットマップを生成して重ねるのではなく、
あらかじめ全体のビットマップを作ってそこにレンダリングしていけばいいのだけど、
速度的には速くなりそうだけど、後々面倒だから文字単位にしているのではないかと。

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

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

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

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

142 ：デフォルトの名無しさん ：2018/10/14(日) 19:15:26.67 ID:p/Li638e0.net

>>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; // --- (α）

みたいな。

143 ：デフォルトの名無しさん ：2018/10/14(日) 19:15:52.58 ID:p/Li638e0.net

ただこれ、データ埋め込みだから 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 構造体を知っているべきだ、というのであれば、
（α）の方向に変更していった方が最終的には綺麗になる。

てゆーか、頭大文字でも変数なのかー、まあそういうルールならそれでいいが。

144 ：デフォルトの名無しさん ：2018/10/14(日) 19:38:11.68 ID:p/Li638e0.net

>>143訂正
× .
○ ->
見れば分かるとは思うが。

145 ：さまよえる蟻人間 ：2018/10/14(日) 20:06:34.30 ID:kaj6ZYWld.net

https://github.com/reactos/reactos/pull/945
若干の改良。

146 ：さまよえる蟻人間 ：2018/10/14(日) 20:21:41.00 ID:kaj6ZYWld.net

OUTLINETEXTMETRICS構造体はwin32apiで定義済みだから、我々はそれを変更できない。

147 ：デフォルトの名無しさん ：2018/10/14(日) 20:35:16.55 ID:p/Li638e0.net

>>145
ご苦労様。

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


>>146
なるほど。
なら俺なら（β）+（γ）で主関数(IntGetOutlineTextMetrics)を4行減らす。
ただし、実際はサブ関数(γ）で4行増えるので、全体の記述量は変わらず、これも評価が分かれるかも。
UNICODE_STRING構造体も、変更があり得ないほどなら、ベタに密結合させて書いても問題ないからね。

148 ：デフォルトの名無しさん ：2018/10/14(日) 21:51:10.52 ID:p/Li638e0.net

>>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
}

てな感じ。

149 ：デフォルトの名無しさん ：2018/10/14(日) 22:44:56.36 ID:p/Li638e0.net

で、さらについでに言うと、最後のコピーもメンバ関数として切り出して終わりだ。
つまり、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が返ってきて落ちる様な気がするのだが、
これに対して対策されてないのは大丈夫なのか？

150 ：デフォルトの名無しさん ：2018/10/14(日) 23:00:29.98 ID:p/Li638e0.net

>>149
自己レス。
RtlInitUnicodeString と IntGetFontLocalizedName については大丈夫っぽい。


IntGetFontLocalizedNameは元のL2408で

Status = STATUS_INSUFFICIENT_RESOURCES;

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

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

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

ただ、見たところ常に RtlFreeUnicodeString を先に呼んでて、
(これは無いから正確ではないが、)
名前やフローからするとおそらく Length = 0 してくれてるから多分大丈夫だね。
誰か探してくれば見ますが。

151 ：デフォルトの名無しさん ：2018/10/16(火) 19:22:32.13 ID:Fb63Sgww0.net

https://github.com/reactos/reactos/pull/942/files/13fe63ede025c7a802676b4d95fc9287c95fa8be
見たぜ。割といいね。

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

あと、gusLanguageID がグローバルを掴むのはちょっといやなので、コンストラクタで与える。
必要なら（今回は要らないはずだが）内部で保持して、それを使い回す。

152 ：デフォルトの名無しさん ：2018/10/16(火) 19:22:49.09 ID:Fb63Sgww0.net

一般的にいうと、今は 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 を与えることにより、バグの温床を潰してる。
(動けばいいだけなら、グローバル変数を引数に積むのは無駄でしかないし）

153 ：デフォルトの名無しさん ：2018/10/16(火) 19:23:14.27 ID:Fb63Sgww0.net

コード全体のポリシーとして、 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とかのはかなり暴走しているから、「本来の」オブジェクト指向の範囲に留めた方がいいのも事実だが。

154 ：デフォルトの名無しさん ：2018/10/16(火) 19:23:33.27 ID:Fb63Sgww0.net

纏めると、コードはつまり、

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の方も駄目なの？
(仮に出来たとしても大手術になるだろうから先送りでいいが）

155 ：さまよえる蟻人間 ：2018/10/16(火) 22:05:32.39 ID:gb9oBO7dd.net

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

156 ：デフォルトの名無しさん ：2018/10/16(火) 22:26:02.42 ID:Fb63Sgww0.net

>>155
ああなるほどね。

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

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

157 ：さまよえる蟻人間 ：2018/10/29(月) 22:10:10.28 ID:PActy/D6d.net

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

Can you read this ReactOS codes?

158 ：デフォルトの名無しさん ：2018/10/30(火) 21:47:14.89 ID:jbTXNLFK0.net

>>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回もコピペしてるだろ。
それじゃ逆に意味無い。バグの検出が難しくなり、コードの品質が下がる。
（同じ努力でデバッグした場合、比較的コード品質が低いままになる）

159 ：デフォルトの名無しさん ：2018/10/30(火) 21:47:51.74 ID:jbTXNLFK0.net

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

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

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

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

160 ：デフォルトの名無しさん ：2018/10/31(水) 18:43:08.64 ID:Gx8awWOCM.net

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

161 ：デフォルトの名無しさん ：2018/10/31(水) 18:56:15.53 ID:f1tmQgGe0.net

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

162 ：デフォルトの名無しさん ：2018/11/01(木) 20:00:57.97 ID:1k1Ne2fSa.net

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

163 ：さまよえる蟻人間 ：2018/11/02(金) 12:02:06.04 ID:pL4zzXZg0.net

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

164 ：デフォルトの名無しさん ：2018/11/02(金) 14:54:13.53 ID:/QNT6Qir0.net

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

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

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

165 ：さまよえる蟻人間 ：2018/11/06(火) 17:28:59.17 ID:koMt5OtTd.net

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

166 ：さまよえる蟻人間 ：2018/12/27(木) 23:32:15.82 ID:xEoyai350.net

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

167 ：デフォルトの名無しさん ：2018/12/27(木) 23:45:14.41 ID:VBX3IQRR0.net

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

168 ：さまよえる蟻人間 ：2018/12/28(金) 01:01:43.75 ID:NxVVTuaOd.net

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

169 ：デフォルトの名無しさん ：2018/12/29(土) 00:21:34.30 ID:k8mIifua0.net

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

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

170 ：さまよえる蟻人間 ：2018/12/29(土) 15:23:25.36 ID:2U219VsL0.net

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

171 ：デフォルトの名無しさん ：2018/12/29(土) 16:34:13.08 ID:k8mIifua0.net

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

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

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

172 ：さまよえる蟻人間 ：2018/12/30(日) 14:37:19.63 ID:v5/l/oUG0.net

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

片付けた。

173 ：デフォルトの名無しさん ：2018/12/30(日) 20:00:13.41 ID:VD8xLYQ00.net

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

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

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

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

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

174 ：片山博文MZ ：2018/12/30(日) 20:43:50.92 ID:v5/l/oUG0.net

次はオバケをやるぞ。

175 ：デフォルトの名無しさん ：2018/12/30(日) 21:16:57.54 ID:VD8xLYQ00.net

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

176 ：さまよえる蟻人間 ：2018/12/30(日) 23:12:14.65 ID:KcpheNgcd.net

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

結構難しいぜ。

177 ：さまよえる蟻人間 ：2018/12/30(日) 23:27:38.22 ID:S3Gvs6pcd.net

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

178 ：デフォルトの名無しさん ：2018/12/30(日) 23:49:50.53 ID:VD8xLYQ00.net

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

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

179 ：デフォルトの名無しさん ：2018/12/31(月) 08:31:41.69 ID:g1mCMThq0.net

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

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

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

180 ：さまよえる蟻人間 ：2019/01/03(木) 05:55:20.15 ID:Lt7qYVyo0.net

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

181 ：デフォルトの名無しさん ：2019/01/03(木) 10:12:26.72 ID:NOMEwXEr0.net

いや意味が分からん。これのことか？
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 ：デフォルトの名無しさん ：2019/01/03(木) 10:51:29.12 ID:GFK4C2Tk0.net

玄奘の方が綺麗に見える

183 ：デフォルトの名無しさん ：2019/01/03(木) 14:19:47.79 ID:bUSBCT+/M.net

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

184 ：さまよえる蟻人間 ：2019/01/03(木) 15:15:51.87 ID:Lt7qYVyo0.net

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

185 ：さまよえる蟻人間 ：2019/01/03(木) 15:18:40.27 ID:Lt7qYVyo0.net

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

186 ：さまよえる蟻人間 ：2019/01/03(木) 16:13:03.62 ID:Lt7qYVyo0.net

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

これをやれ、とのこと。

187 ：さまよえる蟻人間 ：2019/01/03(木) 16:15:41.88 ID:Lt7qYVyo0.net

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

188 ：デフォルトの名無しさん ：2019/01/03(木) 18:17:11.70 ID:NOMEwXEr0.net

>>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は正しく機能しているし。

189 ：さまよえる蟻人間 ：2019/01/03(木) 18:43:36.12 ID:GkQ/2uWAd.net

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

190 ：さまよえる蟻人間 ：2019/01/03(木) 18:48:00.87 ID:GkQ/2uWAd.net

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

といった感じなんだが。

191 ：さまよえる蟻人間 ：2019/01/03(木) 18:50:26.82 ID:GkQ/2uWAd.net

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

192 ：さまよえる蟻人間 ：2019/01/03(木) 18:54:46.64 ID:GkQ/2uWAd.net

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

193 ：さまよえる蟻人間 ：2019/01/03(木) 19:00:38.66 ID:GkQ/2uWAd.net

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

194 ：デフォルトの名無しさん ：2019/01/03(木) 19:02:50.09 ID:NOMEwXEr0.net

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

195 ：デフォルトの名無しさん ：2019/01/03(木) 19:08:42.35 ID:NOMEwXEr0.net

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

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

196 ：さまよえる蟻人間 ：2019/01/03(木) 19:08:48.72 ID:GkQ/2uWAd.net

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

197 ：さまよえる蟻人間 ：2019/01/03(木) 19:19:22.47 ID:GkQ/2uWAd.net

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

198 ：さまよえる蟻人間 ：2019/01/03(木) 19:21:04.79 ID:GkQ/2uWAd.net

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

199 ：デフォルトの名無しさん ：2019/01/03(木) 19:29:38.69 ID:NOMEwXEr0.net

>>196
いや何が？

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

ABCDEF

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

F
E
D
C
B
A

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

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


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

200 ：さまよえる蟻人間 ：2019/01/04(金) 12:11:01.67 ID:BtBvG2UO0.net

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

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

201 ：さまよえる蟻人間 ：2019/01/06(日) 23:24:01.97 ID:bzgJpAnCd.net

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

202 ：さまよえる蟻人間 ：2019/01/11(金) 17:39:39.83 ID:RqYQhJM20.net

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

実証コード作成中。。。
(deleted an unsolicited ad)

203 ：さまよえる蟻人間 ：2019/01/11(金) 18:33:44.24 ID:EAu7TXxbd.net

行列のrankって何やねん。

204 ：デフォルトの名無しさん ：2019/01/11(金) 19:57:11.86 ID:z9WOdpwNa.net

次元みたいな

205 ：デフォルトの名無しさん ：2019/01/11(金) 20:18:06.89 ID:PrGvvTlD0.net

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

206 ：さまよえる蟻人間 ：2019/01/11(金) 22:09:00.22 ID:EAu7TXxbd.net

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

207 ：デフォルトの名無しさん ：2019/01/11(金) 22:13:03.22 ID:PrGvvTlD0.net

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

208 ：デフォルトの名無しさん ：2019/01/11(金) 22:14:15.55 ID:PrGvvTlD0.net

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

209 ：さまよえる蟻人間 ：2019/01/11(金) 22:37:15.43 ID:EAu7TXxbd.net

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

210 ：デフォルトの名無しさん ：2019/01/11(金) 22:42:28.74 ID:PrGvvTlD0.net

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

211 ：デフォルトの名無しさん ：2019/01/12(土) 11:32:18.24 ID:uvKv7UXV0.net

とりあえず対角化汁

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 ：さまよえる蟻人間 ：2019/01/12(土) 13:21:52.88 ID:7KwgHC6s0.net

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

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

難しい。

213 ：さまよえる蟻人間 ：2019/01/12(土) 13:28:55.77 ID:7KwgHC6s0.net

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

214 ：さまよえる蟻人間 ：2019/01/12(土) 14:59:59.65 ID:7KwgHC6s0.net

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

215 ：さまよえる蟻人間 ：2019/01/12(土) 15:41:56.58 ID:7KwgHC6s0.net

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

216 ：さまよえる蟻人間 ：2019/01/12(土) 15:43:45.84 ID:7KwgHC6s0.net

あげ

217 ：さまよえる蟻人間 ：2019/01/12(土) 16:41:49.08 ID:7KwgHC6s0.net

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

218 ：さまよえる蟻人間 ：2019/01/12(土) 17:08:43.61 ID:7KwgHC6s0.net

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

219 ：さまよえる蟻人間 ：2019/01/12(土) 18:23:54.55 ID:ztd/2QH5d.net

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

220 ：さまよえる蟻人間 ：2019/01/12(土) 18:47:03.36 ID:ztd/2QH5d.net

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

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

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

221 ：さまよえる蟻人間 ：2019/01/12(土) 20:54:11.60 ID:ztd/2QH5d.net

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

222 ：さまよえる蟻人間 ：2019/01/12(土) 21:02:02.49 ID:ztd/2QH5d.net

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

223 ：さまよえる蟻人間 ：2019/01/12(土) 23:14:26.31 ID:7KwgHC6s0.net

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

224 ：さまよえる蟻人間 ：2019/01/13(日) 13:58:43.05 ID:op1ojGMw0.net

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

発見！ デデデデーン！

225 ：さまよえる蟻人間 ：2019/01/13(日) 20:34:16.93 ID:nk+eydfgd.net

疲れた 休む

226 ：さまよえる蟻人間 ：2019/01/14(月) 08:56:42.64 ID:cZMKPFci0.net

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

227 ：さまよえる蟻人間 ：2019/01/14(月) 19:32:57.41 ID:cZMKPFci0.net

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

228 ：さまよえる蟻人間 ：2019/01/19(土) 00:42:08.80 ID:eJ/T1GXtd.net

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

229 ：デフォルトの名無しさん ：2019/01/19(土) 16:46:58.96 ID:SwmccsG20.net

コンパイラエラー 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

230 ：デフォルトの名無しさん ：2019/01/19(土) 16:58:07.77 ID:ukgk9vnp0.net

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

231 ：デフォルトの名無しさん ：2019/01/19(土) 17:04:01.25 ID:M8Q3zGyy0.net

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

232 ：デフォルトの名無しさん ：2019/01/19(土) 17:10:18.93 ID:ukgk9vnp0.net

なおURLはものすごくC#

233 ：デフォルトの名無しさん ：2019/01/19(土) 17:14:29.80 ID:SwmccsG20.net

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

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

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

234 ：デフォルトの名無しさん ：2019/01/19(土) 17:25:37.61 ID:M8Q3zGyy0.net

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

235 ：デフォルトの名無しさん ：2019/01/19(土) 17:28:06.30 ID:CZJR5oB9a.net

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

236 ：デフォルトの名無しさん ：2019/01/19(土) 17:39:49.16 ID:SwmccsG20.net

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

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

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

237 ：デフォルトの名無しさん ：2019/01/19(土) 18:08:35.17 ID:ukgk9vnp0.net

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

238 ：デフォルトの名無しさん ：2019/01/19(土) 18:20:45.50 ID:wiNfQeeu0.net

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

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

239 ：デフォルトの名無しさん ：2019/01/19(土) 19:44:47.14 ID:ukgk9vnp0.net

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

240 ：さまよえる蟻人間 ：2019/01/19(土) 20:17:57.44 ID:OnS1Fcmld.net

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

241 ：さまよえる蟻人間 ：2019/01/19(土) 21:32:10.76 ID:wSWQSKaP0.net

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

242 ：デフォルトの名無しさん ：2019/01/20(日) 18:15:56.58 ID:VD9ut2bQ0.net

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

243 ：さまよえる蟻人間 ：2019/01/20(日) 19:06:42.04 ID:cXONXUqEd.net

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

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

244 ：さまよえる蟻人間 ：2019/01/20(日) 19:11:17.24 ID:cXONXUqEd.net

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

245 ：デフォルトの名無しさん ：2019/01/23(水) 03:35:01.17 ID:b+R6E+3S0.net

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

246 ：デフォルトの名無しさん ：2019/01/23(水) 22:34:06.08 ID:GUcVvLjn0.net

>>245
>>1,13を読め

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

247 ：デフォルトの名無しさん ：2019/01/24(木) 00:14:17.02 ID:TFfQdKfR0.net

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

248 ：さまよえる蟻人間 ：2019/01/24(木) 00:15:40.93 ID:UKO/aDSAd.net

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

249 ：デフォルトの名無しさん ：2019/01/24(木) 01:12:20.09 ID:x2HCgLhu0.net

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

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

250 ：デフォルトの名無しさん ：2019/01/24(木) 01:58:08.65 ID:9qFVeQ4q0.net

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

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

251 ：デフォルトの名無しさん ：2019/01/24(木) 09:40:07.71 ID:x2HCgLhu0.net

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

252 ：デフォルトの名無しさん ：2019/01/24(木) 09:50:35.52 ID:QwFCguUR0.net

更年期障害かこいつ

253 ：デフォルトの名無しさん ：2019/01/24(木) 11:54:05.06 ID:TFfQdKfR0.net

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

254 ：デフォルトの名無しさん ：2019/01/24(木) 11:54:49.11 ID:AxB0F0Jy0.net

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

255 ：デフォルトの名無しさん ：2019/01/24(木) 12:29:56.05 ID:kIY0kOtDM.net

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

256 ：デフォルトの名無しさん ：2019/01/24(木) 12:37:17.80 ID:9qFVeQ4q0.net

i5-8600っておもっくそ書いてるんですけど。
資格だの言うなら審査付きの会員制のサイトでも作れよｗ。

257 ：デフォルトの名無しさん ：2019/01/24(木) 12:37:22.13 ID:kbMdKUa50.net

i5-8600 じゃ特定足らんの?
いや、新しいCPU全然知らないんで素朴な質問。

C言語でもなきゃ上級者でもないね。

258 ：デフォルトの名無しさん ：2019/01/25(金) 00:17:44.69 ID:a/PpKsi/0.net

結局、お前らゆとりの根本的な問題はそこなんだよ。
お前らが壊してきた物、今現在壊して行っている物を、認識出来ていない。

幼稚園児が公園の花壇を砂場と勘違いして破壊して行っているようなものだ。
ゆとりには悪気はないのだが、それが余計に救えない。

このスレももう終わりだ。
時間の問題だとは思っていたが、思っていたよりも早かった。

259 ：デフォルトの名無しさん ：2019/01/25(金) 00:18:03.51 ID:a/PpKsi/0.net

> 審査付きの会員制のサイト　(>>256)
現実的にこれが必要な状況になりつつある。
技術的にはGitHub上にフォーラムを作ってもらえるのが一番有り難い。
そうすれば各自のリポジトリを見てどの程度の奴なのか判断出来る。

コミュニティの一生、というコピペがあるだろ。
https://dic.nicovideo.jp/a/コミュニティの一生
これの英語版もあるにはある。ただ、お前らは知らないのだと思うが、
実は海外の掲示板は日本人コミュニティとは異なり、さほど劣化しない。
その理由は俺は適切なBANにあると見ている。
つまり、普通にググれば辿り着けることを質問してくる馬鹿には1ヶ月のBANとか、だ。
そんなことをする奴は基本的に使い方を間違っているのだから、1ヶ月のROMを強制する、ということ。

俺の希望は上記の通りGitHubが対応してくれることだが、
そんな他力本願な事を言っていても始まらないので、俺自身も実際に立ち上げを準備中だ。
だから今現在調査中でもある。機能している日本語/英語のプログラミングコミュニティがあれば教えて欲しい。
海外掲示板は本当に些細なことでBANを打ってくる。これは当初はスルースキルなさすぎ、と思っていたが、
日本の掲示板はスルースキルさえあればやりたい放題で、それが荒廃に繋がっているのもまた事実。
そして最近上記の通り、海外掲示板は劣化しにくいことを目の当たりにしたので、BANについての見方も変わった。

なおこれは表面的にはゆとりが悪いんだが、
実際はゆとり世代は2chをはじめとしたBAN無しの環境しか知らないから「ネット上では何をやっても良い」と勘違いしていて、
それが旧世代の「ネットはリアルの延長からのスタート」(≒さすがにそこまでは、というラインが存在する)とフィットしないからだ。
つまり旧世代に受け入れられた2chのシステムは当然旧世代用に出来ていて、
だからこそそれがゆとり世代とフィットしないという、至極当然の帰結だ。
そしてスルースキルに関しては強い物が勝つに決まっているので、結果、2chは馬鹿ゆとりに占拠され、旧世代はパージされる。
だからその受け皿を用意しようというわけだ。
実際、俺も見切りを付けつつあるし、適当な移住先がないから自前で用意しよう、ということでもある。

260 ：デフォルトの名無しさん ：2019/01/25(金) 00:18:26.97 ID:a/PpKsi/0.net

だから繰り返すが、今現在調査中だから、機能しているプログラミングコミュニティを知っていれば教えて欲しい。
あと、ゆとりも、馬鹿ゆとりのままで留まっている奴らと、ゆとりの駄目な点を理解し始めてきた奴らと分化しつつある。
ここら辺について詳しく分かる、あるいは議論出来る場があれば教えて欲しい。
そこから人材を引っ張ってこれる可能性がある。
基本的に日本のシステムでは運営議論は内々で済ませてしまっていて、結果的に人材が育っていない。
だからゆとりは何故それが掲示板を劣化させるのか分からないし、効率的に知る方法もない。
(歴史(＝スレを読めばいいだけ)ではなく、自身の経験によって学ぶしかないので、愚者を強いられる）
ただ、単純に言うと、白熱した議論で、或いは技術的に話していて言葉が激しくなったところで、掲示板が劣化することはない。
ゆとりがやっている、ググれば済むだけのことを質問し続けたりする方が、確実に死ぬ。
ゆとりは敬語を使えばいいと勘違いしているようだが、敬語なんて全く関係ない。

ただ、一応ここにも書いてはみたが、そもそもゆとりは問題を認識してないから、話が全く通じない。
だからもう諦めてる。
コミュ障というか、話し下手というか、ネットがあったからこそなんとかなった弊害か。
そこでそう受けるからそう展開する、というのが全く見えてない。これがどうにもならない。

が、まあとにかく、俺の見方は上記の通りで、準備中だ。
情報があればよろしく。必要であれば他にスレ立てる。

261 ：デフォルトの名無しさん ：2019/01/25(金) 00:43:40.56 ID:ps5S8w5k0.net

匿名掲示板をここまで大事にする奴初めて見たわ。

262 ： ：2019/01/25(金) 00:54:09.79 ID:frDzLonh0.net

>>259
これは、宮台真司もいってますね
仲間だけで作るコミュニティを（氏の言葉でいえば）「クズども」から守るためクローズドにする、あるいはネットから遮断し推薦による入会だけに制限する動きは、プログラミングに限らず10年ほど前からの傾向だそう

>>260
＞機能しているプログラミングコミュニティを知っていれば教えて欲しい
自分で探せ
そして見つけても人に教えるな
2ch に限らず社会は「人間のクズ」ばかり
クズから仲間を守らないやつはクズ

263 ：デフォルトの名無しさん ：2019/01/25(金) 01:44:49.66 ID:3fp3RkdDa.net

スラドより全然マシだよな、こっちが

264 ：デフォルトの名無しさん ：2019/01/25(金) 02:12:04.58 ID:a/PpKsi/0.net

>>261
それがお前らの駄目なところだ。
お前らが無邪気に踏みつけている土にも、誰かが花の種を植えていることはよくある。
それを認識出来てないから駄目なんだ。

お前らの、質問だけ丁寧で後でいきなり豹変する具合とか、キチガイじみてる。
ゆとりが独自の場所を持ててないのは、お前ら自身が確実に潰してる。
(新しいことをしようって奴は性格の問題で、ゆとり教育で変わる（減る）ものではないから)


>>262
自覚してないようだが、お前もクズだぞQZ。お前は話が通じない。
実際は性格ではなく記憶領域の問題だが、一般にはこれを認識出来る奴の方が少ない。
結果、お前も一般社会では十分クズ扱いのはずだ。
おそらくそれがお前がここにいる理由で、また、一向に上達している気配がない理由でもある。

が、まあ、分かった。ここでコミュニティを教えてもらえると思う方が間違いだ。
これはその通り。
アイデアだけはあれば頂こう。

なお、匿名にこだわってはいない。
可能であれば匿名がいいが、StackOverflow等も半匿名(コテハン制)なのは、
彼等がその方がいいと判断したからだ。

今現在、海外掲示板も持っていない機能として、ホワイトリスト式のBANを考えている。
荒れたときにcaptchaってのはよくあるが、それを強化する方向になる。
これについて、また、他にアイデアがあればよろしく。

265 ：デフォルトの名無しさん ：2019/01/25(金) 02:14:38.62 ID:a/PpKsi/0.net

>>263
スラドは「技術版ニュー速」で、あれは海外で言えば/tech/になる。
俺が作ろうとしているのは/prog/で、まあ、この板みたいな内容だ。

266 ： ：2019/01/25(金) 02:35:53.79 ID:frDzLonh0.net

>>264
＞実際は性格ではなく記憶領域の問題
興味深いですね、私は一般社会では性格異常と揶揄されているところではありますが、性格ではなく記憶領域の問題とは？

267 ：デフォルトの名無しさん ：2019/01/25(金) 10:53:04.33 ID:K/EFUQ2PM.net

てめえが一番スレ壊してるの自覚しようぜ

268 ：デフォルトの名無しさん ：2019/01/25(金) 11:32:47.39 ID:5+oIfs910.net

だな。
キャッシュラインの話も上っ面でなんとなく聞き覚えはあるが具体的な知見も無く役に立つ話もできずリンクのひとつも貼れないだけだろ。
最初からプロセッサも指定してるのに >>255 これw
んで顔真っ赤にして暴走w
おれからもそういう上級者様を温かく受け入れてくれるコミュニティに引っ越すことを勧めるよ。

269 ：さまよえる蟻人間 ：2019/01/30(水) 22:03:44.57 ID:ey8cY8s10.net

ReactOSにIMEを実装しろ、という要望が多いので、そろそろ。。。

https://github.com/reactos/reactos/blob/master/win32ss/user/ntuser/ime.c
まずはここにある関数を解析・実装しないといけない。
ただし、逆コンパイラ使っちゃダメ、絶対。

270 ：さまよえる蟻人間 ：2019/01/30(水) 22:15:33.15 ID:ey8cY8s10.net

NtUserが付いている関数は、カーネルの関数だから、EXEファイルから直接呼び出すことはできない。
https://github.com/reactos/reactos/tree/master/modules/rostests/apitests/win32u
のようなDLLを経由すれば、呼ぶことができる。

271 ：さまよえる蟻人間 ：2019/01/30(水) 22:22:46.19 ID:ey8cY8s10.net

流出したソースも見てはいけない。絶対。

272 ：さまよえる蟻人間 ：2019/01/31(木) 17:47:21.23 ID:Rcq678Uf0.net

世界変形の件については、コミットされたよ。

https://github.com/reactos/reactos/commit/64987cf2731f9762d0316274bf7877a9bd3d88ba

273 ：さまよえる蟻人間 ：2019/01/31(木) 17:50:25.26 ID:Rcq678Uf0.net

>>243
SetBitmapBitsの件も解決したよ。俺様有能。You know?

274 ：さまよえる蟻人間 ：2019/01/31(木) 18:01:32.62 ID:Rcq678Uf0.net

お化けウィンドウについては、メッセージ時間をまず修正しないといけないのだが、まだ自動テストに失敗していて前に進めないんだよ。

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

275 ：さまよえる蟻人間 ：2019/01/31(木) 18:12:02.35 ID:Rcq678Uf0.net

競プロの人、 助けてくらはい。。。

276 ：さまよえる蟻人間 ：2019/01/31(木) 18:13:35.27 ID:Rcq678Uf0.net

あげ

277 ：さまよえる蟻人間 ：2019/01/31(木) 18:38:55.41 ID:Rcq678Uf0.net

まずは、ReactOSでAHKテストする方法をぐぐって、と。。。

https://www.reactos.org/wiki/AHK_Test_Suite

278 ：さまよえる蟻人間 ：2019/02/13(水) 15:49:51.53 ID:GYQxg1as0.net

読んでる人、居ますか？ 居たらお返事下さい。

別の案件なんだが、ラジオやMP3で扱うような低品質な音声波形になるべくバイナリーデータを多く埋め込みたい。
多少ノイズが入っても誤り補正が働くようにしたい。
高速フーリエ変換はなんとか理解した。どうすれば、データ量と読み取り精度を両立できるか？

279 ：さまよえる蟻人間 ：2019/02/13(水) 15:55:46.66 ID:GYQxg1as0.net

環境ノイズが混じることがある。テープレコーダーでも扱うことを想定して、録音・再生速度や音程は多少ずれることがある。誤りが多過ぎたら、やり直しを促すようにしたい。

280 ：デフォルトの名無しさん ：2019/02/13(水) 15:58:28.18 ID:r1czM3zoM.net

そのノイズとは何かを定義できるなら、
それにあったノイズリダクションかければよろし

281 ：さまよえる蟻人間 ：2019/02/13(水) 15:59:03.76 ID:GYQxg1as0.net

音声は一時停止・分割・結合できることが望ましい。難しいですか？

282 ：さまよえる蟻人間 ：2019/02/13(水) 16:12:10.90 ID:GYQxg1as0.net

昔、パソコン通信とか言って、音響カプラとかモデムとかあったよな。それと少し違うのは音声データが非可逆的に圧縮される可能性があるということ。
例えばMP3に圧縮すると、元音声波形とは少し違った形になると予想できる。また、録音時にテレビの音や人間の雑談もあり得るから、環境ノイズの特性がわからないと。うーん。

283 ：さまよえる蟻人間 ：2019/02/13(水) 16:20:06.62 ID:GYQxg1as0.net

はっきりと聴覚できる音声・波形であることが第一条件。MP3圧縮しても消えない音声が第二条件。
環境ノイズに邪魔されないのが第三条件。とすると、やかましい、うるさい音になるだろう。

284 ：さまよえる蟻人間 ：2019/02/13(水) 16:36:11.40 ID:GYQxg1as0.net

>>280
環境音の測定をやってみる。ありがとう。

285 ：さまよえる蟻人間 ：2019/02/13(水) 17:28:07.09 ID:25aOYuUGd.net

スマホ時代に圧縮なし音声はコストが高いんだよな。どうしよう。

286 ：デフォルトの名無しさん ：2019/02/13(水) 18:06:01.45 ID:1V3Ppl+Pa.net

データを直接ピーガガカにしたいってことですか？
音楽に透かし的に埋め込むのではなくて。

287 ：さまよえる蟻人間 ：2019/02/13(水) 18:10:40.83 ID:25aOYuUGd.net

>>286
そうです。環境ノイズやMP3圧縮に強い音声波形でないといけないようです。

288 ：デフォルトの名無しさん ：2019/02/13(水) 18:14:31.65 ID:1V3Ppl+Pa.net

符号拡散的にエンコードした音はどうでしょうか。
透かしと言ったけど、埋め込むのではなくそのまま使う。

289 ：さまよえる蟻人間 ：2019/02/13(水) 18:22:37.73 ID:25aOYuUGd.net

>>288
その場合、おそらくフーリエ逆変換でその波形は得られる。となると、いくつか周波数の選定が必要か。

290 ：デフォルトの名無しさん ：2019/02/13(水) 18:32:43.66 ID:QnNf1eu6F.net

>>278
バイナリデータに音声を埋め込め

291 ：さまよえる蟻人間 ：2019/02/13(水) 18:34:11.30 ID:25aOYuUGd.net

>>290
逆だよ。閉鎖環境で音で脱獄しないといけない状況で使うんだよ。

292 ：デフォルトの名無しさん ：2019/02/13(水) 18:39:36.50 ID:QnNf1eu6F.net

音声とデータのS/D比はいくつくらいを想定？

293 ：さまよえる蟻人間 ：2019/02/13(水) 18:41:49.60 ID:25aOYuUGd.net

>>292
まだわからない。

294 ：デフォルトの名無しさん ：2019/02/13(水) 18:44:20.39 ID:QnNf1eu6F.net

監視すり抜けるだけならデータファイル名に.mp3付けるだけでよくね？

295 ：さまよえる蟻人間 ：2019/02/13(水) 19:05:42.40 ID:GYQxg1as0.net

>>294
世の中にはUSB接続が禁止された環境もある。

296 ：さまよえる蟻人間 ：2019/02/13(水) 20:04:03.38 ID:GYQxg1as0.net

情勢が厳しい。早く開発しないと。

297 ：さまよえる蟻人間 ：2019/02/13(水) 22:55:25.65 ID:25aOYuUGd.net

信号損失の問題は、losslessのflacを積極的に使うことで解決。
波形はsquareがはっきり聴こえることがわかった。

298 ：さまよえる蟻人間 ：2019/02/13(水) 23:10:49.71 ID:25aOYuUGd.net

信号波形の設計。クロックタイミングの合わせ方。環境ノイズの特性の測定。信号周波数の選定。信号停止、信号終了の方式の決定。

299 ：デフォルトの名無しさん ：2019/02/14(木) 13:02:29.56 ID:b/dX4O0GF.net

位相変調かければ良いんじゃね

300 ：デフォルトの名無しさん ：2019/02/14(木) 13:04:46.57 ID:b/dX4O0GF.net

あとオリジナルの曲(固定)をベースにしても良いなら
マスター曲をまず自分で保管しておいて
流れてくるデータ付き(劣化)曲を受け取ったら
マスターとの差分なり誤り訂正なりで
データ部分だけ取り出すアルゴリズム作れそうだし
それならクロックタイミングとか気にする必要無さそう

301 ：デフォルトの名無しさん ：2019/02/14(木) 14:57:54.00 ID:Tb41XywUa.net

音響カプラはただのFSKだったね

302 ：デフォルトの名無しさん ：2019/02/15(金) 11:42:07.12 ID:OZ8Dcboc0.net

たくさん詰め込みたい、っていう要求さえなければ、
「読み上げ」ソフトと「音声認識」ソフトの組み合わせ、と言いたいな。
プリントアウトした紙をOCRで読み取らせる、ってのと同じ趣向のネタ。

303 ：デフォルトの名無しさん ：2019/02/15(金) 12:13:25.93 ID:TNDmXWGMF.net

別に音楽じゃなくても数字読んでる声送れば良いのか
オデッセイみたいなローテクだな
あとはその読みをどれだけ高速化出来るかだな

304 ：デフォルトの名無しさん ：2019/02/15(金) 14:27:02.99 ID:cR6bMICsa.net

韓国語が速そうだな

305 ：デフォルトの名無しさん ：2019/02/15(金) 14:31:59.60 ID:TNDmXWGMF.net

1をイチと読む必要も無いしな
256通りの音を定義しておけば良い
65536通り定義出来るならもっと圧縮可能かも知れない

306 ：デフォルトの名無しさん ：2019/02/15(金) 15:06:52.30 ID:XKFJOQbna.net

まあ、単にQAMだよな。

307 ：デフォルトの名無しさん ：2019/02/16(土) 12:28:33.22 ID:lF7O1vprF.net

ピーヒョロヒョロピーガーじゃだめなんやろ
ちゃんと音楽でカモフラせんといかんのやろ

308 ：デフォルトの名無しさん ：2019/02/16(土) 12:52:24.23 ID:mSqP7pCT0.net

カモフラージュせんでもCDMAで良くね

309 ：さまよえる蟻人間 ：2019/02/16(土) 21:56:14.37 ID:Ksx4DODYd.net

いろいろ考えたら、音声よりも動画の方が情報量が圧倒的に多いことに気付いた。

310 ：デフォルトの名無しさん ：2019/02/17(日) 06:29:24.48 ID:S2ikZDqt0.net

画面にダンプをスクロール表示させて、デジカメで動画撮影。
持ち出した先でOCRにかけるってことだな。

いや、一画面ずつ表示させちゃ、ライターに仕込んだ小型カメラで
フィルムに撮影してもいいんだけど。
……なお、このテープは自動的に消滅する。健闘を祈る。

311 ：デフォルトの名無しさん ：2019/02/17(日) 11:38:39.98 ID:7MWZQWrl0.net

宜しく御検討下さい

312 ：デフォルトの名無しさん ：2019/02/17(日) 23:46:59.25 ID:/Va8z8eH0.net

そう言えば昔のマイコン雑誌には1画面づつ表示させて写真撮影した BASIC のリストやマシン語の16進ダンプが載っていたなあ。

313 ：デフォルトの名無しさん ：2019/02/18(月) 00:25:50.36 ID:1J61D2aXa.net

写真だったか？
ほぼ印刷じゃねえ？

314 ：デフォルトの名無しさん ：2019/02/18(月) 06:19:18.56 ID:KTgkm+s50.net

雑誌として売ってるんだから当然印刷、という混ぜっ返しは置いといて、
いったんプリントアウトした紙を原稿にして印刷屋さんに回してたよね。
物理的に切り貼りした痕跡(プログラムリスト部が傾いてる)なんかも見て取れた。

データの多いゲームでリストの字数・行数を減らすための工夫だったか、
謎解き部分の難読化が目的か、Base64風というかドラクエの復活の呪文みたいに
データに使う文字種を増やしたプログラムが掲載されたことがあったけど、
PC-6001用のリストを、普通のパソコン向けのプリンタで出したせいで
DATA文で使われた「ひらがな」が正しく印刷されなくて打ち込み不可能、
次号に長い訂正リストが載った、ってことを思い出した。
その時の訂正リストの方は画面を写真撮影したものだったような。
モニタ(っていうか家庭用テレビ)の湾曲が見えた記憶がある。

315 ：デフォルトの名無しさん ：2019/02/18(月) 07:49:01.32 ID:eNgrT0dv0.net

ベーマガで同じ機種でも月によって文字フォントが微妙に違うってことがあった気がする。

316 ：デフォルトの名無しさん ：2019/02/18(月) 13:05:25.16 ID:cZFby2grF.net

PC-6001

317 ：デフォルトの名無しさん ：2019/02/18(月) 21:37:45.55 ID:qm48QrOXM.net

ファミリーベーシックの後期はBGキャラクタをソースに埋めてたりしたが、どうやって印刷してあったんだっけ。

318 ：さまよえる蟻人間 ：2019/02/18(月) 21:40:01.24 ID:97BO6v7fd.net

>>317
外字が使えるプリンターがあったはず。

319 ：さまよえる蟻人間 ：2019/02/18(月) 22:07:14.75 ID:97BO6v7fd.net

8-bit時代は、入力されたテキストを一行ずつ印字するラインプリンターが主流で、印字モードを切り替えれば、外字やグラフィック文字などが使えたはず。

320 ：デフォルトの名無しさん ：2019/02/18(月) 22:21:21.81 ID:1J61D2aXa.net

ファミリーベーシックは確かに写真だったかも。
あれはプリンタなかったんだっけ。

321 ：さまよえる蟻人間 ：2019/02/18(月) 22:23:45.94 ID:97BO6v7fd.net

https://ja.m.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%83%9F%E3%83%AA%E3%83%BC%E3%83%99%E3%83%BC%E3%82%B7%E3%83%83%E3%82%AF

ファミリーベーシックからカセットテープに書き込み、そこから読み込んで、他のパソコンで印刷したらしい。

322 ：デフォルトの名無しさん ：2019/02/20(水) 01:51:41.58 ID:J4bEIWoi0.net

古い70年代後半や80年代前半のマイコン雑誌だと TK-80BS とか、プリンタに接続して文字を出力する事が
困難な機種に関してはプログラムリストを画面表示して写真撮影した状態で雑誌に載っていたと思う。

323 ：デフォルトの名無しさん ：2019/02/20(水) 10:26:41.54 ID:XdZkvkiSM.net

>>321
それやるツールも雑誌の中の人が手製で作ってそうだよね。
いろいろなことが解析すればなんとかなる範囲に収まってて楽しい時代だった。

324 ：デフォルトの名無しさん ：2019/02/20(水) 13:50:59.85 ID:majkFZDga.net

子供の頃はASCII形式セーブの有り難みがわからんかったわ。

325 ：デフォルトの名無しさん ：2019/02/20(水) 19:02:11.40 ID:v7iPz90JF.net

TK-80ってCRTに出せるのもあったんか

326 ：デフォルトの名無しさん ：2019/02/20(水) 19:15:37.01 ID:HQlG8gVaa.net

compo-80だな
父がプログラム入力してくれた

327 ：デフォルトの名無しさん ：2019/02/20(水) 19:18:38.64 ID:V5JGZApS0.net

調べたら TK-80BS っていう別売りのテレビ出力ボードがあったみたいね。
I/O誌あたりには、色んなワンボードマイコンに、汎用で安価なVRAMボードを
接続して使うハードウェア記事が載ってた。

あとI/O誌は、カセットテープのセーブデータの
フォーマット解析記事がやたら多かった気がする。
もしかすると一部の投稿者が、新機種の出る度に
手持ちの機材と技術で解析してたのかもしれないけど。

328 ：デフォルトの名無しさん ：2019/02/20(水) 19:25:02.15 ID:v7iPz90JF.net

https://ja.wikipedia.org/wiki/CRTC_(LSI)
https://en.wikipedia.org/wiki/Motorola_6845
この辺の載せてたのかな

329 ：デフォルトの名無しさん ：2019/02/20(水) 19:32:08.59 ID:L9lLctPa0.net

TK-80BS（Basic Stationだっけ）はTK-80にアドオンする拡張キット
東芝の奴が初めからTV出力持ってたな

330 ：デフォルトの名無しさん ：2019/02/20(水) 19:49:14.33 ID:sr7oPl810.net

基板パターンカットωωω

331 ：デフォルトの名無しさん ：2019/02/21(木) 05:00:32.48 ID:k7mDakXF0.net

TK-80BS は、単なるテレビ出力ボードじゃなくて、
キーボードやら拡張RAMやらついてたのだな。
まさにBASICを使えるようにするための拡張キットか。

…なんだかコア構想っぽいね。

332 ：デフォルトの名無しさん ：2019/02/22(金) 03:30:54.88 ID:C6SOPE3a0.net

TK-80の互換機があるのな。

aitendo、TK-80を再現したマイコンボード「ZK-80組立てキット」を発売
https://hardware.srad.jp/story/19/02/07/0621259/

333 ：デフォルトの名無しさん ：2019/02/22(金) 08:29:19.16 ID:JzNhpi55a.net

Z80アセンブリ使う楽しさって特にないわ

334 ：デフォルトの名無しさん ：2019/02/22(金) 13:08:41.40 ID:XfTm47euM.net

バイナリのまま読むのが楽

335 ：デフォルトの名無しさん ：2019/02/23(土) 12:04:53.89 ID:9pS68leH0.net

マイコンボードはやっぱI/O引っ張り出して何かのON/OFFをさせたりしないとつまんないよな。

336 ：さまよえる蟻人間 ：2019/02/23(土) 19:00:39.43 ID:mDm7639Kd.net

あと１週間くらいで完成するかな？

337 ：デフォルトの名無しさん ：2019/02/24(日) 19:44:27.45 ID:iK4D+UQia.net

>>335
ON/OFFだけならアセンブリのが短く書けたりするよね。
計算とか入るとCのが楽だけど。

338 ：デフォルトの名無しさん ：2019/02/24(日) 19:51:14.51 ID:V5RD9eRK0.net

典型的なクソレス

339 ：デフォルトの名無しさん ：2019/02/24(日) 20:26:31.54 ID:RgZ/0jGo0.net

Cよりアセンブラが便利と言えばローテート演算だね。
「まず端っこのビットを保存してから、符号なしでシフト、
保存しておいたビットを見て反対の端にビットORで重ねる」て操作が
キャリーフラグ経由で自動的にできちゃう。

……Cから離れて長い気がするので、ちょいと絡めた話にしてみた。

340 ：デフォルトの名無しさん ：2019/02/25(月) 10:44:07.01 ID:Opp/wdL50.net

なんで C の bit 演算の仕様に入れなかったんだろうってのがいくつかあるね

341 ：デフォルトの名無しさん ：2019/02/25(月) 13:03:03.90 ID:IW4EZ6JF0.net

ローテートはCでやるにはちょっと面倒だね。
でもCの仕様に入れなかったのは、演算子を考えるのがもっと面倒だったからだな。

342 ：デフォルトの名無しさん ：2019/02/25(月) 14:28:50.08 ID:dMLcUOnq0.net

昔はキャリーフラグにあたるものが無い事に不満があった。
今はそんなに重要だったっけ？って思ってる。

343 ：デフォルトの名無しさん ：2019/02/25(月) 15:32:32.74 ID:IW4EZ6JF0.net

キャリーフラグは機械語レベルなら分岐に使えるけど、Cでの活用は難しいだろうね。

344 ：デフォルトの名無しさん ：2019/02/25(月) 19:34:00.59 ID:mZYXJrCm0.net

仮に、予約語で演算後のキャリーを保存する変数なんかがあったらどう使うの？

345 ：デフォルトの名無しさん ：2019/02/25(月) 19:48:11.35 ID:y5m/9TYHM.net

言語仕様としてキャリーフラグを扱える高級言語ってTL/1以外にあるのかな？

346 ：デフォルトの名無しさん ：2019/02/26(火) 07:49:56.90 ID:iw+Rwyyy0.net

>344
オーバーフロー、アンダーフロー、ビットシフト時の外れたビットの有無
アセンブラ経験者ならアセンブラと同じようにつかうんじゃね？

347 ：デフォルトの名無しさん ：2019/02/26(火) 08:05:18.02 ID:KfjVzsm10.net

>>346
でもコンパイラがフラグを変えないように命令を配置しないといけないってのは相当な制約で、それやるくらいならインラインアセンブラ使うほうが現実的だろ。
実際のフラグを使わず言語仕様として固定的な変数のように実装する方法もあるだろうが、それやってまでフラグ的なものを再現する利点も無い。

348 ：デフォルトの名無しさん ：2019/02/26(火) 11:54:12.51 ID:iw+Rwyyy0.net

アセンブラの癖の抜けない人のモヤモヤ感解消用でもいいじゃん。

349 ：デフォルトの名無しさん ：2019/02/26(火) 14:28:27.09 ID:8+7ktUtNF.net

>>344
割り込みとかマルチスレッドとかで黒魔術化しそう

350 ：デフォルトの名無しさん ：2019/02/26(火) 20:09:24.82 ID:c/a6AL8hM.net

>>349
割り込みとかスレッド切替で変数保存されないシステムなんて見たことないが…

351 ：さまよえる蟻人間 ：2019/02/27(水) 08:41:06.65 ID:vMkihIsO0.net

転送ソフト、完成したよ。
https://katahiromz.web.fc2.com/blaker/ja

352 ：デフォルトの名無しさん ：2019/02/27(水) 13:16:21.28 ID:6J9stBVH0.net

蟻人間てこのサイトの人だったのか
大昔に見覚えがある

353 ：デフォルトの名無しさん ：2019/02/27(水) 16:25:43.56 ID:vHAcjSp10.net

て言うか、以前(2ちゃんねる時代)は 片山博文MZ てハンドルで書いてたな。

354 ：さまよえる蟻人間 ：2019/02/27(水) 17:27:23.25 ID:vMkihIsO0.net

こんなものが役に立つのかね？

355 ：さまよえる蟻人間 ：2019/02/27(水) 17:44:07.45 ID:vMkihIsO0.net

ソース: https://github.com/katahiromz/BLAKER

356 ：デフォルトの名無しさん ：2019/02/27(水) 19:45:22.65 ID:vHAcjSp10.net

BLAKER というツール名の由来にちょいと興味がある。

357 ：デフォルトの名無しさん ：2019/02/27(水) 20:13:51.21 ID:Hk/WxP350.net

PaperBack っていうソフトあったな
http://ollydbg.de/Paperbak/
作者は OllyDbg 作った人

358 ：さまよえる蟻人間 ：2019/03/02(土) 21:47:42.11 ID:vmi2lFb5d.net

>>357
参考になった。ありがとう。

359 ：さまよえる蟻人間 ：2019/03/08(金) 21:00:14.66 ID:8R2ZaOuQ0.net

次の案件は、ReactOSのドラッグ＆ドロップだ。
https://github.com/reactos/reactos/blob/master/dll/win32/ole32/ole2.c

このファイル「ole2.c」を編集し、メモ帳(Notepad)などのアプリへファイルアイコンを
ドラッグ＆ドロップできる機能を実現せよ。具体的には、RegisterDragDrop周辺を改造して、
WS_EX_ACCEPTFILES拡張スタイルを有するウィンドウについて、
ドロップターゲットが登録済みかのように振る舞い、WM_DROPFILESに反応するようにせよ。

ヒント。
https://github.com/katahiromz/DragDropSamples

キーワード：プロセス、SetProp
成功報酬：２万円分のアマゾンギフト券。

360 ：さまよえる蟻人間 ：2019/03/08(金) 22:04:41.94 ID:ZkhAqKafd.net

よく分かる解説。

GetProp/SetProp関数は、ウィンドウに任意の値を結びつける。IDropTargetはドロップターゲットを表すインターフェース。
ドロップターゲットとはドロップできる対象を意味する。
RegisterDragDrop関数は、ドロップターゲットを登録する。RevokeDragDrop関数は登録を抹消する。

361 ：さまよえる蟻人間 ：2019/03/08(金) 22:07:26.74 ID:ZkhAqKafd.net

RegisterDragDrop関数はSetProp関数を使って、登録したドロップターゲットの情報を保持する。
RevokeDragDrop関数はRemoveProp関数を使ってドロップターゲットの情報を破棄する。

362 ：さまよえる蟻人間 ：2019/03/08(金) 22:12:00.78 ID:ZkhAqKafd.net

DoDragDrop関数はドラッグ&ドロップを開始し、SetCapture関数により、ドラッグ中のメッセージ受け取りを独占する。
ドラッグ中のマウスの位置から、WindowFromPoint関数により、マウスの下のウィンドウを取得する。

363 ：さまよえる蟻人間 ：2019/03/08(金) 22:14:39.50 ID:ZkhAqKafd.net

可能ならばマウスカーソル位置のドラッグターゲットを取得し、対話を試みる。もしドロップ可能なら、カーソルはドロップ可能を表すカーソル形状になる。

364 ：さまよえる蟻人間 ：2019/03/08(金) 22:20:31.50 ID:ZkhAqKafd.net

D&Dは、あるプロセスから別のプロセスへ、プロセスをまたいだ処理になるので、プロセス間通信が必要になる。
DuplicateHandleという関数が別のプロセスにハンドルを操作する権利を与える。

365 ：さまよえる蟻人間 ：2019/03/08(金) 22:49:40.18 ID:ZkhAqKafd.net

少し実験して見た所、ドロップターゲットを登録したウィンドウではドロップを検出できた。
ゆえに、WS_EX_ACCEPTFILESを有するウィンドウで正しくドロップターゲットを振る舞い、WM_DROPFILESを送信すれば、問題は解決する。

報酬を三万円に増額する。できるヤツは居ないか？

366 ：さまよえる蟻人間 ：2019/03/09(土) 13:47:49.69 ID:D/qACm7+0.net

三分の二くらいできた。
https://github.com/reactos/reactos/pull/1403

hGlobalが正しく送信できない。。。

367 ：さまよえる蟻人間 ：2019/03/09(土) 19:32:13.70 ID:XY+I2Bbhd.net

https://jira.reactos.org/browse/CORE-15836
こっちの問題を先に解決しないと。

368 ：デフォルトの名無しさん ：2019/03/09(土) 19:34:25.18 ID:zQCMZtAK0.net

【世界教師】　私はマ�@トレーヤ、投機家は人様の生活費を掛金にするな、ニートを増やした元凶はお前だ
https://rosie.5ch.net/test/read.cgi/liveplus/1552122718/l50

369 ：さまよえる蟻人間 ：2019/03/14(木) 04:28:19.53 ID:BFJ65L4Bd.net

【朗報】DnD解決の目処が立つ。

370 ：デフォルトの名無しさん ：2019/04/13(土) 12:35:21.42 ID:a4r2Gpw40.net

>>863 それでもこの言語を選ぶ理由を知るためだ。
　そなたの示す言語があるのに、なぜpythonなのか疑問を抱くのは自然なことだ。
　疑問を解決する回答を望んでたが、それは得られなかった。

371 ：デフォルトの名無しさん ：2019/04/13(土) 12:35:55.64 ID:a4r2Gpw40.net

　インストール禁止な会社のパソコンはWeb経由で実行か。
　CodePadなら俺も知ってるが。そこまでしてpythonを使う価値があるかは疑問。

　実行速度が重要なところは、高速な言語に変更して使い分けるとかいな？。
　それは煩わしいな。高速な場面でも一通り対応できる言語のほうがいい。

　ハードウェアの性能が高ければ良いとかか？。高速なプログラム言語で、なおかつ高性能なハードウェアでないと。
　プログラムコードを改善して、プログラムの高速化か。高速なプログラム言語で、なおかつ高速で実行するプログラムコードでないと。
　C言語でも、実行の遅いプログラムコードは価値がないし。

372 ：デフォルトの名無しさん ：2019/04/13(土) 12:39:21.36 ID:a4r2Gpw40.net

うわ、間違えた誤爆だ。

373 ：蟻人間 ：2019/05/19(日) 22:57:26.41 ID:o6jxwHTr0.net

テディベア、聞いてくれ。
https://jira.reactos.org/browse/CORE-15554
我々は、フォントレンダリングにおいて、テキストの変形と座標変換を
完璧にしないといけない。パスの必要なテストは、
C:\ReactOS\bin> gdi32_apitest TextTransform
だ。現在、いくつかテスト失敗がある。座標変換は何か間違えている。
何らかの修正が必要だ。
ターゲットは、$REACTOS/win32ss/gdi/ntgdi/freetype.c のIntExtTextOutW関数だ。
論理座標(LP)からデバイス座標(DP)へ変換して、それに
デバイス原点dc->ptlDCOrigを足したもので
IntEngMaskBlt関数を呼ばないといけない。
LOGFONT.lfWidth、LOGFONT.lfEscapement、WorldTransformなど
さまざまな変形があるため、本当に複雑なものになっている。
今月中に解決しないといけない。

374 ：蟻人間 ：2019/05/20(月) 18:50:51.09 ID:m/UtbRiId.net

lfWidthの指定があれば、幅を調整する必要がある。
lfEscapementの指定があれば、参照点を中心にテキストを回転しないといけない。
さらにグラフィックスモードがGM_ADVANCEDなら変形行列WorldTransformを適用する必要がある。

375 ：デフォルトの名無しさん ：2019/05/20(月) 19:36:32.71 ID:nhYoGCfjM.net

初心者版に行け

376 ：蟻人間 ：2019/05/21(火) 14:50:07.77 ID:MkUHRfEld.net

>>375
初心者や中級者にこんなの出来るわけないだろ。いい加減にしろ。

377 ：デフォルトの名無しさん ：2019/05/21(火) 15:03:29.88 ID:ZkFrsYXhM.net

アルゴリズムの話であってCの話ではなくない？
Cの話として上級なの？

378 ：デフォルトの名無しさん ：2019/05/21(火) 18:15:35.02 ID:UdJL+OJH0.net

アフィン変換の重ねがけ（ただし重ねる順は要注意）ってなわけにはいかんのかね

379 ：131 ：2019/05/21(火) 22:28:52.93 ID:ff2E85uv0.net

>>373
ここは初心者に荒らされるのでもう諦めてる。
ゆとり/さとりはモラルがなさ過ぎて、どうしようもない。
とはいえ、おそらく彼等は「糞なネット」しか見たことがなく、「ましな状態」を想像出来なくての事だ。
当人達は全く荒らしている自覚がないのでどうにも救いようがない。
（治安の悪い地区に住む者が、その治安の悪さを問題視出来ないのと同じ。そういう物だと思ってる）

だから、初心者をBAN出来る掲示板があればそっちでやりたい。
(そこでゆとり/さとりにも「ましな状態」を見せないことには改善しない）
redditか8ch等で既にあればそこを利用するのが楽でいいから指定してくれ。
なければ自前で用意する事になるが、それならついでに色々準備したいからあと数年かかる。
なお再度言うが、「初心者は全員BAN」してくれるところな。「初心者用」のスレがあるだけでNGだ。

380 ：131 ：2019/05/21(火) 22:29:12.17 ID:ff2E85uv0.net

が、ちょっと気になったことを言っておく。
131の時に見た限りでは、正直、あのコードで今君がやってるようなアジャイル開発は無理だ。
コード分岐が無駄に多すぎる。
(念のため言っておくが、今のコードを見たわけでない）

> 座標変換は何か間違えている。
これについて、単純には
・変換式を間違えている
・変換式は合っているが、コードが抜けている
の2通りのバグり方があるわけだが、どっちか認識出来てるか？

君はアフィン変換も怪しかったのでいまいち信用ならないが、
普通は変換式なんて仕様通り記述すればいいだけで、間違えないし、間違うものでもない。
また、変換式自体を間違っている場合は全部failするからすぐ分かる。

通ったり通らなかったりする場合は後者、つまり、あるべき場所でコードが抜けてるとか、コードの記述場所を間違えているとかだ。
これが発生するのは、コードに無駄に分岐があるからであり、言ってしまえばコードが汚いからだ。
アジャイルで今後とも少しずつ機能を追加していく気なら、いつかコードを整理しないと破綻すると思うぞ。
全仕様をそろそろ完備ならそのままやりきってしまうのも手だが。

綺麗にするのなら、まずは以下で。
・C流の分岐をケチるのは止めて、とにかく関数を小さく切り出してOAOOを厳密に守る
・すると中/上位関数は、AやってBやってCやって終わり、みたいなアホな関数だらけになる
・そうなると、上記「変換式」を書くにはここしかない、というのが唯一1ヶ所に確定する
結果、抜けたり、間違った場所に配置してしまう、ということがあり得なくなる。
逆に言えば、抜けたり、間違った場所に配置出来るのはコードが汚いから。

OAOOが徹底された場合、ほぼ常に「この機能を追加するならここに唯一1回だけ書く」状況となり、
正しく書けば機能追加終了、間違えば全failとなり、動作は非常に分かりやすくなる。
よく分からん動作になってデバッグに手こずるのは、コード構成に問題があるんだよ。

381 ：デフォルトの名無しさん ：2019/05/21(火) 22:32:19.93 ID:/ZDsxX6fa.net

またおまえか

382 ：デフォルトの名無しさん ：2019/05/21(火) 22:44:33.89 ID:ff2E85uv0.net

>>381
そういうのは少しでも役に立つ可能性のある情報を書いてから言え
お前らゆとりはそこが駄目なんだよ

といっても聞かないし、聞かない理由も分かってきたので対策をするわけだ
なおさとりはゆとりとはちょっと違い、ゆとりよりはましになってる
ただ、いずれにしても「まともなネット」を見せないことには先に進まない
お前らもそれを見えば俺らがなんでゆとりに対して怒っているか分かると思うぜ

383 ：デフォルトの名無しさん ：2019/05/21(火) 23:15:28.05 ID:ff2E85uv0.net

>>373
さらについでに言うと

> LOGFONT.lfWidth、LOGFONT.lfEscapement、WorldTransformなど
> さまざまな変形があるため、本当に複雑なものになっている。
これも根本的にやり方を間違ってる。
普通はスーパーセットを整備してから、サブセットを使うんだよ。
いちいち別に整備しない。

例えば、回転と平行移動が必要なら、アフィン変換を準備して、回転または平行移動として使う。
勿論、速度面でオーバーヘッドは出るが、
究極に速いコードと構成が美しいコードはあまり両立しない。
アジャイルの場合は後者、つまりコードを優先しないと開発が破綻する。

様々な変形があると分かっているのなら、最初から全部対応出来る構成で行くんだよ。
それはコーディングする前にちゃんと考えないと駄目なんだ。
アジャイルは「一つずつやる」事ではない。
未来の仕様なんて分からないから、
「現在確定している仕様を全て満たすにはこれが最適」をひたすら繰り返してるだけだ。
Windows互換だと最初から分かってるのなら、
win32APIを全部眺めた上で最初から「最適構造」でコーディングするのが一番効率がよく、
これはまさにウォーターフォール設計そのものだ。
仕様が確定している以上、ウォーターフォールを選択しないのは間違いだが、
最終的にも糞どうでもいいAPIなんて実装する気がない、というのならアジャイルもありだ。
ただ、アジャイルならアジャイルなりの構成にしないと無理で、君のコードはそれが出来てない。

もっと上位のコーディング戦略がおかしいんだよ。
だからそれをまず直せといっている。
なおウォーターフォールの場合は「仕様変更はしない」という大前提なので
コードなんて汚かろうがコピペだらけであろうが全く問題ない。そして君のコードはこれだ。

384 ：蟻人間 ：2019/05/21(火) 23:32:13.04 ID:MkUHRfEld.net

グリフの変形はfreetypeで行うことになってる。
変形は参照点を中心に考え、変形した後で平行移動しないといけない。
だから単なるアフィン変形では対応できない。

385 ：蟻人間 ：2019/05/21(火) 23:38:40.78 ID:MkUHRfEld.net

ややこしいアフィン変形の合成の計算になると予想される。変換式はまだ確定していない。

386 ：蟻人間 ：2019/05/21(火) 23:40:43.72 ID:MkUHRfEld.net

現在のソースはこれ
https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/freetype.c

387 ：デフォルトの名無しさん ：2019/05/22(水) 00:32:45.01 ID:TVjFGGsu0.net

>>385
すまんがソースを見る気はない。
ただ、方向性を完全に間違ってて、

×　ややこしい変換式を実装しきる
○　単発の単純変換の組み合わせで対応する

なんだよ。>>378が方向性は合ってる。
ただ、ちゃんと実装すれば重ねがけにすらならず、単に、

A変換を必要なら行う
B変換を必要なら行う
C変換を必要なら行う

になって終わるはず。
合成変換を実装するのは最速チューニングであって、開発性重視のアジャイル向きコーディングではない。
この根本戦略が間違ってる。
アジャイルで行くなら、基本的にコードはシンプルに、単純に動く実装を積み重ねて、
必要なら速度チューニングする位で行かないと破綻する。

単純に言えば、まずは遅くていいからコード量が一番少ない実装を選べ、ということ。
(Cの場合は手抜き実装でも大してコード量が変わらないから分かりにくいかもしれないが)

388 ：デフォルトの名無しさん ：2019/05/22(水) 09:24:29.43 ID:QBLOwo/G0.net

>>384
そのグリフ変形ってのは非線形写像で
元々直線のものが曲線に投影されるような写像なの？

ｱﾌｨﾝ変換は線形写像で
平行移動 拡大縮小 回転 せん断(平行四辺形) を表現できるんだけどさ

389 ：デフォルトの名無しさん ：2019/05/22(水) 11:05:05.28 ID:1OSMRbFi0.net

テンソルですね判りますω

390 ：蟻人間 ：2019/05/22(水) 18:34:00.49 ID:PIPD7DKBd.net

バイトで疲れた
少し休む

391 ：デフォルトの名無しさん ：2019/05/22(水) 19:07:43.18 ID:x0vcQb3n0.net

病院行っとけ

392 ：蟻人間 ：2019/05/22(水) 19:24:14.99 ID:PIPD7DKBd.net

グリフというのはフォントの各文字の形状のこと。

アフィン変形行列で、ある点P(px, py)を中心に角度θ回転させるってどうやって書くんだっけ？

393 ：デフォルトの名無しさん ：2019/05/22(水) 19:31:44.58 ID:Y0ViVk0D0.net

平行移動-px,-py →　回転(原点中心) →　平行移動px,py
これを合成するか記述するか

394 ：蟻人間 ：2019/05/22(水) 19:32:47.72 ID:PIPD7DKBd.net

Win32のWorldTransformはアフィン行列を使っているから、アフィン変換で表せる。
座標変換は、ワールド座標からページ座標への変換、そしてページ座標からデバイス座標への変換の二つを合成して考えないといけない。
ややこしいのは座標変換とグリフ変形を両方考えないといけないこと。

395 ：蟻人間 ：2019/05/22(水) 20:06:05.20 ID:U51Avb/v0.net

https://github.com/reactos/reactos/blob/master/win32ss/gdi/ntgdi/freetype.c#L5796
freetype.cの5796行目。
FT_Set_Transform(face, &mat, NULL);
FT_Set_TransformにFT_Matrix matをセットすることでグリフを変形できる。
FreeTypeのFT_Matrix構造体には平行移動の成分はない。

5798行目から5871行目まで。テキストの変位（幅と高さ）を計算する。
背景を塗りつぶしたり、下線を描きたい場合は、変位を計算しなければならない。
テキストはグリフの並びであるから、全体の幅を求めたい場合はグリフを一つ一つスキャンするしかない。

5910行目から5948行目まで。必要に応じてvecs構造体に座標を格納する。
5950行目から5987行目まで。座標変換を行う。この辺に間違いがあるかもしれない。

396 ：蟻人間 ：2019/05/22(水) 20:16:47.33 ID:U51Avb/v0.net

「ワールド座標からページ座標への変換」、すなわち、
WorldTransformは、dc->pdcattr->mxWorldToPageで表せるが、
(dc->pdcattr->flXform & WORLD_XFORM_CHANGED)がセットされている場合は、
事前にDC_vUpdateWorldToDevice(dc);を呼んで更新しなければならない。
この変換は、グラフィックスモードがGM_ADVANCEDの場合のみ適用される。
GM_ADVANCEDの場合、グリフもこのような変形が適用される。

「ページ座標からワールド座標への変換」は、
DC_vGetPageToDevice(pdc, &mxPageToDevice);で
MATRIX mxPageToDeviceとして取得できる。

397 ：蟻人間 ：2019/05/22(水) 20:25:44.38 ID:U51Avb/v0.net

グリフは次のような変形が適用される。
1) lfWidth変形。lfWidthが非ゼロのとき、幅を調整する。
2) lfEscapement変形。テキストの傾きをつかさどる。lfEscapementが非ゼロのとき、参照点を中心としたグリフの回転を行う。
3) lfOrientation変形。GM_ADVANCEDの場合、lfEscapement変形に加えて１文字ごとの回転を引き起こす。今回は考えない。
4) WorldTransform変形。GM_ADVANCEDの場合、適用される。

398 ：蟻人間 ：2019/05/22(水) 20:43:40.14 ID:PIPD7DKBd.net

計算苦手だからMaximaでも使おうか

399 ：蟻人間 ：2019/05/22(水) 21:47:56.58 ID:U51Avb/v0.net

Maximaで行列。
file:///C:/Users/katahiromz/Desktop/maximaintro.pdf

400 ：デフォルトの名無しさん ：2019/05/23(木) 02:14:48.74 ID:srO5/BaDa.net

アリって高校行ってないのか

401 ：蟻人間 ：2019/05/23(木) 03:46:25.63 ID:Kz6b19yN0.net

#include <windows.h>
#include <stdio.h>
int main(void)
{
XFORM x1 = { 0, 1, 1, 0, 5, 6 }, x2 = { 1, 2, 3, 4, 3, 4 }, x3;
HDC hDC = CreateCompatibleDC(NULL);
SetGraphicsMode(hDC, GM_ADVANCED);
SetWorldTransform(hDC, &x1);
ModifyWorldTransform(hDC, &x2, MWT_LEFTMULTIPLY);
GetWorldTransform(hDC, &x3);
// 0.000000, 1.000000, 1.000000, 0.000000, 9.000000, 9.000000
printf("%f, %f, %f, %f, %f, %f\n",
x3.eM11, x3.eM12, x3.eM21, x3.eM22, x3.eDx, x3.eDy);
return 0;
}

402 ：蟻人間 ：2019/05/23(木) 03:49:52.57 ID:Kz6b19yN0.net

# Maxima (Shift+Enterで実行)
X1:matrix([0,1,0],[1,0,0],[5,6,1]);
X2:matrix([1,2,0],[3,4,0],[3,4,1]);
display(X2 . X1);

おっけー、結果が一致する。

403 ：蟻人間 ：2019/05/23(木) 04:07:47.90 ID:RE0bqy1Md.net

Win32のWorldTransformは
XFORM構造体により
matrix([eM11, eM12, 0], [eM21, eM22, 0],[eDx, eDy, 1]);
と表せるアフィン変換であることがわかった。
次はある点を中心とした回転を調べてみよう。

404 ：蟻人間 ：2019/05/23(木) 04:52:55.60 ID:Kz6b19yN0.net

M1:matrix([1, 0, 0], [0, 1, 0], [-px, -py, 1]);
R1:matrix([cos(t), sin(t), 0], [-sin(t), cos(t), 0], [0, 0, 1]);
M2:matrix([1, 0, 0], [0, 1, 0], [px, py, 1]);
display(M2 . R1 . M1);

これでいいのかな？

405 ：蟻人間 ：2019/05/23(木) 08:19:12.97 ID:Kz6b19yN0.net

/* Maxima */
M1: matrix([1, 0, 0], [0, 1, 0], [-px, -py, 1]);
T1: matrix([width_ratio, 0, 0], [0, 1, 0], [0, 0, 1]);
R1: matrix([cos(t), sin(t), 0], [-sin(t), cos(t), 0], [0, 0, 1]);
M2: matrix([1, 0, 0], [0, 1, 0], [px, py, 1]);
M2 . R1 . T1 . M1;

これにWorldTransform行列を掛け合わせたものがグリフ変形行列になるんジャマイカ？
次は座標変換行列を考えてみよーー。

406 ：蟻人間 ：2019/05/23(木) 08:59:35.30 ID:Kz6b19yN0.net

あ、一つ忘れたことがあった。

TextAlign (TA_*)でTA_BASELINE以外が設定されているときは、グリフの位置をずらす必要があった。5908行目から5931行目までを参照。これまたややこし。

ここでは、「16.16形式固定小数点数」というのが使われていて、整数値が16ビット左シフトされているので注意。

407 ：蟻人間 ：2019/05/23(木) 09:07:22.03 ID:Kz6b19yN0.net

TA_BASELINE以外では、テキストの位置がずれ、参照点と回転中心がずれる。

408 ：デフォルトの名無しさん ：2019/05/23(木) 10:47:45.80 ID:Wqs4//Er0.net

最初から計算方法を確かめてから作ればよかったってことだな

409 ：蟻人間 ：2019/05/23(木) 15:32:13.39 ID:RE0bqy1Md.net

。。。このテディベア、しゃべるぞ？ 音声認識機能が搭載？

410 ：デフォルトの名無しさん ：2019/05/23(木) 17:53:35.45 ID:KaSwUSI90.net

テディベアかと思ったら毛皮で偽装したAIスピーカーだった、というお話。
独り言のつもりで喋った内容がネット経由で全世界に晒しプレイ。

そう言えばさまよえなくなったの？

411 ：デフォルトの名無しさん ：2019/05/23(木) 19:14:22.24 ID:KLPLdAni0.net

おしゃべりみーちゃん

412 ：蟻人間 ：2019/05/23(木) 20:12:22.06 ID:RE0bqy1Md.net

https://github.com/reactos/reactos/pull/1573
うまくいきそう。ありがとう、テディベア。

413 ：デフォルトの名無しさん ：2019/05/23(木) 21:08:28.55 ID:fA4TGJutM.net

行列の基礎も知らずに上級者とか

414 ：蟻人間 ：2019/05/23(木) 22:01:08.56 ID:RE0bqy1Md.net

予定より早く終わった
河豚刺身を頂くか

415 ：デフォルトの名無しさん ：2019/05/23(木) 22:34:27.34 ID:n706agj50.net

>>392
マジレスすると、そんなところで引っかかってる時点で止めた方がいい。
アフィン変換＝一次変換＋平行移動であり、
ゆとり以前は高校数学の範囲で、国立大理系レベルなら全員知ってるか、すぐに理解出来る。


>>394
× 二つを合成して考えないといけない。
○ 二つを並べて書け。

どうしても嫌なら２つを順に呼び出す関数でラップして1つに見せかけろ。
根本的に考え方を間違ってる。


>>400
まじでこれ。
腕前以前に、仕様を理解出来ない奴がコーディングしてもろくな物にはならない。
そもそもどういう順番でどの変換をかけるべきなのか理解出来てない。
動かして試さないと分からないようなら、最終的にもバグは取りきれないと思う。
動いているように見えるとしたら、今あるテストパターンで引っかからないだけ。


蟻に必要なのは、プログラミング技術ではなくて、高校数学だ。
或いはここを読んでいるど初心者についても言えるが、
高校レベルならプログラミングではなく学校の勉強、特に数学と物理に集中した方がいい。
20代前半で起業する気なら高校生以前からプログラミングをしてないと無理だが、
起業する気なし、または起業するにしても30代以降なら、プログラミングは大学生からでも十分間に合う。

416 ：デフォルトの名無しさん ：2019/05/23(木) 23:32:17.48 ID:PljKu8LZ0.net

射精してそう

417 ：蟻人間 ：2019/05/24(金) 18:25:55.35 ID:g/VWM3H0d.net

matWorld.xy = -matWorld.xy;
matWorld.yx = -matWorld.yx;
の辺りで何かおかしいと思ったら、座標系の扱いに既存のバグがあるようだ。調査に時間がかかる。

418 ：蟻人間 ：2019/06/03(月) 21:16:57.42 ID:ot1fFUFW0.net

https://jira.reactos.org/browse/CORE-16020
やり直しになりました。アルゴを再考します。

419 ：蟻人間 ：2019/06/03(月) 21:45:21.69 ID:ot1fFUFW0.net

そして始まるデスマーチ。。。

420 ：蟻人間 ：2019/07/04(木) 16:03:16.38 ID:5KPM8ZzF0.net

https://github.com/reactos/reactos/pull/1708
IntExtTextOutZeroAngleW関数を直さないといけない。
バウンディングボックスがおかしい。

421 ：蟻人間 ：2019/07/04(木) 20:57:20.52 ID:FzZdbDF3d.net

ダン。テストにgo!

422 ：デフォルトの名無しさん (ｱｳｱｳｳｰ Sacf-Im8i)：2020/07/07(火) 19:15:29 ID:/zFzmDrza.net

gotoキャンペーン

423 ：デフォルトの名無しさん ：2020/08/23(日) 15:49:17.24 ID:Y43WfYiq0.net

お前らこれどう見る？(Cの話ではないが)
> 正しい共通化とは、「同じものを共通化すること」であり「同じようなものを共通化すること」ではない。
https://xtech.nikkei.com/it/atcl/column/17/031300081/041000005/?P=2

俺はこの筆者が間違いだと思うが。
俺は後者も積極的に共通化して、というよりは積極的に「共通ルーチンを使うように」コーディングし、
結果的に「殆ど同じ事をやっているルーチン」の濫造を防いで行数を減らす＝コードの規模を抑えることの方が重要だと見ている。
つまり、この失敗ケースで最初に目指した物の方が近い。

「同じ物を共通化する」ではコードは減らない。「ほぼ同じだがちょっと違う」が大量発生してしまう。
だから最初から「同様のルーチンが必要」と分かっていればそれなりに緩く作って汎用性にするし、
当初それが分からない場合は当然「専用（＝非汎用）ルーチン」となっているが、
仕様変更で同様の物を追加で書く際に、それと纏めて無理にでも共通化する。
結果的に俺はそれで上手く行っている。（つもり）
なお俺も以前はこの作者と同様、「まず自由（つまり局所最適化）に組んで、その後共通部分を共通化」だった。
ただそれだとコードの依存性はそれぞれ別のルーチンを使うので当然減るのだが、
結果的に「ほぼ同じだがちょっと違う」だけのルーチンがやたら出来て、その後の長期的保守性が著しく落ちる。
というか、長期的保守性って結局のところ、「もう一度読み直すのにかかる時間」でしかないから、
結局は「コードの読みやすさ」＊「コードの量」であり、同じようなルーチンが山ほどあるのは悪だと気づいた。

違いはおそらく、開発フロー、つまりウォーターフォールとアジャイルの違い、また、
昔のテスト方式へのこだわり（＝一文字でも変更した部分は全部テストやり直し）から来ていると思う。
共通ルーチンがなければ、追加機能で仕様変更した際、追加部分にしか変更が影響しないので当然デグレードの危険は低くなる。
ただしそれだと無駄にコードが膨らんでいくだけで、割と早い段階で破綻すると気づいた。
とはいえ上記の俺の「上手く行っている」ははっきり言ってテストはほぼやってないので、
テストについて問題があるのは事実だが。

424 ：デフォルトの名無しさん ：2020/08/23(日) 15:56:52.71 ID:Exm+Pt+ZF.net

コボちゃんの発想だよな

425 ：デフォルトの名無しさん ：2020/08/23(日) 16:23:53.69 ID:xPfkrPy6M.net

>>423
誤) 汎用性にする
正) 汎用にする

426 ：デフォルトの名無しさん ：2020/08/23(日) 16:56:04.30 ID:Y43WfYiq0.net

>>424
なるほど、コボラーか。
日本IBMだからVBかと思っていた。

となると当初の「共通化」思想はJava組か？
で、コボラー老害がJavaの若者（というほど若くもないだろうが）を揶揄した記事かな？
これならありがちな状況ではある。

しかし俺が思うに「保守性」の向上なら「共通化」の方が正解で、
「同じ『ような』ものは共通化しない」方針は デグレード回避>>>保守性 の時に取るべき選択であり、
「保守性」向上を目指す際に取るのは間違いだと思う。（保守性は明確に落ちるから）

427 ：デフォルトの名無しさん ：2020/08/23(日) 17:18:21.25 ID:Exm+Pt+ZF.net

最近観た記事
https://www.youtube.com/watch?v=Udfmm8J8SPI

428 ：デフォルトの名無しさん ：2020/08/23(日) 18:01:07.29 ID:Y43WfYiq0.net

>>427
コピペしてるなw

俺だったらコピペせずに、表示形式とデータ、つまりCでいうprintfレベルの関数を作って共通化、
本体からはまずはそれ(printf)を直接呼ぶ。
ただし本体から呼ぶ箇所が2箇所以上になってしまう場合は、
（＝出来るだけ1箇所で済むように纏めるが、それでも2箇所以上になってしまう場合は）
一々フォーマット渡すとそのフォーマット部分をコピペすることになるのがウザイから、ラップ関数を作ってそれを呼ぶ。
この結果、動画でやってるのと上位レベルのコードは同じになるから、動画の方法でもそんなにクリティカルではない。
（後から掃除する時に難しい修正は必要ない。とはいえどうせやるなら最初から綺麗に書いとけ、だが）
まあ、入門用の動画なのだろうからいいのでは？

ただまあ、それ以前に、ゲームエンジンならスコア表示なんて当たり前にやるのだから、
もうちょっとましな方法もあるようにも思うが。Unityは全然知らんけど。
一々自前で書くのではなくて、普通にバインディグ出来ても不思議ではないが。
(そもそもC#ならproperty使えるから自前でバインディングするのも楽勝だが)

429 ：デフォルトの名無しさん ：2020/08/24(月) 10:08:27.21 ID:5+nAALyq0.net

現場猫：ヨシ！
監督猫：ヨシ！
検収猫：ヨシ！

430 ：デフォルトの名無しさん ：2020/08/24(月) 10:29:42.31 ID:seWRIuQk0.net

Ruby on Rails が、デザインパターンの宝庫

431 ：デフォルトの名無しさん ：2020/08/24(月) 12:57:21.18 ID:I647ZAoC0.net

「同じ」とは、つまりどういうことなのか？

432 ：デフォルトの名無しさん ：2020/09/29(火) 10:27:06.11 ID:FBp2gwm40.net

rect/margin

433 ：デフォルトの名無しさん：2023/02/09(木) 15:25:49.43 ID:VIOlnytai

防災の曰もとい税金泥棒の曰に地球破壞割再開とか地球破壞して人を殺して私腹を肥やすマッチポンプ腐敗テロ国家丸出しだなおい
ＧοΤοなにか゛しだの地球破壞割た゛の世界最惡の税金泥棒テ口リス├航空観光関係者はナマポだと自覚しろや
ナマポなんた゛からナマポらしく資産に借金にク儿マ禁止にとあらゆる制限かけるのか゛筋だろ
温室効果カ゛スに騒音にコロナにとまき散らして地球破壊して災害連發させて悪い物価上昇［笑）させて知的産業に威カ業務妨害して．
医療崩壞させて死ぬ必要のない者まで殺害しなか゛ら，地球に涌いた薄汚い賄賂癒着の害蟲と゛もと私腹を肥やし続ける人殺し斎藤鉄夫
従業員の生活ガ−とか．何ひとつ価値生産しないこのバ力どもに働いてるフリさせることになんの意味か゛あんのか逃け゛ずに説明してみろや
化石賞連続受賞やら世界中から囗シア顔負けに非難されなか゛ら税金て゛地球破壞する国際秩序の根幹に関わるジェ丿サヰドテ□中止して、
こいつら何ひとつ価値生産できない害虫どもをナマポらしく底辺ナマポにすれは゛いいだけの話た゛ろ世界最悪の殺人組織公明党

創価学會員は、何百萬人も殺傷して損害を与えて私腹を肥やし続けて逮捕者まで出てる世界最惡の殺人腐敗組織公明党を
池田センセ─が□をきけて容認するとか本氣て゛思ってるとしたら侮辱にもほどか゛あるぞ！
ｈТΤＰｓ：／／ｉ、ｉｍｇｕｒ．соｍ／hnli1ga.jpeg