タグ付けされた質問 「libraries」

ライブラリは、独立したソフトウェアを開発するためのデータやサービスを提供するリソースの集まりです。

14
Qtで記述されたデスクトップアプリが増えないのはなぜですか?[閉まっている]
Qtでの経験で私が知っている限り、また理解している限りでは、非常に優れた、簡単に学習できるライブラリです。非常にうまく設計されたAPIを持ち、クロスプラットフォームであり、これらは魅力的な多くの機能のうちの2つにすぎません。Qtを使用しないプログラマが増えている理由を知りたいです。それに反対する欠陥がありますか?Qtよりも他のライブラリの方が優れている機能はどれですか?問題はライセンスに関連していますか?
202 api  libraries  qt 

13
入力が技術的に有効であるが、満足できない場合の例外と空の結果セット
私は公開リリースを目的としたライブラリを開発しています。オブジェクトのセットを操作するためのさまざまなメソッドが含まれています-セットを生成、検査、パーティション分割、新しいフォームに投影します。関連する場合IEnumerableは、NuGetパッケージとしてリリースされるLINQスタイルの拡張を含むC#クラスライブラリです。 このライブラリの一部のメソッドには、満たされない入力パラメーターを指定できます。たとえば、組み合わせメソッドには、m個のアイテムのソースセットから構築できるn個のアイテムのすべてのセットを生成するメソッドがあります。たとえば、次のセットを考えます: 1、2、3、4、5 2の組み合わせを要求すると、次の結果が得られます。 1、2 1、3 1、4 等... 5、3 5、4 現在、3つのアイテムのセットを提供し、各アイテムを1回しか使用できないというオプションを設定しながら、4つのアイテムの組み合わせを要求するなど、実行できないことを要求することは明らかに可能です。 このシナリオでは、各パラメーターは個別に有効です。 ソースコレクションはnullではなく、アイテムが含まれています 要求された組み合わせのサイズは、ゼロ以外の正の整数です 要求されたモード(各アイテムを1回のみ使用)は有効な選択です ただし、パラメーターの状態を一緒にすると問題が発生します。 このシナリオでは、メソッドが例外をスローすることを期待しますか(例:)InvalidOperationException、または空のコレクションを返しますか?どちらも私にとって有効なようです: あなたは、の組み合わせを生成することができないn個のセットから項目をm個の項目N> M君はそれゆえ、一度だけ、各アイテムの使用を許可しているので、この操作は不可能と考えることができる場合InvalidOperationException。 n> mが空のセットである場合にm個のアイテムから生成できるサイズnの組み合わせのセット。組み合わせは作成できません。 空のセットの引数 私の最初の懸念は、サイズが不明なデータセットを処理する場合、例外が慣用的なLINQスタイルのメソッドのチェーンを妨げることです。言い換えれば、あなたはこのようなことをしたいと思うかもしれません: var result = someInputSet .CombinationsOf(4, CombinationsGenerationMode.Distinct) .Select(combo => /* do some operation to a combination */) .ToList(); 入力セットのサイズが可変の場合、このコードの動作は予測できません。場合は.CombinationsOf()、例外をスローしたときsomeInputSetよりも少ない4つの要素を持っている場合、このコードがします時々、いくつかの事前チェックせずに、実行時に失敗します。上記の例では、このチェックは簡単ですが、より長いLINQチェーンの途中で呼び出す場合、これは面倒になります。それが空のセットを返す場合、空になりますresult。 例外の引数 私の2番目の懸念は、空のセットを返すと問題が隠れる可能性があることです-LINQのチェーンの途中でこのメソッドを呼び出して静かに空のセットを返す場合、後でいくつかの手順で問題が発生するか、空の結果セット。入力セットに何かが確実に含まれていた場合、それがどのように発生したかは明らかではないかもしれません。 あなたは何を期待しますか、それに対するあなたの議論は何ですか?

