본문 바로가기
C++/따배씨 강의 정리

[몽돌] [따배씨 - 공부 노트] 0.4.0 통합개발환경의 기본적인 사용법 - 윈도우즈 비쥬얼 스튜디오

by 몽돌리스트 2021. 9. 9.
반응형

참고 링크

참고 블로그 : https://iagreebut.tistory.com/54

 

2가지 환경 혼합 

밝은 색상의 배경 - VS 2017 / 강의 자료 캡쳐

어두운 색상의 배경 - VS 2019 / 직접 실행 및 캡쳐

통합개발환경 시스템 

IDE : Integrated Development Environment 

 

일단 C++을 공부하기 위한 것이므로, 

Workloads 에서 Desktop Development with C++ 를 선택해줍니다.

 

영문판을 쓰는 이유는 오류가 발생시 쉽게 찾을 수 있기 때문입니다.

( 위의 메뉴 Language pack을 선택하면 언어를 쉽게 변경할 수 있다는 점 ! 


설치 후에,

처음 해야하는 것은 Solution & Project 를 만드는 것입니다.

먼저 New -> Project -> Installed -> Visual C++ -> Windows Desktop -> Windows Console Application or Windows Desktop Wizard 를 통해 만들어줍니다. 여기서 console 과 wizard는 차이가 있긴 하지만, 해당 예제(Hellow world)에서는 상관이 없습니다. ( 추후 설명이 될겁니다. ) 

 

여기서 Solution name / Project name 을 지정해줍니다.

대부분 Solution 이름이 Project 이름과 동일하게 작성되곤 하는데,

때때로 한 Solution 밑에 여러가지 project를 생성할 수 있기 때문에 그 경우에는 Solution 이름을 다르게 지정하는 것도 하나의 방법입니다.

 

 

Dynamic Link Library / Static Library 는

추후에 다른 프로그램을 실행할 때 해당 기능을 가져다 쓸 목적으로 만드는 용도 입니다.

알아두면 좋다. ( DLL / Lib ) 

 

또한 간단한 예제를 실행하기에는 Console 창을 띄어놓고

출력되는 것을 보면 되기 때문에 Application type을 Console로 설정했습니다.

 

큰 프로젝트, 즉 소스파일이 많은 경우에 빌드 시간을 줄여주는 목적을 위해 Precomplied를 쓰기도 한다. 

** 근데 문제는 이 기능을 활용하면 리눅스에서 컴파일이 안된다는 점 !

** multi platform 에서는 작업을 하고 싶다면? 사용하지 않아야 한다.

** 윈도우즈 전용 프로그램을 만든다면 뭐... 괜찮다 :) 

 

아무튼 기본 조건으로 생성을 해주면,

솔루션 밑에 프로젝트가 있고, 여러 폴더들이 보입니다.

 

일단 CPP 파일을 만들어봅니다.

( Header file / Class file 은 강의 뒷 부분에서 설명할 예정입니다. )

 

시작 시작 !

Include ( 기본 프로그램을 가지고 와서 포함을 시키는 명령어입니다. )

( 자동완성 기능을 활용하면, 손쉽게 선택할 수 있지만 직접 타이핑 하는 것이 더 좋습니다. )

#include <iostream>

iostream : 출력할 수 있는 기능들을 가지고 있습니다.

코드를 하나하나 다 작성할 수 없으니까, "기존에" 만들어져 있는 기능들을 가지고 오는 것 입니다.

 

Build started...
1>------ Build started: Project: HelloWorld, Configuration: Debug Win32 ------
1>Source.cpp
1>HelloWorld.vcxproj -> C:\Users\jipa\Desktop\Example\HelloWorld\Debug\HelloWorld.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

 

여기서 프로젝트를 여러개 가지고 있으면, Build started : project 1, project 2 ,.... 이런 순서로 출력됩니다.

 

Configuration -> debug ( Debug는 오류를 수정하는 과정입니다. ) 

Win32 ------ 

