10/15(복습)

강kang·2024년 10월 15일

순수가상함수
함수의 실체가 없다.
구현을 하지않는다.
선언만하겠다고 알려주는 형태로 오른쪽에 =0;을 적는다.
구현이 없는 상태로 선언.
순수가상함수 자체는 본문에 없지만 순수 가상 함수를 만들어 놓으면 자식클래스에서 그것을 오버라이딩하는 동시에 원하는 본문을 채워넣어 자식 클래스에서 사용할 수 있다.

추상 클래스
순수 가상 함수가 하나라도 있는 클래스, 추상 클래스를 가지고 있는 인스턴스(객체)를 만들 수 없기 때문이다.
추상클래스의 객체를 생성하지 못하고 상속하는 용도로만 사용한다.
자식클래스에서 추상클래스를 상속받으면 강제사항이 생기는데 부모 순수가상함수를 꼭재구현해야한다.
가상함수를 재구현하는 것은 자식 클래스에서 옵션이다. 다른 동작을 시킬려고 재구현을 할 수 있지만, 순수가상함수는 구현이 빠져있기 때문에 재구현을 해야한다.

상속 관계에서의 형변환
업캐스팅 자식클래스 타입에 대한 참조(포인터* 또는 레퍼런스&)를 부모타입에 대한 것으로 형변환하는 것을 말합니다.

base *b = new Derived;

모든 업캐스팅은 묵시적으로 일어날 수 있다.

형변환
이때까지 수치데이터형으로 다뤘는데 상속관계에 있는 클래스간에 상속관계에 대해서
이야기
형변환은 항상 형변환의 대상이 되는 소스, 값은 변경되지 않는다.
형변환은 새로운 다른 값을 만들어내는 것이다.
부모 자식간에 있는 클래스들간에서 서로서로 형변환이 가능하다.
객체가 변경되는 것이 아니다.
형변환은 새로운 애를 가르쳐주는 것이다.
포인터 또는 레퍼런스는 정보를 저장하는 데이터 주소값이라던가, 동일하게 주소값이지만 결국엔 형변환하는 애기는, 어떤 값이 있는데 고부분을 바꾸는게 형변환인 것이다, 주소값의 주소값 포인턴는 무조건 주소값이다.

배열은 시작주소

부모클래스의 래퍼런스(&)로 자식클래스를 들어갈 수 있다.

메모리의 사이즈와 규칙
포인터는 간접참조이다. (역참조 연산자 포인터 앞에 붙으면)

우리가 이때까지 알던 형변환은 소괄호 안에 하는 것, 원시형변환인데 거의 제약이 없다. 제한이 없는 것을 쓰는 것은 위험하다.

형변환 연산자에는 4개가 있다. 이것을 위주로 쓰는것으로 하자.
암시적 형변환은 딱히 부작용이 없을 때 허용해준다.
자식클래스가 부모클래스로 할 때 부작용이 없다.

업캐스팅
부모를 형변환, 부작용 없음, 상속관계레퍼런스끼리
다운캐스팅
부모-자식 자식을 형변환, 위험한 형변환이다.

형변환의 종류에는 static_cast<변환하고싶은 데이터>(형변환할 소스 원본);
static dynamic 정적이랑 동적
정적 컴파일은 static
런타임 동적은 dynamic

static 형변환 컴파일할 때 정해진다. 예외가 발생하는 것 프로그램이 죽음 형변환을 하는데 커마일 타이밍에 정해져있는대로 형변환을 시도하고, 잘못된 경우 예외발생 죽음, 일반적으로 사용하고 있던 수치데이터간의 형변환은 static
정적타이밍에 정해지는 것
상속관계에서 업캐스팅 다운캐스팅 사용은 가능
다운캐스팅은 사용하는 것이 아니다.
컴파일 에러는 나진 않지만 진짜 동작이 보장되어있는 경우나 사용하는 거다.
기본데이터형 타입변환
업캐스팅같은 경우 static으로 해라