9
「クリーンコード」の実践からはほど遠いコードを使用しながら、巨大なオープンソースライブラリをどのように維持しますか。
私はまだ高品質のコードを書くには経験が浅いので、Robert C. MartinによるClean Codeなどの問題に対処する本を読み、よく知られているライブラリのコードをチェックしてスキルを向上させます。 多くのオープンソースライブラリは長年にわたって維持されていますが、正しいパスにないことはほとんどありませんが、それらの多くのコードは、クリーンなコードを記述するための原則からはほど遠いことがわかりました。数百行のコード。 だから私の質問は次のとおりです。きれいなコードの原則はあまりにも制限されていますか?そうでない場合、これらの原則の多くを考慮せずに巨大なライブラリをどのように維持していますか? 簡単な説明をいただければ幸いです。質問が初心者の人からばかげていると思われる場合、私は謝罪します。 編集 Butterknifeライブラリでこの例を確認してください。Androidコミュニティで最もよく知られているライブラリの1つです。

2
「影付き」Java依存関係とは何ですか?
JVM開発者はこちら。最近、私はIRCチャットルームや、自分のオフィスでさえ、いわゆる「影付き」Javaライブラリについて冗談を言っています。使用のコンテキストは次のようになります。 「このように、XYZに「シェーディング」クライアントを提供します。」 完璧な例は、HBaseのこのJiraの問題です。「シェーディングされた依存関係を持つクライアントアーティファクトを公開する」 だから私は尋ねる:シェーディングされた JAR とは何ですか、「シェーディングされた」とはどういう意味ですか?
75 java  libraries  jvm 

3
JavaScriptフレームワーク/ライブラリに、純粋なJavaScriptにすでに存在する関数があるのはなぜですか?
フレームワーク/ライブラリは、ネイティブに既に存在しているのに、なぜ独自のヘルパーを持っているのでしょうか。 jQueryとAngularJSを見てみましょう。独自のeach反復関数があります。 jQuery.each() angular.forEach() しかし、我々は持っていArray.prototype.forEachます。 同様に、 jQuery.parseJSON() angular.fromJson() しかしJSON.parse()、バニラJavaScriptには関数があります。

2
ヘッダーのみのライブラリはより効率的ですか?
仮定 C ++のヘッダー専用ライブラリの利点の1つは、個別にコンパイルする必要がないことです。 CおよびC ++ inlineでは、関数がヘッダーファイルで定義されている場合にのみ意味があります*。 従来、Cでは、ヘッダーが翻訳単位の最小限のパブリックインターフェイスを表す.c / .hレイアウトが使用されてきました。同様に、.cpp / hpp。 質問 一般に、ヘッダーのみのライブラリは、従来のレイアウトよりもコードおよび実行時間の面で効率的ですか?もしそうなら、これは広範なインライン展開または他の最適化のためですか? *-ヘッダーで関数を定義することで、コンパイラーは翻訳単位のコンパイル中に実装を確認でき、実際にインライン化コードが可能になります
48 c++  c  libraries 

16
ライブラリとコードスニペットを多用しない具体的な理由はありますか?[閉まっている]
全体的に私は約8年間プログラミングに携わっており、「仕事をやり遂げる」ためにオープンソースライブラリとスニペット(GitHubを気にせず)にますます依存しているように思えます。やがて自分の実装を書くことができることは知っていますが、全体的な設計に集中したいです。 これは正常ですか(非企業環境)?私の「プログラミング」が異なるライブラリーを一緒に接着すること以外の何物でもない場合、何がうまくいかないのでしょうか? 「車輪を再発明しない」ことは知っていますが、もう1つの車輪を発明しないとどうなりますか?

5
ライブラリ内からSTDINから読み取ることはアンチパターンと見なされますか?
私が仕事で取り組んでいる大規模なプロジェクトのライブラリを作成しているときに、トークンを電子メールアドレスに送信する必要があるという問題が発生し、その後コードに戻されてさらに使用できるようになりました。 私の同僚は(Pythonを使用してcode = input("Enter code: "))STDINから読み、それをユーザーに渡すように言っていますが、私にはライブラリがサーバー上のバックグラウンドタスクで使用される可能性があるため(この場合は間違いなく)、これは悪い習慣のようです。 これがアンチパターンと見なされるかどうか疑問に思っていました。

