감사합니다.

C++은 객체지향형 언어라고 한다.

보통 "Class"라고 부르는 C++의 자료형 때문이다.

C++에서는 함수와 변수를 묶어서 Class로 표현한다.

덕분에, 특정 동작을 하는 모듈을 상속을 통해, 쉽게 설계할 수 있고,

강력한 추상화를 지원한다.

추상화를 통해, C언어에서는 만들기 어려웠던 것들도, C++에서는 쉽게 구현이 가능해지는것도 있다.

어쨌든 C++은 C언어보다는 진보된 언어이다.

그러나, 장점이 많지만, 단점도 존재한다.

바로, 속도가 느려진것이다.

C언어에서는 클래스포인터등을 사용하지 않고, 주로 전역변수등을 통해, 쉽게 속도향상이 가능했다.

그러나, 전역변수를 많이 사용할 수록, 복잡한 프로그램은 작성이 어려워진다.

유지보수 또한 매우 어려워진다.

C언어에서도 구조체를 통해, 상속을 구현할 수 도 있다.

원리는 C++와 동일하다.

단, C에서는 클래스포인터를 따로 처리해주지 않으므로, 동일한 동작을 하는 코드를 작성했을때는, C++로 작성한 프로그램이 더 빠르다.(컴파일러가 지원해주지 않으니)

장점이 있다면, 단점도 있다.

Class의 멤버함수, 변수를 참조, 호출하기위해서는 this라고 하는 클래스 포인터가 필요하며, this 포인터 참조를 한번은 더 해야한다.

가끔 호출하는 멤버함수나 변수는 성능에 문제가 없으나, 매우 자주 호출되는 기능을 멤버함수나 변수로 만들경우, 엄청나게 느려질 수 도 있다.

컴퓨터가 발전함에따라, 메모리양이 늘어나고, 속도도 빨라져, C++로 작성해도, 큰 불편함은 없었다.

아니, 사실은 잘 못느낄 뿐이었다.

C++로 작성한 프로그램을 사용하다가, C로 작성된 프로그램을 사용하면, 매우 빨리, 매우 부드럽게, 잘 동작하는것을 느낄 수 있다. 물론, 기능은 떨어진다.

하지만 그만큼의 가치가 있는지 묻고 싶다.(대부분 어쩔 수 없다.)

C++언어는 상속이라는 과정을 통해, 어떤 기능을 호출하면, 마치 양파을 까듯이, 하나 하나 호출하는 방식으로 동작한다.

그러니 당연히 느릴 수 밖에 없다.

C언어로도 C++처럼 동일한 방식으로 작성한다면, 동일하거나, 더 느리다.

그러나, C언어는 위에서도 설명했지만, 비교적 간단한 기능을 프로그램하며, 사람이 직접 전역변수등을 통해, 직/간접적으로 최적화를 시킨다.

그러므로, 속도는 매우 빠르다.

C언어의 단점은 위와 같은 방식으로 전역변수를 많이 사용할 경우, 규모가 큰 프로그램은 작성이 어려워진다.

또한 스파게티 코드라고 부르는 디버깅이 난해한 프로그램이 자주 탄생한다.

규모가 큰 프로그램은  C++로 작성하는것이 좋고, 소규모의 간단하고, 속도가 필요한 프로그램은 전역변수를 많이 사용하는 C언어처럼 작성하는것이 좋다.

C++언어로도 C코드를 만들 수 있다. 당연한 소리.

C++언어로 C와 똑같은 방식으로 프로그램이 가능하다.

어쨌든, 최신 컴퓨터를 사용하는 사람은 잘 못느끼지만, 10년전 20년전 컴퓨터를 사용하는 사람도 많다.

오래된 컴퓨터를 사용하는 사람들에게는 C++언어로 작성된 프로그램은 느릴 수 밖에 없다.

윈도우 운영체제도 내부적으로 C함수로 작성되던 것이, 이제는 점점 C++클래스로 바뀌고 있다.

덕분에 윈도우 업그레이드를 할 수록, 전체적으로 무거워진다.

최신 윈도우에 불필요한(?)기능이 많기도 하지만, C++ 언어의 클래스 때문에 느려지는것 한몫한다.

윈도우XP를 사용하던 컴퓨터에 윈도우7을 설치하니, 너무 느려서, 답답하다.

똑같은 프로그램을 실행하는데도 말이다.

대부분의 사용자들은 최신 컴퓨터에, 최신 기술을 선호한다.

그러나, 최신 기술들은 대부분, 속도면에서 더 느려진다.

동일한 작업을 하는데 있어, 필요이상의 고급 하드웨어와 많은 프로그램 코드를 사용하고 있지는 않은지?

그래도, 최신 컴퓨터와, 최신 운영체제와, 최신 프로그램을 선호하는 사람이 더 많은것은, 어쩔 수 없는 인간의 특성인듯 싶다.

"짜증나면, 컴퓨터를 바꿔라"....???

어쨌든, 이런 특성을 지닌 인간이 설계한 기계는, 가격을 낮추거나, 규모를 축소하는데, 많은 어려움이 있다.

