c - 2024-11-13

 

 

 

시작

당연히 실행하면 결과가 잘 나올 것입니다. 

이때 만약 originInt의 이름을 helloInt로 바꾸고자 할 때에 일일이 바꾸는 방법도 있지만,

 

컨트롤 + H를통해 선택 영역을 지정한 상태로 바꾸기 창이 나옵니다.

그리고 알트 + A를 통해 일괄적용이 가능합니다. 이때 앞에 두 개에만 체크하는 것이 중요합니다.

 

 

* 혹여나 c/c++에 있는 기본적으로있는 기능들을 그대로 쓰는 것이 좋겠다는 생각이 들었습니다.

직접 구현하려거든 엄청난 노력이 들지만, 노력에 비하여 성능이 별차이 없거나 안좋아지는 경우도 있기에,,,

하지만 밑에 블로그처럼 직접 시도해보면 기억에 많이남을 듯하여 저도 언젠간 도전을 하긴 해야할듯합니다.

https://yjg-lab.tistory.com/74

 

* Y2K같은 문제가 발생할 날이 얼마 안남았습니다.

https://namu.wiki/w/2038%EB%85%84%20%EB%AC%B8%EC%A0%9C

2038년 1월1일이면 오버플로우로인하여 1971년 1월1일로 돌아갈지,,,, 아니면 이미 그것도 고려하여 개발이 되고있는지 궁금하긴합니다.

 

C/C++

좋은 블로그입니다. c언어 이전 시대에는 기기간 호환성에 관하여 문제가 많았다고 이해하였습니다.

https://joone.net/2017/02/18/%EC%9C%A0%EB%8B%89%EC%8A%A4%EC%99%80-c%EC%96%B8%EC%96%B4/
추가로 자바에서 운영체제에 구애받지 않도록 해주는 JVM이 떠올랐었습니다. 

 

* 자료형의 크기가 이상했던 내용을 해결해주는 블로그입니다.

int도 4인데 long도 4바이트여서 의문이 있었습니다.

추가로 포인터의 크기가 32비트는 4바이트, 64비트는 8바이트인 이유를 얼핏 들었던 기억이 나지만 추후 찾아보려고 합니다. 

https://hackerpark.tistory.com/entry/C%EC%96%B8%EC%96%B4-int-%EC%99%80-long-%EC%9D%80-%EB%AC%B4%EC%97%87%EC%9D%B4-%EB%8B%A4%EB%A5%BC%EA%B9%8C-short-short-int-int-long-int-long-long-long

 

 

class Character {};

C언어에서 해당 형태로 클래스를 생성 시 생기는일입니다.

기본 생성자 ,  소멸자, 복사 생성자, 대입 연산자, 이동 연산자, 이동 대입연산자가 생깁니다.

 

우선 기본 생성자입니다. 이는 c#과 동일하게 또 다른 생성자가 정의되면 기본 생성자는 사라집니다.

 

소멸자입니다. 소멸 시에 출력된 모습입니다. 

복사 연산자와 대입 연산자도 클래스 내부에 =가 분명 정의 되어있지않은데, 작동하게 됩니다.

 

: 하고 뒤에 쓰면 값이 입력 되는 것을 활용한 것입니다. 5로 값이 초기화 되었습니다.

 

 

Hello를 char*로 저장하여 int*에 넣게 되면, int로 값이 저장됩니다.

분명 int로 넣어도 아스키코드 값이 나오는 것을 예상했지만 결과가 달라서 추측을 해보았습니다.

 

1Byte인 char을 4Byte인 int로 인식하는 과정에서 뭔가가 생긴것인지,

아니면 char*이라 한들 공간의 크기는 4Byte로 인식이 되면서 문제가 생긴 것인지..

추후 알아봐야겠습니다.

 

결과적으로는 int* 인것을 char*로 하여도 원래 문자 그대로 출력된 모습입니다.

 

추가로 const 키워드를 안 붙이면 에러가 발생됩니다.

 

 

 

 

RTTI

RTTI는 Run Time Type Information으로 런타임에 타입 정보를 아는 것입니다.

그러므로 B를 A로 업캐스팅하고, A을 C로 다운캐스팅 할 때에 오류인 상황을 인지할 것입니다.
https://makga.tistory.com/81

 

* 런타임은 간단하게 메모리에 프로세스가 적재되는 순간입니다.

 

업캐스트/다운캐스트

업캐스팅 다운캐스팅 예제 해보려했는데 실패했습니다.

분명 문제점이 있는데 못찾았습니다. 추후 다뤄보겠습니다.

 

밑에 블로그는 자바로 업캐스팅 다운캐스팅을 설명하였습니다.

이는 A 에서 B로 가면 다운 캐스팅, B에서 A로 가면 업캐스팅입니다.

https://ssow93.tistory.com/33

 

cast

https://musket-ade.tistory.com/entry/C-C-%ED%98%95-%EB%B3%80%ED%99%98-%EC%97%B0%EC%82%B0%EC%9E%90-staticcast-constcast-dynamiccast-reinterpretcast

C-Style에서는 비교적 자유롭게 형 변환이 가능하며, 포인터 공간의 크기가 같다면 변환을 해줍니다. 위험합니다.

