タグ付けされた質問 「c++」

静的に型付けされた自由形式のマルチパラダイムでコンパイルされた汎用プログラミング言語であるC ++に関する質問。

17
最高のC ++インタビューの質問は何ですか?[閉まっている]
C ++プログラマーにC ++スキルを測定するために1つの質問をすることができたら、それは何でしょうか? 私が一番いいと思う質問は、「これを削除してください」と呼ぶことができますか?メンバー関数内?(最初によく考えてから、これをリンクとして配置してから、ベストC ++インタビューの質問-今までに行って正しい答えを確認してください。) ほとんどの人が答えを知っていると思うので、私はこれを尋ねません。もし彼らがそうすれば、それほど有用な質問ではないでしょう。私は、彼らが正しい答えに向かって進むことができるかどうか、そしてどのようにそれをするかを尋ねます。
28 c++  interview 

2
純粋な抽象クラスとインターフェースの実装
これはC ++標準では必須ではありませんが、たとえばGCCが純粋な抽象クラスを含む親クラスを実装する方法は、問題のクラスのすべてのインスタンス化にその抽象クラスのvテーブルへのポインタを含めることです。 当然、これは、このクラスのすべてのインスタンスのサイズを、それが持つすべての親クラスのポインターによって膨張させます。 しかし、多くのC#クラスと構造体には、基本的に純粋な抽象クラスである多くの親インターフェイスがあることに気付きました。sayのすべてのインスタンスがDecimal、さまざまなインターフェースすべてへの6つのポインターで肥大化していた場合、私は驚くでしょう。 それで、C#がインターフェースを異なる方法で実行する場合、少なくとも典型的な実装では、どのようにインターフェースを実行しますか(標準自体はそのような実装を定義しないかもしれません)。また、純粋な仮想親をクラスに追加するときに、C ++の実装にオブジェクトサイズの膨張を回避する方法がありますか?


3
どの文字列検索アルゴリズムが実際に最速ですか?
私は、これが最速の文字列検索アルゴリズムであり、多くの意見を聞いてきましたが、最終的にはわかりません。 最速のアルゴリズムはボイヤー・ムーアであると言う人もいれば、Knuth-Morris-Prattが実際に速いと言う人もいます。 私はそれらの両方の複雑さを調べましたが、それらはほとんど同じに見えますO(n+m)。最悪の場合、ボイヤー・ムーアO(nm)はO(m + 2 * n)を持つクヌース・モリス・プラットに比べて複雑であることがわかりました。ここで、nはテキストの長さ、mはパターンの長さです。 私が知る限り、ボイル・ムーアはガリル規則を使用する場合、線形最悪のケースタイムを持ちます。 私の質問、実際には最速の文字列検索アルゴリズムです(この質問には、ボイヤー・ムーアとクヌース・モリス・プラットだけでなく、考えられるすべてのスティングアルゴリズムが含まれています)。 編集:この答えのため 私がまさに探しているのは: テキストを考えるTと、パターンPIは、すべての外見見つけなければならないPでをT。 また、PとTの長さはfromで[1,2 000 000]あり、プログラムは0.15秒未満で実行する必要があります。 KMPとRabin-Karpは問題について100%のスコアを得るのに十分であることは知っていますが、ボイヤー・ムーアを試して実装したいと思っていました。このタイプのパターン検索に最適なのはどれですか?

7
慣用的なC ++の書き方を学ぶにはどうすればよいですか?
私はコンピューターサイエンスの学生であり、その結果、クラスのあるCのより良いバージョンとしてC ++を教えられました。複雑な問題の解決策が必要なときはいつでも車輪の再発明を試みようとしますが、その後しばらくして、何らかの言語機能または標準ライブラリルーチンがそれを可能にしてくれました。 私は自分char*と*(int*)(someVoidPointer)イディオムに満足していますが、最近、オープンソースプロジェクトに(わずかな)貢献をした後、C ++コードを書くときに考えるべきことではないと感じています。Cとは大きく異なります。 私がオブジェクト指向プログラミングをかなりよく知っていること、そして急な学習曲線で大丈夫であることを考えると、C ++をコーディングしているときにC ++トラックに心を向けるために何を提案しますか?
27 c++ 

