アカウント名:
パスワード:
不具合大作の方は、 かなりの部分はFreeBSDと共通でソースがあるし、なくても、たとえば、システムコールトレースをとるなどで結構原因を追求できる。 ということかなぁ。
現在、知人が「WindowsXPでadmin権限がないと動かない
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
ソフトの導入がしやすく、不具合も自分で直しやすい? (スコア:1)
マックを導入する理由について、東大では「ウィンドウズに比べて様々なソフトの導入がしやすく、不具合が起きても自分で直しやすい利点がある」と
Re:ソフトの導入がしやすく、不具合も自分で直しやす (スコア:1)
不具合大作の方は、 かなりの部分はFreeBSDと共通でソースがあるし、なくても、たとえば、システムコールトレースをとるなどで結構原因を追求できる。 ということかなぁ。
現在、知人が「WindowsXPでadmin権限がないと動かない
Re:ソフトの導入がしやすく、不具合も自分で直しやす (スコア:1)
ところで良ければ教えてください>皆様
DLLやsoみたいな「動的ライブラリ」は、MacOSX(とオフトピですが旧)では
どういう風になってるんでしょうか?
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:0)
OS自体が「動的ライブラリ」の集合みたいなもので
アプリはなるべく自分でコードを書かずオブジェクトを使う方が信頼性があがるそうな。
ジョブスもOSXでプログラミングをすることは20階建てのビルを10階から作り始めるみたいなものと言っていた
つまり「動的ライブラリ」も必要なものほとんどがOSの一部として用意され、統一性が取れているのではないかと。
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:1)
>OS自体が「動的ライブラリ」の集合みたいなもので
ええと。
「OOP」であることと「動的ライブラリ」であることと「自分で書かない」こととは
互いにほぼ無関係です。全く無関係とまではいいませんが。
C++のような存在があることから判ると思いますが、
OOPであっても動的ライブラリである義務(?)は無いです。
まあ動的ライブラリであるほうが便利なのは確かです(Javaのように)が、
逆にいえばOOPじゃなくて動的ライブラリのほうが便利であって(^^;、
OOPと動的ライブラリは直接は繋がりません。
あと、OOPであることと自分で書かないこととは、
Javaだろうがなんだろうがの大抵のOOP言語で書かれたプログラム(アプリ)を
見れば判りますが、これも無関係です。
Javaとかでも、main(が入ったクラス)という1つのクラスしか自作されてないアプリ、なんて
滅多に無いですよね。つーかそういうのを作るのすらほぼ無理では?
#クラスを作ってるという「実感」をプログラマに持たせない(隠蔽する)言語は有りますが、
#それは言語の内輪の事情とはあんまり関係ない話です。
つーか^2、自分でクラス作ることは、しばしば必要だし、しばしば(アプリ以上に!)楽しいですよ(^^;
#ところでクラス作るってのは、そのほうが楽しいとか便利だとかいう理由もありますが、
#一方で、「状態保持モデルとしてのクラスを適宜作っておかないと、プログラムがぐちゃぐちゃになる」という面も有ります。
#intとchar*だけでプログラムが書けるからってstructを使わないと
#しばしば酷いプログラムになりますが、それと全く同じです。
#作らないとしょーがないんです。
そして、(知らないですが恐らく十中八九)OSXでも、クラスを自作することは「可能」ですよね…?
つーか^3、自作の必要性を脇に置いておいてしまっていいのならば、そもそも動的ライブラリである必要は有りません。
だってOS「に」リンクすればそのクラスにアクセスできるわけでしょ?
リンク先は動的ライブラリではなく静的(!)なOSであればいいんです。はい。
>つまり「動的ライブラリ」も必要なものほとんどがOSの一部として用意され、統一性が取れているのではないかと。
OOPが統一が取れるのは、クラスの実装自体が既に統率されているから、ではありません。
誰がクラスを自作しても、クラスという「メタな枠組み」が統率されているからです。
どんなに多様なクラスを作っても、それがクラスだという面においては統一性があるからです。
だから、あなたは(^^;クラスをなんぼ作ってもいいのです。
作ったからといってシステムの統一性を崩してしまわないか?という心配なぞ、しなくていいのです。
勿論、別の基準においての統一性の問題が有り、それを崩さないように心配する、という必要はしばしば有りますが、
それはOOP自体とは無関係な問題だ、ということです。
>アプリはなるべく自分でコードを書かずオブジェクトを使う方が信頼性があがるそうな。
プログラムは自分でやりたいことを(しばしばリスクを侵しながら(^^;)書くためのものです。
そして「出来合いを使う」だけじゃ、「やりたいこと」が全部書けないこともあります(多いです)。
よって欲しいものは、出来合い道具だけではなくて、
「道具を自作もできる。ただし、その自作したもの「の」の信頼性を高める手段も、無いと困る」
ってのもあるんですよね。
OOPは、出来合い道具の供給手段としても有用ですが、一方で、自作道具の信頼性を確保する手段としても、有用です。
それは上記のようにメタな枠組みがあるから。その枠組みが或る面においてコードの暴れを抑えこんでくれるから。
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:0)
従って、ここではC++ではなく、Objective Cについての話です。
Objective Cはレイトバインディング(=「動的ライブラリ」?)が基本ですよね。
>「OOP」であることと「動的ライブラリ」であることと「自分で書かない」こととは
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:1)
>従って、ここではC++ではなく、Objective Cについての話です。
ふむ。まあいいでしょう。ObjectiveC(の一般論およびOSXでの実装)は俺も知らんし。
ただ、元の文には、
「MacOSXの場合、元のNextStepがオブジェクト指向OSのため
OS自体が「動的ライブラリ」の集合みたいなもので」
という風にOOP(OS)と動的ライブラリとの間に因果があるように書かれていたわけでして…
>Objective Cはレイトバインディング(=「動的ライブラリ」?)が基本ですよね。
ええと。「動的ライブラリ」と「動的な(弱い)型づけ言語」とは別概念ですよ。
上記で仰ってる「bind」ってのは、何と何をbind(結合)する話ですか?
関数とかの呼び出し元と、呼び出し先(が格納されてるライブラリファイル等)を、bindするのは前者です。
メッセージ名と、メソッド実装(が格納されてるクラス等)を、bindするのは後者です。
#HP-UXの動的ライブラリのlazy(=late) binding(こちらは前者の意味です。OOPとかと関係ない世界の話です。)に色々困らされてるのでG7
そのへんごっちゃになってませんか?
ちなみに言語仕様が規定するのは、普通は後者のほう(だけ)です。
>「OOP」の部分を「MacOSXにおけるObjective C」に置き換えて、文章を書き直していただけると参考になるのですが…。
参考にはなりませんが、読解(解読)の助けにはなります。というわけでどうも。
あと、「自分で書かない」ことについては、前述の通りです。
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:0)
自分が言っている「動的ライブラリ」とは、実行時バインディングを考えています。HP-UXは知りません。しかしMacOSXのプログラミングについての話でしたら、Objective Cになりますし、実行時バインディングです(ちなみに自分はC++はオブジェクト指向言語ではないと思っています。SmallTalk 万歳!)。
元に戻れ
最初に話を戻すと、MacOSXでは、メインのプログラミング言語が、Objective Cであり、そのため、DLLは使わずに、オブジェクトを実行時バインディングする。Objective Cを選んだ結果として、短時間でプログラムを
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:0)
Re:ソフトの導入がしやすく、不具合も自分で直しや (スコア:0)
手間のかかった荒らしだな。
結局何が言いたいんだか全然わからん。