「ライブラリ」「フレームワーク」「API」「SDK」 ->画像>1枚

全部同じなの？
https://monobook.org/wiki/Framework

同じに決まってるだろ

SDKだけはちょっと違う

方言だよ方言

モジュールなんて呼び方もある

スパコンやってた時代は全部ライブラリだった

新しい言葉を作らないとご飯が食べられない人もいるんです

この業界は言葉を作って素人さんを騙して仕事を確保し続けているからな

もうさ、モジュールで統一しようぜ

>>9
ruby信者かよ

コボルもモジュールじゃなかったか？

SDKというライブラリ群がある。
ライブラリにはAPIがある。
APIからフレームワークを作られてる。

こんな感じ？

統一なんて無理

API OSに近い
ライブラリ 汎用的
フレームワーク でかい

こんなイメージ

>>9-11
モジュールはなんか嫌

真ん中とってライブラリで統一しようぜ

このスレは荒れる
なんとなくそんな感じがする

>>11
Perlもそう
perl moduleで拡張子pm

SDKはツール類も付属しているイメージ

まあただのランタイムを仮想マシンと言い張って初心者を騙して高揚させてる業界ですから

ライブラリの英語の意味を考えよう

１ 図書館。図書室。
２ 映画・写真・レコードなどで、資料として収集し保管してあるもの。また、その施設。
３ 個人の蔵書。文庫。
４ 叢書?(そうしょ)?。文庫。シリーズものの出版物の名称に用いる語。「世界名作ライブラリー」


つまりは「なにか」を "集めた" ものだ

インターフェースの英語の意味を考えよう

1(境)界面.
2 (複数の学問・研究分野の)共通問題，学際事項
3 (異なる種類のものの間の)境界，接触面，接点
4 (異種のものの間の)対話，連絡，意思疎通
5 (複数のものを)円滑につなぐもの，仲介するもの，仲立ち；橋渡し

つまりは「なにか」と「なにか（あなた）」をつなぐものだ

フレームワークの英語の意味を考えよう

1 骨組み，構造物.
2 枠組み；(組織の)構成，構造，体制
3 額縁の製造［販売］.
4 枠を用いて作った作品(刺繍ししゅうなど)；枠細工品.
5 (工事用)足場；骨組みの工事.
6 (果樹の)枝；主枝.
7 =frame of reference.

つまりはなにかのための「枠組み」だ

APIはあくまでインターフェース
インターフェースが同じでも実装が異なることはあり得る
例えばlibeditはreadlineのBSD版として作られた。これらは別のライブラリだが同じAPIを持つ

SDKは、プラットフォーマーがサードパーティに向けて提供する開発キット
APIの定義やそれを実際に使うためのライブラリは勿論だが、その他のツール類やドキュメント諸々も含む

フレームワークは……曖昧だが
アプリケーション全体の構造を決めてしまうような大掛かりなライブラリみたいなイメージ？

このゲームオネシャス
https://goo.gl/2UVYAA

U7R

よし、モジュールで統一しよう

フレームワークは「穴埋め式」。
ライブラリは「呼び出し式」。
APIは、それとは独立して動いているものを呼び出すよってこと。
SDKは、何かを作るときにいるものの一式。

.NET FrameworkはSDK？

>>28
独立して動いているものを呼ぶのは一般にRPCだ
WebAPI想定なんだろうが、WindowsのAPIには単なるライブラリ関数でしかないものも結構ある
APIは呼び出し方の規約であって中身は関係ない

SDK！SDK！

>>30
> WindowsのAPIには単なるライブラリ関数でしかないものも結構ある
それお前がAPIとライブラリをごっちゃにしてるだけだろ

例えばWindows APIであれば、C言語からではなく例えばVBなどから呼び出すこともできる
だから特定の言語には依存しない。それがAPIであって他の言語から呼び出せないようなものは
単なるライブラリ関数であってAPIではない

他言語向けラッパーを書けばライブラリからAPIに昇格するのか

するわけないだろ。ライブラリはいくら頑張ってもAPIにはなれない

例えば、Windows APIというものがある。
それをある言語から呼び出すための "ライブラリ" を作ったとする。

その場合、"Windows API" は "API" だし、
その "ライブラリ" は、当然 Windows APIを呼び出すための "ライブラリ"
ライブラリは API ではない

