08/12/29 23:36:26
監視端末(Windows)と機械のファームは別だろう。
端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず
263:デフォルトの名無しさん
08/12/30 00:23:35
>>261 >>262
もちろん、機械のファームはWindowsではないですが、
監視端末はWindows2000です。XpやLinuxにするだけのメリットがないので。
枯れた技術(STLですら新技術扱い)・枯れたコンパイラーしか(いまだに、VC6だぜ)使わせてくれないから、ブルースクリーンになることは、まずないよ。
>端末からの信号が途絶えたとしても、安全動作するよう普通考えるはず
のように設計指示はしてるのだけど、実際に作ってるのがFSIの新人だから、
評価だけはしっかりやらせてる。
264:デフォルトの名無しさん
08/12/30 00:43:11
なるほど！安心しました。まあ従業員の命がかかってるからそりゃ対処してるでしょうね。
265:２６３補足
08/12/30 01:05:15
EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
同じDLL（Version違い）がWindowsディレクトリにあった場合に、
動作してしまう可能性がある。
DLLのVersionチェックとかできればいいのだけど、
Versionチェックそのものがバグってた場合や、Cランタイム／MFCランタイム
に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。
Version差分によって修正されたDLLの場所に、
競合とかリークとか実装上のミスがたまたま引っかかって、
１％の確率で落ちたりしたら、だれが責任とるんじゃ？という問題があるのよ。
１００万個作る場合、１万個の不良が出てしまう。。。
だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
リスク軽減。その辺ってかんがえてる？
266:デフォルトの名無しさん
08/12/30 04:29:07
ダイナミックリンカのバージョンが変われば問題も起こるからなぁ。
プロトコルが決まっていればいいんだが、
プロトコルが一定でない関数呼び出しみたいなものは出荷検査みたいなのに対応できない。
267:デフォルトの名無しさん
08/12/30 18:15:34
>>265
まず言っとくけど、安全側に倒すってのもわかるし、DLLを強制するわけでもないぞ。
>EXEが使用するDLLが、何らかの拍子で規定の場所から消えて、
>同じDLL（Version違い）がWindowsディレクトリにあった場合に、
>動作してしまう可能性がある。
これはそういう風に依存するDLLを自動検索するよう作ってるからであって
.localファイルなりDLLを絶対パスで指定するなりすればいいんでないの？
>DLLのVersionチェックとかできればいいのだけど、
>Versionチェックそのものがバグってた場合や、Cランタイム／MFCランタイム
>に問題が合った場合、評価したDLLのVersionと違う環境で動作してしまう。
バージョンチェックがバグってたら、てそれはバージョンチェックするのはDLLホスト側なんだし
そんなバグ出るかもなんてレベルでホスト側のテスト通してるんならスタティックリンクしようがダイナミックリンクしようが
バグ埋め込みそうなものだけどなぁ。
Cランタイム／MFCランタイム側まで問題があった場合なんて言ったらそれこそスタティックリンクしようがダイナミックリンクしようがどうしようもないじゃないの。
ちなみにDllGetVersion()とかCOMとかCOM相当の自前でインターフェイスベースでコンポーネント作るとかやれば
バージョン違いでのDLLを使用することはそれなりに避けられるんじゃない？
>だったら、最初からスタティックにしておけば、DLLの外部要因をOSのDLLだけにしておける。
>リスク軽減。その辺ってかんがえてる？
その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
全てのフローを網羅するとなったら個々のモジュール間が全て統合された場合の状態を全部網羅しなきゃならないし、
一部だけテストするとなったらなったでカバーしなきゃならない状態のテスト漏れとか起こりそうだし、
DLLでモジュールを細かく分割統治するより別側面でのリスクが増大しそうな気がする。
268:267
08/12/30 18:17:14
今気づいたがぜんぜんwxWidgetsと関係ない話に脱線してるな。ｺﾞﾒﾝﾅｻｲ。
269:デフォルトの名無しさん
08/12/31 16:23:30
いや、おもしろいよ。どうせ閑古鳥スレだし。
270:デフォルトの名無しさん
08/12/31 16:39:20
wxWidgets の場合、公式バイナリのような dll が無いので、 dll をほかの wxWidgets アプリと
共有しようとしたら違うconfigやコンパイラでビルドされた dll を使ってしまう可能性があって危険。
(C言語の場合ABIが決まってるけど、C++だとコンパイラのバージョンそろえないと怖い)
だから、wxWidgets の dll を system32 とかにぶち込む気にはなれない。
dllを共用できないのであれば、スタティックリンクにした方がいらない関数をリンクから外すとか
できるのでサイズが縮む。起動時間もダイナミックリンクがいらない分早くなるはず。
271:デフォルトの名無しさん
08/12/31 16:54:07
>>267
単純に疑問なんだけど、リンク形態によってテスト工数が変わる理由がわからないんだが
単純に配布のファイルフォーマットの話じゃないの？
どっちにしろテストは全部しなきゃならんわけで
272:263
08/12/31 17:17:47
>>267
たしかに、評価工数とかを考えると、フツーにモジュールを別にしますね。
>その代わりテストするのは一塊の実行ファイルなりモジュールなりになるわけで、工数もテストの規模もでかくなると思われ。
ええおかげさまで、ひどい目に遭いましたよ。帰れない日々が・・・。
COM形式なら、最悪IFクラスそのものを切り替えてしまえばいいので
それもありですね。
やっぱ、状況しだいなのかな。
273:デフォルトの名無しさん
08/12/31 17:40:14
>>271
前に、 モジュール（DLL←→EXE）間の、
「構造体メンバのアライメント指定」が不一致が原因でメモリ壊してる
バグがあったです。と言うのは関係ないか。
どっちかというと、バイナリとしてのモジュールが違うから、
別の担当者に作業を割り当てることができるから、というのも違うな。
LIBにするのだから、IFでわけるわな。
納品される側から考えたら、DLLでもLIBでも対して違いはないですな。
作る側から考えたら、DLLの概要仕様から作らなきゃならんわけで、
めんどくさいてのはあるかも。
外注に、「DLLの要求仕様を出してないんかい」てのは、なしの方向で。
274:デフォルトの名無しさん
08/12/31 17:48:18
DLLは基本的に「そうせざるを得ない」場合にしか使わないなぁ
275:デフォルトの名無しさん
08/12/31 18:09:06
お前ら完全にスレ違いだが
いいぞもっとやれ
276:デフォルトの名無しさん
08/12/31 18:40:32
そもそも、ネタがない・・・。
無理矢理作るか？
「wxwidgets乗ってたはずのC++Builder X ってどうなったんだ」とか？
これからやろうとしてるのだけど、
MFC製Dialogベースアプリを、
wxWidgetsのMDIの一画面にしてまともに動くのかとか？
277:デフォルトの名無しさん
08/12/31 19:11:49
mfcのdllとか危険過ぎる。
278:デフォルトの名無しさん
08/12/31 23:10:02
ちょっと気になった＆連絡。
あけましておめでとうございます。
SVNのVCプロジェクトファイルなんだけど、
今までマルチバイトのはずだった(Debugと、ユニバーサルじゃない方)設定
が全部、Unicodeビルドになってる。。。
2.9に更新する場合は、wxString → char*変換周り、全部直さないとだめぽ。
279:デフォルトの名無しさん
09/01/01 04:24:51
>>278
それ以前に、ASCIIで事足りる文化圏の人間じゃないなら、最初からUnicode使っておけよ。
280:デフォルトの名無しさん
09/01/01 13:30:08
>>278
前スレとかにあったような気がするんだけど、wxWidgetsの3.0からUnicodeに統一されるよ。
詳細は以下のサイトとかが参考になると思う。
URLﾘﾝｸ(wxwidgets.blogspot.com)
281:デフォルトの名無しさん
09/01/01 20:38:42
wxとboostがあればもう何もいらない。
これでSOHO GUIアプリ請負で25歳月収60-70万だぜ。
282:デフォルトの名無しさん
09/01/02 21:05:10
>>281
すごい。SOHOって仕事は自分で営業して取ってくるの？
283:デフォルトの名無しさん
09/01/02 23:21:46
発注元の慈悲に過ぎん。あと有能な営業なら同じ仕事でも100万で取ってくる。
284:デフォルトの名無しさん
09/01/03 01:49:01
マ板ネタになりそうだからこれで最後にするが
>>282
もちろんそうよ。ただ、特定の取引先と運良く良いコネが生まれたってのもある。
283のいうとおり、相手の良心に依存してるのはたしかだ。
まだwx自体が知られてなくて、それなりのGUIを作れるわりに
オープンでクロスプラットフォームということもあって
ある程度安心してガンガン技術習得に時間投資できるから
技術的精度が良かったり小回りが効いたりで客の評価は概ね高い。
285:デフォルトの名無しさん
09/01/03 02:17:40
webやDB込みだよね？
スタンドアロンなアプリで60ならすごいな
286:デフォルトの名無しさん
09/01/03 02:52:57
たしかにスキルがあって良いコネがあれば，そんぐらいもらえるかもなあ…
羨しすぎる
287:デフォルトの名無しさん
09/01/03 09:25:49
個人は浮き沈みが激しいから最高値だけで語れないし
将来が不安すぐる
俺も学生の時に某大手商社から個人契約でやらないかって言われたけど
２年後くらいにその商社の社員の賞与が全額カットとかで
行ってたら余裕で切られてたはず
で、今はニートな訳ですが何か？
288:282
09/01/03 14:16:16
>>287
自分も今は無職だよ。
ハローワークとかでも、ちょこちょこMFC使った案件の募集をやってる(自分は面接で落ちてしまうけど)んで、
そのままクロスプラットフォーム対応にしたwxWidgetsもそれなりに需要はあると思う。
ただ、wxWidgetsはAUIとかが今後メンテ・拡張されてくのかちょっと不安。
VS2008SP1のMFCみたいな強力なGUIとか、今後開発されるのかな？
289:デフォルトの名無しさん
09/01/03 15:28:01
無職ならOSSで名を売る作業に戻るんだ
けど、OSSから職に繋がったのなんてほとんど聞いたことない
290:デフォルトの名無しさん
09/01/03 16:49:55
AUIってドッキングインターフェース？
一般的なアプリでそれほど必須の機能とは思えないけど…
ドッキングできる場所が限定されれば自分で書くのもそれほど大変じゃなさそうだし
市販アプリならスキン的にやたらエキセントリックなUIにしたがるからそっちの方をなんとかしたほうが
wxWidgetsは何処ぞの組み込み系描画ライブラリ企業からバックアップ受けてるから
wxUniversalだのの、コンポーネントを自己描画する方向性ばかりが強まりそう
でもSwingでさえLook&Feelはそれほど発展しなかったのに
wxUniversalにどれほどの需要と将来性があるか個人的には非常に不明だわ
ハロワでMFC案件なんてあるんだ、行ってみようかなぁ
291:デフォルトの名無しさん
09/01/03 18:55:11
こんなスレまでハロワとかの話題が出てきて
悲しい気分になってきた．．
292:デフォルトの名無しさん
09/01/03 21:09:04
ハロウは楽しかったなあ。俺はあんまり仮装には参加できなかったけどね。
293:282
09/01/03 21:22:39
>>289
OSSが仕事で出来れば、それに勝る幸せはないかも。
>>290
wxMac(wxCocoa?)はMac持ってないんで良く分からないんだけど、
wxGTKではMDIがノート(タブ)形式になってしまうんで、LinuxでもMDIっぽいことを
やろうとすると何だかんだでAUI頼みになりそうな気がする。
wxUniversalは個人的には黒歴史として闇に葬り去られて欲しいんだけど、
wxPythonとかではむしろ積極的に活用されてるのかな？
>>291
ごめん、ハロワとかの暗い話題はこの辺でやめときます。
294:デフォルトの名無しさん
09/01/12 12:28:27
290みたいな御託だけで何もしなさそうな奴が、無職なのはすごく納得する。
295:デフォルトの名無しさん
09/01/12 15:59:53
wxBlogの方で以下の記事を見かけたんだけど、
日本語に翻訳されたものって何処かにあるのかな？
[wxBlog: Another Year of WX]
URLﾘﾝｸ(wxwidgets.blogspot.com)
[The Wonderful World of wxWidgets 3.0]
URLﾘﾝｸ(svn.wxwidgets.org)
296:デフォルトの名無しさん
09/01/12 17:45:04
>>294
御託だけで何もしないか、そうか、悪かったな。
>>295
概要だけで許せ
[wxBlog: Another Year of WX]
●2008年のwxの大きな動き
・コード書きより環境の改善が大きかった。
・sourceforgeのバグトラッカーをやめてTracを使うようにした。
・BuildBotを導入してビルドエラーを自動検出するようにした。
・Doxygenを使ってドキュメントを自動生成できるようにした。
●2008年に決定した戦略
・wxMacについてCarbonベースからαレベルではあるがwxCocoa(wxOSX)に移行を開始した。
これにより32/64bitの両環境に対応しUnixスタイルのdynamic libraryからframeworkに移行できる。
・ライブラリの品質向上。
これにより（長くメンテされておらず、バグが多く非互換性が強くなった）ODBCのサポートがドロップする。
同様にかなり酷い状況だったwxSocketとwxURLがクリーンアップされた。
全てではないがいくつかのwxGridの問題が修正された。
297:デフォルトの名無しさん
09/01/12 17:45:28
（続き）
●機能追加
・wxPorpertyGridがwxWidgetsに含まれた。
・wxDataViewCtrlと関連クラスが結構良くなった。
・wxRichTextCtrlが多くの小さな修正で重要な改善を果たした。
・wxGrid/wxListCtrlのカラム表示サポートの一部としてwxHeaderCtrl、
wxRearrangeListと関連クラスが追加され、カラムの順序変更が実装された。
・wxWrapSizerが追加された。
・wxCalendarCtrlがネイティブ実装になった。
・wxMessageDialogが改良され、特にボタンにカスタムラベルが使用可能になった。
・wxStaticTextがいくつか改良され、内容の省略をサポートした。
・wxGLCanvasがアンチエイリアスをサポート。
・AUIの主要な変更はwxAUIToolBarの追加。
・ついにwxBaseにイベントのサポートが追加された。
・忘れてるだけで他にもあるかも。
●他
・2.9.0の開発ブランチをプレビューリリースできなかった。
Unicode関連のフィードバックを取り込むため可及的に早くしたい。
・wxButtonで画像をサポートして欲しいという要望が多い。簡単なのですぐやる。
・今年はwxOSXを完成させて3.0をリリースしたい。
298:デフォルトの名無しさん
09/01/12 17:46:52
[The Wonderful World of wxWidgets 3.0]
Documentation in Doxygen
・3.0までにカスタムLaTexでドキュメントを整備する。
・ドキュメントの質を上げるためDoxygen形式を採用するが、手作業がかなり必要。
・これで3.0までに内容が見やすく正確になり、
ビルトインサーチや多くのコントロールのスクリーンショットが含まれる。
C++ features and template support
・STLはバギーな環境・コンパイラが多かったので避けてきた。
・が、大分良くなったので以下のようなSTLが有効な部分で使用する。
コンテナwxVector<T>、スマートポインタwxSharedPtr<T>、弱参照wxWeakRef<T>等々。
・Visual C++ 6.0のような古いシステムではwxが使えないか、機能制限される。
Platform features and backwards compatibility
・プラットフォームの新機能を取り込む一方、
最新のシステム向けの開発を阻害しない範囲で互換性もサポートしてきた。
・特にOSXとGTK+2が問題で、10.4Tiger未満のOSXと2.4未満のGTK+2は非サポートに。
・クロスプラットフォームなDB APIは本来範囲外だろということでwxODBCはドロップ。
299:デフォルトの名無しさん
09/01/12 17:48:24
Unicode: A Single Build for Everyone
・3.0までは歴史的経緯によりUnicodeビルドとANSIビルドの2つが存在する。
・WindowsやJavaはUTF-16を使いGTK+やOSXがUTF-8を使う時代になった。
・ANSIモードは削除。WindowsではUTF-16、それ以外ではUTF-8を使うことを決定。
UnixとGTK+での呼び出しで異なるUnicode表現間の変換は不要になる。
wxString、wxPrintf()等はUnicodeと8bit-stringの両方を必要に応じ受ける。
・wxアプリのユーザには見えないが、基礎的な変更で、3.0の主要な動機だった。
New 2D Drawing Code
・2D描画API(wxDC, wxPen等)は常にwxの一部だったが、初期からほぼ変わらず、
単一のフロントエンドに対し多数のバックエンドが分岐して
バイナリ互換性を気にすることなく簡単にプラットフォームの差違を吸収してきた。
・古い描画APIは多くのタスクと1990年代の描画能力に対し十分であったが、
WindowsのGDI+やLinuxのCairo、OSXのCoreGraphics等、
透過やアンチエイリアス、マトリックス変換といった現代的2Dシステムの
先進的機能を使用できなかった。
・このため新描画API(wxGraphicsContextとか)が追加される。
ビットマップでのαチャネルのサポート
ビットマップのRAWデータへのアクセスをサポート
定数を変更、wxMODERN→wxFONTFAMILY_MODERN、wxSOLID→wxBRUSHSTYLE_SOLID等。
・参照カウントが合理化されプラットフォームで共通になる。
なんかバカバカしくなったのでここまでで終了。
しょせん気まぐれだ、許せ。
300:295
09/01/12 19:19:24
>>296-299
翻訳超乙。Unicode化の理由と、Graphicsの改善のあたりが良く分かった。
とりあえず、3.0は期待して損はなさそうだね。
301:デフォルトの名無しさん
09/01/12 21:10:20
一服して若干気を取り直したので続きを投下。
Changes to wxBase
（訳注：wxBase自体の紹介は省略）
・wxStringとコンテナクラスには多くの変更がある。
・wxBaseの一番大きな変更はwx3.0でイベントベースのプログラムを書くための
イベントループ、タイマー、ソケット等の追加。
・ソケットのコードは重複部分を削除、C/C++で分かれていたコードをドロップ。
302:デフォルトの名無しさん
09/01/12 21:10:54
New controls and other major GUI additions for all ports
全ての修正とマイナーチェンジを羅列できないので、GUIの変更の概要のみ。
・柔軟な表現が可能なwxDataViewCtrl/wxDataViewTreeCtrlを実装。wxListCtrl/wxTreeCtrlを一部代替。
・wxGridの表形式はwxHeaderCtrlに分離したネイティブなヘッダを実装。
・wxPropertyGridの追加。
名前-値のペアを表現する一般的クラス。
wxDataViewCtrlと同様、数値、テキスト、リスト、フォントなどの
組み込みのエディタ（in-place, ポップアップ、コンボボックス等）を提供する。
・wxHyperlinkCtrlをGTKでネイティブに、他では一般的方法で実装。
・ファイルダイアログのカスタマイズのためwxFileCtrlを実装。
・wxRichTextCtrlに親・子スクリプトのサポートを始め高速化など色々改良。
・wxTreeCtrlに状態アイコン表示機能追加。チェックボックス的にも使える。
・wxCalendarCtrlを刷新しMSWとGTK+でネイティブに。その他改良。
・wxTextCtrlとwxComboBoxでオートコンプリート機能を実装。
・wxAUIのクラス群にwxAUIToolBarを追加。より柔軟で自然に。
・wxBitmapComboBoxを再実装、MSWとGTKではネイティブに。
・wxBitmapToggleButtonを全プラットフォームに。
・wxStaticTextは全プラットフォームで省略表現をサポート、GTK+でマークアップ書式をサポート。
・全プラットフォームでwxListBoxの選択イベントの発起方法を書き直し精確にした。
・GTKとOSXでwxCollapsiblePaneをネイティブ実装。
・複数行に渡ってwrap可能な新しいsizer、wxWrapSizerを追加。
・OpenGlキャンバスにマルチサンプル、アンチエイリアスサポート追加。
wxGLCanvasとwxGLContext分離。
・wxTopLevelWindowをネイティブウィンドウハンドルから構築するため
MSWとGTK+にwxNativeContainerWindowを追加。
303:デフォルトの名無しさん
09/01/12 21:11:29
wxMac specific changes (now called wxOSX)
・wxMacという呼称は廃止、wxOSXと呼称、iPhoneとiPodを一部サポート。
・Carbon, Cocoa, CocoaTouchの3つの一般コードに整理。
・OSXのCoreFoundationへのラッパでったり一般的なクラスへのラッパだったり。
・CarbonがwxMacのコアで安定していたが、iPhone対応にCocoa(Touch)が必要で、
64bitのOSXでは非推奨となるため、現在はCarbonでも今後はCocoaにフォーカス。
・リストラクチャリングの一貫としてQuickDraw APIを使ったコードは削除。
今後はCoreGraphicsを使用する。
・同様にOSX10.4にないCarbonの関数を使用したコードは削除。
OSX10.4が最低動作環境になる。
・IconRefのサポート拡充。
・英語以外のロケールでのメニュー項目の重複を修正。
・ボタンにアクセラレータが使用可能に。
・CFLocaleを使用したwxLocal::GetInfo()の実装。
wxGTK specific changes
・GTK+のAPIが後方互換性がなくなって来たためGTK+2.4を最低環境とする。
・wxToolbarは新しいGTK+のツールバーAPIを使用。
・wxChoiceはGtkOptionMenuでなくGtkComboBoxを使用。
・wxComboBoxは非推奨のGtkCombでなく常にGtkComboBoxを使用。
・URLのドラッグはwxURLDataObjectで"text/x-moz-url"を使用。
・GtkPrintとCairoのダイアログを使用した新しいプリントバックエンド。
・アイドルイベントの生成コードを書き直し。
・タブの走査はGTK+でネイティブに。
・wxFrameのメニューバー、ツールバー、クライアントウィンドウとステータスバーは
GtkVBoxを使用したレイアウトに書き直し。
・ウィンドウマネージャに帰属するウィンドウの装飾に係わらず
トップレベルウィンドウSetSize()/GetSize()を正しく実装。
・wxYield()の呼び出しを避ける（リエントラント問題回避）ため
wxClipboardの非同期APIを追加。
・Nokiaのタブレットで使われるMaemoプラットフォームの
Hildonコントロールをいくつかサポート。
304:デフォルトの名無しさん
09/01/12 21:13:12
wxMSW specific changes
・後方互換性が確保されており、ユーザ数が多いため最も安定しており、
他のプラットフォームに比べ大きな変更はない。
・wxCheckListBoxがよりネイティブな感じに。
・長いツールチップが可能に。
・wxCheckBoxとwxToggleButtonで複数行ラベルをサポート。
・より正確なプリントプレビュー。
・サイズ変更可能なダイアログでリサイズグリップを表示。
以上、>>294曰く「御託だけで何もしない無職」の大雑把な訳でした。
305:300
09/01/12 23:38:51
>>301-304
引き続きサンクス。wxOSXが結構面白そうに思えたんで、Mac Miniの中古でも
買ってみようかな。
あと、御託云々はあんまし気にしなくても良いと思うよ。
それよか、スタティックリンクでソース公開しなくてもいいwxWidgetsを使って
金儲けできると良いんだけど、クロスプラットフォームでお金になりそうなアプリって
どんなのだろ？どうにもイメージが沸かない。
306:デフォルトの名無しさん
09/01/13 07:22:12
２ちゃんでちょっと煽られたくらいでむきになるようだと
実社会で辛くないか
307:デフォルトの名無しさん
09/01/13 07:46:14
翻訳しただけでムキになってるとか決めつけるようだと
実社会ですぐ口論にならないか
308:デフォルトの名無しさん
09/01/13 18:05:10
まぁ、どう見ても煽られたのが原動力にはなってるがな
309:デフォルトの名無しさん
09/01/13 18:18:57
翻訳人は無能ではないことを証明したし
英語読めない人は3.0の改善項目がわかったし
みんな幸せってことでいいんじゃなかろか
310:デフォルトの名無しさん
09/01/14 00:58:01
英語読めるようになりたいな
311:デフォルトの名無しさん
09/01/14 01:40:22
これからはアラビア語の時代だけれどもね。
312:デフォルトの名無しさん
09/01/14 13:11:27
つまらん、次
313:デフォルトの名無しさん
09/01/14 13:56:31
これからはアラビアゴムの時代だけれどもね。