대부분의 개발자들은 컴퓨터의 운영체제가 지원해주는 편리한 기능들을 마구(?) 가져다 사용한다.

그리고나서, 최소 사양을 결정지을때는, 동작하기도 어려운 버벅임을 해결하는데, 고생도 한다.

때로는 아예 실행이 안되는 경우도 있다.

인터넷 뱅킹을 하는데, 여러가지 설치프로그램들이 덕지덕지 설치해야한다.

윈도우XP라면, 서비스펙2이상을 설치해야하고, .Net프레임워크, XML 등도 설치해야한다.

설치가 안되면, 아예 동작이 안된다.

물론 윈도우7에서는 기본적으로 설치가 되어 있다.

사람들은 현재의 편리함을 위해, 약간의 성능 희생하고, 점점 느려지는 컴퓨터를 원망하기도 한다.

물론, 컴퓨터가 느려지는것이, C에서 C++로 바뀌었기때문만은 아니다.

그러나, 상당 부분 영향이 있는것은 사실이다.

하드웨어는 점점 빨라졌지만, 소프트웨어는 오히려 점점 느려졌다.

요약 : 컴퓨터가 점점 느려지는 원인중에 하나는 C++ Class의 영향도 무시할 수 없다.

void main()

{

int a;

int b;

int c;

a=1;

b=1;

c=a+b;

...

}

위와 같은 코드가 있을때,

컴파일 속도에 영향을 미치는 요인은 어떤것들이 있을까요?

눈에는 보이지 않지만, 문장의 끝에는 \r\n 2개의 문자가 들어 있습니다.

그리고 앞에는 Tab문자가 들어 있습니다.

컴파일러는 1문자당 1바퀴 루프를 돌게 되는게 일반적입니다.

루프문 1바퀴를 돌려면, 여러가지 조건이 있고, 이 조건을 포함해서 돌게되면,

최소 몇 클럭은 필요합니다.

1문자 때문에 최소 몇클럭씩 낭비가 되는것입니다.

위 코드를 아래와 같이 바꾼다면,

void main()

{

int a,b,c;

a=1;

b=1;

c=a+b;

...

}

개행문자(\r\n) 4문자와 "int " 2개, Tab 2개가 없어졌으니,

총 4+4+4+2=14문자가 사라졌습니다.

컴파일러는 14문자만큼의 루프를 덜 돌아도 되며, CPU클럭으로 따지면, 

1문자당 3클럭으로 계산해도, 최소 42클럭이상 빨라진것입니다.

또한 소스코드를 로딩할때도 이미 소모된 클럭이 있으므로, +@로 처리시간이 단축됩니다.

여기서 조금 더 나아가면,

- 변수명을 짧게

- 불필요한 공백을 사용안함

하면 +@의 효과를 얻을 수 있습니다.

물론, 코드의 가독성은 떨어집니다.

적당히 줄이세요.

"그거 줄여봐야 얼마나 되겠어?"

"요즘 CPU가 얼마나 빠른데?"

하시겠지만, 이런 수천 라인의 소스파일, 수천개를, 컴파일하게되면, 분명히 시간차이가 발생합니다.

또한, 파일에 저장하기위한 공간도 줄어듦니다.

무리하게 할 필요는 없고, 지금부터라도, 불필요한 공백은 자제합시다.

요약 : 불필요한 중복된 문자(동일한 변수형 반복), 불필요한 개행문자, 긴 변수명은 자제하자.

우스개 소리로, 예전에 마이크로 소프트사와 유닉스 진영에서 개행문자(\r\n)에 대한 논의(?)가 있었습니다.

유닉스진영에서는 개행문자가 \n 1바이트입니다만, 마이크로 소프으 윈도우에서는 \r\n 2바이트입니다.

컴퓨터에 있는 파일의 적지않은 용량의 파일이 택스트 문서이고,

해당 문서에서 개행문자때문에 소모되는 공간도 무시할 수 없다는 것입니다.

지구상의 모든 컴퓨터의 하드디스크에서 무시할 수 없는 공간이 낭비된다는 것입니다.

하드디스크 공간이 비약적으로 늘어나서, 그 피해가 너무 작을뿐, 낭비되는것은 맞습니다.

마이크로 소프트사에서는 이 문제 때문에, \r\n을 \n 으로 바꾸려는 시도를 하기도 했었습니다만, 엑셀, 비쥬얼베이직 같은 프로그램에서 문제가 발생하여, 중단한것으로 알고 있습니다.

유니코드문자를 사용하는 요즘에는 2배로 낭비되고 있습니다. ㅎㅎ

VC++6.0 기준

Lib파일로 DLL을 만들 수 있을까?

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

가능해 보임

DLL을 Lib로 만들 수 있을까?

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

된다고 함.

exe를 Lib로 만들 수 있을까?

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

될것 같음

기존 소스를 최소한의 수정으로 DLL을 만드는 방법은?

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

DLL을 만들려면, dllexport, dllimport 매크로를 기존 함수 앞에 붙여줘야한다.

