MS独自の拡張記法を許容するかどうか

[kobake]

僕は今のところは許容して良いと思っています。

許容したくない場合にはその理由を明確に説明しておかないと議論が平行線をたどります。
ここでちゃんと整理しておきましょう。

例

#90

https://msdn.microsoft.com/ja-jp/library/tcxf1dw6.aspx
hs は Microsoft の拡張なので使わなくて済むのなら使わないほうがいいと思います。

[KENCHjp]

僕は今のところは許容して良いと思っています。

Windowsという家の中で暮らす限り、最大のパフォーマンス（性能だけではなく）を得るためにはその家の作法にのっとらないと、エンドユーザーに提供できる満足なサービスが得られない事が多々あったので、クロスコンパイルやどのOSでも動くCLI的なコマンドでないかぎり、拡張記法はさけられないかなとおもいます。
文法的な問題で回避方法だったりもっとモダンな方法があるなら別ですけど。

ただ残念なのは当のMicrosoftが都合が悪くなるとまた勝手に仕様を変えてしまうこと・・・

[m-tmatma]

MinGW 等の他のコンパイラをサポートするかしないかがポイントだと思います。

サポートしないならMicrosoft固有表現を使うことには問題ないですが、サポートするなら条件コンパイルするなり、
Microsoft固有表現を避けるなりの対応が必要です。

MinGWもサポートする前提で考えていたのですが、
サポートしなくていいと考えていますか？

[KENCHjp]

MinGW

こちらのコンパイルをサポートするあまり、提供できる機能に制限が出る、またはmsとバッティングしてそれこそスイッチが増えていくならもういっそMinGWをすててもいいのかなというおもいがありますが、
単に文法的なお作法守って標準語をつかってるかぎりMinGW使うひととも交流できるのであれば方言使わないほうがいいかなと。

現にいまMinGWでもコンパイルできるようにするためにオーバーヘットかかってるんすかね。
コミッターではないのでそのあたりの温度感が私はつかみきれなくて。

[k-takata]

MinGWはCRTとして msvcrt.dll を使いますので、printf 等に関して言えば、システムに入っている msvcrt.dll でどの書式が使えるかという問題になります。最近の Windows では、ファイル名は VC6 用と同じですが中身は VC2005 辺りのものが使われているのではないかと思っています。(_stat64 などがあるので。)

__USE_MINGW_ANSI_STDIO をdefineすれば、規格準拠度の高い MinGW 独自の printf が使われるようになりますが、MS拡張書式にどこまで対応しているかは知りません。

まあどちらにしても "%I64d", "%hs" 等の VC6 の頃からある書式なら使えるんじゃないでしょうかね。

[kobake]

自分のスタンスや所感を述べさせていただきますと、

• MinGW でコンパイルしたことが無いので、そもそも現状のコードが MinGW でコンパイル通るかどうか知らない。
• 自分は MinGW に対して興味を持っていない。
• が、MinGW 対応したい人がいるのであればそれを止めるつもりはない。
• が、VS での開発効率を著しく落とすことがあるのであれば、それは避けてほしい。
• 例に出した "%hs" については現状のコードで既に多数使われているので、今の時点の追加実装でこの書式を使うことにNGを出すのは時期尚早に思う。仮に "%hs" の利用を弾きたいのであれば先に既存コードの整理をするのが先。その後のレビューで "%hs" が弾かれるのであれば筋は通っている。
• k-takata さんからも指摘があるとおり、おそらく "%hs" は問題なく動作すると想像される。
• それ以外の記法については随時検討が必要かもしれないが、VS 開発効率を第一優先に考えて欲しい。

というところです。

[berryzplus]

%hsについて「MinGWでも使える」ということが分かったので議論は一旦終了、と見ています。

vs2017をメイン開発環境としたい理由。
C言語でwindowsアプリを作るなら、VC++を使うべきだと考えています。
なぜなら、C言語でアプリを書くにはOSの製造元から提供されたヘッダーファイルが必要で、
windowsのヘッダーファイル(=SDK)はVC++でビルドすることを想定して書かれているからです。
OSの提供元が意図した通りのヘッダーを使うにはVC++を使うしかない、ということになります。

microsoftがwindows sdkをvc++向けに書いていることが正しいかどうか、ということは別問題。
たまに、数年前までは正しいとされていた情報が「非推奨」になってることがあるのも別問題。

VC++での開発効率を、本気で考え始めてよいのであれば、
ATLやWTLの採用も視野に入ってくると思っています。
いろいろと癖の多い MFC と比べ、ATLは扱いやすいと思っています。