일반적으로는 dynamic 캐스팅을 사용한다 생각하면 된다.
다운캐스팅은 명시적형변환만 가능
static은 컴파일타이밍으 형변환 타이밍에 고정하는 것이다.

dynamic 캐스팅
dynamic_cast<변환하고싶은 데이터>(형변환할 소스 원본);
형변환을 하는게 컴파일 타이밍에 정하지 않는거다. 형변환이 가능한지 아닌지를 직접 해보는거다. 가능한 경우는 정상적인게 안되면 null포인터를 준다.
비용이 덜든다.
실행중에 제대로된 형변환인지 거친다.
예외가 발생하지 않고 null체크로 필터링할 수 있다.
다운캐스팅은 dynamic캐스팅으로 기본을 해라, null체크를 기본으로 하는 걸 해라. 기본으로 세트다.

거꾸로 업케스팅은 안전하므로 할 필요가 없다.
dynamic은 캐스팅은 자식클래스에만 있는 걸 쓸 때 사용할 수 있다.

가상함수에 overried적기

형변환하는 케이스만 알면 된다.
static캐스트 업캐스팅
dynamic캐스트 다운캐스팅

상수를 함수로 호출하는 경우는 const_cast 쓰지마
붙이는거는 부담가지지말고 때는거는 부담가져라

정수를 포인터형으로 한다거나 제약사항이 없고 그만만큼 불안정하다.

다운캐스팅과 업캐스팅이 불안정한 이유

  • 업캐스팅은 괜찮지않나? 다운캐스팅이 불안정하고 dynamic캐스트를 사용해야하는 것이고 업캐스팅은 안전하기에 정적인 static을 사용하는거고

다중상속 부모스트럭트가 2개, 다중상속은 편한점은 있지만 단점도 있다.
이유는 다이아몬드형 상속으로 생각하면 된다.

다중상속은 보통 멤버변수 추가하지 않고 왠만하면 멤버변수를 추가하지 않은 상태에서 쓰는게 낫다.

c#은 다중상속을 허용하지 않는다. 순수가상함수만 허락하는 그런 것은 있다.
다중상속이 필요하다하면은 멤버변수는 제끼고 추상함수만 만든 다음에 실행한다.

템플릿은 필수다
STL라이브러리가 탬플릿으로 만들어졌다.
프로그래밍은 항상 재사용 유지보수 편하게 설계해야하는데 재사용하는데 많은 도움을 준다.
중요한 것 중에 하나가 최적한 탬플릿은 컨파일타임에 돌아가는 걸 만든다. 그때 결정이 되는 것이다. 그때 결정이 되는 것 실행중에 연산이 되는게 아니라 사용한는 형태가 되는 것 이래저래 자유롭게 사용할 수 있는 것이다. 좋은 것이다.

매개변수랑 반환형 원래 함수 만들 때 함수탬플릿은 꺽쇠로 데이터타입을 하나 더 넘겨줌으로서 탬플릿 인자, 함수 탬플릿이라고 부른다. 매개변수는 소괄호안에다가 넣는 것처럼 탬플릿인자 꺽쇠안에다가 쓰는 형태.
탬플릿인자로 TIMENAME(키워드)을 하나 쓰겠다. 애는 자체로는 함수가 아니다. 코드조각이다. 탬플릿 코드들은 컴파일타임에 돌아가는 코드들 댐플릿 함수를 만든다.
다 헤더에다가 탬플릿은 넣어줘야한다.
선언부와 구현부를 구분하는게 불가능하다. 헤더에 전부다 넣어주는 거다.
풀버전에 탬플릿 코드가 있어야지 실행할 수 있어서 헤더에다 넣어야된다.

탬플릿클래스
인자를 정해주면서 시작 밑에오는게 클래스인거고 탬플릿인자들 사용하는걸 봐보자
사용할려면 탬플릿 인자를 넣어서 만들어준다<> 꺽쇠넣어서 새로운 클래스를 하나 만드는거야 만든 다음에 사용할 수 있게 만드는거고 상속관계와는 다른 것이다.
동일한 멤버들을 사용한다.
INT버전 DOUBLE버전 탬플릿 코드는 무조건 헤더에 넣는다. 헤더에서 다른 CPP코드를 인클루드하는 상태로 구분할 수 있다.
한번만들어진 것은 그 것을 계속 사용