8
非推奨は有害と見なされますか?[閉まっている]
私は自分のコードのいくつかを-std=c++0xGCC のフラグでコンパイルしているところです。すべての若い人たちがやっていることを漠然と追いかけたいので(芝生にとどまっている場合)、警告がたくさん出ましたauto_ptr廃止されることについて。もちろん、私はそれauto_ptrがC ++ 0xで廃止されることを知っていましたが... 廃止は時間と労力の無駄ではありませんか?廃止されない理由(例としてauto_ptrを使用): まだサポートが必要な大量のコードがあり、何百万もの警告を生成しても、警告をオフにしたくなるだけです。 auto_ptr 少しナッフですが、実際にはブリキに書かれていることを行います。 私たちが本当に物事を非難したいなら、私は指名しprintf()ます。しかし、その後に続く悲鳴を想像してください。auto_ptrあまりにも多くの友人はいませんが、少なくとも私のC ++コードではprintf、まったく使用されていないを超えて使用されています。 委員会はこれを正しく行ったという悪い記録を持っています-彼らは名前空間のスコープで静的を廃止し、今では廃止されていないようです- auto_ptr同様のカムバックをしても私は驚かないでしょう 最後に、委員会の言うことは何でも、コンパイラの実装者はそれらを無視します-彼らは単に彼らの顧客コードを壊す危険を冒すことができません、彼らができるすべては刺激的な警告を出すことです。 だから私の質問-(auto_ptrsだけでなく、C ++だけでなく)非推奨を良いアイデアと考えていますか?そうであれば、なぜですか?

5
C ++テンプレートは単なるマクロの一種ですか?
このようなC ++テンプレートとC#/ Javaジェネリックのさまざまな比較から、 https://stackoverflow.com/questions/31693/what-are-the-differences-between-generics-in-c-and-java-and-templates-in-c/31929#31929 C ++テンプレートは、コンパイルではなく、何らかの種類の前処理(解析前のプレーンテキスト置換)によって実装されているという認識を得ました。C ++テンプレートの型チェックはCマクロに似ているためです。エラーがある場合、それらはテンプレート自体からではなく、テンプレートコードブロックを処理した後に生成されたコードからのエラーです。言い換えれば、それらはCのマクロの一種の上位バージョンにすぎません。 次に、これをサポートする他のいくつかの事実を見つけました- C ++テンプレートが前処理によって実装される場合、動的リンク(.dllを使用)に問題があると思いました。そして、クイックグーグルがこれをサポートしました。 もう1つのポイントは、整数定数を引数としてテンプレートに渡すことができるということです。また、何らかの再帰をサポートします。ただし、この再帰は、コンパイルされたアセンブリ/マシンコードにはありません。再帰的なことは、すべての再帰呼び出しに対して関数を生成することにより、コンパイル時に管理されます。したがって、より大きく、より高速な実行可能バイナリを持ちます。 Cマクロとは異なりますが、いくつかの優れた機能があります。しかし、C ++テンプレートは何らかの前処理で実装されていませんか?これは異なるC ++コンパイラでどのように実装されていますか?
27 c++  c  compiler  templates  macros 

2
C ++関数constexprをマークするのは悪いことですか?
非常に簡単な関数を考えると、 int transform(int val) { return (val + 7) / 8; } この関数を関数に変換するconstexprことは簡単で、constexpr変数を定義するときに次のように使用できることは非常に明白です。 constexpr int transform(int val) { return (val + 7) / 8; } 私の想定では、これは厳密に改善されたものです。関数はconstexprコンテキスト以外でも呼び出すことができ、コンパイル時の定数変数の定義に使用できるようになったためです。 私の質問は、これが悪い考えである状況はありますか?たとえば、この関数を作成することによりconstexpr、特定の状況でこの関数が使用できなくなる状況や、誤動作する状況に遭遇することはありますか?
26 c++  c++11 

