면접대비 질문 정리

절차지향과 객체지향 차이

절차지향 : 순차적인처리 중요, C언어 컴퓨터의 작업 처리 방식과 유사 객체지향보다 더 빠름..

객체지향 : 실제 세계를 모델링, 데이터와 절차를 하나의 덩어리로 묶어서 생각하는법.. 3대 특성으로는 캡슐화, 상속, 다형성

캡슐화(데이터를 감추고 메소드로 통하는 방법), 상속(이미 작성된 클래스를 이어 받아 새로운 클래스를 생성하는것, 재활용성)

다형성은(가상함수의 특성을 이용한것. 부모의 타입으로 자식의 함수를 실행)

절차지향의 특징은

데이터와 함수가 분리되어 있다 (즉 독립적이다)

가상함수 테이블

가상함수를 만들때 생기며 클래스의 첫 4바이트에 가상함수 테이블 주소가 추가된다. 인스턴스마다 존재하면 메모리 낭비가 심해서

테이블을 클래스 정보로 두고 각각 인스턴는 포인터 값으로 가상함수 테이블을 가리킨다

가상함수들를 가리키는 함수포인터를 저장해놓은 테이블이다.

vtable(클래스마다 하나의 고유함), vptr(이건 가상함수가 하나라도 있으면 생성됨..vtable의 시작주소를 가리키는 포인터)

---

메모리 영역

1) code 영역

- 코드 자체를 구성하는 메모리 영역으로 Hex파일이나 BIN파일 메모리다.

- 프로그램 명령이 위치하는 곳으로 기계어로 제어되는 메모리 영역이다.

   

2) data 영역

- 전역변수(global), 정적변수(static), 배열(array), 구조체(structure) 등이 저장된다.

     가) 초기화 된 데이터는 data 영역에 저장되고,

        나) 초기화 되지 않은 데이터는 BSS (Block Stated Symbol) 영역에 저장된다.

- 프로그램이 실행 될 때 생성되고 프로그램이 종료 되면 시스템에 반환 된다.

- 함수 내부에 선언된 Static 변수는 프로그램이 실행 될 때 공간만 할당되고, 그 함수가 실행 될 때 초기화 된다.

   

Q) data영역과 bss 영역을 구분 하는 이유?

   컴파일 해서 이미지를 올릴 때 초기화 되지 않은 데이터까지 올리게 되면 ROM 사이즈가 커지기 때문에 구분하지 않았을까? -> 혹시 정확히 아시는 분은 답변 부탁 드립니다. 

   

3) heap 영역

- 필요에 의해 동적으로 메모리를 할당 하고자 할 때 위치하는 메모리 영역으로 동적 데이터 영역이라고 부르며, 메모리 주소 값에 의해서만 참조되고 사용되는 영역이다.

- 이 영역에 데이터를 저장 하기 위해서 C는 malloc(), C++은 new() 함수를 사용한다.

   

 4) stack 영역

- 프로그램이 자동으로 사용하는 임시 메모리 영역이다.

- 지역(local) 변수, 매개변수(parameter), 리턴 값 등 잠시 사용되었다가 사라지는 데이터를 저장하는 영역이다.

- 함수 호출 시 생성되고, 함수가 끝나면 시스템에 반환 된다.

- 스택 사이즈는 각 프로세스마다 할당 되지만 프로세스가 메모리에 로드 될 때 스택 사이즈가 고정되어 있어, 런타임 시에 스택 사이즈를 바꿀 수는 없다.

- 명령 실행시 자동 증가/감소 하기 때문에 보통 메모리의 마지막 번지를 지정 한다.

→ 함수안에 쓰는 변수(지역변수)로 stack영역에 들어간다.

    함수가 여러번 실행되면 HEAP, STACK가 늘어날 수 있다.

    만약 프로그램이 늘어나면 용량이 커지므로 코드영역이 늘어난다.

    변수선언시 stack이 끝번지 주소를 나타내는 것은 아니지만 마지막 영역에 해당한다.

    컴파일하면 code는 더이상 늘어나지 않는다.

→stack의 지역변수는 사용하고 소멸하므로 데이터 용량의 불확실성을 가지므로 밑에서부터 채워 올리고 heap은 위에서 부터 채워 내려진다. 용량의 불확실성은 컴파일러가 알아서 메모리영역을 선택(랜덤적)

   

-stack영역에서의 주소값은 시작주소는 밑에서부터(먼저선언된 순서) 그다음 주소는 순서대로 정해진다.

   

HEAP overflow-heap이 위에서부터 주소값을 채워져 내려오다가 stack영역을 침범하는 경우.

STACK overflow-stack영역이 heap을 침범.

   

