記 可 爲 學

C++17부터 옵셔널 라이브러리가 추가되었다.

이 옵셔널 타입은 원래 함수형 언어에서 나온 개념인데, 개념적으로는 모나드라고 부른다.

예외처리 방법 중 하나며, 안전성이 높아서 명령형 언어들에서도 채용을 많이 하는 편이다.

C#의 Nullable이 그렇고, Swift의 옵셔널, 코틀린의 ??, 러스트의 Result 등이 있다.

단어 자체의 뜻을 보면 '선택적인'이라는 뜻인데. 값이 선택적으로 있을수도 없을수도 있다는 뜻이다.

좀 다르긴 하지만 포인터 타입도 이런 면에서 옵셔널의 특성을 가진다고 할 수도 있다. 

널 포인터를 가지면 값이 없는 것이고 뭐라도 갖고있으면 주소가 있는거니까 값이 있는 것이다.

옵셔널은 이러한 특성을 포인터뿐만 아니라 모든 타입에 적용시킬 수가 있다.

게다가 값이 들어있는지 아닌지 명시적으로 확인을 하게 해서 포인터에 비하면 아주 안전하다.

그대신 귀찮은 면이 있긴 하지만 어느정도 감수할만한 부분이라 생각된다.

옵셔널로 선언된 객체는 그 자체로는 사용할 수 없다.

값이 들어있는 상태인지 아닌지 모르기 때문이다.

옵셔널의 값을 사용하려면 value 메서드를 쓰면 된다. 

다만 값이 없을 때 쓰면 예외가 뜨니까 has_value나 operator bool로 값 여부를 체크하고 사용해야 한다.

"John"이라는 값이 멀쩡히 들어있으니 아주 잘 수행된다. 

값이 없으니 "??"가 나온다.

포인터에서 빈 주소를 표현하는 용도로 nullptr가 예약된것처럼

빈 옵셔널을 표현하는 객체로 nullopt가 있다.

근데 값을 사용할때마다 조건문을 달아주는건 꽤 귀찮은 작업이다.

위에서 했던건 value_or 메서드 하나로 퉁칠 수 있다.

이건 값이 들어있으면 값 그냥 반환하고, 값이 없으면 인자로 받은걸 반환한다.

variant는 진화된 공용체다.

기존의 union은 문제가 많았다.

예를 들어 기존의 union을 쓸 때, 

double 버전으로 값을 넣고 int 버전으로 사용을 한다 해도 아무런 문제 없이 작동이 된다.

하지만 출력값을 보면 알겠지만 값이 정상적이지 않다.

C의 공용체는 아무런 타입 검사를 수행하지 않는다. 이 때문에 C의 공용체는 타입-safe하지 못하다고 한다.

아무튼 저런 맛이 간 출력값이 나온 이유는 아무런 조치 없이 메모리에 존재하는 비트값을 그대로 읽어왔기 때문이다. 정수 타입과 실수 타입의 메모리 구조는 완전히 다르다. 게다가 엔디언과 바이트 크기까지 고려하면 같은 계열의 타입이라도 괴리가 발생할 수가 있다.

물론 이런걸 이용해서 편법적으로 사용할 수도 있지만, 

실제로 이런 식의 접근은, 99% 사용자의 실수에서 발생한다. 그리고 실수는 결함으로 이어진다.

union은 이처럼 안전성에 문제가 많다.

게다가 기존의 union은 생성자/소멸자/가상메서드가 없는 이른바 POD 타입만을 멤버로 둘 수가 있다는 심각한 기능적 결함이 있었다.

다시말해 C++스타일의 타입은 제대로 담아둘수 없었다는 것이다.

C++17에서는 이런 문제들을 해결한 variant라는 멋진 녀석을 내놓았다.

variant는 타입-safe한 공용체 템플릿이다.

당연히 C++ 스타일의 클래스도 멤버로 둘 수 있다.

기존의 공용체와 다른 특징으로, 이녀석은 반드시 초기화를 해야만 접근 타입을 바꿀 수가 있다.

해당 타입으로의 초기화를 수행하지 않고 접근을 한다면 예외가 발생한다.

