나의 지식 보관소

이벤트는 대리자를 event 한정자로 수식해서 만드는 것으로써 대리자와 큰차이가 나지않는다. 따라서 다른점을 알아볼것이다. 이벤트와 대리자의 가장 큰 차이는 이벤트는 외부에서 직접 사용할 수 없다는 점이다. 이벤트는 public으로 선언 되어있더라도 자신이 선언되어있는 클래스 외부에서는 호출할 수 없다.

대리자는 메서드에 대한 참조이다. 즉 대리자에 메서드의 주소를 할당한 후 호출하면 이 대리자가 메서드를 호출하여 준다. 대리자는 다음과 같이 delegate 키워드를 이용해서 선언한다. 1 한정자 delegate 반환형식 대리자이름 ( 매개변수목록 ) 단, 대리자는 참조할 메서드의 매개변수와 반환형식이 같아야한다. 제네릭 대리자 1 delegate int Compare(T a, T b); 다음과 같이 선언한다. 대리자 체인 대리자는 하나의 메서드 뿐만 아니라 여러 메서드를 동시에 참조할 수 있다. 메서드를 대리자에 += 연산자를 통해 결합할 수 있다. 1 2 3 delegate1 += method1 delegate1 += method2 delegate1 += method3 대리자에서 메서드를 끊어 낼때에..

프로세스: 실행 파일이 실행되어 메모리에 적재된 인스턴스, 하나 이상의 스레드로 구성된다. 스레드: 운영체제가 CPU시간을 할당하는 기본 단위. 여러개가 있으면 멀티스레드로 불린다. 멀티스레드의 장점: 1. 사용자 대화형 프로그램에서 응답률을 높힐 수 있다. 2. 멀티프로세스에 비해 자원 공유가 쉽다. 3. 경제성이 높다. 멀티스레드의 단점: 1. 멀티스레드 프로그램의 구현이 어렵다. 2. 자식스레드에 문제가 생기면 전체 프로세스가 영향을 받는다. 3. 스레드가 너무 많이 사용되면 성능이 저하된다. 스레드 시작하기 .NET 프레임워크는 스레드를 나타내는 클래스로 System.Threading.Thread를 제공하므로 이것을 사용하면 된다. 1 2 3 4 5 Thread t1 = new Thread(new..

리모트 레퍼런스는 브랜치 태그 등을 포함한 리모트 리포지토리의 레퍼런스(포인터)이다. $ git ls-remote 명령을 사용해서 리모트 레퍼런스의 목록을 얻을 수 있다. $ git remote show 명령은 리모트 브랜치들의 정보를 얻을 수 있다. 하지만 보통은 remote-tracking branch를 사용한다. Remote-tracking branch Remote-tracking branch는 리모트 브랜치들의 상태를 참조하는 브랜치이다. Remote-tracking branch는 움직일 수 없고 Git이 자동으로 움직여준다. 리모트 저장소에 마지막으로 연결했을 때 브랜치가 어떤 커밋을 가리키고 있었는지 나타내는 북마크라고 생각하면 된다. Remote-tracking branch는 / 의 이름 형..

Git에서 barnch 관련 명령은 생성과 삭제외에도 더 많은 일을 한다. 인자 없이 $ git branch 명령을 실행하면 간단한 브랜치 목록을 보여준다. 그중 * 문자로 수식되어있는 브랜치는 현재 체크아웃되어있는 브랜치임을 나타낸다. $ git branch -v 를 사용하면 각 브랜치의 마지막 커밋을 볼 수 있다. 다른 유용한 옵션으로는 --merged와 --no-merged 가 있는데 이 옵션들은 현재 사용중인 브랜치를 기준으로 머지를 했는지 안했는지 필터링해준다. 이미 머지된 브랜치를 보고 싶으면 $ git barnch --merged를 사용하면 된다. 이 명령 실행이후 *이 붙어있지 않은 브랜치는 이미 다른 브랜치와 merge 했기 때문에 $ git branch -d 로 삭제해도 되는 브랜치다...

Git 충돌 발생 3-way merge가 실패하는 경우 즉, 병합하는 두 브랜치에서 같은 파일의 같은 부분이 동시에 수정이 일어났을 때 병합을 시도하면 Git은 해당 부분을 병합하지 못하고 충돌을 발생시킨다. 이러한 충돌이 발생하면 개발자가 대신 해결할 때까지 병합할 수 없다. 자 그럼 이제 연습을 위해 일부러 충돌을 일으켜보자. 여기서 사용되는 브랜치와 파일 내용은 아래와 같고, branchA와 branchB를 병합할 것 이다. 브랜치 텍스트 파일 내용 master aaa bbb ccc branchA aaa 111 ccc branchB aaa 222 ccc branchA와 branchB모두 master브랜치를 기반으로 두고 있고, 두 브랜치 모두 두 번째줄을 수정했으니, 두번째 줄에서 충돌이 일어날 것..

예시 기반 커밋 커밋1 커밋2 머지 커밋 A A B B B B C Ca Cb 충돌 발생 D D 위 표는 커밋1과 커밋2를 병합하려고 하는데, 두 커밋의 공통된 기반 커밋을 참고하여 어떤 것을 머지 커밋에 채택할지 결정하고 있다. 이런 방식을 3-way merge라고 부른다. 위 표를 보면 기반 커밋이 A파일을 가지고 있고, 커밋1 또한 A파일을 가지고 있는데 커밋2는 A파일을 가지고 있지 않다. 이 말은 즉슨 커밋1에서는 A파일에 대한 수정이 일어나지 않았지만 커밋2에서는 A파일을 삭제했다는 뜻이 되므로 두 커밋을 병합할 때 우선시해야 할 수정사항은 A파일의 삭제가 된다. 두 번째로 기반 커밋과 커밋1, 커밋2 모두 B파일을 가지고 있고 이는 아무런 변화도 일어나지 않음을 뜻하므로 병합할 때 또한 B파일..

Fast Forward 병합 먼저 다음과 같은 프로젝트가 있다고 가정해보자. 이 프로젝트에서 발생한 이슈를 해결하기 위해, 이 이슈에 집중할 수 있는 브랜치를 새로 만든다. 브랜치를 만들면서 checkout 까지 한 번에 하려면 $ git checkout 명령에 -b 옵션을 추가하면 된다. 따라서 $ git checkout -b issue 명령을 실행하면 아래와 같은 상태가 된다. 또한 issue 브랜치로 checkout 했기 때문에 HEAD는 issue브랜치를 가리키는 상태이다. 그러므로 뭔가 작업을 하고 커밋을 하면 issue 브랜치가 앞으로 나아간다. 만일 이상태에서 중요한 문제가 발생해서 현재 작업을 중단하고 즉시 문제를 해결해야 할 상태가 되면, 다른 복잡한 과정 없이 master 브랜치로 돌아..