탬플릿 특수화
탬플릿을 함수든 클래스든 만드는 이유는 만들려고 그런데 탬플릿 특수화는 인자를 어떤 특정한 데이터 타입이 들어오면 이것은 다르게 만든다는 뜻, 약속된 버전이 기본 특수화를 하려면 비 특수화가 하나 있어야 할 수 있다.

프로그램흐름에 영향을 미치는 것: 예외처리구문
예외처리를 하기전에 예외사항은 정의를 일단 해야한다.
뭘 예외라고 부르는지 NULL포인터에 대고 넘버접근연산자를 쓴다. 실제로 참조하고 있는 연산자가 없는데 어떻게 동작할지 판단할 수 없다. 수학에서 정수 0으로 나누는 건 안된다. 나누는 수가 0이야 어떤 값을 리턴할지 알 수 없다. 프로그래밍 돌 때 예외사항이 돌아가면 어떤 사항이 일어나고 프로그램 정상적으로 돌아가게 만들거나 기타 등등할 수 있는지에 대한 이야기가 예외처리다.

예외하면 트라이 캐치 쓰로우 이 3개가 생각이 나야한다.
쓰로우는 리턴이랑 비슷하다. 반환할 값을 적어주거나 안적어주거나 하면은 함수가 딱 종료 쓰로우문을 만나면 함수가 그녕 중지된다. 약속되어있는 값을 리턴하는게 아니라 예외를 리턴해 특정 데이터 값중에 하나인 거다.
트라이랑 캐치는 이프문이랑 비슷해보여 트라이구문은 트라이로 시작해서 중괄호 열고닫고요 안에다가 코드들을 집어넣는다. 캐치구문은 엘즈문처럼 혼자서 못온다. 항상 트라이에 쌍으로 와야한다. 캐치문이 하나의 트라이에 여러개가 붙을 수 있다.
모양은 이러하다.
각각의 구문들이 프로그램 흐름에 어떤 영향을 미치는지 생각해보면 위에서 아래로 한줄씩 프로그램이 흘러가는 것이다. 트라이 안에 식이 있으면서 함수호출 등등 트라이안에서 예외가 발생한다면 프로그램흐름은 어디로 나오면 이런 경우는 예외사항이라 정의해서 쓰로우가 예외를 발생시킨다. 이미 만들어진 기능중에서 여기에서 쓰로우를 발생하게 해놓은게 있다. 그러면 다른 예외가 전달되는 것이고, 이런 케이스는 예외로 삼자발생시키는 것 쓰로우는 프로그래머가 예외사항을 발생시키는 것이다. 트라이 구문안에서 쓰로우가하면 캐치구문들보면 소괄호안에 데이터형변수를 안에 넣어준다. 쓰로우하는 애랑 똑같은 데이터형인자가 있다면 캐치블록 실행 전체 트라이 구문이 종료

예외처리는 억지로 쓰면안된다. 트라이 캐치구문은 사실 아까전에 본건 IF문으로 조절할 수 있다. 함수 매개변수의 값을 전달할 때 검증을 하든 IF문으로 충분히 할 수 있다. 그런거까지한다면 코드 복잡성이 높아지고 가독성이 안좋아진다. 불가피할 때만 하는 것이다. 무조건해야할 때는 파일을 읽을 때 파일을 쓸 떄 네트워크에 연결되어서 네트워크에 연결을 받을 떄 이러면 진행을 할 수가 없는 상황이니 그런 경우에만 사용하고, IF문이나 값을 검증하는 형태로 할 수 있다면 IF문으로 쓰는 것이 좋다.
파일다룰 때 예외처리를 쓴다.