-stack은 4kb를 기본으로 하는 경우가 많고 지역변수를 많이 쓰면 stack용량이 커지므로 적당히 쓰는것이 좋다. stack, heap는 기준이 없으므로 프로그램을 실행시켜봐야 알수 있다.

▶ex) int A선언 후 실행 

 먼저 컴파일시 생성되는 기계어가 코드위에 씌어지게 되는게 여기서는 int A 가 '4byte공간을 stack생성하라' 란 일종의 명령이 code영역에 들어간다. 이 때 실행파일을 하드디스크에서 .exe만드는데 여기에는 header(code,bss,data)가 실행파일을 만들때 앞에 함께 들어간다. 이 것을 윈도우에서는 PE (portable executive)라고 한다.

 만들어진 .exe실행파일을 실행하면 운영체제가 실행되고 실행파일을 메모리에 적재(loader)한다. 그리고 실행시에 A가 메모리에 나타난다.

   

※리눅스용 프로그램을 윈도우에서 실행되지 않는 이유

(리눅스 elf, 윈도우 PE구조)이므로 앞에 내용을 붙이는 (header구조)가 다르기 때문에 실행되지 않는다.

---

메모리 단편화

메모리의 빈공간 또는 자료가 여러개의 조각으로 나뉘는 현상이다. 

쉽게 말해 할당한 메모리를 해제를 하게 되면 그 메모리 공간이 빈 공간(사용하지 않는 공간)이 되고 그 빈공간의 크기보다 큰 메모리는 사용못함.

그리하여 이 공간들이 하나둘 쌓이게되면 수치상으로는 많은 메모리가 남았음에도 실제로 사용못함.

내부 메모리 단편화

 - 할당될 크기에 비해 실제 할당된 단위자원 크기가 커서 해당 단위 자원내부에 사용하지 않는 메모리 공간이 발생할때를 이야기함.

32비트 CPU는 메모리에서 값을 읽어올때 한번에 4바이트(32비트), 64비트 CPU는 한번에 8바이트(64비트)를 읽어온다. 

그런데 네트웍을 통해서 구조체 자체를 전송하려고 하면 패팅비트가 굉장히 중요한 변수가 된다. 왜냐하면 구조체가 메모리에 정의되는 형태는 OS와 컴파일러에 따라 달라지기 때문이다. 동일한 구조체를 서로 다르게 메모리에 정의하고 있는 시스템끼리 메모리에 있는 구조체 내용을 그대로 주고 받는다면 구조체의 각 멤버는 서로 다른값을 가지게 된다.

패딩비트는 삽입되는 위치가 컴파일러에 따라 달라진다. 또한 32비트와 64비트 시스템은 동일한 구조체에 대해서 삽입하는 패딩비트의 수가 각각 다르다.

그럼 시스템 A(32비트)가 시스템 B(64비트)에게 아래의 구조체를 네트웍으로 전송하고, 시스템 B는 받은 패킷을 아래 구조체로 캐스팅해서 그대로 사용하는 경우 어떤 문제가 생길까? 

* 참고로 char = 1byte, long long = 8bytes
struct test_s
{
  char a;
  long long b;
} test;

32비트 시스템에서는 위 구조체를 사용할때 멤버 a 뒤에 3바이트의 패딩비트를 넣어서 구조체 사이즈가 12바이트가 된다. 반면에 64비트 시스템에서는 7바이트의 패딩비트를 넣어서 구조체 사이즈가 16바이트가 된다. 

따라서 구조체의 시작위치에 있는 첫번째 멤버 a는 값이 변하지 않지만, 그 다음 멤버들은 값이 다 바뀌게 된다.

첫째, #pragma 또는 #packed 키워드를 사용해서 컴파일러가 패딩비트를 사용하지 않도록 하는 방법이 있다. 하지만 이 방법은 C 표준이 아닌 관계로 이식성이 없다. 

#pragma pack(1)
struct test_s
{
  char a;
  int c;
} test;
#pragma pack(8)

구조체 선언할 때 1 byte 단위로 pack 시킨다고 지정해 주고 선언이 끝난 후에 적절히 4 byte나 8 byte 로 (원래대로) 확장(원복) 시켜 주는 방법이다. 

서론 :