( 위에 보면 Debug와 숫자 ( x 86 or x 64 ) 와 관련이 있습니다.

( 여기에서는 Win 32 는 x86과 관계가 있는 숫자라는 것을 알고 있으면 됩니다. 

( 보통은 윈도우에서 실행되는 파일들을 편하게 Win 32라고 부릅니다. 

 

Source.cpp -> 해당 파일이 컴파일 되었다는 것을 의미합니다.

HelloWorld.vcxproj -> C:\Users\jipa\Desktop\Example\HelloWorld\Debug\HelloWorld.exe

vcxproj -> exe // 프로젝트가 실행파일로 만들어졌어! 라는 의미를 갖습니다.

 

 

빌드 끝 ! 

빌드는 컴파일과 링킹을 포함한다. ( 앞 강의 참조 ) 

그것을 포함하고 있다는 증거는 어디에 있는지를 살펴봅시다.

소스 파일에 우클릭을 하면 Open Containing Folder가 보일겁니다.

source cpp 파일이 보이고,

.vcxproj 는 프로젝트의 정보를 담고 있습니다.

( 프로젝트 안에 각 소스들이 어떤 관계를 가지고 있는지 정보를 가지고 있는 파일입니다.

 

그리고

Debug 폴더 안에 들어가보면, 

 

여기서 obj 파일이 보입니다.

소스 파일이 여러개가 있다면, 컴파일 후, 

같은 개수의 obj 파일이 생성된다는 것을 알고 있어야 합니다. 

*** 확장자에 따라 obj ( 윈도우 ) o( 리눅스 ) 라는 오브젝트 파일들이 생성됩니다.

*** 또한 여러개의 obj 파일이 생성되면, 그것들을 연결 시켜서 ( linking ) 실행 파일을 만들게 됩니다.

 

그렇게 생성된 실행 파일은 어디에 있을까요?

솔루션에서 지정을 해주는 Debug 폴더 안에 생성이 됩니다.

그렇다면 해당 실행 파일을 실행시키면 어떻게 될까요?

VS에서 해당 실행 파일을 실행시키는 가장 쉬운 방법은 

Debug -> Start without debugging 메뉴판 

을 해주면 됩니다.

 


그렇다면 비주얼 스튜디오를 통하지 않고, 실행 파일을 실행하는 방법을 알아봅니다.

윈도우 키 -> x65 native tools command prompt for VS 2017을 실행시켜 줍니다.

( 저는 2019를 실행시켰습니다.

 

실행파일을 실행시키려면?

먼저 실행파일이 있는 곳으로 이동을 해야한다. 

 

cd ( change directory ) 그리고 디버그 폴더를 그대로 끌어서 커맨드 창에 가지고 옵니다. 

dir 

( 그러면 해당 폴더 안에 무엇이 들어가 있는지 상세하게 보여줍니다. 

 

왼쪽 수업 자료 (VS 2017) / 오른쪽 직접 실행 (VS 2019)

*** VS 버전에 따라 솔루션이 지정한 Debug 폴더 안에 생성되는 것들이 달라지기도 하는 모양입니다.

 

여기서 간혹 

코드를 다른 드라이브에 저장한 경우가 있다

만약 D 드라이브에 저장을 했다면,

그냥 cd 를 치고 경로를 입력했을 때, 해당 경로로 들어가지지 않습니다. 

이 경우에는 d: 라고 치고 들어가면 됩니다. 

 

 

아무튼 실행 시키려고 한다면

해당 Directory 로 이동을 해서 xxx.exe 이라고 명령어를 쳐주면

실행파일이 실행됩니다.

 

오타가 걱정된다면? tab키를 눌러주는게 좋다. 그러면 가장 적합한(?) 파일을 먼저 찾아주고

다시 한번 tab 키를 누르면? 다른 파일을 찾아줍니다. ( 비슷한 이름을 가진 )

참고할 것 !

 

 

원래는 이렇게 실행파일을 command prompt 에서 실행하는 것인데,

visual studio 에서는 이를 자동적으로 다 ~ 실행시켜줍니다.

편리하죠. 하지만 뒤에서 어떤 일이 벌어지는지 꼭 잊지 말아야 합니다.

 

 

std::cout ( cout - console out 이라는 뜻이겠지요? ) 

모르겠으면 -> 구글링 혹은 우클릭 -> go to definition으로 들어가면 됩니다.

 

잘 살펴보면

우리는

#include <iostream>을 해줬습니다.

std:: 을 분석해보면

:: -> namespace

std -> iostream 안에 들어가 있는 모든 것들은 Standard template lib 라는 namespace 안에 정의가 되어있다. 라는 뜻입니다. 일단 이렇게 이해를 하고 넘어갑시다. 

 

코드를 작성 후, 다음과 같은 순서로 실행을 시켜줍니다.

1. build -> build solition ( 솔루션을 빌드하고 ) 

2. Debug -> start without debugging or start debugging 을 해주면 됩니다.

만약에 build -> clean solution 을 해주면 

Debug 폴더에 있는 것들이 다 사라집니다.

 

 

 

이 상황에서 만약  

Debug -> Start without debugging을 해주면

Build 부터 할거냐고 물어보는 것을 확인할 수 있습니다. 

 

빌드란, 소스코드 파일을 실행가능한 소프트웨어 파일로 만드는 일련의 과정을 의미합니다.

따라서 해당 과정을 다시 시작해야 하니까 물어보는거라 생각하시면 됩니다. 

 

( Clean solution 을 해주기 전에는 Debug 폴더 안에 파일들이 존재 했기 때문에

( 해당 내용을 물어보지 않았다는 것을 알 수 있습니다.

( 아마 Debug 폴더 안에 Build 와 관련된 파일들도 생성되는 것으로 추측됩니다. 

 

 


그리고 위에 상단에 보면 Debug와 Release를 선택하는 부분이 있습니다.

그렇다면 뭐가 다를까? 

Release 로 실행시켜주면 Debug가 실행되지 않습니다. ( Release = start without debugging ( ctrl + F5 ) ) 

*** 앞으로는 자동으로 Build 되는 것을 사용할 예정입니다.

*** 기초 단계인 만큼 어떤 과정이 일어나는 지를 보여주기 위한 것 이었습니다. 

 

아무튼 둘다 실행시켜주면 작동되는건 똑같은데

Debug 폴더와 Release 폴더가 생성됩니다.

 

 

 

왼쪽은 Debug 폴더 안, 오른쪽은 Release 폴더 안에 구성내용들입니다.

둘다 exe 파일이 생성된 것을 볼 수 있습니다.

 

근데 자세히 보면 실행 파일의 사이즈가 다릅니다.

왜? Debug 모드에서 빌드를 하면, Debug 할 때 도움이 될 수 있는 정보들이 모두 같이 들어가 있기 떄문에

용량이 더 커지게 됩니다. 

 

Release 는 실제 배포를 할 때,

실제 사용자들이 쓰라고 최소화 된 내용만을 담고 있다. 

 

같은 실행파일이지만, 실행속도가 실제로 정말 차이가 난다고 합니다. 

Debug speed <<<<<< Release speed

따라서 그래픽이나 비전, 혹은 게임 관련 프로그램 // 복잡한 알고리즘을 만들었다면

Debug 모드가 아닌 Release로 해야 제 속도를 볼 수 있습니다.  


 

초창기에 쓰던 칩 번호에서 따온 x86 이라고 나와있지만,

사실 이것은 32bit mode를 의미합니다.

x64 는 64bit mode를 의미합니다.

 

 

64 bit mode 에서는 우리가 개발한 프로그램이 굉장히 커질 수 있다.

( 메모리를 상당히 많이 사용할 수 있다. )  

 

반면 32 bit mode 에서는 제한이 있다. 

예전에는 컴퓨터의 성능이 좋지 않았기 때문에 대부분 x86를 썼지만,

최근에는 주로 x64를 쓰는 경우가 많다. 

 

 

 

 

 

 

 

 

 

반응형

댓글