-
Notifications
You must be signed in to change notification settings - Fork 162
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MS独自の拡張記法を許容するかどうか #115
Comments
Windowsという家の中で暮らす限り、最大のパフォーマンス(性能だけではなく)を得るためにはその家の作法にのっとらないと、エンドユーザーに提供できる満足なサービスが得られない事が多々あったので、クロスコンパイルやどのOSでも動くCLI的なコマンドでないかぎり、拡張記法はさけられないかなとおもいます。 ただ残念なのは当のMicrosoftが都合が悪くなるとまた勝手に仕様を変えてしまうこと・・・ |
MinGW 等の他のコンパイラをサポートするかしないかがポイントだと思います。 サポートしないならMicrosoft固有表現を使うことには問題ないですが、サポートするなら条件コンパイルするなり、 MinGWもサポートする前提で考えていたのですが、 |
こちらのコンパイルをサポートするあまり、提供できる機能に制限が出る、またはmsとバッティングしてそれこそスイッチが増えていくならもういっそMinGWをすててもいいのかなというおもいがありますが、 現にいまMinGWでもコンパイルできるようにするためにオーバーヘットかかってるんすかね。 |
MinGWはCRTとして msvcrt.dll を使いますので、printf 等に関して言えば、システムに入っている msvcrt.dll でどの書式が使えるかという問題になります。最近の Windows では、ファイル名は VC6 用と同じですが中身は VC2005 辺りのものが使われているのではないかと思っています。(_stat64 などがあるので。)
まあどちらにしても "%I64d", "%hs" 等の VC6 の頃からある書式なら使えるんじゃないでしょうかね。 |
自分のスタンスや所感を述べさせていただきますと、
というところです。 |
%hsについて「MinGWでも使える」ということが分かったので議論は一旦終了、と見ています。 vs2017をメイン開発環境としたい理由。 microsoftがwindows sdkをvc++向けに書いていることが正しいかどうか、ということは別問題。 VC++での開発効率を、本気で考え始めてよいのであれば、 かなり近い未来に導入提案を予定している機能のいくつかは、 |
WTLはオープンソースですが、ATLは違います。 |
すみません。嘘でした。 |
劣化版CComPtrがNGだとすると、vc++特化しかないような… ぼくが何も言わなくてもいずれそのCOMインターフェースの話は出て来るような気がしています。 MinGW というか、 GNU projects には色々お世話になってる気がするので、ビルド互換性を維持することが何かの貢献になるのなら残したい気持ちはあります。ビルド互換性を維持していく動機は、ぼくにとって「何らかの貢献」以外の何者でもないような気がします。 ならば、他の方法で貢献できないかと考えるわけです。 GNUにはvimやemacsがいるので、テキスト編集機能で貢献するのは難しい気がします。 どうでしょうか。 |
ひとつ大事な点を書き洩らしていたので追記しておきます。 自分の観測範囲内では、
という点があります。MinGW 対応が歴史的にどのタイミングで行われたのか把握していませんが、プロジェクトの方針としてどういう理由で MinGW に対応しようとしていたのかについて経緯をご存知の方がいらっしゃいましたら教えていただきたいです。 ビルド方式が複数存在することにより気を遣う点が大きく増えることは足並みを遅らせるという点で大きなデメリットであると感じていますが、それを上回るメリットがあるとするならば検討の余地はあると考えています。
これらはトレードオフの関係にあるかと思います。 |
標準語を話す事で他のプロジェクトが直接テク間接的に参考にできる、及び他のプロジェクトからソースをインスパイヤしやすくなるってことはあるじゃなと思います。 私はC++超ド素人ですがコピペしてきたソースが全然別な言語に見えることがありまづ。 ただ、
こちらが軸で他の方の参画が容易なら方言使うのもいいのかなと。 すいません繰り返しな意見になりますが。 |
おそらくですが下手に MinGW 対応のコードが混じっていることが原因で「このプロジェクトは MinGW に対応することが前提で運用されている」という誤解(?)を招いているところが大きいと思います。いや誤解ではないのかもしれませんが。 今現在での方針を定めるとしたら、これまでの経緯は一旦無かったことにしておいて「今現在のコミッタ都合で」MinGW 対応有無の方針を改めて決め直すくらいの温度感で良いと思ってます。 仮に「MinGW 対応しない」という方針になったとしても将来のどこかのタイミングで MinGW 対応の強い要望があればそのときに対応し直すことは可能かと思います。
本プロジェクトが方言ベースの書き方になっていたとしても、MinGW ベースの他プロジェクトのコードを取り込むことについてはおそらく互換性的に問題は起こらないと考えています。KENCHjp さんの言い回しを使うならば、方言に標準語が混じることがあっても動作上なんら問題はないということです。 逆に、本プロジェクトのソースコードの一部を他プロダクトで再利用するようなことがあるのであればMS独自記法は避けたほうが良いでしょう。しかしながら本プロジェクトの性質は「再利用を見据えた部品の提供」ではなく「プロダクトそのものを動かす」ことにあるので、独自記法をそこまで避ける理由は見当たらないと自分は考えています。 |
確かにあんまり特殊すぎるものは使いたくないですね。 コンピュータを扱う上で「雰囲気」のような曖昧な考え方を嫌がる人が一定数いることも認識しているのですが、メンテナンスに関わる人が人間である以上は雰囲気でよしなに運用していくのがストレスなく円滑に進める方針として悪くないと思っています。 今後も方言周りの問題は何度も出てくると思います。 方言が広範囲に分散しないように何かしらのラッパーを作って方言を一箇所に集約するという運用も場合によってはベターな選択になると思っています。 P.S. |
この議論の終着点は「今の時点(今後はさておき)で MinGW をサポートするかどうか」だと思います。 |
@berryzplus さんに調べてもらった情報をいただきましたのでここに貼っておきます。議論の材料にしていただければと。
|
話に出てきてませんが、初期のサクラエディタはVC++6.0とBCC5.5に対応していたようです。 MinGWについては、ぼくが真面目に考え過ぎてたなぁという所感ですね。 MinGW向けコードの大半は本体に食い込んでいるので、 将来的には MSIX(#101) や iOS 、android 等に対応させて行きたいですが、 |
別件の #100 でも触れましたが、ドッグフーディングできない領域は無理に対応しても誰が得するかというとウーンというのが自分の考えです。 |
ログ漁りました。 |
ぼちぼち終息でよいですか? 当初の議題は「 ms 固有の フォーマットパラメータ を許容するか否か?」 ぼく個人は、もっとガシガシ visualstudio 一択の方向に進めていきたい動機を持っていますが、 |
雰囲気的に方言許容で良さそうではありますね。 明日あたりにその旨をWikiにでも明記して、このIssueはクローズしようと思います。 一応将来的にこの話がぶり返されてもそれはそれで構わないです。現時点での方針がまずは決まればと。 |
以下 Wiki に開発ポリシーをまとめていきます。 今回は「MS独自の拡張記法は許容する」旨を記載しました。 |
僕は今のところは許容して良いと思っています。
許容したくない場合にはその理由を明確に説明しておかないと議論が平行線をたどります。
ここでちゃんと整理しておきましょう。
例
#90
The text was updated successfully, but these errors were encountered: