'프로그래밍'에 해당되는 글 125건

  1. 2013.03.15 C언어를 굳이 배워야하는이유[펌]
  2. 2013.02.03 이클립스에서 디버깅
  3. 2013.01.31 아두이노 블루투스
  4. 2012.12.08 이클립스 vim 플러그인
  5. 2012.12.01 이클립스 vim 플러그인
프로그래밍/C 2013. 3. 15. 09:40

써 몇 년이 지난 이야기다. 교육을 받던 분이 굳이 C언어를 배워야 할 필요가 있냐고 물어보셨다. 그에 대한 개인적인 생각을 적어보도록 하겠다.



1. 체계화된 프로그래밍 순서를 익힐 수 있다.

모든 프로그래밍은 기본적으로 연산에 필요한 데이터를 메모리에 적재(load)하고 일련의 계산 결과를 저장(store)하게 된다. 이 후에 결과 데이터를 특정 위치로 전송하거나 복제하기도 한다. 이런 기본적인 계산 단위가 논리적으로 분기되고 복합적으로 연결된 것이 바로 프로그래밍이 되겠다.


그러나 가장 중요한 연산의 기본 단위는 읽고 계산하고 쓰는 작업이라는 점은 변하지 않는다.


프로그래밍 언어의 발전은 바로 이 읽고 계산하고 쓰는 작업을 편리하게 하거나 빠르게 하는 목적으로 발전해왔다. 편리함을 목적으로 하는 인터프리터 언어나 자바와 같은 언어들은 언어적인 측면에서 위 작업들을 간소화시켜준다. 예를 들어 A라는 위치에 있는 메모리를 B라는 변수로 복사한다고 치자. 몇몇 인터프리터 언어는 간단하게 '=' 기호로 이를 가능하게 한다.


1# python같은 인터프리터는 다음과 같이 선언된다.
2# B에 A를 저장한다.
3B = A


위와 같이 인터프리터 언어는 한 줄로 메모리를 읽을 수 있다. 그러나 한 줄의 코드에는 많은 내용이 함축되어있다. 예를 들어 B 변수에 메모리가 할당되어있지 않다면 할당해주고, 변수의 길이를 체크하여 부족하다면 재할당해주는 것도 포함된다. 또한 변수의 타입이 숫자인지 문자인지 변환하는 것도 가능하다.


그러면 위와 똑같은 작업을 C언어로 한다고 치자.

먼저 B의 메모리의 할당 여부 및 크기를 확인해야 할 것이다. 만일 작다면 reallocation으로 overflow를 막아야 하기 때문이다. 이를 위해 realloc을 사용해야 하며, 메모리 크기를 내부 로직에서 관리해야만 한다.


그 다음은 뭘 또 해야 할까? 음... A의 타입이 문자열인지, 문자열로 표시되는 숫자인지 다양한 검사를 해야 하는 경우도 있다. 데이터 오류를 막기 위해 여러 복잡한 검사를 해야 할지도 모른다. 이를 위해 정규표현식(REGEX)이나 바이트 단위로 데이터를 읽어야 하는 일까지 생길 수 있다.


결국 "B=A"의 한 줄로 표현되는 간단한 인터프리터 코드가 C언어에서는 수십줄이 넘어가게 된다는 것이다. 이 과정에서 버그도 심심찮게 일어날 수 있다. 이렇듯 인터프리터는 복잡한 작업을 간단하게 해주는 장점이 있다.


하지만 인터프리터 언어는 장점외에 단점도 분명히 존재한다!!


장점은 위와 같이 편리한 코딩, 즉 생산성이 높다는 점은 확실하다. 단점은 그와 반대로 너무 편리해서 어려운 프로그래밍을 못하게 된다는 점이다. 인터프리터 언어와 같이 언어가 대신해주는 작업이 많을수록 프로그래머는 쉬운 것에 익숙해지고 성능을 높이기 위해서 해야 하는 메모리, 연산기법들에 대해 둔감해지게 된다.


좀 멋진 말로 포장하면 transparency 때문에 하부 구조를 제대로 이해하지 못하게 된다는 것이다.


