うーむ、何を持って API とされているのか分かりませんが、例えば socket １つ開くライブラリ関数は、引数の意味などおそらく違いますよね。また、thread は linux では pthread ですが、 Windows では NT thread (実は良く知りません。識者の訂正、お願いします。)で、関数名などから違っているでしょう。
＞Win32 API
なんとなく、「MSDNでプラットフォームSDK以下に出てくるやつ全部」（これWin32 APIと同義？）を「直接は」使わない、って言っているように読めます。＜違ったらごめんなさい。
ラップしたクラスとか、もっと高次のものを使うのはもちろんありで、それがライブラリ（これも微妙な用語だ）を使ってプログラムするってことじゃないですか？
LC2002で聞いていないですか？ (スコア:4, 参考になる)
朝日新聞の記事中の「経済産業省も産業技術総合研究所にオープンソースＯＳを導入して運用試験を始める。」話は、このプレゼンのpdfの21ページ目右下の図にあります。「産総研モルモットプロジェクト」(^^;と呼んでいました。:-)
Re:LC2002で聞いていないですか？ (スコア:2, 参考になる)
こういうのはどこの会社（政府）でも同じで、担当者の趣味的に社内で運用が始まり、そのうち役割が増えるに従って
という声が大きくなって導入されるパターンが結構多いと思うので、トップダウンでいきなり入るのとは違って、現場レベルでのモルモット度は低そうです。大変なのは適正な調達コストを計算したり技術評価をしなくてはならない担当者か？
Re:LC2002で聞いていないですか？ (スコア:0)
俺の周辺はLinuxでしかプログラム書かない研究者ばかりですね。少なくとも、Win32 APIでまともなプログラムを書いた経験のある人は俺の周囲には一人もいません。ま、我々はあくまでも「研究者」
余談：API? (スコア:1)
>のある人は俺の周囲には一人もいません。ま、我々はあくまでも「研究者」であって、「商用プログラマ」ではないので、
何の研究をしてる所なのか、にも時として依存するのでしょうけども、それはさておき一般的に
「APIで」プログラムするなんてことが、そうそう頻繁に有るものなのか？という疑問が、生じます。
Winのアプリ作りはよくやらされました(笑)が、APIなんてまず使わなかったですね。
良い言語(笑)とその上での良いライブラリ、を大抵使ってました。 APIを叩く必要なんて滅多に無い。
どっかの地方(笑)に行けば、アプリ書くときも日常的にAPIに触れるということをしているようですが、
それで生産性高いのかよ？と老婆心ながら思ってしまいます。
また、一方でLinuxのほうにしても、カーネルやドライバを常時書いている人なら話は別ですが、
それ以外の人もそんなにAPI(ってゆーか)を日常的に使いますかね？
で、「(技術的に)使わないとならない」のだとしたら、それはそれで1つの不幸だと思います。面倒ですから。
あ。それともWin32 APIな環境という意味でしょうか？
だったら判るけど、それなら回りくどくなく「Win32」といえば良いのに。
環境といえば、もし今後GtkだのQtだのGNOMEだのKDEだのが隆盛してきたら、
あれらは一応(^^;クロスプラットフォームですから、
APIセットがOS環境を特定するとはいえなくなってきますね。
OSではなく GUIライブラリ「の」APIなわけでして。
余談：
というか、どこまでを「API」と呼ぶか、ですね。
例えばJava界隈ではクラスライブラリをAPIと呼ぶようですが、
同じようにOSをラップする(^^;クラスライブラリという位置付けであるDelphi界隈では
VCLをAPIとは呼ばなかった(あっちでAPIといえばOSのほうのを指しますね)わけで、
APIってなんじゃらほい？と思ってしまう昨今。
----
>でも、研究発表ではPowerPointとか使いますし、WORDの書類がメール添付で来ることもしょっちゅうなので、Windowsも使っ
こっちについては、幸い、FREEのOfficeソフトとかも出始めてますよね。
OpenOffice.orgの日本の書籍(軽い感じの)が既に何冊か出ているのを見て、ちょっと嬉しかったです。
#もちろん今はMSOfficeの書籍が無数にある中でのほんの数冊でしかないのですが。
まあMSのとの互換性とかもまだまだ厳しいようです(俺も最近使ってみてます)が、将来に期待。
#でもWYSIWYGなワープロ文書ってものを人間は、気がつけばソフト実装にバリバリ依存した書き方をしてしまうものだから、
#完全互換ってのは険しい道のりだろうとは思いますけどね。Fontの寸法とかの微妙な処理の相違で
#レイアウトががらっと狂ってしまったりする。非WYSIWYG環境ならこんな極端な面倒は負わずに済むのだが…
Re:余談：API? (スコア:1)
pthread は使う場面は少ないかも知れませんが、socket は結構使うんじゃないでしょうか？
Qt とかを使えばそれらの違いを吸収してくれると聞いたことはあるのですが、それらが万能なのか、良く分かりません。例えば thread を使っていると、 lock 関係のプリミティブが何で、どれがもっとも高速か、などが結構気になって、それによってプログラムの書き方が変わるのですが。
Re:余談：API? (スコア:1)
>例えば thread を使っていると、 lock 関係のプリミティブが何で、どれがもっとも高速か、などが結構気になって、
>それによってプログラムの書き方が変わるのですが。
直接関係ない話ですが、そういう問題については、アプリじゃなくライブラリレベルで解決したいですね。
つまり、問題を吸収するか(それが不可能なら「切り分ける」か)をするライブラリを自作するとか、
あるいは可能ならばそのライブラリ(QtはGPLだよね(^^;)がそういう問題を
吸収あるいは切り分けする能力を強化するようなContributeをしてあげる、とか。
「アプリごとに毎度工夫する」ってのは、ちょっとやってられないです。
そういやJavaのFileクラスは面白いです。メジャー(笑)な環境におけるFileの機能のうち、共通化できる部分だけを扱っている。
なので、結構意外な機能(^^;が不在だったりします。
>万能なのか、良く分かりません。
なんで「判らない」んだろう？
既に判っている人が構築したライブラリなんだから、判ってる人に聞けばいいのに。
特にOpenSourceなら、そういう情報を仕入れるのは比較的簡単なわけで。#Qtの出自についは微妙ですが(^^;
Re:余談：API? (スコア:0)
>> 一般的に「APIで」プログラムするなんてことが、そうそう頻繁に有るものなのか？という疑問が、生じます。
VC++とかBorland C++で、Win32 API使わずにプログラム書けるんですか?例えばwinsock2だってWin32 APIの一部だった気がしますし、ちょっとグラフィックを表示するだけでもWin32 APIは必須になると思いますが。
>> あ。それともWin32 APIな環境という意味でしょうか？
>> だったら判るけど、それなら回りくどくなく「Win32」といえば良いのに。
単にWin32とだけ書くと、cygwin環
Re:余談：API? (スコア:1)
なんとなく、「MSDNでプラットフォームSDK以下に出てくるやつ全部」（これWin32 APIと同義？）を「直接は」使わない、って言っているように読めます。＜違ったらごめんなさい。
ラップしたクラスとか、もっと高次のものを使うのはもちろんありで、それがライブラリ（これも微妙な用語だ）を使ってプログラムするってことじゃないですか？
極端な例ですがWin32APIを直に使ってウインドウを描画するってのは結構悲惨なコードですよね。そういうことはしない、という意味かと。
＞cygwinやmingwでしかコンパイルできないソース
cygwinやmingwでしかコンパイルできなくてもWin32上のプログラム足りえるものはできます。
クロスコンパイル（のようなこと）をするにせよ、それはコンパイラがgccなだけで、至って普通のWin32プログラムだと思いますが？
ところでcygwinだとforkとかpthreadとかの挙動が。。。（涙
ちょっとエグめのことをやろうとするとLinuxマシンかVMwareが必要だったり。
Re:余談：API? (スコア:1)
それです。
で、あえてそういう道を選ぶ必要が有るような「研究」でしたらそれはそれなんでしょうけど、そうでもない限り、
職業か趣味か研究かに"拠らず"に、悲惨なコードは書かないほうが幸せでしょ、と思うんですが、
それは変(＆非実用的)、ですかね？
そういう悲惨なのを逆に欲する考え方って、どっちかってーと、
1:Fotran君(昔取った杵柄で、これしか知らないんだもん)
2:assembler君(これのほうが速いんだ!ボクがPCを一番旨く使えるんだ!)
くらいしか、思いつかないんですけど。
はい。どっちも非生産的ですね。#仕事に不利という意味だけじゃなく、人生(笑)における損失。
まあパフォーマンスについてはそれが必要になる「仕事」があるのも判りますが、
それこそ組み込みでもAssmは避けてCでやるってのと同じで、「(人生の損失を減らすためには)出来れば避けたい」
ことですし、近年は避けるのが結構無理じゃなくなってきてるわけですし。
Re:余談：API? (スコア:0)
Re:余談：API? (スコア:1)
>、ちょっとグラフィックを表示するだけでもWin32 APIは必須になると思いますが。
Win純正(?)モノを作るときのプログラミング環境としてVC++とかを専ら連想する人にとっては、
どうやらそういう世界が拓けているらしいですよね(笑)。
俺は一言もVC++ともC++とも言っておりませんので。はい。
ちなむと例えばDelphiの世界はだいぶ違います。
APIまみれに比べれば少しはお洒落なプログラミングがやれる世界ですんで、よろしく。
そういや、APIそのものはCレベルで定義されてるから、
MFCを使うのがwin純正世界で一方VCLを使うのはそうではない、
という論法は成り立たないはずですね。#MFCがMS製品かどうかは別問題。
>単にWin32とだけ書くと、cygwin環境やmingwという誤解をも招きかねないのて、Win32 APIと書きました。
うーん。そういう方向性の話は、(スラドの人々なら恐らく判りきってるんで)わざわざ言及するまでもないと思います。
Winの世の中にはcygwinかVC++か(象徴的に言えば)という選択肢しかないわけじゃないんで。
別にC(++)に話を限定しないとならん謂れもないですよね、この文脈だときっと。
#蛇足だが(というかどこまでが蛇足だかも微妙だが)VBやRubyやPerlや…ならどうなんだろう？
>でも、cygwinやmingwでしかコンパイルできないソースを書いても、一般的には「Win32上のプログラミング」とは呼べないでしょう。
これは他の人も指摘しているように、ヘンですね。
そして逆にいえば、Win32上としか言いようがないけどもVC++でもBCでもない(笑)世界も、
メジャーなものだけでも沢山あるわけで。
そういやDelphiには最近はKylixが有りますが、Delphiそのものは(それ自体もTargetも)やっぱりWinモノだし。
>GTKやqtなども(俺はWin32上でGTKを使ってますけど)あくまでも「UNIX環境ですでに慣れ
>たAPI群のレイヤをWin32上に構築する」という逃げ道でしかありませんね。
そんな事を言い切ってしまったら、「クロス」プラットフォーム環境を作ろうと努力してる諸兄が
悲しむでしょうね。(と泣き落としを試みる俺(笑))
>例えば「Windows上での開発経験有」って条件の人材募集で、「Win32 APIは全く知りません。cygwin + GTKなら開発できます」って
>条件で挑んだら、普通は確実に不採用だと思いませんか？G7氏が採用担当だと、喜んで採用するのかもしれませんが。;-)
これ困るんですよね。Win経験ってのが逆に、コテコテのVC++でAPIでMFCで「しか」知らない奴を
募集してるかのように誤解されるかも知れない(というか、されがちな)現状が、ね。
ま、例えばDelphi屋が欲しければDelphi屋と書けばいいんですが、それもまた困るんですよね。
必ずしもDelphi馬鹿しか欲しくないわけじゃないことが(業種によっては)多いでしょうから。
単にWinをターゲットに仕事できる人が欲しい、というだけで。
OSを指定したいだけなのに、言語＆ライブラリ(やAPI)環境まで指定したかのように思われるのは、
ちょっと辛いです。もっと幅が欲しいなあというか。
APIそのものがどれだけ必要か、ってのは、作るソフト次第だとも言うでしょう。
ちなむと俗に業務ソフトとか言われるものにAPIがさほど沢山必要になることは
あんまり無いはずですね。そのくせ業務用クライアントとしてご存知のようにWinは独壇場
であるわけで、じゃあそこで動く巷の無数のクライアントアプリがどんな内部構造をしているのか、を
ちょっと想像して頂けると幸いです。
うーん。俺なら、必要最小限とLazyとがキーワードかな。
Win32のことも「必要最小限」知ってればいい、くらい。
どうしても必要になったら、なった時点(Lazy)にNetなり書籍なりで、がーっと情報集める「力」がある人。
また、道具の選定も、使えるものを最小限知っているとか、必要になったら見つける(見分ける)「力」があるとか。
なお、FREEや非FREEの「巷の既存ライブラリ」ってのも結構有り、
そういうのを(うまく沢山)使うと、これも「API叩き」とは違う雰囲気を醸し出せるわけです。
使い勝手も美しさもパフォーマンスもイケてるライブラリ(と言語(^^;:つまり(V)C++に限らないのです)を
日常的に使ってると、API叩きなんかには「戻れません」ね。
そして、それでいいんです。健全な技術の肩の上に乗るのならば。
APIを間接的に呼ぶのまで勘定に入れたら、「どんな」言語/ライブラリを使っていたってAPIを使ってることになっちゃうんで無意味です。
例えばNetworkごときでいちいち「自分で」A
Re:余談：API? (スコア:0)
教えていただけませんでしょうか?
# って、まじでそういう機能はないの?
Re:余談：API? (スコア:0)
Re:余談：API? (スコア:0)
Re:余談：API? (スコア:0)
Re:余談：API? (スコア:0)
研究者に向けて生産性がどうのとか、日常的がどうのとかいう言葉が
ふさわしいとお考えなんでしょうかね。
生産性の良し悪しを論じられるほどこなれた分野に対して、
研究が必要なんでしょうか。
企業のお仕事と研究と、いっしょくたにして断じてしまうのはいかがなものかと。
Re:余談：API? (スコア:1)
うーん。そもそも何の研究なのか？という問題があると思います。
LinuxなりWinなりのAPIそのものに触ることが直接テーマと関係あるような研究なら、
そりゃ引くわけにはいかないでしょうね。
一方、そうでないなら、「もっと便利な道具を(研究だろうが商用だろうが問わず)使おうぜ」
という話をするほうが、健全だと思います。
ある人が「研究者」であっても、viでもEmacsでも秀丸(笑)でもなくNotepad.exeを使え、と言われたら
その「生産性の低さ(笑)」に泣くと思います。生産性ってのはそういう意味です。
で、もともと最初の話ですと、APIそのものが研究のネタだというなら、
そもそも他所OSに乗り換えが生じないのは「当然」のことなので、議論する意味が無いんですよね。
(比較文化論(ぉ)でもやるなら別ですが、それなら今度は常時「両方」を手がけてないとヘンだし。)
逆にいえば議論が始まった(^^;ということは、乗り換えの余地がある(にも関わらずしていない)
という話であるはずで、APIそのものが研究ネタではなく、APIは単に「道具」でしかない人(研究者)
なのだろう、と推察したのですが、どうなんでしょう？
Re:余談：API? (スコア:0)
そのライブラリが提供するものは何? ていうかライブラリの機能をアプリ側からどうやって呼び出すん? ... それがAPIすなわち Application Programming Interface ゆうもん、ちゃう?
まあAPIの定義によってはOSの提供するものだけをそういったりするみたいなん
Re:余談：API? (スコア:1)
ほっとけばそこがデフォルトの名前空間になります。
で、なまじデフォルトで、しかもあっちの世界(笑)の連中はその空間のことしか頭にないから、疲れるんですよ…
>ライブラリの機能をアプリ側からどうやって呼び出すん?
ところで蛇足ですが、「呼び出す」だけがAPIじゃないですね。
CallBack(というかOOPのMethodは皆そうだが)のように逆に「呼び出される」こともあるし、
Classだと属性などのように「呼ぶ、呼ばれる」関係とはまた違う話も一杯あるんで、
APIとか機能とかを「呼ぶ」という言い方は必ずしも常には妥当ではない。
Re:余談：API? (スコア:0)
てことか?
省略しすぎだよ!
Re:余談：API? (スコア:1)
>そんな無茶な...
そうかなあ？
ここスラドJでは(笑)しばしば、やたらと
そのスレッドローカルな文脈にばかり拘る人が出現しますが、
あのノリに比べたら可愛いもんじゃないかとは思いますけどね。
>文章長ければイイつーもんじゃないぞ。
ん？長さは関係ないのでは？
Re:余談：API? (スコア:0)
そうです。日本語として分かりませんでした。
> ん？長さは関係ないのでは？
失礼。関係ありませんでしたね。陳謝します。
反面教師としていただければ幸いです(意味わかりますか?)。
Re:LC2002で聞いていないですか？ (スコア:0)
Re:LC2002で聞いていないですか？ (スコア:0)
はぁ？俺の周囲の人々は各々がLinuxを使ってるというだけで、別にLinux推進者とかじゃないですよ。っつーか、すでに自分はLinux環境なのに、わざ
Re:LC2002で聞いていないですか？ (スコア:0)
本来やりたいことに到達するのになるべく近道するなら、書類とかの時間がかかるモノはパスしたいですからね。
Re:LC2002で聞いていないですか？ (スコア:0)
まったく不思議じゃないですよ。今回の採用もね。