소스파일이 너무 많은 경우, 함수마다 일일이 다 붙여주기도 힘들다.

LIB_DLL_API 매크로는 해당 함수가 DLL에서 외부로 보여지게 만들어 준다.

표시가 없는 경우, DLL내부에 존재는 하지만, 외부에서 해당함수를 찾아서 사용할 수 없다.

#ifdef LIB_DLL_EXPORTS

#define LIB_DLL_API __declspec(dllexport)

#else

#define LIB_DLL_API __declspec(dllimport)

#endif

1) 헤더파일에만 표시해줘도 된다.

   소스파일에는 표시 안해도 됨.

실행파일에서 DLL링크 방법

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

DLL을 만들때, Lib파일도 같이 만들어진다.

VC++6.0 에서는 DLL파일이 만들어지는 경로는 지정할 수 있으나,

Lib파일이 만들어지는 경로는 Debug나 Release로 고정된듯하다.

아래와 같이 Lib 파일을 지정경로(개인용 Lib)로 복사하는 파일을 만들어 두고, 컴파일 후, 한번씩 실행해준다.

(컴파일 후, 자동으로 실행해주는 기능은 없는듯함)

//copy lib to Lib.bat

copy D:\C\Lib_DLL\Debug\aD.lib D:\C\Lib\aD.lib

copy D:\C\Lib_DLL\Release\a.lib D:\C\Lib\a.lib

정적링크/동적링크

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

1) 정적링크

실행파일을 만들때, DLL만들때 생성된 Lib파일을 참조하여,

exe파일 실행시, DLL파일의 함수들을 한꺼번에, 자동으로 끌어오는 방법이다.

exe파일 실행시, DLL파일이 없다면, 에러를 내뿜고 종료된다.

2) 동적링크

exe파일에서, 필요시, DLL파일의 특정함수를 끌어오는 기능이다.

사용자가 GetProcAddress, LoadLibrary함수를 사용해서, 각 함수별로 끌어와야한다.

함수포인터변수를 만들고, 해당함수의 주소를 불러오는것이다.

함수 포인터 변수(함수별로 각각 모양이 다름)+함수명(문자열)+끌어오는 코드가 필요함.

exe파일 실행시, DLL이 없는 경우 사용자가 에러를 핸들링할 수 있다.

동적링크는 주로, 윈도우의 시스템 DLL에 있는 함수를 끌어올때 사용한다.

디버그용과 릴리즈용 DLL  구분

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

디버그용과 릴리즈용 DLL을 만들어야 디버깅이 편하다.

디버그용은 소스가 있다면, DLL 내부까지 디버깅이 가능하다.

보통 디버그용은 파일명 뒤에 'D"를 붙인다.

exe파일에서 DLL정적 링크

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

#include "..\Lib\a_DLL.h"

#ifdef _DEBUG

#pragma comment(lib, "a_DLLD.lib")

#else

#pragma comment(lib, "a_DLL.lib")

#endif

기존에 만들어둔 Lib파일을 일괄적으로 DLL로 변환할 수 있을까?

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

헤더파일에 함수명앞에 DLL EXPORT 매크로만 추가하면 됨(?)

DLL파일을 사용함으로써 장점,단점

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

1) 장점

- 컴파일 시간 감소(Lib와 동일)

- 기존 Lib 파일 대비, 링크 시간 감소

- 여러개의 프로그램이 있을때, DLL하나만 업데이트하여, 모든 프로그램의 성능이 개선될 수 있음.

- 윈도우에서 DLL은 1개만 로드하므로, 여러개의 프로그램이 동시에 실행되고, 동일한 기능을 DLL로 묶을 경우,

  DLL파일 크기만큼 메모리가 절약되나, 3G정도의 메모리를 사용하는 요즘에는 1M크기의 DLL은 아무런 이득이 안됨.

2) 단점

- 프로그램 수정시, exe, DLL 2가지중에 어느것을 업데이트 해야할지 복잡해짐.

  exe파일로 만든 경우에는 exe 파일 한개만 교체하면, 업데이트가 되지만,

  DLL이 있는 경우, 어느것을 업데이트 해야할지, 아니면, 2개다 교체해줘야하는 번거로움이 있음.

- exe, DLL버젼이 서로 안맞는 경우, 문제가 됨

- DLL을 타인이 무작위로 사용할 수 있음.

- DLL파일을 만들기위한 프로젝트를 만들고, 관리해야 함.

- DLL이 분리되어 있어, DLL 내의 소스 수정이 필요한 경우, 절차가 번거로움.

  exe 파일은 한번에 모두 됨.

- DLL이 수정된 경우, 해당 DLL을 사용하는 기존의 다름 프로그램도 영향을 받아, 문제가 될 수 있음.

- DLL버젼 표시가 어려움.

  exe 파일에서 DLL파일의 버젼을 표시해주지 않는 이상, DLL파일의 날짜로만 구분이 가능해짐.

평가 : 단점이 더 많아 보임....

기타

----

DLL파일을 동적링크함으로써, 해당 응용프로그램을 자유롭게 확장할 수 있다.