3
C ++ 11は、動的/共有ライブラリ境界間でstd libオブジェクトを渡す懸念に対処しましたか?(つまり、dllなど)?
C ++についての私の主な不満の1つは、動的ライブラリ(つまり、dll / so)境界の外側にstdライブラリオブジェクトを渡すことが実際にはどれほど難しいかということです。 stdライブラリは、多くの場合ヘッダーのみです。これは、いくつかの素晴らしい最適化を行うのに最適です。ただし、dllの場合、それらは多くの場合、stdライブラリコンテナの内部構造/コードに影響する可能性のある異なるコンパイラ設定で構築されます。たとえば、MSVCでは、1つのdllがイテレータデバッグをオンにしてビルドされ、別のdllがオフでビルドされます。これらの2つのdllは、stdコンテナーを渡す問題に遭遇する可能性があります。std::stringインターフェイスで公開すると、クライアントが使用しているコードがstd::stringライブラリのに完全に一致することを保証できませんstd::string。 これにより、デバッグや頭痛などの問題が発生しやすくなります。組織内のコンパイラ設定を厳密に制御してこれらの問題を防ぐか、これらの問題のない単純なCインターフェイスを使用します。または、クライアントが使用するはずの予想されるコンパイラ設定を指定します(別のライブラリが他のコンパイラ設定を指定する場合、これは問題になります)。 私の質問は、C ++ 11がこれらの問題を解決するために何かを試みたかどうかです。
34 c++  libraries  c++11 

7
ライブラリを使用せずにタスクを実行できる場合、ライブラリを使用する必要がありますか?[閉まっている]
私は、オープンソースのJavaScriptプラグインを使用してタスクを遂行できる状況にあります。しかし、それを使用しようとしたとき、私はすでにやったことの多くを再設計する必要があることに気づきました。きれいなコードで同じタスクを達成できるのに対し、自分で作成でき、これまでに行ったことを変更する必要はありません。 とにかく、このような状況ではライブラリを選択する必要がありますか(コードの品質を向上させるためなど)。

14
ネイティブJavaScript開発にはどのような利点がありますか?[閉まっている]
ネイティブJavaScriptと比較した場合、jQueryの開発がどれほど簡単かを考えると、jQueryのようなライブラリを完全に見捨てる理由は何ですか? これは、jQueryに制限があるのか​​、遅いのですか?つまり、jQueryがネイティブjavascriptと比べて非常に簡単な場合、人々はまだ純粋なjavascriptを使用しなければならない理由は何ですか?

16
独自の「その他のユーティリティ」ライブラリはありますか?あなたが最も誇りに思う部分は何ですか?[閉まっている]
私たちの多くは、頻繁に使用するツールとユーティリティを使用して、独自の小さな個人ライブラリを維持していることを知っています。 私は16歳の時から私のものを持っているので、かなりの規模に成長しました。私が書いたもののいくつかは、その後フレームワークに追加されました。LINQのかなり前に、遺伝的アルゴリズムで使用する式ツリーの独自の小さな実装を作成しました。しかし最近、私はそれを経験して.NET 4.0にアップグレードし、興味を再燃させました。 だから私はあなたがあなたのライブラリを何のために使うのか興味があります。たぶん、便利な小さなスニペットのためにいくつかのクールなアイデアを得て、それらを私たちの間で共有することができました。 だから私の質問は: その他のユーティリティライブラリはありますか? あなたが最も誇りに思っている部分とその理由は? 必要に応じてコードの例を挙げてください :-)

7
タイプセーフな構造体ポインターではなく、パブリックAPIでのキャストを必要とする不透明な「ハンドル」を使用する理由
現在公開APIが次のようになっているライブラリを評価しています。 libengine.h /* Handle, used for all APIs */ typedef size_t enh; /* Create new engine instance; result returned in handle */ int en_open(int mode, enh *handle); /* Start an engine */ int en_start(enh handle); /* Add a new hook to the engine; hook handle returned in h2 */ int …