かなり近い未来に導入提案を予定している機能のいくつかは、
ATL::CComPtrを使えるのと使えないのとで実装方法が全然変わってくる代物です。
ATLはMPLという一種のオープンソースで公開されているので、
MinGW互換のために 劣化版 CComPtr を提案する腹積もりでいました。
vc++特化が許されるなら本家ATLをそのまま使いたいです。

[k-takata]

ATLはMPLという一種のオープンソースで公開されているので

WTLはオープンソースですが、ATLは違います。

[berryzplus]

WTLはオープンソースですが、ATLは違います。

すみません。嘘でした。
atlは無償配布で入手できるだけでした:cry:

[berryzplus]

劣化版CComPtrがNGだとすると、vc++特化しかないような…

ぼくが何も言わなくてもいずれそのCOMインターフェースの話は出て来るような気がしています。
そのときまで保留にするか今決めるか。

MinGW というか、 GNU projects には色々お世話になってる気がするので、ビルド互換性を維持することが何かの貢献になるのなら残したい気持ちはあります。ビルド互換性を維持していく動機は、ぼくにとって「何らかの貢献」以外の何者でもないような気がします。

ならば、他の方法で貢献できないかと考えるわけです。
ソースをビルドできることは sakura の機能とは無縁なんです。
テキストエディタとしての機能で何か、具体的な貢献をすることはできないかと考えるわけです。
もしそれができたらビルド互換性を維持する理由がなくなると思います。

GNUにはvimやemacsがいるので、テキスト編集機能で貢献するのは難しい気がします。
GUI のサクラエディタならではのMinGW連携機能を何か作り込めたら卒業でいい気もします。

どうでしょうか。

[kobake]

ひとつ大事な点を書き洩らしていたので追記しておきます。

自分の観測範囲内では、

• MinGW 対応についてのプロジェクトとしてのスタンスがいまいち不明確

という点があります。MinGW 対応が歴史的にどのタイミングで行われたのか把握していませんが、プロジェクトの方針としてどういう理由で MinGW に対応しようとしていたのかについて経緯をご存知の方がいらっしゃいましたら教えていただきたいです。

ビルド方式が複数存在することにより気を遣う点が大きく増えることは足並みを遅らせるという点で大きなデメリットであると感じていますが、それを上回るメリットがあるとするならば検討の余地はあると考えています。

MinGW というか、 GNU projects には色々お世話になってる気がするので、ビルド互換性を維持することが何かの貢献になるのなら残したい気持ちはあります。ビルド互換性を維持していく動機は、ぼくにとって何らかの貢献以外の何者でもないような気がします。

• MinGW, GNU に対する貢献（？）
• エンドユーザに対するスピーディーな改修

これらはトレードオフの関係にあるかと思います。
どちらを優先すべきかについて方針をある程度共有しておく必要があるでしょう。
個人的には後者を優先したい気持ちが強いです。

[KENCHjp]

標準語を話す事で他のプロジェクトが直接テク間接的に参考にできる、及び他のプロジェクトからソースをインスパイヤしやすくなるってことはあるじゃなと思います。

私はC++超ド素人ですがコピペしてきたソースが全然別な言語に見えることがありまづ。

ただ、

エンドユーザに対するスピーディーな改修

こちらが軸で他の方の参画が容易なら方言使うのもいいのかなと。
標準語しゃべるためにオーバーヘッドがあるのなら。

すいません繰り返しな意見になりますが。

[kobake]

おそらくですが下手に MinGW 対応のコードが混じっていることが原因で「このプロジェクトは MinGW に対応することが前提で運用されている」という誤解（？）を招いているところが大きいと思います。いや誤解ではないのかもしれませんが。

今現在での方針を定めるとしたら、これまでの経緯は一旦無かったことにしておいて「今現在のコミッタ都合で」MinGW 対応有無の方針を改めて決め直すくらいの温度感で良いと思ってます。

仮に「MinGW 対応しない」という方針になったとしても将来のどこかのタイミングで MinGW 対応の強い要望があればそのときに対応し直すことは可能かと思います。

標準語を話す事で他のプロジェクトが直接テク間接的に参考にできる、及び他のプロジェクトからソースをインスパイヤしやすくなるってことはあるじゃなと思います。

本プロジェクトが方言ベースの書き方になっていたとしても、MinGW ベースの他プロジェクトのコードを取り込むことについてはおそらく互換性的に問題は起こらないと考えています。KENCHjp さんの言い回しを使うならば、方言に標準語が混じることがあっても動作上なんら問題はないということです。

逆に、本プロジェクトのソースコードの一部を他プロダクトで再利用するようなことがあるのであればMS独自記法は避けたほうが良いでしょう。しかしながら本プロジェクトの性質は「再利用を見据えた部品の提供」ではなく「プロダクトそのものを動かす」ことにあるので、独自記法をそこまで避ける理由は見当たらないと自分は考えています。

[KENCHjp]

