본문 바로가기

전체 글36

2. 메모리 누수 없는 C언어 프로그래밍 (3/3) - 레퍼런스 카운트 2부 이전 포스트들에서 다룬 규칙을 다시 한 번 더 확인해보자. (규칙1) 가능하다면 메모리 할당과 해제는 한 코드 블록 안에서 한 번만 (규칙2) 메모리 할당과 해제가 한 블록 이내에서 이뤄질 수 없다면 레퍼런스 카운트를 활용 이전 포스트에 이어지는 내용으로 이전 포스트를 읽지 않았다면 먼저 읽기를 강력히 권한다. ("2. 메모리 누수 없는 C언어 프로그래밍 (2/3) - 레퍼런스 카운트 1부" (www.kernelpanic.kr/35)) 이전 포스트에서는 규칙 2를 구현하는 간단한 방법에 대해서 살펴보았다. 이번 포스트에서는 앞에서 살펴본 구현의 취약점을 살펴보고 코드를 좀 더 정교하게 구현하는 방법에 대해서 살펴본다. 레퍼런스 카운트가 제대로 해제되지 않는 경우 앞서 우리는 레퍼런스 카운트(이하 rc)를.. 2021. 5. 13.
2. 메모리 누수 없는 C언어 프로그래밍 (2/3) - 레퍼런스 카운트 1부 앞선 포스트에서 C언어에서 메모리 누수를 피할 수 있는 두 가지 규칙을 소개하고, 규칙1 "가능하다면 메모리 할당과 해제는 한 코드 블록 안에서 한 번만"에 대해서 다뤘다. (www.kernelpanic.kr/34) 규칙1은 간단하고 강력하지만 규칙1을 적용할 수 없는 예외적인 상황들이 있다. 이 경우에 사용 가능한 방법이 규칙 2 "메모리 할당과 해제가 한 블록 이내에서 이뤄질 수 없다면 레퍼런스 카운터를 활용"이다. 이번 포스트에서는 어떤 경우에 규칙1을 적용할 수 없는지, 그리고 레퍼런스 카운터를 활용하는 방법에 대해서 다루도록 한다. (규칙1) 가능하다면 메모리 할당과 해제는 한 코드 블록 안에서 한 번만 (규칙2) 메모리 할당과 해제가 한 블록 이내에서 이뤄질 수 없다면 레퍼런스 카운트를 활용 .. 2021. 5. 5.
2. 메모리 누수 없는 C언어 프로그래밍 (1/3) - 메모리 할당과 해제는 한 블록에서 C언어에서 메모리 관리는 실력 여하를 막론하고 꽤나 골치아픈 주제이다. 프로그램 규모가 커지면 동적으로 할당된 메모리 개수가 늘어나게 되는데, 개발자도 사람인 이상 이처럼 할당된 메모리들의 생명주기를 하나도 빠짐없이 관리하는 것은 어렵기 때문이다. 따라서 C개발자들은 메모리 문제를 회피하기 위한 여러가지 테크닉들이 개발하였다. 이번 주제에서는 메모리 누수를 회피할 수 있는 두 가지 규칙과 몇 가지 테크닉들을 소개한다. 이 방법들을 모두 지킨다고 해서 메모리 누수 문제를 100%는 아니더라도 대부분의 메모리 누수 문제들을 피할 수 있다. 소개할 두 가지 규칙은 다음과 같다. 가능하다면 메모리 할당과 해제는 한 코드 블록 안에서 한 번만 메모리 할당과 해제가 한 블록 이내에서 이뤄질 수 없다면 레퍼런스 카운.. 2021. 4. 28.
1. C언어 메모리 관리의 어려움 (2/2) - C언어 메모리 문제 유형들 본 포스트에서는 C언어에서 쉽게 겪을 수 있는 메모리 문제들의 유형을 다룬다. 만약 C언어 메모리 구조에 대해서 잘 알지 못한다면, 앞선 포스트(www.kernelpanic.kr/32)를 먼저 보고오자. C언어 메모리 구조 및 어떤 종류의 메모리 문제 유형들이 있는지 잘 안다면 다음 포스트(www.kernelpanic.kr/34)로 넘어가면 된다. 이번 주제에서 C의 모든 메모리 문제를 해결할 수 있는 솔루션을 제시하지는 않는다. 그럴수도 없다. 다만 메모리 릭과 댕글링 포인터 이슈를 회피하는 테크닉에 대해서 다룰 예정이다. 따라서 메모리 릭과 댕글링 포인터 문제 유형에 대해서 확인하고 가면 된다. 1.2.1 메모리 릭(Memory Leak) 메모리 릭은 프로그램이 불필요한 메모리를 계속 점유하는 현상이.. 2021. 4. 28.
1. C언어 메모리 관리의 어려움 (1/2) - C언어 메모리 구조 포인터는 C언어의 가장 큰 강점이자 우리를 늘 메모리 관련 문제로 괴롭히는 큰 위험요인이다. 많은 좋은 프로그램들이 C언어의 포인터 기교를 사용해서 엄청난 메모리 / 성능상의 이득을 얻었다. 몇년도 전이지만, 아직도 리눅스 커널과 리눅스의 tcp/ip 스택에서 C언어 포인터를 활용한 것을 처음 봤을때의 신선한 충격이 생생하다. 훌륭한 프로그래밍 언어들이 많이 나왔지만 여전히 C의 포인터만큼 HW 직관적이고 강력한 개념은 없는 것 같다. 그러나 동시에 포인터는 원인을 찾기 어려운 버그들을 만들어 내곤 한다. 특히 어떤 버그들은 원인을 찾고서도 고치기가 몹시 난해한 경우들도 있다. 이는 훌륭한 프로그램에서도 예외가 아니다. 모질라 재단은 파이어폭스의 메모리 누수 문제로 수 년간 씨름하다가 결국 C++로 개발.. 2021. 4. 27.
3-4. CSS로 어플리케이션 꾸미기 앱 개발에서 디자인은 정말 중요한 요소이다. 때로는 앱의 본질적인 기능, 성능보다도 디자인이 우선시 되는 경우들이 종종 있는 것 같다. Gtk4 역시 개발자들의 디자인을 돕기 위한 강력한 기능을 제공한다. 2016년에 Gtk에는 중대한 변경점이 있었다. 기존 Gtk(당시는 Gtk3)는 테마를 통해서 어플리케이션의 디자인을 변경했었다. 테마는 데스크탑 전체 어플리케이션에 적용되기 때문에, 데스크탑의 통일성을 유지하는데 용이했다. 하지만 개별 어플리케이션 입장에서는 자기만의 특별한 디자인을 적용하기는 어려웠다. 이에 Gtk에서 찾은 해결책이 Css를 사용한 앱 디자인이다. 이번 포스트에서는 어떻게 CSS를 사용해서 Gtk 앱을 디자인 하는지 다룬다. 관련 블로그: blog.gtk.org/tag/css/ 3... 2021. 4. 24.
3-3. WYSIWYG로 UI 구성하기 - Glade 현재 시점(2021.04.24)에서는 Glade가 Gtk4를 지원하지 않는다. (Gtk3까지만 지원) WYSIWYG는 What You See Is What You Get의 준말로, 말 그대로 화면에 표시되는 모습을 그래도 결과물로 얻을 수 있는 것을 의미한다. 대표적인 WYSIWYG 프로그램으로 MS오피스 제품군이 있다. Gtk에서도 Glade를 사용하면 WYSIWYG로 UI를 구성할 수 있다. Glade는 Gnome 재단에서 공식적으로 지원하는 UI 개발 툴이다. 3.3.1 간단한 Glade 사용법 Glade 사용법을 설명하기에 앞서 고백할 것이 있다. 나는 Glade를 잘 사용하기 못한다. 물론 UI 틀을 구성할 때는 대안이 없기 때문에 Glade를 사용하기는 하지만, 기초적인 기능 외에는 잘 사용하.. 2021. 4. 21.
3-2. 간단한 어플리케이션 만들기 (Container) 앞선 포스트에서는 윈도우에 하나의 위젯을 배치하는 방법에 대해서 살펴보았다. 그런데 우리가 사용하는 대부분의 어플리케이션은 여러개의 위젯으로 구성되어 있다. 이처럼 윈도우에 여러개의 위젯을 배치하고 싶을 때 사용하는 위젯이 Container이다. Container 위젯들은 여러개의 자식 위젯들을 가질 수 있으며, 위젯에 따라서 다양한 유형으로 자식 위젯들을 보여준다. 이번 포스트에서는 가장 많이 사용되는 Container 위젯들인 GtkBox, GtkGrid, GtkNotebook에 대해서 다룬다. 3.2.1 한 줄로 줄세울때는 - Box Box는 수평 혹은 수직으로 연속된 방향으로 위젯을 배치할 수 있게 해주는 Conatiner이다. 다음 코드와 결과물을 보면서 Box가 어떻게 사용되는지 알아보자. /.. 2021. 4. 20.
3-1. 간단한 어플리케이션 만들기 (Window, Label, Button) 앞으로 약 3개정도의 포스트를 통해서 Gtk4 프로그래밍 기초에 대해서 다루려고 한다. 기본적인 내용 구성은 많은 부분을 Gtk4 공식 튜토리얼 문서(developer.gnome.org/gtk4/stable/gtk-getting-started.html)에서 가져오되, 내가 생각하기에 보완이 필요한 부분은 내용을 보충하고, 불필요한 내용은 쳐내면서 내용을 재구성할 예정이다. 3.1.1 간단한 앱 그리기 Gtk의 첫 시작으로 창 하나를 띄우는 간단한 앱을 제작하려한다. 이번 절에서는 Gtk 어플리케이션이 가지는 기본적인 구조와, 시그널과 콜백 함수를 사용하는 기본적인 방법에 대해서 살펴볼 예정이다. 그리고 GtkWindow 위젯(혹은 GtkApplicationWindow 위젯)의 속성을 관리하는 방법에 대해.. 2021. 4. 18.