1
Apache 2.0ライセンスに基づいてライセンスされたライブラリを使用するアプリをリリースする際に留意すべきことは何ですか?[閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 5ヶ月前に閉店。 すぐにリリースできるAndroidアプリを作成しています。 このライブラリを使用してタブシステムを実装するだけです。Apache 2.0 Licenseの下でライセンスされていることを読みました。配布したアプリ/プログラム/ゲームにライセンスされたライブラリを使用したことがないため(配布していないため)、ライセンスやライセンスされたライブラリの経験がないので、何かありますかApache 2.0ライセンスに基づいてライセンスされたライブラリを使用するアプリを配布する際に留意してください。 覚えておいてください StackOverflowでこの質問をしましたが、代わりにプログラマに移動することをお勧めしましたが、投稿する前にこのサイトがこの種の質問を受け入れた場合はヘルプセンターを確認することをお勧めします。私はやった、そして私が読んだものを見て理解できる限り、この種の質問は許される。 私はいくつかの似たような質問を読んで、いくつかの質問に対する答えを見つけましたが、まだ疑問があり、間違いを犯さないように明確にしたいことがあります。 これらは残りの質問です 「私のアプリケーションのユーザーは、Apache 2.0ライセンスのコピーを受け取らなければなりません。混乱を避けるために、ライセンスが適用されるディストリビューションの部分も明記する必要があります」と読みました。アプリの[アプリについて]ページにApache 2.0ライセンスへのリンクを配置し、リンクとともにライセンスライブラリの名前を伝えるだけで十分ですか? 上記の質問を続けます。「ライセンスが適用されるディストリビューションの部分を記載する」必要がありますか。それは単に、アプリのどの部分がライセンスされているかを伝えなければならないということですか(言い換えれば、ライブラリがライセンスされた部分であることを意味します)? ライブラリのソースを変更し、変更したバージョンをアプリに含めて販売することはできますか? (これはライセンスライブラリとは関係ありません)アプリにライセンスを適用する必要がありますか?はいの場合、どれが推奨されますか?アプリをGoogle Playストアにアップロードすると、著作権によって自動的に保護されますか?「コピーキャット」から保護するために推奨されるものは何ですか? 推奨事項やガイドラインはありますか?間違いを犯さず、罰金を支払ったり、トラブルやそのようなことをしたりしないように、知りたいです。ありがとう! 更新:私はamonの答えを読んで、さらにいくつかの質問を見つけました: amonが言ったことからわかるように、私のアプリは著作権によって自動的に保護されています。彼はまた、私が著作権を登録することができ、それがいくつかの管轄区でいくつかの利点を与えるかもしれないと言った。著作権はどこで登録できますか? ライセンスのどの部分を「about」ページに印刷する必要がありますか?これを(Apache 2.0ライブラリWebサイトから)ライブラリの情報テキストの下に配置し、Apache 2.0ライセンス全体を含む別のページ(アプリ内)へのリンクを配置するだけで十分ですか?: 著作権[yyyy] [著作権所有者の名前] Apacheライセンス、バージョン2.0(「ライセンス」)の下でライセンスされています。ライセンスに従う場合を除き、このファイルを使用することはできません。ライセンスのコピーは、次の場所で入手できます。 http://www.apache.org/licenses/LICENSE-2.0 適用法で要求されるか、書面で合意しない限り、ライセンスの下で配布されるソフトウェアは、明示または黙示を問わず、いかなる種類の保証または条件もなしに「現状のまま」で配布されます。ライセンスに基づく許可および制限を規定する特定の言語については、ライセンスを参照してください。 さらに質問が来るかもしれません。

1
バニラJSはまだライブラリと見なされますか?
私はごく最近、VanillaJS(ドキュメント?)が99%のブラウザーにバンドルされたばかりのライブラリであり、ネイティブJavaScript(私の人生の衝撃)ではないことを発見しました。私自身のライブラリを書いている間、私は通常すべての有用なことを避けます。ほとんどはライブラリです。今、私は3つの質問があります: VanillaJSはまだライブラリと見なされていますか? VanillaJSなしでDOMで何かをする方法はありますか? VanillaJSまたはネイティブJSに基づいた主要なライブラリ(ドキュメントは含まれません)

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.