static-cast는 상속까지는 고려하지 못하는 형 변환입니다. 

A  -> B ,C 의 상황입니다.

B* b = new B();
A* a = static_cast<C*>(b);
C* c = static_cast<C*>(a);              >> 이게 정답 C* c = dynamic_cast<C*>(a);

이론 상으로는 C는 올바른 캐스트지만 RTTI를 통해 검사하면은 문제가 있다는게 밝혀집니다.

 

 

 

 

typeid

typeid를 쓰면 자료형 체킹이 가능해집니다. 

 

name은 클래스의 이름을 가리키며, raw_name은 c에서 구별하기 위한 이름이며, hash_code는 해당 위치의 해시코드입니다.

 

해당 결과는 부모의 클래스와 자기자신 클래스를 출력하게 됩니다. 이를 통해 어떤 부모를 상속 받았는지 확인 가능해지는 것입니다.

허상포인터

허상포인터는 목표를 잃은 채로 존재하는 포인터입니다. 

이는 동적 할당을 하고나서 delete 혹은 free로 할당해제를 해줘야하는데 그게 안된 경우입니다.

https://rhksgml78.tistory.com/245

 

혹은 상속과 부모관게에서 나타납니다.

분명 Character에는 Print()가 없는데 실행이 되어지는 모습입니다. 디버깅 값에도 Character에는 value가 없습니다.

물론 부모에서 출력된 값을 쓰레기 값입니다.

 

이번엔 가상화 유무에 따른 결과 차이입니다.

typeid를 통해 클래스 상태를 확인합니다.

부모에 가상화 된 것이 없으므로 동일한 결과가 나옵니다. 

부모에 가상화된 것이 생기면 원활한 결과가 나옵니다. 

vftable로 인하여 가상화가 진행되어 그런가 싶다가도 무슨 차이인지 궁금하지만 잘 모르겠습니다. 

 

추가로 재정의하는 식으로 하게되면 vftable 내부에 Print가 Chlidren의 것으로 바뀝니다.

 

아니면 자식쪽에서 virtual 걸어버리면 부모에는 존재하지 않게 되므로 엑세스 위반이 발생합니다.

 

inline
C/C++에서 함수 호출을 하면 스택프레임에 가는 동작이 있어야 하는데, 인라인을 사용하게 되면 코드 영역에서 바로 호출된 자리에 삽입을 해주므로 시간이 절약됩니다.

https://www.tcpschool.com/cpp/cpp_cppFunction_inlineFunction#google_vignette

 

inline은 기본적으로 컴파일러가 효율적이라고 판단을 할 때에 작동합니다.

https://blog.naver.com/kyed203/220095954142?trackingCode=rss

 

종류로는 inline, _inline, __inline이 있습니다. 제가 쓰는 visual studio 2022 혹은 ms에서는 저 세 종류는 동일한 것으로 취급한다고 알고 있습니다.

 

* inline은 기본적으로 멤버변수를 반환할 때에 활용하면 좋다고 이해하였습니다. 

* 예를들면 언리얼에서 객체에 관한 정보를 반환할 때에 입니다.

 

해당 코드처럼 짠 후에 디버그 창에서 결과를 보겠습니다.

 

일단 중요한건 call이 나온 다는 것이 inline이 적용 안되었다고만 이해하였습니다.

 

이제 함수앞에 inline 3 종류를 붙인 결과입니다. 결국 call이 나와버립니다.

 

forceinline도 동일하게 작동합니다. 

 

이는 컴퓨터 성능과 연관된다고 이해하였습니다. 예를 들어 ps5에서는 inline으로 처리 안되더라도 switch에서는 inline으로 처리되면 실제로 게임 성능에도 연관이 있을 것입니다.

 

그러므로 inline은 재귀함수 , 함수 포인터의 경우 사용이 불가능합니다.

 

이렇게 선언과 정의가 되어진다면 inline으로 만들어진다고 이해하였습니다.

forceInline
forceInline은 반드시 inline함수화합니다. 실제로는 동작 안할수도 있다고 생각합니다. 위 와 같은 원리로..

 

부모에 forceinline있으면 자식은 inline정의해야한다고 이해했었는데, 저게 없어도 잘 작동하여 추후 내용을 추가할 예정입니다.

macro

macro는 #define입니다. 일단 전처리기쪽에서 처리되므로 사전에 처리되는 개념입니다. f를 붙인 것은 float 아닌 것은 double로 들어간 모습입니다.

이는 값을 그대로 입력하게 됩니다. 

 

 

재밌는 경우라고 생각합니다. TRUE 자체를 보통1, FALSE는 0으로 쓰는데, 랜덤으로 TRUE가 나오는 장치입니다.

이때 주의 사항이 있습니다. 

 

만약 습관적으로 세미콜론을 붙이게 되면, 저 문자가 그대로 입력되는 형태이므로 당연히 에러가 뜰 것입니다. 

 

마지막으로 매크로와 inline은 유사하면서 다릅니다.

그것은 곧 진도 나갈 것 같습니다.

 

 

감사합니다.