포인터 주소값 심지어 다른 포인터의 주소값 주로 값에 연관된 거를 주로 했는데 함수도 메모리에 올라가는거니까 함수도 함수에 포인터가 있다. 포인터니까 주소값이 들어가야되는데 시작주소값이라고 생각하면된다. 포인터는 메모리주소이기 때문에 함수의 매개변수로 넘겨보내줄 수 있다. 함수도 주소를 저장하려면 데이터형을 정해야 한다. 문법이 있겠다. 그거는 약속되어있기 때문에 외우거나 참고해가면서 만들 수 있으면 된다.

함수포인터형의 매개변수를 약속되어있기 떄문에 판검사할 수 있다. 소괄호에 함수호출하는거랑 같은거다. 함수포인터는 반환형을 못쓴다.
함수객체를 만드는게 참조하는 방법 중 하나이다.

스마트포인터
참조할 때 마다 더하기빼기해서 참조하는 애가 없어지면 자동으로 지워줌
3종이 있다. 유니크 쉐어드 위크
유니크는 제약이 가장 많은 포인터다. 마이스트링에서 캐릭터포인터형으로 동적할당받아서 관리하는 형태로 포안터를 사용할꺼면 유니크로 사용하면 된다.
스마트포인터를 딜리트를 안해도 됨.
참조카운팅에 기반해서 삭제해준다.
쉐어드는 극복이 안되는 단점이 있다. 서로를 참조하면 참조카운터가 1이 안된다.

GIT
모든 저장공간이라고 한다.
모든 버전들이 브렌치들이 전부다 들어있는 것 히스토리를 다 알 수 있다.
그런애를 저장소 레파지토리라고 부른다.
저장소를 만들거나 복사해오거나 하는 걸로 저장소를 만드는 영역은 저장소를 생성할 수 있다.
이미 전제하는 거를 클론이 복제한다.
GIT은 전부 다 로컬에 저장되어 있기 떄문에 여기 저장소를 복사해야한다.(집에서 하려면)
로컬에서 저장소를 복사할 수 있고 원격에서 저장할 수 있고 옵션이 있다. 작업 디렉토리라는 용어 워키디아이얼 스테이지 인덱스라고 불리는 거 동의어다. 소스트리에선스테이지라고 나올거다 스테이지 에어리아 커밋해드라는게 있는데 항상 내가 저장소에서 작업을 할 때는 브렌치라는게 선택되어 있고, 브렌치에 포함되어 있는 커밋에 포함되어있는 상태인거다. 항상 커밋이 개별적인 버전이라고 생각하면 된다. 저장소에 작업하고 있다는 애기는 커밋은 개별적인 버전이라고 생각하면된다. 저장소에 작업하고 있다는 애기는 커밋은 개별적인 버전이라 생각해라 푸쉬랑 풀이 있다. 커밋까지는 로컬 저장소에서 알어나는 일 푸쉬는 깃은 모든 저장소가 모든 작업장안에 클론하는 형태로 되어있어 통째로 같은 상태로 되어있는 상태라고 작업하는 거를 보내는 거를 푸쉬, 로컬을 나의 저장소와 일치시키는 것을 풀, 브렌치 처음에는 브렌치가 하나인 상태로 시작, 하나의 커밋이 하나의 버전을 하는 버전이 있지만, 여러 집합이 하나를 하나로 하는 경우도 있다. 커밋의 기준이 있어야한다. 브렌치는 커밋들이 쌓여가는 경로를 말한다 머지는 두 개의 경로를 합치는 것 로컬의 커밋을 수정할 수 있다.
디벨러프 프렌치를 프로젝트 끝까지 존재하는 거다. 개발버전의 최신버전이 유지되는 것, 저장소를 만든 다음, 초기 커밋을 올리고 디벨러프프렌치를 만든다. 주간빌드 버저만 메인버전에 올린다 생각하고 작업하면 된다. 큰 작업을 할 때는 작업별로 브렌치를 따로 만들게 된다. 릴리즈브렌치는 오류를 잡는거라 생각하면된다. 핫픽스는 라이브를 하다가 빨리 수정해야되는 것이 있을 떄

profile
코딩

0개의 댓글