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

イディオムとデザインパターンの違いは何ですか？これらの用語はどこかで重複しているようです。正確には、私にはわかりません。それらは交換可能ですか？何を使うべきですか？ ここでは C ++イディオムのリストです。それらをデザインパターンと呼ぶことはできますか？ ウィキペディアでは、 低レベルの設計パターンとしてのイディオムのプログラミング どういう意味ですか？何をしてない「低レベル」ここに意味ですか？ この質問は別の質問からインスパイアされています：https : //stackoverflow.com/questions/7343531/are-the-some-design-patterns-language-dependent

39 design-patterns  terminology  idioms 

私は他の多くのフレームワーク/ライブラリ開発者が「私たちは考え抜かれたソフトウェアを書く」というフレーズを投げているのを見てきましたが、実際には、それは本当に何を意味しますか？「Opinionated Framework X」の著者は、特定の方法でコードを書くので、あなたが書くのと同じタイプのコードを書くべきだと言っているということですか？ それは少し大げさではありませんか？

24 terminology  idioms 

私は誰かにコードを書いた方法が理解しにくいことを説明しようとしています。そして、あなたがそれをリファクタリングすれば読みやすくなります。私が運転しているこのスタイルのコードは、一般に「イディオマティック」コードと呼ばれます。 しかし、イディオムコードというフレーズは、道徳的な正しさの手荷物をもたらします。これは、人々にコーディングスタイルを変更させる大きな動機ではありません。これをより積極的に表現する方法は、共通のスタイルに従うコードですが、群れのメンタリティの推論として出くわす批判的な思想家に対するものです。 人々がコードを変更する動機を与える方法でこのアイデアを説明する方法は次のとおりです。 リーダーの認知オーバーヘッドを減らすような方法でコードを記述します（たとえば、これが第1種のベクトルか第5種のベクトルかを思い出せません） 意図を理解しやすくするコード（たとえば、このベクトルは何のためですか？） （余談ですが、最初の出版前のThe Joy of Clojureの本には、「Idiomatic Clojure」というタイトルのドラフトがありました。そのため、読者に「喜び」をもたらすために、コードを「イディオマティック」にする理由に思えます。 ）。 私の質問は次のとおりです。認知オーバーヘッドを減らすために、コードの背後にある目的は「イディオマティック」ですか？

22 idioms 

「イディオム」は、特定の言語では整数インクリメントなどのコア言語構文によって単純化されない一般的な操作またはパターンであると理解しています。 i = i + 1; C ++では、このイディオムは演算子によって簡素化されます。 ++i; しかし、誰かが「イディオマティック」という用語を使用するとき、どのようにそれを理解するかわかりません。コードの一部を「イディオマティック」にするものは何ですか？

19 c++  idioms 

私はそれが高価であることを知っていますが、（IMO）それは非常に良い習慣だと思います。たとえば、営業担当者でない場合は請求書を保存できないなどのルールについて話しているので、その場合は「あなたは許可されていません」などの例外をスローします... 別のアプローチは、ステータスなどのオブジェクトを持つことです 他のアプローチはありますか？それについてどう思いますか？

16 idioms  business-logic  business-rules  rules-and-constraints 

あなたの言語が何らかの概念、たとえばオブジェクト指向、または関数呼び出しをサポートしていない場合、ウェブ上で何度も読みましたが、この他のコンテキストでは良い習慣と考えられているので、それを行うべきです。 私が今目にすることができる唯一の問題は、他のプログラマーがあなたのコードを通常とはあまりにも異なって見つけ、彼らがプログラムするのを難しくしているかもしれないということです。これから他にどんな問題が生じると思いますか？

12 programming-languages  concepts  idioms 

C ++ 11の慣用的なものに基づいて： カスタムコンテナーへのイテレーターは、コンテナー自体が破棄されても存続しますか？ イテレータが無効になったときにそれを検出することは可能でしょうか？ 上記は「デバッグビルド」を実際に条件としていますか？ 詳細：私は最近C ++をブラッシュアップし、C ++ 11の使い方を学びました。その一環として、私はuriparserライブラリーの慣用的なラッパーを作成しています。この一部は、解析されたパスコンポーネントのリンクリスト表現をラップすることです。コンテナーの慣用句についてのアドバイスを探しています。 最近気になるのは、ガベージコレクションされた言語から来ていることですが、ランダムなオブジェクトが、ライフタイムに関して間違いを犯した場合に、ユーザーに表示されなくなるだけではありません。これを説明するために、PathListコンテナとその反復子の両方shared_ptrが実際の内部状態オブジェクトを保持します。これにより、そのデータを指すものが存在する限り、データも存在するようになります。 ただし、STL（および多くの検索）を見ると、C ++コンテナーがこれを保証しているようには見えません。私はこの恐ろしい疑いを抱いており、期待はコンテナーを破壊するだけで、それに伴うイテレーターをすべて無効にすることです。 std::vector確かにイテレータを無効にしても機能するようです。 私が知りたいのは、「良い」/慣用的なC ++ 11コードから何が期待されるかです。光沢のある新しいスマートポインターを考えると、STLを使用すると、誤ってイテレーターをリークして足を簡単に吹き飛ばせるのは奇妙に思えます。shared_ptrバッキングデータを使用することは、不必要な非効率性、デバッグのための良いアイデア、またはSTLが実行しないと予想されることですか？ （これを「慣用的なC ++ 11」に接地することで、主観性の訴えが回避されることを願っています...）

8 c++  c++11  idioms  iterator