지금 까지 나는 byte padding이 cpu 레지스터 사이즈를 따라 일괄적으로 적용 되는 줄 알고 있었다(http://nsjokt.springnote.com/pages/4716509). 하지만 오늘 exe와 dll 사이에서 일어난 문제를 해결하며 찾아본 자료에서 byte padding은 아래의 네 가지 규칙에 따라 구조체에 따라 다르게 적용 된다는 사실을 알았다. 예를 들어 설명 하자면 지금까지 페이지 사이즈가 4byte인 어플리케이션에서는 byte padding 사이즈를 따로 지정해 주지 않는 한 1 byte 짜리 멤버 변수를 가진 구조체나 4 byte 멤버 변수를 가진 구조체의 sizeof 결과가 모두 4 byte로 같을 것이라고 생각 했으나 실제로는 각각 1 byte, 4 byte로 다르게 align 되고 있었다.

 

위에서 언급한 네 가지 규칙을 살펴 보자면(일단 VC 기준, gcc는 다른 옵션이 있겠지) :

1. Unless overridden with __declspec(align(#)), the alignment of a scalar structure member is the minimum of its size and the current packing.
   
2. Unless overridden with __declspec(align(#)), the alignment of a structure is the maximum of the individual alignments of its member(s).
   
3. A structure member is placed at an offset from the beginning of its parent structure which is the smallest multiple of its alignment greater than or equal to the offset of the end of the previous member.
   
4. The size of a structure is the smallest multiple of its alignment larger greater than or equal the offset of the end of its last member.

출처 : http://msdn.microsoft.com/ko-kr/library/83ythb65(v=vs.100).aspx

 

나름 쉽게 풀어쓴다고 썼지만 나도 알아 먹기 힘드니 예제를 통해서 알아 보도록 하자

 

1. Unless overridden with __declspec(align(#)), the alignment of a scalar structure member is the minimum of its size and the current packing.

 

"__declspec(align(#))을 오버라이드 하지 않으면, 스칼라 구조체(long, bool과 같은 일반 변수로만 이루어진 구조체)의 멤버는 변수의 사이즈와 현재 지정된 byte padding align을 따른다."

 

이해를 돕기 위해 아래와 같이 두 가지 타입의 구조체를 만들어 보았다 :

struct Size_1_Align
{
    bool b;
};

 

struct Size_4_Align
{
    long l;
};

 

int main()

{

std::cout << "Size_1_Align:" << sizeof(Size_1_Align) << std::endl;
std::cout << "Size_4_Align:" << sizeof(Size_4_Align) << std::endl;

} 

 

output :

Size_1_Align:1
Size_4_Align:4

bool 는 1 byte, long은 4 btye, 각 구조체의 사이즈는 각각의 멤버 변수 사이즈 대로 만들어진다.

 

2. Unless overridden with __declspec(align(#)), the alignment of a structure is the maximum of the individual alignments of its member(s).

 

"__declspec(align(#))을 오버라이드 하지 않으면, 구조체는 멤버 변수중 가장 사이즈가 큰 멤버 변수의 byte padding align을 따른다."

 

그럼 위의 Size_1_Align 구조체에는 2 byte 변수를, Size_4_Align 구조체에는 long(4byte) 보다 작은 사이즈의 멤버 변수를 추가해 보겠다. 가장 큰 사이즈 멤버 변수의 align을 따른다고 했으므로 Size_1_Align은 2 byte align 규칙을 따를 것이고, Size_4_Align 구조체는 4 byte align 규칙을 따를 것이다 :

struct Size_1_Align
{
    bool b;  // byte padding 규칙에 따라 요 부분은 1 byte가 더 채워 질 것입니다.
    short s;
};

struct Size_4_Align
{
    long l;
    bool b;
   short s;
};

int main()
{
    std::cout << "Size_1_Align:" << sizeof(Size_1_Align) << std::endl;
    std::cout << "Size_4_Align:" << sizeof(Size_4_Align) << std::endl;
} 

output :
Size_1_Align:4
Size_4_Align:8

예상대로 각각 4 bypte 와 8 byte 가 나왔다.

 

3. A structure member is placed at an offset from the beginning of its parent structure which is the smallest multiple of its alignment greater than or equal to the offset of the end of the previous member.

 

"구조체 멤버는 부모 구조체의 byte padding align의 시작 offset에서 부터 이전 멤버 변수의 끝 offset 뒤에 자리 잡는다."

 

여기서 부모 구조체의 byte padding align에 대해서 잠깐 설명하자면, 부모가 4 byte padding 규칙을 가지고 실제 7 바이트 멤버만 가지고 있는 경우 7 byte 보다 큰 4 의 배수 byte offset을 시작 점으로 잡는다는 의미다. 예를 들어 :

struct Size_4_Align
{
    long l;
    short s; // bool b 와 위치가 바뀌었음.

   bool b; // short s 와 위치가 바뀌었음.
};

 

struct Derived_4_Align : public Size_4_Align
{
    char c;
};

int main()
{
    std::cout << "Size_4_Align:" << sizeof(Size_4_Align) << std::endl;
    std::cout << "Derived_4_Align:" << sizeof(Derived_4_Align) << std::endl;
}

 

output :
Size_4_Align:8
Derived_4_Align:12

Derived_4_Align 구조체는 Size_4_Align을 상속 받아 1 byte(char) 짜리 변수를 추가 했다. 생각해 보면 Size_4_Align의 경우 멤버 변수 나열이 4, 2, 1 byte로 나열 되었으므로 뒤에 1 바이트가 추가 되면 8 byte로 align이 될 수도 있지 않을까 생각했지만 에누리 없이 기존 8 byte에 더하여 (그리고 최대 사이즈 멤버 변수가 4 byte이므로) 12 byte 짜리 구조체가 되었다.

 

4. The size of a structure is the smallest multiple of its alignment larger greater than or equal the offset of the end of its last member.

 

"구조체의 사이즈는 가장 마지막 멤버 변수의 offset 을 기준으로 align 되는 byte의 최소 배수이며 offset과 같거나 큰 사이즈를 가진다."

 

말이 조금 달라지긴 했지만 위 3번에서 설명 했던 byte padding align과 같은 의미다. 결국 구조체의 사이즈는 byte padding을 통해 가장 페이징 하기 좋은 사이즈로 결정 된다는 의미다.

struct Size_8_Align
{
    long long ll;
    bool b;
};

 

int main()
{
    std::cout << "Size_8_Align:" << sizeof(Size_8_Align) << std::endl;
} 

 

output :
Size_8_Align:16

결국 가장 큰 멤버 변수 사이즈(8 byte)로 align 되는 구조체는 1 byte가 더 추가 되더라도 8 byte 가 증가 하며 (align 사이즈의 배수) 실제 구조체 사이즈인 9 byte 보다는 크다는 것이다.

 

결론 :

오늘의 핵심은 구조체의 byte padding은 모든 구조체에 일괄적용 되는 것이 아니라 규칙에 따라 각각의 최적의 align 사이즈를 가지고 있다는 것이다.

 

위 코드들은 vc++ 2010과 gcc 4.4.6 버젼 위에서 테스트 해보았다(혹시나 예전 버젼 컴파일렁에서는 padding byte가 일괄 적용 된것이 아니었나 싶어 버젼을 명시한다).

외부 메모리 단편화

 - 분할된 영역이 할당될 프로그램의 크기보다 작아서 할당할 수 없어 모두 빈 공간으로 남아 있는 전체영역

일단 외부 단편화는 메모리를 할당하는 대표적인 세가지 방법인 최초적합(맨처음 찾은 알맞은 공간에 공간을 할당.),최적적합(사용 가능한 공간들중 가장 작은것을 선택) 최악적합(사용 가능한 것중 가장 큰 것을 할당)중 어느걸 하더라도 결국은 일어날 수 밖에 없습니다.

공간을 프로세스의 실행을 위해 할당해주고 프로세스가 끝나면 다시 공간을 돌려 받게 되는데 보통 컴퓨터는 되돌아온 공간 블록과 인접해 있는 블록을 합쳐서 하나의 큰 블록을 만드는 식으로 자원관리를 합니다.

하지만 워낙 빠르게 일을 처리해야 하다보니 프로세스들에게 공간 할당이 마구마구 이루어 지게 되고 중간중간에 남긴 하지만 너무나 작아 별 쓸모 없는 '잉여 공간' 들이 생기게 됩니다.

외부 단편화는 이런 잉여 공간들이 곳곳에 흩어져 있는 문제입니다. 물론 잉여 공간들을 합친다면 다시 프로세스를 충분히 실행 시킬 수 있는 정도가 되겠지만 그건 일이 활발하게 진행되고 있는 컴퓨터의 실행 중에는 불가능 합니다.

그래서 컴퓨터가 너무 과다한 사용으로 느려지게 되었을때는 재부팅을 해주시면 컴퓨터가 부팅중에 공간들을 정리하기 때문에 다시 속도가 향상됩니다.

해결방법

메모리 압축 : 분산된 빈공간 결합 -> 하나의 큰 공간으로 만듬

메모리 통합 : 단편화가 발생된 공간에서 인접해있는 다른 단편화 공간들을 하나로 통합시켜 큰 공간으로 만든다?

메모리 풀 기법

---

페이즈폴트 

---

컨텍스트 스위칭(프로세서의 상태전이에 의해 데이터가 스위칭 되는 이 작업을 컨텍스트 스위칭이라고 한다.)

실행중인 프로세서의 변경은 시스템에 많은 부하를 가져다 주기도 합니다.

cpu내에 존재하는 레지스터들은 현재 실행 중에 있는 프로세서 관련 데이터들로 채워진다고 했는데 현재 프로세스가 Ready 상태로 이전되고,

다른 프로세스가 Running 상태로 전환될때 cpu내의 데이터가 바뀌는 작업을 하기 때문에 부하가 많이 걸리는 것이죠..

이전 프로세서에 있는 자료는 메모리에 저장이 된다.

프로세서와 스레드와의 차이

프로세서는 완전히 독립적이기 때문에 메모리 영역을 다른 프로세서와 공유하지 않는다.

하지만 쓰레드는 해당 쓰레드를 위한 스택을 생성할 뿐 그 이외의 Data Code Heap은 공유를 한다.

스택을 독립적으로 할당하는 이유는

스택은 함수 호출 시 전달되는 인자, 되돌아갈 주소값 및 함수내에서 선언하는 변수등을 저장하기 위해 사용되는 메모리공간인데..

따라서 스택 메모리 공간이 독립적이라는것은 독립적인 함수 호출이 가능하다는 것이고, 이는 독립적인 실행 흐름이 추가되는 것이다.

결국 실행흐름의 추가를 위한 최소조건이 독립된 스택을 제공하는것..

쓰레드가 그나마 프로세서보다 컨텍스트 스위칭이 빠른 이유는 메모리 영역을 공유하기 때문이다. 

sp(stack point) fp(frame point) pc(program counter) 

pc 실행해야 할 명령어의 위치를 가리키는 레지스터

쓰레드별로 main함수를 독립적으로 가지고 있고 함수 호출도 독립적으로 진행되기 때문에 쓰레드별로 현재 pc값은 달라야 한다. pc는 공유되지않음

쓰레드는 독립적인 스택을 가지기 때문에 스택의 정보를 담고 있는 sp와 fp는 공유되지 않는다.

캐시 메모리 :  cpu가 메모리에 저장된 데이터를 요규할때 메인 메모리를 통하지 않고 바로 전달함..

프로세스 사이에서 공유하는 메모리가 하나도 없기 때문에 컨텍스트 스위칭이 발생하면 캐쉬에 있는 모든 데이터를 모두 리셋 하고 다시 불러옴.

근데 쓰레드는 메모리를 공유하기 때문에 비울 필요가 없다. 여기서 속도차이가 발생하는것이다.

**windows에서의 프로세서와 쓰레드 windows에서는 그냥 담는 상자에 불가하다(프로세스 상자에 쓰레드가 담겨있다)

프로세서는 상태를 지니지 않음 running ready blocked 상태를 지닌것은 스레드임..

스케쥴러가 실행의 단위로 선택하는 것도 프로세스가 아닌 스레드이다.

프로세스 컨택스팅 스위칭 역시 실제로 오버헤드가 발생하는 부분은 서로  다른 프로세스에 포함된 스레드간의 컨텍스트 스위칭시 발생하는거임..

---

스택과 힙에 대한 설명

스택

 - 자료구조 관점 : LIFO

 - 스택은 고정사이즈 스택 언더 오버플로우가 발생할 수 있다.

 - 지역변수와 매개변수가 저장된 곳. 함수호출이 완료되면 사라진다. 컴파일 타임 크기 결정

 - 시스템 스택데이터의 크기 == 프로그램 레지스터의 크기(32비트의 경우 스택 데이터의 기본 크기는 32비트)

 - 스택이 늘어날수록 메모리 주소 값은 반대로 작아지도록 되어있다.

1) 스택이 항상 커널의 반대 방향으로 자라기 때문에 영원히 커널을 만나지 않게 된다. 아무리 스택이 커져도 커널을 건들 수 없다

2) 힙과 관련있는데 스택영역과 힙 영역이 공유 라이브러리 영역을 가운데 두고 마주보는 형태이다.

힙

 - 동적 메모리 할당을 곳, 런 타임 크기 결정

---

함수 호출규약 

stdcall : 윈도우즈 API 함수들의 기본 호출 규약이다.

인수 전달은 둘다 오른쪽 먼저이지만 인수전달에 사용된 스택을 정리하는 주체는 호출원이 아니라 함수다.

cdecl

두 차이는 스택 정리 주체가 누구냐는 건데. 이 차이점이 미치는 영향은 별로 없다.

꼭 봐야겠다면 stcall이 조금 더 작다 왜냐면. 스택을 정리하는 코드는 함수 끝에 접미에 딱 한번 작성되기 때문에

반면 _cdcel은 호출원이 스택을 정리하므로 호출할 때 마다 정리 코ㅡㄷ가 반복되어 크기가 조금 더 커진다.

두 차이는?

또 다른 중요한 차이점은 가변 인수 함수를 만들 수 있는가 아닌가 하는 점이다. __stdcall은 함수가 직접 스택을 정리하기 때문에 가변 인수 함수를 지원하지 않는다. 함수 접미에 스택 정리 코드를 작성하려면 인수의 총 크기를 미리 알아야 하는데 가변 인수 함수는 전달되는 인수 개수가 가변이므로 이 크기가 고정적이지 않아 접미에서 스택을 직접 정리할 수 없다. 컴파일러가 접미의 ret n 명령에 대해 n을 결정할 수 없는 것이다.

이에 비해 __cdecl은 함수가 스택을 정리할 책임이 없으며 호출원이 함수를 부를 때마다 스택을 정리한다. 함수를 호출하는 쪽에서는 인수를 몇개나 전달했는지 알 수 있으므로 실제 전달한 인수 크기만큼 스택을 정리할 수 있다. 그래서 printf나 scanf같은 가변 인수를 지원하는 함수는 모두 __cdecl 호출 규약을 사용한다. 또한 윈도우즈 API 함수의 기본 호출 규약은 __stdcall이지만 wsprintf는 예외적으로 __cdecl로 작성되어 있다.

호출 규약 중 호출원이 스택을 정리하는 것은 __cdecl밖에 없으며 그래서 가변 인수를 지원할 수 있는 호출 규약도 __cdecl이 유일하다. 가변 인수 함수를 만들려면 반드시 __cdecl 호출 규약을 사용해야 한다. 만약 가변 인수 함수를 __stdcall로 작성하면 컴파일러는 이를 무시하고 __cdecl로 강제로 바꾸어 버린다.

조금 더 커진다.

---

디버깅방법 브레이크 포인트 말고도 어셈블리로..

__asm { int 3 }

소스코드의 원하는 위치에 위와 같이 인터럽트를 발생시키는 어셈블리 코드를 넣고 다시 빌드 후 실행한다

그리고 알림창이 뜨면 [중단]을 선택한다.

---

STl vector에서 at과 []접근 차이

at는 size를 체크해서 속도가 느리긴 하지만 안정성이 높고 (왜냐면 잘못된 접근 시 에러 발생)

[]는 속도는 빠르나 잘못된 접근이 될 수도 있다.

vector에 객체를 담는것과 포인터를 담는 차이는 : 복사생성자가 발생하느냐 안하느냐, 메모리 해제를 해줘야하느냐 마느냐 문제

vector에 용량이 가득 찼다면

새로운 공간을 할당하고 새로운 공간에 값을 복사한다. 그래서 미리 공간을 크게 할당하면 재할당이 안일어나긴 한데..

그래서 공간할당시에는 reserve를 사용한다. 약 1.5 ~ 2배 공간을 늘리게 된다.

vector와 일반 배열의 메모리 구조 차이?

없는것같다..아니 이건 내용을 못찾음..둘다 선형적인데......뭐..그냐 일반적인 상황 말고는..

맵의 

이진탐색트리기반

균형이진트리 (레드-블랙 트리 : 작은값이 부모 , 왼쪽은 그다음큰값, 오른쪽은 가장 큰 값)

key와 value가 pair로 구성

장점	단점
많은양의 자료에 유리 검색속도 빠름 key와 value 따로 저장 자동정렬	적은양엔 오버헤드로인해 손해

맵과 해쉬맵의 차이

STL 컨테이너 중 map은 말씀하신 대로 바이너리 서치 트리를 이용합니다.

(일반 binary tree가 아니라, binary search tree 입니다) 구현된 STL제품은 대부분 red-black트리를 이용하고 있습니다.

BST는 평균 탐색 시간이 O(log n)이 되는데, 이는 대부분의 경우 납득할 만한 성능을 보여주지만, 평균 탐색시간을 O(1), 즉 상수시간 안에 탐색을 해내고 싶을 때는 해쉬 테이블을 사용하게 되

공식 컨테이너에 들어가지 못한 이유는 바로 탐색 성능이 안정적이지 못해서 입니다.

ash Map의 경우 Hashing Key를 이용해 데이터에 접근하는데 이 Hashing Key를 생성하는 방법은 여러가지입니다.

 - 예를 들면, 구성하는 모든 자료를 각각의 바이트 별로 더하거나, 자릿수에 가중치를 두는 방법도 생각해 볼 수 있습니다.

 - 이렇게 생성된 키를 이용해 배열의 인덱스로 사용하고 접근하기 때문에 접근 속도가 O(1)이 되는 것입니다.

하지만, Hashing Key가 겹쳐서 충돌이 일어나게 된다면 빈 영역을 찾아서 저장해야 합니다.

 - 충돌이 한번 일어난 지역에서는 계속 충돌이 일어나기 때문에 그 근처에 자료가 몰리게 됩니다.

따라서, Hash Map에서는 Hashing Key를 얼마나 잘 생성하는가에 따라 성능이 좌우됩니다.

 - Hashing Key 값이 랜덤하게 분포되어 있을 때 가장 좋은 성능을 발휘합니다.

Hash Map	Map
자료 탐색에 Hashing 사용	자료 탐색에 이진 탐색 트리 사용 (최근엔 Red-Black Tree)
탐색 속도 O(1) 이상 : Key값 분포에 따라 다름	탐색 속도 O(log n) 보장
저장된 내부 자료 정렬하지 않음	저장된 내부 자료 정렬

C++11과 부스트에선 unordered_map이라 불린다.

---

DFS 구현 방법은..

stack을 기반으로 하는데..

머지소트를 제일 빠르게 구현하는 방법??

이것도 모르겠따..

---

TCP / UDP 차이

- TCP 통신 
TCP(Transmission Control Protocol)는 인터넷에서 가장 흔하게 그리고 많이 쓰이는 프로토콜 방식이다. 그 이유는 TCP통신은 error correction이라는게 존재하는데 말 그대로 에러를 다시 잡아주는 것이다. 서버에서 클라이언트에게 어떤 정보를 보냈다고 하자! 그러면 클라이언트는 서버가 보낸 정보를 제대로 받았는지, 확인해주는 메세지를 다시 서버에게 돌려주고, 클라이언트가 제대로 받지 못했을 경우엔 resend를 서버에 요청 할 수 있다. 그러면 loss된 데이터를 다시 클라이언트에게 보낼 수 있는 것이다. 이런 방법들을 flow control이라고 하며, 오리지널 데이터를 로스 하지 않고 받을 수 있게 한다. 즉, guaranteed delivery!

 UDP 통신
UDP(User Datagram Protocol) 은 인터넷에서 또 많이 쓰이는 프로토콜인데 그 사용처는 tcp 통신과는 다르다. tcp통신과의 가장 큰 차이는 단방향 통신이라는것! 서버가 클라이언트에게 혹은 클라이언트가 서버에게! error correction이 없고, 무조건 보내는 쪽에선 던지기만 하고 받는 쪽에선 받기만 한다. 그러다가 데이터 로스가 중간에서 발생하면 어쩌냐? 무시한다. 그냥 던지고 받는거다 ! 이렇게 되면 장점은 TCP통신 보다는 훨씬 빠른 전송을 보여주게 된다. 

두 통신방법은 사용되는 곳이 다르다. 웹페이지 전송이다. 어떤 데이터 베이스를 전송할때는 반드시 TCP통신이 사용되어야 한다. 웹페이지가 전송오류로 얼빵한 화면이 떠져 있다면 사용자는 얼마나 황당하겠는가... 데이터 베이스는 물론이고
UDP통신은 비디오 오디오 신호 전송에 사용된다. 빠른 프레임으로 돌아가는 비디오 스트리밍 프로그램에 한두 프레임 로스가 생겼다고 resend를 재요청하고, 데이터 로스를 일일이 확인해서는 버퍼링 때문에 오히려 속터질것이다.  몇 프레임 정도 놓쳐도 오히려 상관없고 놓친 프레임은 과감하게 버리는 방식. 큰 파일을 스트리밍으로 내려 받을 때 적합하다. 인터넷 스트리밍 영상이나 음향들이 퀄리티가 오프라인으로 받아놓고 보는것 보다 좋지 않은 이유도 이것이다. 

---

크리티컬 섹션과 뮤텍스 차이

1. 스레드 동기화 방법

① 유저 모드 동기화
- 동기화가 진행되는 과정에서 커널의 힘을 빌리지 않고 동기화 -> 커널모드의 전환이 불필요해서 성능상의 이점이 있음
② 커널 모드 동기화
- 동기화가 진행되는 과정에서 커널의 힘을 빌려 동기화 -> 동기화에 관련된 함수 호출 때마다 커널 모드로의 변경 필요해 성능 저하
- 유저 모드에서 제공하지 못하는 기능을 제공 받음

2. 임계 영역에 대한 이해

- 두개 이상이 스레드가 동시에 접근해서는 안되는 공유 자원을 접근하는 코드의 일부
- 두개의 스레드가 동시에 임계영역에 접근할 경우 문제가 발생할 수 있으니 이를 제한

3. 스레드 동기화 기법

① 크리티컬 섹션 기반 동기화(유저 모드) : 코드상 다수의 라인을 보호해야 하는 경우
② 인터락 기반 동기화(유저 모드) : 전역으로 선언된 변수 하나의 접근 방식을 동기화 하는 경우
③ 뮤텍스 기반 동기화(커널 모드) : 누군가가 뮤텍스에 접근이 가능한 상태가 되었을때 Signaled 상태에 놓이고 접근을 하였으면 Non-Signaled 상태로 변함
④ 세마포어 기반 동기화(커널 모드) : 뮤텍스와 유사, 차이점은 카운트의 존재

 

-------------------------------------------------------------------------------------------------------------------------------------------------------

1. 크리티컬 섹션

유저 객체입니다. 커널에서 제공되는 객체가 아니라는 말입니다.

커널 객체가 아니므로 가볍고 빠릅니다.

그러나 한 프로세스 내의 쓰레드 사이에서만 동기화가 가능합니다.

보통의 경우 가볍고 쉽게 쓸 수 있는 동기화 객체입니다.

2. 뮤텍스

크리티컬 섹션과 다르게 커널 객체입니다.

그러므로 크리티컬 섹션보다 무겁습니다.

크리티컬 섹션이 한 프로세스 내의 쓰레드 사이에서만 동기화가 가능한 반면,

뮤텍스는 여러 프로세스의 스레드 사이에서 동기화가 가능합니다.

뮤텍스를 가장 흔히 사용하는 예가 프로세스 다중 실행을 막을 때입니다.

이런 기능은 크리티컬 섹션으로는 불가능합니다.

3. 세마포어

세마포어 역시 커널 객체입니다.

위의 크리티컬 섹션, 뮤텍스는 동기화 함에 있어서 동시에 하나의 쓰레드만

실행되게 합니다.

이에 반해, 세마포어는 지정된 수만큼의 쓰레드가 동시에 실행되도록 동기화하는 것이 가능합니다.

지정된 수보다 작거나, 같을 때까지 쓰레드의 실행을 허용하고,

지정된 수를 넘어서 쓰레드가 실행되려 하면 실행을 막습니다.

 

---

다형성

 : 어떤 문법이 아니라 가상함수의 호출관계에서 보인 특성을 가리켜 다형성 이라고 한다.

모습은 같은데 다르다라는 의미로 자료형이 같은 포인터가 실제 가리키는 객체가 다를 경우 호출되는 가상함수가 다른것이 예가 된다.

---

volatile 소개

volatile로 선언된 변수는 외부적인 요인으로 그 값이 언제든지 바뀔 수 있음을 뜻한다. 따라서 컴파일러는 volatile 선언된 변수에 대해서는 최적화를 수행하지 않는다. volatile 변수를 참조할 경우 레지스터에 로드된 값을 사용하지 않고 매번 메모리를 참조한다

멀티스레딩에서 사용한다는데..

---

STL remove와 erase차이

erase는 멤버함수이고 remove는 알고리즘이다.

erase는 실제 객체를 제거 remove는 그 요소를 덮어쓰움으로써 지운 것처럼 보임..

rase와 remove는 일단 erase는 하나를 지울수 있는데 STL의 데이터와 공간까지 다 지워진다. 하지만 remove의 경우 조건에 맞는 것이 모두 다 지워지는데 공간은 지워지지 않고 데이터만 지워지는 특징이 있다

erase = iterator에 해당하는 하나의 요소만을 삭제 capacity가 실제로 감소

remove = 해당 범위중에 해당값과 일치하는 모든 요소를 삭제한다. capacity가 감소하지 않음

---

소멸자에 virtual을 쓰는 이유는 다형성을 사용하여 자식 클래스가 부모 클래스로 형변환되어 삭제를 한 경우

virtual소멸자를 선언안하면 vtable이 참조하지 않고 부모의 소멸자만 소멸

---

쿼터니언 사용하는 경우

회전각에 대한 보간 = 구면보간이 필요한 경우 행렬보다 계산이 빠르고 간단

회전 행렬에 의해서 두 축의 회전값이 겹칠때 발생하는 짐벌락 문제 해결

[출처] erase와 remove의 차이|작성자 헬랍

---

RTTI run time type information

Run-Time Type Infomation 또는 Run-Time Type Identification 이라고도 합니다. 한글로 풀이하자면 "실시간 형식 정보" 라고 할수 있겠죠. 그럼 이게 무엇에 쓰는 물건인가? 라고 하면, 일단 다형성에 대해 알아야 할 것 입니다. C++에서는 대표적인 특징 중 하나로 다형성이라는 것이 있습니다. 부모 객체의 포인터로 자식 객체를 가리킬수 있는 것이죠. 간단하게 코드로 봐보자면 밑에와 같습니다.

dynamic_cast 와 강제 c언어 스타일의 캐스팅 비교

---

통신 프로토콜은 서비스 혹은 기능 수행을 위해서 클라이언트와 서버간에 교환하는 데이터의 종류와 표현 방식, 절차, 행위에 대한 규약.

대표적인 프로토콜은 tcp / ip가 있다.

이 tcp / ip계층에 적용 확장된 프로토콜에는 전자우편을위한 SMTP

파일전송을 위한 FTP 웹서비스를 위한 HTTP 등이 있다.

HTTP는 WWW상에서 정보를 주고 받을 수 있는 프로토콜이다. tcp / UDP를 사용하고 80번 포트를 사용한다.

소켓통신은 네트워크를 통한 서로 다른 컴퓨터에 수행되는 프로세스간의 토신 채널.. 

소켓 통신 종류에는 TCP UDP가 있다.