11
マルチスレッドのバグに悩まされる
私が管理している新しいチームでは、コードの大部分はプラットフォーム、TCPソケット、およびhttpネットワークコードです。すべてのC ++。その大部分は、チームを去った他の開発者からのものです。チームの現在の開発者は非常に賢いですが、ほとんどの場合、経験的には後輩です。 私たちの最大の問題:マルチスレッドの同時実行バグ。ほとんどのクラスライブラリは、いくつかのスレッドプールクラスを使用して非同期に作成されています。クラスライブラリのメソッドは、長時間実行されるタスクを1つのスレッドからスレッドプールにキューイングすることが多く、そのクラスのコールバックメソッドは別のスレッドで呼び出されます。その結果、誤ったスレッドの仮定に関連する多くのエッジケースバグがあります。これにより、同時実行性の問題から保護するための重要なセクションとロックを保持するだけでなく、微妙なバグが発生します。 これらの問題をさらに困難にしているのは、修正の試みがしばしば間違っていることです。チームが(またはレガシーコード自体で)試みようとしているミスには、次のようなものがあります。 よくある間違い#1-共有データをロックするだけで同時実行の問題を修正しますが、メソッドが期待される順序で呼び出されない場合に何が起こるかを忘れます。これは非常に簡単な例です: void Foo::OnHttpRequestComplete(statuscode status) { m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } そのため、OnHttpNetworkRequestCompleteの実行中にShutdownを呼び出すことができるバグがあります。テスターはバグを見つけ、クラッシュダンプをキャプチャし、バグを開発者に割り当てます。彼は次のようにバグを修正します。 void Foo::OnHttpRequestComplete(statuscode status) { AutoLock lock(m_cs); m_pBar->DoSomethingImportant(status); } void Foo::Shutdown() { AutoLock lock(m_cs); m_pBar->Cleanup(); delete m_pBar; m_pBar=nullptr; } 上記の修正は、さらに微妙なエッジケースがあることに気付くまでは問題ありません。OnHttpRequestCompleteがコールバックされる前にシャットダウンが呼び出されるとどうなりますか?私のチームが持っている実際の例はさらに複雑であり、コードレビュープロセス中にエッジケースを見つけるのはさらに困難です。 よくある間違い#2-盲目的にロックを終了し、他のスレッドが終了するのを待ってからロックを再入力することで、デッドロックの問題を修正します。 よくある間違い#3-オブジェクトは参照カウントされますが、シャットダウンシーケンスはポインターを「解放」します。しかし、まだ実行中のスレッドがそのインスタンスを解放するのを待つことを忘れています。そのため、コンポーネントは完全にシャットダウンされ、その後、コールを予期しない状態のオブジェクトでスプリアスまたはレイトコールバックが呼び出されます。 他のエッジケースもありますが、一番下の行はこれです: マルチスレッドプログラミングは、頭のいい人でも簡単です。 これらの間違いを見つけると、より適切な修正を開発するために各開発者とエラーについて話し合うことに時間を費やします。しかし、「正しい」修正には触れなければならない膨大な量のレガシコードのため、各問題の解決方法についてしばしば混乱していると思われます。 私たちはすぐに出荷するつもりであり、私たちが適用しているパッチは今後のリリースに適用されると確信しています。その後、コードベースを改善し、必要に応じてリファクタリングする時間があります。すべてを書き直す時間はありません。そして、コードの大部分はそれほど悪くはありません。しかし、スレッドの問題を完全に回避できるように、コードをリファクタリングしたいと考えています。 私が検討しているアプローチの1つはこれです。重要なプラットフォーム機能ごとに、すべてのイベントとネットワークコールバックがマーシャリングされる専用の単一スレッドを用意します。メッセージループを使用したWindowsでのCOMアパートメントスレッドに似ています。長時間のブロッキング操作はワークプールスレッドにディスパッチされる可能性がありますが、コンポーネントのスレッドで完了コールバックが呼び出されます。コンポーネントは同じスレッドを共有することさえできます。その後、スレッド内で実行されるすべてのクラスライブラリは、単一のスレッド化された世界を想定して記述できます。 その道を進む前に、マルチスレッドの問題に対処するための他の標準的な手法や設計パターンがあるかどうかにも非常に興味があります。そして、私は強調しなければなりません-ミューテックスとセマフォの基本を説明する本を超えた何か。どう思いますか? また、リファクタリングプロセスに向けた他のアプローチにも興味があります。次のいずれかを含む: スレッド周辺のデザインパターンに関する文献または論文。ミューテックスとセマフォの紹介を超えたもの。大規模な並列処理も必要ありません。他のスレッドからの非同期イベントを正しく処理するようにオブジェクトモデルを設計する方法だけです。 さまざまなコンポーネントのスレッド化を図式化する方法。これにより、ソリューションの研究と発展が容易になります。(つまり、オブジェクトおよびクラス全体のスレッドを議論するためのUML同等物) …