왜 메모리의 데이터 타입이나 경계를 검사해야 하는지? 즉 오버플로우를 신경써야 하는지 생각하지 않아서 편리하겠지만 그와 반대로 제한적인 메모리와 자원으로 프로그래밍 하는 환경에 적응하지 못할 수 있다는 점이다


또한 인터프리터와 같은 언어는 데이터를 옮길 때마다 메모리의 검사와 재할당 등이 발생하는 경우가 많으므로 생각보다 오버헤드가 커지기 십상이다. 이 때문에 일정 성능 이상 올릴 수 없는 구조적 문제도 따라온다.


물론 고급 레벨의 프로그래밍이 전혀 필요하지 않은 프로그래머라면 방금 한 말은 무시해도 된다. 하지만 전문적으로 프로그래밍을 하려고 한다면 언젠가는 고급 레벨을 접근해야만 하고, 그것은 메모리, 하드웨어에 대한 지식이 필요하다는 것을 의미한다.



2. 왜 어려운 프로그래밍 언어를 알아야 하는가?

C언어는 어려운 프로그래밍 언어다. 물론 과거에 사용되던 기계어나 어셈블리어보다는 쉽겠지만 평균적으로는 어려운 언어다. 이에 비해 다른 쉬운 언어들은 빠르게 익힐 수 있지만 덜 고민하게 되고 추상화된 프로그래밍 모델로 인해 쉬운 인터페이스에 집착하는 프로그래밍 스타일을 만들게 된다.


하지만 추상화나 쉬운 인터페이스에만 병적으로 집착하면 성능은 뒷전으로 내팽개치게 되는 성향이 생길 수 있기 때문에 조심해서 접근해야 한다. 이런 말을 하면 성능 문제는 하드웨어의 발전으로 커버할 수 있다고 말하는 사람도 있지만 비용대비 성능으로 볼 때 단순히 하드웨어의 발전만으로 커버되지 않는다. (하드웨어의 발전이 더뎌진 것도 하나의 이유가 된다.[2])


이런 연유로 인해 추상화되지 않은 프로그래밍 언어, 사람보다 컴퓨터가 어떻게 작동하는지 알 수 있는 언어를 알아 둘 필요가 있는 법이다. 


물론 십수년이 지나면 이런 환경도 사라지고 새로운 패러다임이 나올 지도 모르겠지만, 아직까지 C언어가 쌓아올린 컴퓨팅 환경은 견고하고, 컴퓨팅 환경을 이해하는데 있어 C언어를 대체할 만한 것도 없기 때문에 C언어는 꼭 배워두면 좋은 언어라고 생각된다. (물론 C언어를 배운 뒤에 다른 언어를 배워두는 것은 강력 추천한다. 개인적으로 파이썬은 정말 매력적인 언어다.)

'프로그래밍 > C' 카테고리의 다른 글

포인터? 포인터변수? 포인터의 이해  (0) 2013.04.19
Double linked list with using array  (0) 2013.04.19
함수 포인터  (0) 2013.04.19
linked list [펌]  (0) 2013.04.19
Double linked list  (0) 2013.04.19
//
프로그래밍/java 2013. 2. 3. 01:40

1. 디버그 모드로 실행하기

프로그램을 디버깅하려면 디버그 모두로 실행해야 한다. 디버그 모드로 프로그램을 실행할 때는 메뉴바의 Run > Debug As를 이용하면 된다. 메뉴바에서 Run > Debug를 선택하면 Debug 다이얼로그가 뜨며,  Java Application에서 실행하려는 설정을 선택하고, Debug버튼을 누르면 프로그램이 디버그 모드로 실행된다.


 

만약, 이클립스 디버그에 관해 별도의 세팅을 하지 않은 경우에 아래와 같이 다이얼로그가 뜨며, 여기서 Java Application으로 프로젝트를 생성한다. 생성 방법은 Java Application노드에서 오른쪽 버튼 클릭 > New를 클릭하자.

 

그러면, 아래와 같은 다이얼로그가 나타난다.

위의 그림과 같이 Entry Point를 설정해 준다. 즉, main메소드가 있는 클래스의 이름을 셋팅해주고 기타 등등의 설정을 한후 Debug버튼을 클릭하면 디버그가 실행이 된다.

 