また、この場合は、Windows APIであるが、これが何かしらの "ライブラリ" であったとする。
その場合、"ライブラリ" は "ライブラリ" であり、
その "ライブラリを呼び出すためのライブラリ" も、"ライブラリ"

>>14
それAPIについては誤解してる

>>32
はあ、.dllはなんの略だ？

>>37
DLLは同一プロセス上で動作する。
一方RPCは他プロセスと通信する仕組み。

まずWindowsSDKはそもそもC/C++向けにしか提供されていない
ヘッダファイルの中を見ればわかるがインライン関数も結構あるし.libにある関数もある
マクロも一杯あって、全部がWindowsSDKの提供するWindows API

VBがDLLを呼び出す能力があるからといってC向けに用意されたAPIの全部が使えるわけでもない
VC++とABI互換なツールチェインを用いる処理系なら.libもリンクして使えるが
ヘッダにしか無いインライン関数やマクロはC/C++と文法互換な言語(Objective-C等)からしか使えない
こんなのは単に各処理系のFFI機能経由で使える使えないの話で、あくまでSDKはC/C++用

Javaのライブラリの定義もJava APIと呼ばれているし
もっと言えばWeb APIだってソケットにアクセスできない処理系からは使えんし

つまりAPIの定義の話とどの処理系から使えるかは別の話で
APIだからといって言語から独立していなきゃならないなんてことはない

全部違うぞ

>>39
Windows APIをVBから呼び出すための定義ファイルがSDKに含まれてた時期もあった気がするが、まあそれはいいとして。

まず、Windows APIを提供しているのはWindowsというOS自体であってSDKではない。ここ重要。

Windows SDKはOSのAPIをC言語等から呼び出すための支援ツールや定義をまとめたキットなのであれば便利だが、APIの仕様さえ分かればSDKなしでもAPIを呼び出すことも原理的には可能だ。

インライン関数やマクロをWindows APIって言うのは違和感しかない

インライン関数やマクロはWindows APIには含まれないよ

感覚的にはそうなんだろうが、GetCurrentFiberやExの付かないCreateWindowだってマクロだからな？
Interlocked系関数もインライン関数、ライブラリ実装とVC++のintrinsicが混じってて.dllには行かない

>>44
いつからCreateWindowがAPIだと勘違いした？

ああそうか。
真のAPIはCreateWindowWとかなんだな。
SDKやコンパイラが薄いラッパーや代替実装を用意して、そっちをAPIと称してる感じ。

>>46
CreateWindowWもマクロだ
user32.dllがエクスポートしているのはCreateWindowExA/Wだぞ

Windows APIにはこんな感じで元はDLLや.libにあったものが
いつの間にかマクロやインライン関数になった例もちょこちょこある

>>47
あらら、ほんといつの間にだな。
ただOS側には古いAPIの口も残ってるはず。
そうでないと古いWindows SDKで作ったプログラムが動かなくなる。
MS次第ではあるが。

パッケージ

アホみたいに分類しようとするからおかしいだよ。
全部モジュールなんだよ

そんなんだからプログラミング教育が進まないんだよ。
本物のプログラマならいかに簡略化するかだけ考えろ。

その無駄な労力を実用的なビジネスロジック開発に注ぎ込めよ。

結局のところ、全部「モジュール」だったCOBOLを否定して新しさを演出するためだけに作られた言葉たちなんだよ。
それによりアホに新しいシステムが売れるんだよ。
めぼしい機能を一通り実装したら定期的にプラットフォームを移行させて稼ぐしかなくなるからね。

最近だと「WindowsリッチクライアントをWebアプリ化しませんか」とかね。

>>51
C言語ライブラリの個々のファイルはモジュールっていうしなー
それぞれの流儀だべ結局は

アメリカ人にとってはくだらない話題に見えるんだろうな。
ライブラリ＝書庫 みたいに捉えてるんだからな。

書庫
汎用書庫
共通書庫
オブジェクト書庫
クラス書庫
モジュール書庫

ライブラリと聞いたら、あぁ書庫ね。集めて置くところね
ぐらいにしか思わない。何も迷わないんだろうな

クレート

麻原書庫

修行するぞ修行するぞ修行するぞ

アーカイブ