13
C ++の基礎に苦労している学生の指導[非公開]
私は、最初のプログラミング言語であるC ++の基礎を学ぶのにかなり苦労している数人の生徒を指導しています。私は、最初のCSコースを失敗または脱落させた優秀で優秀な学生を多く知っています。私が指導している全員が、クラスでの彼または彼女の経験について同様の説明をします。インストラクターはあまりにも速く動きますが、講義では何も意味がありません。このCSクラスの前は、これらの苦労している学生のほとんどは、ワードプロセッサ、Webブラウザ、またはその他のエンターテイメント以外のものとしてコンピュータに興味を示していませんでした。コンピューターは機能するブラックボックスであるため、なぜそれを台無しにしますか? 私の最良の推測は、コンピュータサイエンスの抽象化とおなじみの概念との接続に問題があることです。つまり、これらの学生は数学、生物学、または物理学を学ぶ方法を知っているかもしれませんが、プログラミングに関してはそれらのテクニックは機能していません。 誰か提案やアドバイスはありますか?私が手伝っている学生は、このクラスに失敗するに値しません。インストラクターがこれらの生徒の学習スタイルを考慮していないことは明らかです。つまり、インストラクターは生徒ではなく失敗しています。

9
コンパイラの警告を無効にする必要があるのはなぜですか?
この回答とそれに追加されたコメントは、#pragmaディレクティブを使用していくつかのコンパイラ警告を無効にする方法を示しています。 なぜそれをしたいのでしょうか?通常、警告は理由があるので、私は常にそれらが正当な理由だと感じています。警告を無効にする「有効なケース」はありますか?今は何も考えられませんが、多分それは私だけです。
26 c#  c++  c  warnings 


4
なぜC ++とJavaの両方が「参照」の概念を使用しますが、同じ意味では使用しないのですか?
C ++では、関数への参照引数により、関数が参照を他のものに参照させることができます。 int replacement = 23; void changeNumberReference(int& reference) { reference = replacement; } int main() { int i = 1; std::cout << "i=" << i << "\n"; // i = 1; changeNumberReference(i); std::cout << "i=" << i << "\n"; // i = 23; } 同様に、関数への定数参照引数は、参照を変更しようとするとコンパイル時エラーをスローします。 void changeNumberReference(const int& reference) …
26 java  c++  pointers  reference 

4
私のコードで「マネージャー」を避ける方法
この質問は、Software Engineering Stack Exchangeで回答できるため、Code Review Stack Exchangeから移行されました。 6年前に移行され ました。 現在、C ++向けにEntity Systemを再設計しています。多くのマネージャーがいます。私の設計では、ライブラリを結合するためにこれらのクラスがあります。「マネージャー」クラスに関しては、多くの悪いことを聞いたことがあります。おそらく、クラスに適切な名前を付けていません。しかし、他にどのような名前を付けるべきかはわかりません。 私のライブラリーのほとんどのマネージャーは、これらのクラスで構成されています(ただし、多少異なります)。 コンテナ-マネージャ内のオブジェクトのコンテナ 属性-マネージャー内のオブジェクトの属性 ライブラリの新しいデザインには、ライブラリを結び付けるために、これらの特定のクラスがあります。 ComponentManager-エンティティシステムのコンポーネントを管理します ComponentContainer コンポーネント属性 シーン*-シーンへの参照(以下を参照) SystemManager-エンティティシステム内のシステムを管理します SystemContainer シーン*-シーンへの参照(以下を参照) EntityManager-エンティティシステム内のエンティティを管理します EntityPool-エンティティのプール EntityAttributes-エンティティの属性(これはComponentContainerおよびSystemクラスのみがアクセス可能です) シーン*-シーンへの参照(以下を参照) シーン-すべてのマネージャーを結び付ける ComponentManager SystemManager EntityManager Sceneクラス自体にすべてのコンテナ/プールを配置することを考えていました。 すなわち これの代わりに: Scene scene; // create a Scene // NOTE: // I technically could wrap this line in …

3
構造体とstd :: pairの使用にはどのような違いがありますか?
私は経験が少ないC ++プログラマです。 を使用しSTL mapていくつかのデータを保存および操作したい場合、これらの2つのデータ構造アプローチの間に(パフォーマンスにも)意味のある違いがあるかどうかを知りたいと思います。 Choice 1: map<int, pair<string, bool> > Choice 2: struct Ente { string name; bool flag; } map<int, Ente> 具体的にはstruct、シンプルではなくを使用してオーバーヘッドがありますpairか?

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