@kobake さんの意見にほぼ同意ですね。

変な例えしましたが、方言でも九州弁どうしで会話してる分には、標準語まざっても、混乱しないと。
東北弁が混ざると混乱するかもしれないがって感じですかね。

ただ標準語で話さないとと見下す一部の人もいるかとおもうので、@m-tmatma のご指摘の通り不用意にMS独自仕様を使わないにこしたことはないかなっていうのは皆さん同意なのかなとは思います。（ですよね？）

[kobake]

確かにあんまり特殊すぎるものは使いたくないですね。
方言を使う使わないについてはゼロかイチかで無理に統一しようとはせずに、使えるところは使うくらいの感じで柔軟に運用していきたいです。随時「雰囲気」で判断するくらいで良いと思ってます。

コンピュータを扱う上で「雰囲気」のような曖昧な考え方を嫌がる人が一定数いることも認識しているのですが、メンテナンスに関わる人が人間である以上は雰囲気でよしなに運用していくのがストレスなく円滑に進める方針として悪くないと思っています。

今後も方言周りの問題は何度も出てくると思います。
その度に（人によっては面倒かもしれませんが）必要とあれば随時議論していきましょう。

方言が広範囲に分散しないように何かしらのラッパーを作って方言を一箇所に集約するという運用も場合によってはベターな選択になると思っています。

P.S.
「方言」という言い回しは文字数少ないしたぶん齟齬なく皆に意味伝わると思うので割と気に入ってます。

[kobake]

この議論の終着点は「今の時点（今後はさておき）で MinGW をサポートするかどうか」だと思います。
これについてコンセンサスが取れたらクローズしましょう。

[kobake]

@berryzplus さんに調べてもらった情報をいただきましたのでここに貼っておきます。議論の材料にしていただければと。

ログ辿ったら痕跡が残ってました。
どうも2009年に公開された blog 記事を、2012年に拾って、2013年に取り込まれたようです。
元ネタは mac 上の MinGW でビルドして遊んでいただけの模様。
upatchid:271
Imp: MinGW32 コンパイル対応

[berryzplus]

話に出てきてませんが、初期のサクラエディタはVC++6.0とBCC5.5に対応していたようです。
これらとの互換性は既にないので、折を見て関連コードのアーカイブ化を進めるのが良いと思います。
https://github.com/sakura-editor/sakura/tree/master/btool
この issue とは別件で、対応をすすめてみてもよいと思います。(優先度：低)

MinGWについては、ぼくが真面目に考え過ぎてたなぁという所感ですね。
「やりたい人がいればやればよい」です。
現在ここを見てる人の中に MinGW でビルドしたい人がいないなら気にしなくていいと考えています。

MinGW向けコードの大半は本体に食い込んでいるので、
単にアーカイブすることができない認識です。
この issue とは別件で、対応をすすめるべきだと考えています。(優先度：中)

将来的には MSIX(#101) や iOS 、android 等に対応させて行きたいですが、
他環境移植と開発環境(CRT の方言)は別の話だと思っています。
必要があれば個別に議論の場を設けて行けばよいと考えています。

[kobake]

別件の #100 でも触れましたが、ドッグフーディングできない領域は無理に対応しても誰が得するかというとウーンというのが自分の考えです。

[kobake]

話に出てきてませんが、初期のサクラエディタはVC++6.0とBCC5.5に対応していたようです。

ログ漁りました。
http://sakura-editor.sourceforge.net/cgi-bin/cyclamen/cyclamen.cgi?log=unicode&ol=200711&tree=s44
僕のスタンスとしては当初から VS 一択派だった模様ですｗ

[berryzplus]

ぼちぼち終息でよいですか？

当初の議題は「 ms 固有の フォーマットパラメータ を許容するか否か？」
で、
「MinGWは結局 msvcrt.dll に依存するからその辺気にしなくてもいいんじゃない？」
という発言がてて、
「それもそうだね。」、
とみんなが納得した状態だと思っております。

ぼく個人は、もっとガシガシ visualstudio 一択の方向に進めていきたい動機を持っていますが、
それはこの議題とは関係のない話だと思っています。

[kobake]

雰囲気的に方言許容で良さそうではありますね。
いったん許容ってことにしましょうか。

明日あたりにその旨をWikiにでも明記して、このIssueはクローズしようと思います。
@sakura-editor/sakura-developers 異論があれば今のうちにコメントを！

一応将来的にこの話がぶり返されてもそれはそれで構わないです。現時点での方針がまずは決まればと。

[kobake]

以下 Wiki に開発ポリシーをまとめていきます。
https://github.com/sakura-editor/sakura/wiki/10.DevelopmentPolicy

今回は「MS独自の拡張記法は許容する」旨を記載しました。
本 Issue は一旦クローズします。