아래 그림은 Debug 다이얼로그에서 Main탭의 Stop in main 체크박스에 체크한 상태에서 프로그램을 디버그 모드로 실행한 모습이다. Stop in main 체크박스에 체크했기 때문에, main()매서드의 첫 코드가 실행되기 직전에 진행이 멈추었다. 이렇게 멈춘 프로그램을 계속하려면, Debug 뷰의 툴바에서 Resume 버튼을 누른다.

 

2. 브레이크포인트 (Breakpoint) 설정하기

작성한 프로그램이 의도대로 실행되지 않는다면, 의심되는 부분을 집중적으로 살펴봐야 하는데, 바로 이럴 때 사용하는 것이 브레이크포인트이다.

Eclipse는 프로그램을 실행하다가 브레이크포인트를 만나면 프로그램의 실행을 멈추고 에디터에 브레이크포인트가 지정된 행을 하이라이트한다. 이상태에서 프로그램을 한 단계씩 실행시키며 프로그램의 흐름이 원하는 대로 진행되는지, 각 변수나 수식의 값이 제대로 설정되고 있는지를 확인 할 수 있다. 브레이크포인트는 디버그 모드로 실행될 때만 의미가 있다.

 

브레이크포인트를 사용해보자. 에디터에서 브레이크포인트를 지정하고 싶은 위치에 에디터의 왼쪽에 있는 마커(marker bar)를 더블클릭하거나 마커바에서 오른쪽 버튼 클릭 > Toggle Breakpoint를 선택해도 된다. 브레이크포인트가 추가되면 마커바에 파란색 동그라미로 표시된다. 삭제는 파란색 동그라미를 더블클릭하면 제거된다.

 

브레이크포인트를 설정하고 디버그를 실행하면 아래와 같은 그림이 나온다.

설정된 브레이크포인트들은 [Breakpoints View]에 전부 리스트 되며 설정된 브레이크포인트는 Breakpoints View에서 해당 항목을 check, uncheck 함에 따라 활성화 또는 비활성화된다

 

 * 브레이크포인트 활성화/비활성화

상황에 따라 브레이크포인트를 활성화하거나 비활성화할 수 있다. 활성화 상태에서 브레이크포인트의 팝업 메뉴중 Disable Breakpoint를 선택하면 비활성화 된다. 비활성화 브레이크포인트는 흰색 동그라미로 표시되고, 이 상태에서는 프로그램의 실행을 멈추지 않는다. 이는 특정 브레이크포인에서 실행을 멈추지 않고 싶지 않지만, 그렇다고 삭제하고 싶지 않은 경우에 이용한다.

비활성화를 활성화 하려면 팝업 메뉴에서 Enable Breakpoint를 선택하면 된다. 

 

루프 안에 설정된 브레이크포인트의 반복 횟수가 많을 경우(오류로 인한 무한 로프) 특정 회수에 대해서만 프로그램이 멈추게 하기 위해서는 브레이크포인트가 설정된 마커바에서 오른쪽 버튼의 팝업 메뉴의 [Breakpoint properties]를 눌러 나타나는 팝업 창의 [Hit Count]를 체크하고 방문 횟수를 입력한다.

 

또는 Hit Count를 설정하려는 브레이크포인틀 선택한 다음 컨텍스트 메뉴에서 Hit Count를 선택하려는 브레이크포인트를 선택한 다음 컨텍스트 메뉴에서 Hit Count를 선택하면 아래와 같은 그림이 뜨며, 여기에 적절한 숫자를 입력하면 된다.

 

브레이크포인트에 Hit Count가 설정되면, Breakpoint 뷰에서 해당 브레이크포인트 옆에 아래 그림과 같이 Hit Count 숫자가 표시된다.

 

3. 디버그 진행하기

설정한 환경 (breakpoint, hit count, stop in main...) 에 따라 프로그램의 진행을 수동으로 관리할 수 있다. 여기에서는 [Debug View]의 툴 바에 있는 메뉴들을 중심으로 Debug 진행 관리 방법을 살펴보자.

 

(1) Resume (F8): 멈췄던 쓰레드 다시 진행. 다음 브레이크포인트까지 계속 진행

(2) Suspend: 쓰레드를 멈춤

(3) Terminate: 프로그램 종료