아마 이런 방식을 통해서 타입체킹도 엄격하게 하고 생성자/소멸자도 써먹을 수 있게 한 것 같다.

일단 아래 코드는 아주 정상적으로 작동하는 코드다.

int 타입으로 값 대입 한번 해주고, 접근해서 출력하고.

double로 초기화해주고, 접근해서 출력한다.

하지만 초기화를 수행하지 않으면 이렇게 예외가 나온다.

이렇게

그리고 애초에 없는 타입이나 인덱스는 당연히 컴파일부터가 안 된다.

암튼 그렇다.

자세한 건 레퍼런스를 참조

https://en.cppreference.com/w/cpp/utility/variant

oop 흉내.

C의 한계로, 메서드마다 첫번째 인자로 객체 자신의 주소를 보내줘야 함.

https://github.com/myyrakle/c-oop-string/blob/master/main.c

Q: When you allocate memory on the heap, the only limit is free RAM (or virtual memory). 
힙에 메모리를 할당할 때는 램이나 가상메모리의 크기 내에서는 자유롭게 사이즈를 줄 수 있죠.

It makes Gb of memory.
그래서 보통 기가바이트 단위도 쓸 수가 있어요.

일단 이건 비주얼 스튜디오에서만 해당되는 문제입니다.

입력을 받는 간단한 프로그램을 하나 짜보도록 하죠.

VS에서는 이렇게 문법적으로 아무런 문제도 없는 코드를 짜도, 문제가 발생할 수 있습니다.

초심자들이 한번씩은 걸려드는 함정이죠.

자 오류가 떴습니다. 근데 대체 뭐라고 하는걸까요?

scanf 함수는 안전하지 않으니까 scanf_s를 쓰라고 하는 겁니다.

근데 그건 니들 생각이고, 나는 그걸 쓰고싶지 않아요. 

1.define(안됐는데 알고보니 됨)

어쨌든 scanf를 쓰고싶으면 _CRT_SECURE_NO_WARNINGS라는 매크로를 정의하라고 하는데요. 그럼 이렇게 짜면 됩니다.

이런 빌어먹을. 그래도 안된다고 합니다. 얘들이 왜이러지? 예전에는 이러면 됐었는데 뭔가 바뀌었나봅니다.

수정) 알고보니 define을 맨 위에 둬야한다네요. 잘못 씀.

2.pragma

다른 매크로를 써보죠, pragma란 것도 있습니다.

3.그냥 scanf_s를 쓸까?

근데 저놈들은 이게ㅔ 뭐라고 자꾸 쓰라고 강요를 하는 걸까요?

실제로 scanf에 취약점이 존재하기 때문입니다. 전달받은 변수보다 입력으로 들어오는 값이 더 크면 버퍼오버플로가 발생하는데, 이게 상당히 위험할 수 있거든요.

그래서 더 큰 값이 들어와도 잘라버릴 수 있도록 맨 마지막 인자로 변수의 크기를 넣어줍니다. '너무 커도 이 변수 크기까지만 넣어라!' 라는 뜻이죠. 

이렇게요.

잘 됩니다.

근데 사실 _s는 그렇게 좋은 기능만은 아닙니다. 이걸 이렇게 강력하게 지원하는 컴파일러가 사실상 이거밖에 없는데요... 

굳이 이걸 쓰지 않아도 취약점을 막을 수 있는 방법이 많기 때문입니다.. 마지막 인자 때문에 추가되는 오버헤드도 있고요.

4.프로젝트 설정

코드에 손을 대고 싶지 않다면, 좀더 근본적으로 문제를 차단할 수도 있습니다.

자꾸 _s 버전 쓰라고 강요하는걸 SDL 체크라고 하는데요. 이걸 꺼버리면 됩니다.

솔루션 탐색기 창에서 프로젝트 파일에 마우스 오른쪽 버튼을 누르고

속성 창으로 들어갑니다.

그리고 C/C++ -> 일반 -> SDL 검사에서 '아니요'를 선택해주시고 확인 누르시면

잘 됩니다.