記事ディレクトリ
- 【よくあるデザインパターン】
- 【C++クラスはどのように実装されているのか】
- 【サーバー向け高同時実行ソリューション】
- [C++ の 6 つのオブジェクト指向設計原則]
- [C++のメモリ管理]
- 【C++の基本データ型】
- 【STLにおける消去と削除の違い】
- 【グローバル変数、スタティック変数、ローカル変数のライフサイクルとスコープ】
- [STL におけるイテレータとイテレータの無効化の問題]
- 【ポインタと配列の違い】
- [const型のポインタ]
- [カプセル化、継承、ポリモーフィズムの違い]
- 【ハッシュ衝突】
- [マップとマルチマップ -- ダークホースの説明]
- 【IPデータグラムの送信手順】
- 【ダングリングポインタ、ワイルドポインタ、メモリリーク、メモリオーバーフローの原因と回避方法】
- 【httpの短い接続と長い接続】
- 【IPアドレスの構成とIPパケットのサイズ】
- Linuxで特定のポートが占有されているかどうかを確認する
- プラグマ前処理ディレクティブ
- 削除と削除[]の違い
- 詳細なスタックとスタック オーバーフロー
- 共通ポート番号
- ベクトルメモリ解放の問題
- 【getとpostの違い】
【よくあるデザインパターン】
【C++クラスはどのように実装されているのか】
C++ では、クラス结构体或类を定義することでクラスが実装されます。構造体またはクラスは、オブジェクトがデータを格納および操作できるように、メンバー変数とメンバー関数のセットを定義します。
クラス定義では、「はい」になります使用各种访问修饰符来控制成员变量和成员函数的可见性和访问权限。一般的なアクセス修飾子は、パブリック、プライベート、およびプロテクトです。パブリック メンバー変数とメンバー関数はクラス外のコードからアクセスできますが、プライベート メンバー変数とメンバー関数はクラス内でのみアクセスできます。保護されたメンバー変数とメンバー関数には、クラスおよび派生クラス内のコードからアクセスできます。
C++ のクラスには、メンバー変数とメンバー関数に加えて、コンストラクター、デストラクター、静的メンバー変数、静的メンバー関数などの特別なメンバーを含めることもできます。
コンストラクターは、クラスのインスタンスの作成時にメンバー変数を初期化するために使用され、デストラクターは、オブジェクトが破棄されるときにリソースをクリーンアップするために使用されます。
静的メンバー変数と静的メンバー関数は、クラスのインスタンスではなく、クラス自体に関連付けられます。静的メンバーには、クラスのインスタンスを作成せずに、クラスの外部からアクセスできます。
【サーバー向け高同時実行ソリューション】
[C++ の 6 つのオブジェクト指向設計原則]
/*
* 面向对象的六大设计原则：
* <1>单一职责原则：单一职责原则是在描述一个类其中应该只包含一组和其功能相关的成员函数和数据，而不应该再含有其他功能，
* 当一个类中含有较多不想关的成员变量或者函数时，我们应该考虑将这个类拆分成多个类
* 单一职责原则的优点：
* 单一职责原则可以降低类的复杂度，提高系统的可维护性。
* 单一职责实际也减少了类的冗余性，提高了类的重组性和功能单一化
* 消除耦合，减小由业务变化引起的代码僵化
* 单一职责原则解决的问题：
* 当有类A,需要有两个功能T1和T2时，当T1的功能需要改变时，可能会导致T2的功能有障碍，因此在设计时就需要将T1和T2两个
* 分别构建类Fun1和Fun2，来分别完成他们的功能
*
* <2>里式替换原则
*
* 里式替换原则：里式替换原则是依赖于继承和多态的，当有父类出现的地方，子类也可以出现，并且子类对象可以替换父类对象，并且
* 使用者不需要知道是父类还是子类，但是反之却不行。因为父类中不一定有子类的方法。
*
* 里式替换的优点：里式替换可以提高代码的可重用性
* 保证子类中含有父类的所有属性，
* 缺点:子类中有时候可能就比较冗余
*
*
* <3>依赖倒置原则：依赖倒置原则在讲各个类之间是通过接口去耦合，而不是和类的接口的实现方法相关
* 是和类方法的地层实现不相关的。
*
*
* <4>开放封闭原则：开放封闭原则讲的是对于修改我们应该封闭，而对于拓展我们是应该开放
*
* <5>迪米特原则： 对象与对象之间应该使用尽可能少的方法来关联，避免千丝万缕的关系。
* 一个对象应该对其他对象有最少的了解。一个类应该对自己需要耦合或调用的类知道的最少，
* 类的内部如何实现与调用者或者依赖者没有关系，调用者或者依赖者只需知道它需要的方法即可。
* 一般是伴随着类的组合出现
*
* <6>接口隔离原则：接口隔离原则推荐在设计类时应该使用最小的接口，使用多个单一功能的接口比使用一个总的接口要好。
*/
[C++のメモリ管理]
【C++の基本データ型】
【STLにおける消去と削除の違い】
C++ の STL では:
erase是真正的删除元素はい、イテレータに再びアクセスすることはできません。
ただしremove只是简单的把要remove的元素移到了容器的最后、コンテナの内部構造を知らなくてもイテレータには引き続きアクセスでき、位置を移動するだけで実際に要素を削除することはできません。
【グローバル変数、スタティック変数、ローカル変数のライフサイクルとスコープ】
[STL におけるイテレータとイテレータの無効化の問題]
データ (データ) と動作 (メソッド) を一緒に編成する OOP (オブジェクト指向プログラミング) とは異なり、STL GP (ジェネリック プログラミング) の中心的な考え方は次のとおりです数据容器(containers)和算法(algorithms)分开，彼此独立设计，最后再以胶着剂将它们撮合在一起。那么之间的胶着剂就是迭代器(iterator)。
イテレータは、動作がポインタに似たオブジェクトです (スマート ポインタ オブジェクトの主な動作は、コンテナ内のデータ メンバを走査してアクセス () することです遍历范围[first,last]。そのため、イテレータは、operator&() および Operator*() をオーバーロードする必要があります。同時に、それ自体の有効性 (デストラクター) の問題も考慮に入れます。
【ポインタと配列の違い】
1. 概念:
配列は、同じ型の複数のデータを格納するポインタの集合です.
ポインタは変数に相当しますが、変数とは異なります. 変数のメモリアドレスを格納します;
2. 違い初期化サイズなどの代入と格納方法
1) 代入: 同じ型のポインタ変数同士は代入できるが、配列は代入できず、1つずつ代入またはコピーのみ; 2
) 格納方法
配列: 配列メモリに継続的に保存され、連続的なメモリ空間が開かれます。配列は配列添字に基づいてアクセスされます。多次元配列は 1 次元配列としてメモリに保存されますが、論理的には多次元です。配列の保存方法: 配列の保存
スペース(静的領域またはスタック上のいずれか)。
ポインター: ポインターは柔軟で、あらゆる種類のデータを指すことができます。ポインタのタイプは、アドレス空間内でポインタが指すメモリを表します。
ポインタの格納方法:指针的存储空间不能确定ポインタ自体が変数であり、格納するものも変数であるため、格納スペースは不確実です。
3)配列のサイズを調べます: sizeof (配列名):配列によって占有されているメモリまたは配列の
サイズポインタを求めます: sizeof (ポインタ名) = 4 (32 ビット未満); sizeof (ポインタ名) = 8
4) 64 未満bits) アクセス効率
数组通过下标直接访问、アクセス効率はポインタより高いが、柔軟性は非常に低い;
指针通过地址找到指针所指的对象，再访问对象的内存单元、間接アクセスに属し、アクセス効率は配列より低いが、柔軟性は高い; 5)セキュリティ
のセキュリティ
配列はポインタの値よりも大きいです
配列 ( 数组访问越界)
ポインタで考えられる問題 考えられる問題 ( 野指针 空悬指针 造成内存泄露)
[const型のポインタ]
【重点】 const 对象一旦创建之后就不能改变，所以const对象必须初始化；
ポインタ変数には 2 つのメモリ空間が必要であり、指针变量本身所占用的内存空间以及指针变量本身所指向的数据的内存空间const 型の変数は変数の値を変更できないことを示すため、const とポインタを組み合わせるには次の 2 つの形式が必要です一是指针本身是常数（顶层const)，另一种是指针变量所指的数据为常数(底层const)。
1. 定数へのポインタ:ポインタが指すデータは定数であり、読み取り専用変数を指します。形式:<类型>const* <指针变量>或const <类型>*<指针变量>
; 比如 int const*p const int *p const は *p を変更するために使用されます。これは、p が指す空間の内容をこのポインターを通じて変更できないことを意味します。
2. 定数ポインタ ポインタ自体は初期化が必要な定数であり、初期化が完了すると変更することはできません。
形式:<类型>*const<指针变量>
例: int * const p ; const はポインタ p 自体を変更し、ポインタの値を変更できないこと、つまりポインタのポイントを変更できないことを示します;
3. 定数を指す定数ポインタ即指针的值为常量 同时指针所指向的数据也为常量
** 形式: const<型>*const <ポインタ変数> **
[カプセル化、継承、ポリモーフィズムの違い]
参考資料
多态实现之重写: サブクラスが親クラスの仮想関数を再定義すると、親クラス ポインターは、割り当てられたさまざまなサブクラス ポインターに従って、サブクラスに属する関数を動的に呼び出します (動的であることを忘れないでください)。このような関数呼び出しは実行できません。コンパイル中に決定されます (呼び出されたサブクラスの仮想関数のアドレスは指定できません)。したがって、そのような関数アドレスは実行時にバインドされます (遅延バインディング)。
3 つの主要な機能の役割:
カプセル化により実装の詳細を隠し、コードをモジュール化できる;
継承によって既存のコード モジュール (クラス) を拡張できる; それらの目的は - です代码重用。
そしてポリモーフィズムは別の目的を達成するためのものです -接口重用
【ハッシュ衝突】
- ハッシュ衝突とは何ですか?
通常、キーと値は 1 対 1 に対応しますが、不同的key通过哈希映射到的value是同一个競合がある場合、これはハッシュの競合です。 - ハッシュ競合を解決する 4 つの方法
1. オープン アドレッシング方式
オープン アドレッシング方式とは、競合が発生した場合に次の空のハッシュ アドレスを見つける方法であり、ハッシュ テーブルが十分に大きい限り、常に空のハッシュ アドレスを見つけることができます。そして、レコードを以下に保存します
。 ※ オープンアドレッシング方式との競合を解決する方法は、競合が発生した場合、何らかの検出技術を使用してハッシュテーブルに検出シーケンスを作成します。指定されたキーワードが見つかるまで、またはオープン アドレスが見つかるまで (つまり、アドレス ユニットが空です)、このシーケンスに沿ってユニットごとに検索します (挿入したい場合は、オープン アドレスを検出した後、挿入するアドレスを挿入できます)新しいノードはこのアドレス単位に格納されます。検索中にオープンアドレスが検出された場合は、テーブル内に検索対象のキーワードが存在せず、検索が失敗したことを示します。
2 番目に、リハッシュ
とも呼ばれます双哈希法。
基本实现思路是: キーワードが key であるハッシュ アドレス p=H(key) が衝突する場合、p に基づいて別のハッシュ アドレス p1 を生成し、それでも p1 が衝突する場合は、p に基づいて別のハッシュ アドレス p2 を生成します ...衝突しないハッシュ アドレスになるまで見つかった。
3. ジッパーメソッド
とも呼ばれます链地址法。基本的な考え方は、各ハッシュ テーブル ノードが次のポインタを持ち、多个哈希节点可以用next指针构成一个单向链表同じインデックスに割り当てられた複数のノードをこの一方向リンク リストで接続できるということです。
例:
キーと値のペア k2, v2 とキーと値のペア k1, v1 の計算後のインデックス値は 2 になります。このとき競合があっても、k2 と k1 が配置されているノードは接続できます。チャネルのネクスト ポインタによって、ハッシュの競合の問題を解決します。
4.
パブリック オーバーフロー領域を確立する基本的な考え方は、ハッシュ テーブルを基本表和溢出表2 つの部分に分割し、基本テーブルと競合するすべての要素を 1 つのテーブルに埋めることです。 ;
[マップとマルチマップ - ダークホースの説明]
マップとマルチマップの両方关联容器;底层是二叉树
要素タイプはすべてpair
key-value構造体です
すべての要素は要素に基づきます键值自动排序
2 つの違いは次のとおりです。
マップ コンテナでは、キー値要素の繰り返しは許可されません。コンテナ内の
マルチマップ允许容器中有重复的key值要素は許可されません。
【IPデータグラムの送信手順】
MAC ヘッダー
mac ヘッダーは、イーサネットで使用されるヘッダーです。データグラムの送信中に、IP包中的源IP地址和目的IP地址始终不变，通过改变mac头部的接收方mac地址和发送方mac地址达到两点之间的传输;
【ダングリングポインタ、ワイルドポインタ、メモリリーク、メモリオーバーフローの原因と回避方法】
指针これは、ポインタが指すオブジェクトのメモリ アドレスを格納する変数であり、ポインタを介してトラバースおよびアクセスできます。まず、ポインタ上のアドレスを通じてポインタが指すオブジェクトを見つけ、次にそのオブジェクトのメモリ空間にアクセスします。これは間接アクセスに属します。
空悬指针: 破棄または再利用されたアドレスを指すポインタですが、このポインタはまだ NULL を指していません。このポインタは、
プログラミング時に free または delete を呼び出すときに動的に割り当てられたメモリを解放するだけでなく、ダングリング将相关的指针指向NULLポインタを避けるよう促します ; :
野指针ポインタ没有初始化はワイルド ポインタ;
内存泄露: プログラム内にメモリを申請するプロセスがありますが、プログラム終了後も占有されていたメモリが解放されていないため、このメモリは単独では使用できなくなり、オペレーティング システムは使用できなくなります。他のプログラムによって使用されている場合、この状況はメモリ リークです。
内存溢出: 使用可能なメモリが占有されており、メモリを適用できません。
解決策は引用计数型智能指针shared_ptr/weak_ptr
、同じオブジェクトを指す 2 つのポインタがあると仮定することです。2 つのポインタは 2 つのスレッドにあります。一方のポインタがオブジェクトを解放すると、もう一方のオブジェクトは空のメモリを指します。このとき、ポインタはダングリング ポインタです。 。
解决方案是引入引用计数型智能指针:
スマート ポインタ オブジェクトを導入します。この智能指针保存有指针和计数器カウンタは、オブジェクトを指すポインタの数を記録します。オブジェクトを解放するポインタがあるたびに、参照カウントは 0 になるまで 1 つ減り、オブジェクトは安全に破棄できます。
shared_ptr は、参照カウントされるスマート ポインターであり、型パラメーターを 1 つだけ持つクラス テンプレートです。参照カウントは一般的に使用される RALL メカニズムです (リソースの取得は初期化です)。参照カウントが 0 に減少すると、オブジェクトは破棄されます。weak_ptr も参照カウント ポインタですが、これは弱参照です。複数のスレッドが Shared_ptr にアクセス
する它不增加对象的引用次数場合
、同時に、必要があります用mutex来保证它的线程安全。
【httpの短い接続と長い接続】
参考資料
長い接続と短い接続はクライアントとサーバーを指します连接维持时间的长短。HTTP
の長い接続と短い接続は、本質的には TCP の長い接続と短い接続です。
HTTP はアプリケーション層プロトコルに属し、トランスポート層では TCP プロトコルを使用し、ネットワーク層では IP プロトコルを使用します。
では、HTTP/1.0デフォルトで短い接続が使用されます。つまり、クライアントとサーバーです每进行一次HTTP操作(传输HTTP数据），就建立一次TCP连接，任务结束就中断连接。クライアント ブラウザによってアクセスされる HTML またはその他の種類の Web ページに他の Web リソース (JavaScript ファイル、画像ファイル、CSS ファイルなど) が含まれている場合、そのような Web リソースに遭遇すると、ブラウザは重新建立一个HTTP会话.
今後はHTTP/1.1、接続特性を維持するために、デフォルトで長い接続が使用されます。長時間接続の HTTP プロトコルを使用すると、次のコード行が応答ヘッダーに追加されます。
Connection:keep-alive
長い接続を使用する場合、Web ページを開いたときに、クライアントとサーバー間の接続が用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
Keep-Alive は接続を永続的に維持するものではなく、接続を保持します保持时间。この時間は別のサーバー ソフトウェア (Apache など) で設定できます。永続的な接続を実装するには、クライアントとサーバーの両方が永続的な接続をサポートする必要があります。
【IPアドレスの構成とIPパケットのサイズ】
版本号--IP报头长度--服务类型--IP包总长--标识符--标记--片偏移
-生存时间--协议--头部校验--源端和目标端地址--可选项--填充
バージョン番号 (バージョン: 長さ 4 ビットは、現在使用されている IP プロトコルのバージョン番号を識別します。一般的な値は次のとおりです)0100（IPv4），0110（IPv6）
IP ヘッダーの長さ (ヘッダー長) : 长度4比特。IP ヘッダーには可変長のオプション部分があるため、このフィールドの目的は IP ヘッダーの長さを記述することです。この部分は4ビットを占め、単位は32ビット（4バイト）、つまりこの領域の値＝IPヘッダ長（単位はビット）/（8×4）となるため、IPヘッダの最長長は「1111 」、つまり 15 4=60 バイトです。IP パケット ヘッダーの最小長は 20 バイトです。
サービス タイプ (サービスの種類) : 长度8比特。8 ビットは次のように定義されます。 PPP DTRC0
PPP: パケットの優先順位を定義します。値が大きいほど、データの重要性が高くなります。
IP パケットの合計長 (Total Length) : 长度16比特。IP パケットの長さはバイト単位で計算されるため (ヘッダーとデータを含む)、IP パケットの最大長は 65535 バイトになります。
識別子: 长度16比特。このフィールドは、より大きな上位層データ パケットに対してフラグメンテーション操作を実行するために、Flags および Fragment Offest フィールドと組み合わせて使用されます。ルーターがパケットを分割すると、宛先デバイスがどのパケットが分割パケットの一部であるかを区別できるように、すべての分割パケットに同じ値がマークされます。
フラグ: 长度3比特。このフィールドの最初の桁は使用されません。2 番目のビットは DF (Don't Fragment) ビットで、DF ビットが 1 に設定されている場合、ルーターが上位層のデータ パケットをフラグメント化できないことを示します。上位層パケットをフラグメント化せずに転送できない場合、ルータは上位層パケットを破棄し、エラー メッセージを返します。3 番目のビットは MF (More Fragments) ビットで、ルーターが上位層のデータ パケットをフラグメント化するとき、ルーターは最後のフラグメントを除く IP パケットのヘッダーの MF ビットを 1 に設定します。
フラグメント オフセット: 长度13比特。フラグメント パケットのグループ内の IP パケットの位置を示し、受信者はこれに基づいて IP パケットを組み立て、復元します。
生存時間 (TTL) : 长度8比特。IP パケットが送信されるとき、最初にこのフィールドに特定の値が割り当てられます。IP パケットが途中の各ルーターを通過すると、途中の各ルーターは IP パケットの TTL 値を 1 減らします。TTL が 0 に減少すると、IP パケットは破棄されます。このフィールドにより、ルーティング ループが原因で IP パケットがネットワーク内で継続的に転送されるのを防ぐことができます。
プロトコル (プロトコル) : 长度8比特. 上位層で使用されるプロトコルを識別します。
ヘッダー チェックサム: 长度16位。IP ヘッダーの正確性をチェックするために使用されますが、データ部分は含まれません。各ルーターは TTL 値を変更するため、ルーターは通過するパケットごとにこの値を再計算します。
送信元アドレスと宛先アドレス: どちらのフィールドも 32 ビットです。この IP パケットの送信元アドレスと宛先アドレスを識別します。NAT が使用されない限り、これら 2 つのアドレスは送信プロセス全体を通じて変更されないことに注意してください。
ここまでは、IP ヘッダーの基本的な 20 バイトについて説明しましたが、次の部分は必須ではなくオプションです。
オプション (Options ): これは可変長フィールドです。このフィールドはオプションであり、主にテストに使用され、必要に応じて発信元のデバイスによって書き換えられます。オプションの項目には次のようなものがあります。
松散源路由（Loose source routing）：给出一连串路由器接口的IP地址。IP包必须沿着这些IP地址传送，但是允许在相继的两个IP地址之间跳过多个路由器。
严格源路由（Strict source routing）：给出一连串路由器接口的IP地址。IP包必须沿着这些IP地址传送，如果下一跳不在IP地址表中则表示发生错误。
路由记录（Record route）：当IP包离开每个路由器的时候记录路由器的出站接口的IP地址。
时间戳（Timestamps）：当IP包离开每个路由器的时候记录时间。
Padding : IP ヘッダーの長さの単位 (Header Length) は 32 ビットであるため、IP ヘッダーの長さは 32 ビットの整数倍でなければなりません。したがって、オプション項目の後に、IP プロトコルは 32 ビットの整数倍に達するまでいくつかの 0 を埋めます。
Linuxで特定のポートが占有されているかどうかを確認する
1. ポート 80 が占有されているかどうかを確認します命令:netstat -anp | grep 80
。 2. 現在の環境で使用されているポート情報を確認します命令:netstat -nultp
。 3. 合格した場合はkill -9 PID、スレッドを強制終了します。
プラグマ前処理ディレクティブ
一般的に使用されるプラグマ ディレクティブの詳細な説明により、
1.#pragma once。ファイルが 1 回だけインクルードされること、ファイルがディスク ファイルに基づいていること、#ifndef がマクロに基づいていることが保証されます。
2.#pragma warning。コンパイラ警告メッセージの動作を選択的に変更できます。次のような使用法があります:
#pragma warning(disable:4507 34; Once:4385; error:164) は次と同等です:
#pragma warning(disable:4507 34) // 警告メッセージ 4507 および 34 を表示しません
#pragma warning( Once: 4385) // 4385番の警告情報は1回だけ報告
#pragma warning(error:164) // 164番の警告情報をエラーとして扱う
#pragma warning(default:176) // コンパイラの176番をリセットデフォルト状態への警告動作
同時に、このプラグマ警告は次の形式もサポートしています。ここで、n は警告レベル (1 ～ 4) を表します:
#pragma warning(push) // すべての警告メッセージの既存の警告ステータスを保存します
#pragma warning(push,n) // すべての警告メッセージの既存の警告ステータスを保存し、グローバル警告レベルを n
#pragma comment(lib,"XXX.lib")に設定して
、ライブラリ XXX.lib をリンクします。これは、書き込みと同じ効果があります。プロジェクト設定の XXX.lib。
#pragma comment(linker,"/ENTRY:main_function") は、
指定されたリンカ オプション /ENTRY:main_function を示します
削除と削除[]の違い
delete はデストラクターを 1 回だけ呼び出します。
delete[] になります调用数组中每个元素的析构函数。
delete new单个对象指针によって割り当てられたメモリを解放します
delete[] new对象数组指针によって割り当てられたメモリを解放します
詳細なスタックとスタック オーバーフロー
参照とは、関数呼び出し中のスタックの変更
を指します。関数呼び出しでは、最初にスタック フレームが割り当てられ、これらのローカル変数の内容は関数の実行終了後に失われます。しかしクリアできていない。関数が戻ると、EBP がポップされ、スタックが関数呼び出しのアドレスに復元され、戻りアドレスが EIP にポップされてプログラムが続行されます。スタック オーバーフロー:スタック オーバーフローとは、スタック内のデータ ブロックのサイズに関係なく、多すぎるデータがデータ ブロックに書き込まれ、古いスタック データが上書きされることを意味します。C++ メモリ パーティション: C++ では、メモリは 5 つの領域に分割され、それぞれ です。
然后在栈帧中将被依次压入：参数，返回地址，EBP(指针寄存器)。如果函数有局部变量，接下来，就在堆栈中开辟相应的空间以构造变量。
数据越界
堆、栈、自由存储区、全局/静态存储区和常量存储区
スタックの違い:
ヒープとスタックは、実際にはプロセスが占有するメモリ空間に対するオペレーティング システムの 2 つの管理方法であり、主に次の違いがあります: (1)
管理方法が異なります。スタックは手動制御なしでオペレーティング システムによって自動的に割り当ておよび解放されます。ヒープの適用と解放はプログラマによって制御されますが、メモリ リークが発生しやすいです。(2) 領域のサイズが異なります
。各プロセスのスタック サイズはヒープ サイズよりもはるかに小さくなります。
（３）成長方向が異なる。ヒープの成長方向は上向きで、メモリ アドレスは低位から高位へ、スタックの成長方向は下向きで、メモリ アドレスは高位から低位へです。
(4) 配布方法が異なります。ヒープは動的に割り当てられ、静的に割り当てられるヒープはありません。スタックを割り当てるには、静的割り当てと動的割り当ての 2 つの方法があります。静的割り当ては、ローカル変数の割り当てなど、オペレーティング システムによって実行されます。動的割り当ては alloca() 関数によって割り当てられますが、スタックの動的割り当てはヒープとは異なり、手動で実装しなくてもオペレーティング システムによって解放されます。
(5) 分配効率が異なります。スタックはオペレーティング システムによって自動的に割り当てられ、ハードウェア レベルでスタックのサポートが提供されます。つまり、スタックのアドレスを格納するための特殊レジスタの割り当て、スタックのプッシュとポップ、および実行する特殊な命令があります。スタックの効率が比較的高いかどうかを判断します。ヒープは C/C++ が提供するライブラリ関数や演算子によって割り当ておよび管理されますが、その実装メカニズムは比較的複雑で、頻繁にメモリを使用するアプリケーションではメモリの断片化が発生しやすくなります。明らかに、堆的效率比栈要低得多。
(6) 保存内容が異なります。 栈存放的内容，函数返回地址、相关参数、局部变量和寄存器内容等。
堆，一般情况堆顶使用一个字节的空间来存放堆的大小，而堆中具体存放内容是由程序员来填充的。
上記からも分かるように、スタックに比べてmalloc()/free()やnew/deleteを多用するため、大量のメモリ断片化が発生しやすく、スイッチングが発生する可能性があります。ユーザー モードとコア モードの間で実行されますが、効率が低くなります。スタックはヒープに比べてプログラム内で広く使用されており、最も一般的な関数呼び出し処理はスタックによって実装され、関数の戻りアドレス、EBP、実パラメータ、ローカル変数はすべてスタックに格納されます。スタックには多くの利点がありますが、ヒープに比べて柔軟性が低いため、大量のメモリ空間が割り当てられる場合があり、主にヒープが使用されます。
ヒープであれスタックであれ、内存使用时都要防止非法越界，越界导致的非法内存访问可能会摧毁程序的堆、栈数据プログラムが不確実な状態で動作したり、期待した結果が得られなかったり、プログラムが異常終了したりすることは、メモリを扱う上で注意すべき問題です。プログラミング。
停電によりサーバーがクラッシュし、TCP 接続が確立された後にネットワーク ケーブルが抜かれた場合はどうなりますか? 1.RST包サーバーのクラッシュ: サーバーはクライアントに
RST パケットを送信して接続を閉じます (非グレースフル クローズ) 3 ) 閉じたソケットでデータを受信します (通常はハーフオープン接続で、一方が知らないうちにもう一方を閉じます)参考: https://my.oschina.net/costaxu/blog/127394
2. サーバーの電源がオフになり、ネットワーク ケーブルが抜かれます。パケットを受信できないため、クライアントが開く必要がありますkeep-alive。長時間応答が受信されない場合、接続は自動的に閉じられます。
一般に心跳包的机制、クライアントは積極的に送信し、サーバーは定期的に受信します。クライアントが応答を受信しない場合はサーバーが切断されたと判断し、サーバーがハートビート パケットを受信しない場合はクライアントが切断されたと判断します。
共通ポート番号
SSH ポート番号默认端口号是TCP 22端口
redis ポート番号6379
Mysql ポート番号3306
ベクトルメモリ解放の問題
ベクトルのメモリ空間は増加することだけができますが、減少することはできません。一般的に使用される操作clear()とerase()は、実際にはsize()を減らしてデータをクリアするだけであり、容量は減らないため、メモリ空間は減少しません。下降。
では、メモリ空間を解放する方法は、正しい方法は ですswap()操作。メモリと swap() 操作を解放するために必要なベクトル空的vector 如vector<int>()。
【getとpostの違い】
GET请求是一种用于客户端从服务器获取数据的方法。 POST请求用于从客户端向服务器提交数据。
GET と POST は、HTTP プロトコルで一般的に使用される 2 つのリクエスト メソッドであり、クライアントとサーバーの間でデータを送信するために使用されます。
それらは次の点で異なります。
パラメータの場所: GET リクエストのパラメータは通常、クエリ文字列の形式で URL の末尾に追加されますが、POST リクエストのパラメータはリクエストの本文に含まれます。
パラメータの長さの制限: GET リクエストのパラメータは URL 内にあるため、URL の長さによってパラメータの長さが制限され、転送されるデータ量も制限されます。POST リクエストのパラメータはリクエストボディ内にあり、特定の長さ制限はなく、大量のデータを送信できます。
セキュリティ: GET リクエストのパラメータは URL に含まれるため、機密情報がブラウザの履歴やサーバー ログ ファイルに公開され、さらにネットワーク キャプチャを通じて取得される可能性があるため、機密情報の送信には適していません。POST リクエストのパラメータはリクエスト本文に含まれており、これは比較的安全であり、URL に直接公開されません。
キャッシュ: GET リクエストはブラウザによってキャッシュできます。同じ GET リクエストが複数回送信された場合、ブラウザは実際のリクエストを送信せずに、キャッシュされた応答結果を直接返すことがあります。デフォルトでは、POST リクエストはブラウザによってキャッシュされません。
冪等性: GET リクエストはべき等です。つまり、同じ GET リクエストを複数回送信しても同じ結果が得られ、サーバーに副作用はありません。POST リクエストは冪等ではないため、POST リクエストが送信されるたびに、サーバー上で異なる結果や副作用が生じる可能性があります。
リクエストの目的と転送するデータに応じて、データ転送に適切なリクエスト メソッド (GET または POST) を選択することが重要です。GET はリソースの取得に適しており、POST はデータの送信やサーバーに影響を与える操作の実行に適しています。