(4) Step Into (F5): 스텝 단위로 프로그램 실행, 메서드가 호출될 경우 그 메서드 안으로 이동

(5) Step Over (F6): 메서드가 호출되더라도 메서드 안으로 이동하지 않고 현재 코드 진행

(6) Step Return (F7): 현재 메서드로부터 리턴. 메서드 호출부로 위치 이동

(7) Drop to Frame: 특정 메서드를 실행하다 그 메서드의 처음부터 다시 실행

(8) Step Filtering: 디버깅 도중 디버깅 대상이 되지 않는 메서드 안으로는 들어가지 않게 설정하는 곳. [Window > Preferences > Java > Debug > Step Filtering]에서 설정

 

아래 그림과 같이 Debugging을 하며 관련된 변수들을 관찰할 수 있는 창이 있는데 이 창이[Variables View]이다. 현재 가용한 변수들이 나열되고 현재 진행 시점에 할당되어 있는 값을 볼 수 있다.

 

[Display View] 현재 스택 프레임의 컨텍스트에서 실행할 수 있는 모든 종류의 수식을 입력 및 실행이 가능하다. 원본 코드의 수정 없이 다양한 형태로 메서드나 변수 값들을 또는 그 조합 결과를 확인해 볼 수 있다. [Window > Show View > Display] 로 Display View를 활성화 시킨다. 관찰하고자 하는 수식이나 메서드들을 기술해 놓는다. Debugging을 하면서 현재 Display View에 기술된 수식 또는 메서드의 상태 값을 알기 위해서는 해당 항목을 선택한 수 뷰 툴바의 [Display Result of Evaluating Selected Test] 또는 [Ctrl + Shift + D]를 누르면 값을 보여준다. 잘못된 입력이나 값을 알 수 없는 상황일 경우 에러를 보여준다.

 

[Inspect]는 Display View에서는 결과를 문자열로만 파악할 수 있다. 때문에 객체의 상태를 알기 위해서는 다른 방법을 사용해야 하며 그 중 하나가 Inspect 기능을 이용하는 것이다. Inspect 는 관찰 대상 수식을 선택하고 컨텍스트 메뉴에서 Inspect를 선택 (Ctrl + Shift + I)하는 것이다. 하지만 Inspect는 일시적인 관찰 방법이며 자세한 관찰을 하고 싶을 경우 [Ctrl + Shift + I]를 다시 눌러 Expression View 로 대상을 옮겨 관찰한다.

 

[Watch] 특정 수식을 지속적으로 관찰하고 싶을 경우 inspect 기능이나 Display View를 이용하는 것은 번거로울 수 있다. 이런 때 Watch 기능이 아주 유용할 수 있다. Watch 기능은 Expressions View안에서 작동한다. 위 그림에서 작은 '(X+Y)' 아이콘이 붙은 항목들이 Watch 기능이 적용되고 있는 것들이다. Watch 항목은 Expressions View 내에서 [컨텍스트 메뉴 > Add Watch Expression]을 눌러 나타나는 [Add Watch Expression] 위한 팝업 창에 여러 가지 수식을 입력하여 지속 관찰할 수 있다.

//
프로그래밍/아두이노 2013. 1. 31. 20:33



//
프로그래밍 2012. 12. 8. 09:02


vrapper_0.26.1_20121124.zip


플러그인 , feature 에 jar 카피

'프로그래밍' 카테고리의 다른 글

git 명령어 및 이용  (0) 2014.03.23
Git 을 사용한 소스 버전관리  (0) 2014.03.17
프로세스와 메모리의 이야기  (0) 2013.08.04
IA32 레지스터에 관한 글-1  (0) 2013.08.04
이클립스 vim 플러그인  (0) 2012.12.01
//
프로그래밍 2012. 12. 1. 00:47

 help > install new software > add > " http://vrapper.sourceforge.net/update-site/stable"


'프로그래밍' 카테고리의 다른 글

git 명령어 및 이용  (0) 2014.03.23
Git 을 사용한 소스 버전관리  (0) 2014.03.17
프로세스와 메모리의 이야기  (0) 2013.08.04
IA32 레지스터에 관한 글-1  (0) 2013.08.04
이클립스 vim 플러그인  (0) 2012.12.08
//