GLib 기능을 사용하는 이유는 무엇입니까?

GLib 기능을 사용하는 이유는 무엇입니까?

C 및 GTK+에서 프로그래밍하는 동안 사용하는 것이 "더 나은" 이유는 무엇입니까?g_strdup_printf,g_free,g_strcmp0GLIB 동료들은?

일반적으로 GLib의 목적은 유틸리티 및 휴대성 라이브러리입니다.그것 자체가 그것을 사용하는 것을 고려하는 이유입니다.

여러분이 언급한 특정 기능들은 모두 C 표준 라이브러리 변형 위에 추가적인 기능을 제공합니다.

• g_strdup_printf는 것과 같은.sprintf, 하지만 실제로 버퍼를 할당하고 버퍼의 크기에 대한 추측을 저장합니다. (반환 값은 다음과 같아야 합니다.)g_freed.)
• g_free는 것과 같은.free, 그러나 NULL-포인트가 있는지 확인합니다.
• g_strcmp0는 것과 같은.strcmp, 그러나 NULL 포인터를 빈 문자열처럼 처리하여 앞에 정렬합니다.

여러 운영 체제에서 일관된 동작을 제공합니다.휴대성이 좋은 것입니다.

Linux 이외의 다른 유닉스 환경에서는 또는 프로그램이 Windows에서 컴파일된 경우 해당 기능 중 일부가 대상 운영 체제에서 존재하지 않거나 다르게 동작할 수 있습니다.

glib 버전을 사용하면 일관된 동작을 보장할 수 있습니다.

GLib은 컬렉션 유형(링크 리스트, 배열, 해시 테이블 등)과 같은 모든 프로그래밍 언어에서 요즘 기대할 수 있는 휴대성과 기본적인 것을 제공합니다.다음은 GLib이 제공할 수 있는 혜택입니다.

휴대성

---

GLib의 요점은 C 표준이 아니라 표준의 구현을 위해 휴대할 수 있도록 하는 것입니다.GLib은 코드를 그런 고약한 버그가 있는 플랫폼으로 포팅해야 할 때까지 일견 쓸모없어 보일 수 있는 알려진 별난 것들을 처리합니다.

예를 들어 보겠습니다.g_free, 많은 사람들이 비판하는 것처럼.C99가 작동해야 한다고 해도 실패하는 플랫폼이 있습니다.그 수표는 적어도 1998년 이후로 존재합니다. (나는 그것을 git history에서 추적했습니다.)더 이상 필요 없다고 하시는 분들도 계시겠지만, 2017년에도 확인하는 회사에서 일했습니다.NULL부르기 전에free그렇지 않으면 내장된 플랫폼에 충돌할 수 있기 때문입니다.또한 심각한 메모리 디버깅을 수행하고자 할 때 코드를 삽입하기 위한 래퍼 역할도 합니다.

가독성

---

휴대성을 향상시킬 뿐만 아니라 많은 언어의 함정을 피할 수 있도록 도와주는 몇몇 래퍼 기능을 제공함으로써 코드의 가독성을 향상시키는데 도움을 줍니다.몇 분이 테스트를 하십니까?malloc돌아오는지 보다NULL? 복구할 방법이 있는 사람이 몇 명이나 됩니까?NULL, 기본적으로 기억이 안 나는데요?

g_malloc사용자가 원하는 것을 할당할 수 없으면 응용 프로그램을 중단합니다. 많은 응용 프로그램에서 이는 사용자가 원하는 동작일 뿐입니다.실패할 수도 있는 매우 큰 할당의 경우,g_try_malloc하지만, 할 수 이는 malloc와 동일하지만, 여전히 도구로 사용할 수 있는 포장지라는 이점을 제공합니다.

쓰기 가능:

char *buffer = g_malloc(30);
/* Do something with it ... */
g_free (buffer);

을 하고 하고자 하는 에 집중할 수 있도록 ...정신을 frees하고 개발자가 자신이 달성하고자 하는 작업에 집중할 수 있도록 합니다.또한 다음을 사용하여 프로그램을 작성하려고 하기 때문에 나중에 프로그램이 중단되는 것을 방지합니다.NULL포인터가 있으면 할당된 부분을 추적해야 합니다.

표준 C 라이브러리는 트랩으로 가득 차 있으며, 작성하는 코드 한 줄을 모두 마이크로 관리할 필요가 없어 다행입니다.몇 가지 기능에 대해서는 맨페이지의 벅스 부분만 읽으시면 알 수 있습니다.오류를 확인할 수 있는 보일러 플레이트 코드가 적으면 코드를 쉽게 읽을 수 있어 유지보수성이 향상되고 버그가 적게 발생합니다.

특징들

---

또 다른 점은 GLib이 제공하는 모든 컬렉션 유형이 다시 구현할 필요가 없다는 것입니다.연결된 목록을 다시 구현하는 것이 쉽다고 해서 해야 하는 것은 아닙니다.저는 몇 가지 링크된 목록 구현이 포함된 코드를 발송하는 다른 회사에서 일했는데, 몇몇 개발자들은 단지 Not Invented Here 신드롬을 가지고 자신들의 것을 재개발할 것이기 때문입니다.GLib과 같은 일반적이고 철저하게 테스트된 광범위한 라이브러리는 이러한 말도 안 되는 일을 방지하는 데 도움이 됩니다.아주 구체적인 성능 제약이 없는 한 그 물건을 재개발해서는 안 됩니다.

이러한 동작은 GTK+가 지원하는 모든 플랫폼에서 잘 정의되어 있으며, 때로는 부분적으로 작동할 수도 있는 기본 기능과는 대조적입니다.

저는 이것이 의도된 것은 맞지만 잘 실행되지 않았다고 말해야겠습니다.포인터를 여러 번 놓아도 프로그램이 충돌하거나 타지 않아 다행입니다.또는 NULL 문자열을 정렬합니다.하지만 그건 복합적인 축복입니다.코드에서 이러한 고약한 버그를 발견하지 못하도록 합니다.비표준 기능에 의존하기 때문에 프로그램을 포팅하는 데 어려움을 겪을 뿐만 아니라 코드가 버그가 있어 한 번도 발견하지 못했기 때문에 매우 어려움을 겪을 것입니다.

10년 전에는 Gnome lib을 사용하는 것이 타당했을지 모르지만, 지금은 유산 부채입니다.C89는 매우 안정적인 기능과 구문을 가진 세계에서 가장 표준적인 언어이므로 다른 사람의 C89 코드를 디버깅할 수 있습니다.

대조적으로 Gnome의 glib은 C 표준 이외의 기능을 변경하므로 C로 된 모호한 래퍼 코드 디버깅을 처리할 수 있을 뿐만 아니라 Gnome이 래퍼 기능을 변경하기 때문에 코드가 작동하지 않을 수도 있습니다.

그림 A: g_snprintf()

표준 sprintf() 기능의 보다 안전한 형태.출력은 n자(종료 null 문자 포함)를 초과하지 않도록 보장되므로 버퍼 오버플로가 발생하지 않도록 보장하기 쉽습니다.

g_strdup_printf()도 참조하십시오.

1.2.3 이전 버전의 GLib에서는 출력이 잘린 경우 이 함수가 -1을 반환할 수 있으며 잘린 문자열은 null로 종료되지 않을 수 있습니다.1.3.12 이전 버전에서는 출력 문자열의 길이를 반환합니다.

g_snprintf()의 반환 값은 ISO C99에서 표준화된 snprintf() 함수를 준수합니다.출력 문자열의 길이를 반환하는 기존 snprintf()와는 다릅니다.

형식 문자열에는 Single Unix 규격에 지정된 대로 위치 매개 변수가 포함될 수 있습니다.

Gnome을 대체할 링크드 리스트를 작성하게 된 것에 대한 감격이 덜합니다. 그리고 또 다른 버전의 snprintf()와 조용히 malloc() 메모리를 저장하는 crappy 래퍼 코드를 작성하여 C 코딩의 절대적인 최대치인 "Always malloc() and free() in same scope"를 g_strdup_printf()로 대체할 수 있습니다.

g_strdup_printf()

표준 C sprintf() 함수와 유사하지만 필요한 최대 공간을 계산하고 결과를 유지하기 위해 메모리를 할당하기 때문에 더 안전합니다.반환된 문자열은 더 이상 필요하지 않을 때 g_free()로 해제해야 합니다.

여기에 gchar를 char로 변경하거나 gboolean을 boolean을 boolean으로 변경하는 등 "유용한" 일을 하기 위해 코드에 수많은 문자열 변경을 하는 스릴을 더하면 내 서브버전 비교가 전화번호부가 될 때까지 메스꺼움이 발생합니다.더 나쁜 것은, 당신은 결국 점점 더 많은 코드를 변경해야 한다는 것입니다. 왜냐하면 이 것들은 .h 파일들 전체에 흩어져 있기 때문에, 그것은 배에 실린 시체처럼 계속해서 거대한 혼란으로 확대되기 때문입니다.

계약직 범위를 정하고 어디서든 glib.h를 찾는다면, RUN!!!그냥 안 된다고 해요!

추신: 소스를 다운로드하고, Gnome 고유의 유형을 모두 제거하고, 다시 컴파일하여 자신만의 "g_"-less functions sorta를 만들고, 어느 정도 효과가 있으며, 시간을 많이 절약할 수 있습니다.

전시 B: g_strdup_printf()

그놈에서 온 더 끔찍한 그놈 크라폴라.Gnome에는 g_strdup_vprintf()와 같이 반환된 문자열을 보관하는 데 필요한 저장소의 양을 "마법적으로" 알고 있는 "사랑스러운" 기능이 많이 있습니다. 저는 "마법적인" 기능 뒤를 살펴볼 기회가 있었습니다.이것은 Cever의 가장 끔찍한 학대로 제 상을 받습니다.

모든 래퍼 함수를 통해 g_strdup_vprintf()를 계속 추적하면 gmessages.c.

/**
 * g_printf_string_upper_bound:
 * @format: the format string. See the printf() documentation
 * @args: the parameters to be inserted into the format string
 *
 * Calculates the maximum space needed to store the output
 * of the sprintf() function.
 *
 * Returns: the maximum space needed to store the formatted string
 */
gsize
g_printf_string_upper_bound (const gchar *format,
                             va_list      args)
{
  gchar c;
  return _g_vsnprintf (&c, 1, format, args) + 1;
}

모든 printf() 기능이 절대 0일 때 snot보다 느릴 뿐만 아니라, 오버플로를 보장하는 저장을 위해 바이트 전체(예, gcharc 전체)를 할당한다는 것을 알게 될 것입니다. 하지만 누가 신경 쓰겠습니까?()를 말로크하는 데 필요한 줄의 길이를 얻을 수 있습니다. 왜냐하면 그들은 돌아서서 전체 인쇄물 ()을 다시 수행할 것이기 때문입니다. 이번에는 충분한 저장 공간만으로 "마법적으로" 작업을 수행할 수 있습니다.

물론 그 크기에 +1을 더할 것입니다. 그래서 당연히 끔찍한 비용을 지불해야 할 누런 터미네이터를 사용할 수 있는 여지가 있을 것입니다. 하지만 그들은 그것을 코드 깊숙이 숨겨놨기 때문에 그냥 포기하고 맹목적으로 사용할 것이고 이것이 얼마나 거대한 두뇌 조각인지 알아채지 못할 것이라고 장담합니다.이런, 고마워 얘들아.난 그저 기어 다니는 내 암호가 너무 좋아요.

g_vsnprintf() 함수가 당신을 버리게 하지 마세요. 왜냐하면 gprintfint.h를 사용하면 작은 보석은 평범한 오래된 바닐라 vsnprintf()의 다른 이름에 불과하다는 것을 알게 될 것이기 때문입니다.

/* GLIB - Library of useful routines for C programming
 * Copyright (C) 1995-1997  Peter Mattis, Spencer Kimball and Josh MacDonald
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the
 * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
 * Boston, MA 02111-1307, USA.
 */

/*
 * Modified by the GLib Team and others 2002.  See the AUTHORS
 * file for a list of people on the GLib Team.  See the ChangeLog
 * files for a list of changes.  These files are distributed with
 * GLib at ftp://ftp.gtk.org/pub/gtk/. 
 */

#ifndef __G_PRINTFINT_H__
#define __G_PRINTFINT_H__

#ifdef HAVE_GOOD_PRINTF

#define _g_printf    printf
#define _g_fprintf   fprintf
#define _g_sprintf   sprintf
#define _g_snprintf  snprintf

#define _g_vprintf   vprintf
#define _g_vfprintf  vfprintf
#define _g_vsprintf  vsprintf
#define _g_vsnprintf vsnprintf

#else

#include "gnulib/printf.h"

#define _g_printf    _g_gnulib_printf
#define _g_fprintf   _g_gnulib_fprintf
#define _g_sprintf   _g_gnulib_sprintf
#define _g_snprintf  _g_gnulib_snprintf

#define _g_vprintf   _g_gnulib_vprintf
#define _g_vfprintf  _g_gnulib_vfprintf
#define _g_vsprintf  _g_gnulib_vsprintf
#define _g_vsnprintf _g_gnulib_vsnprintf

#endif

#endif /* __G_PRINTF_H__ */

Gnome과 함께 작업하기 전에 Oz의 마법사를 다시 보는 것이 좋습니다. 그래서 커튼 뒤를 보지 않는 것을 알 것입니다.내 악몽에 온 걸 환영합니다!

Gnome이 C보다 더 안정적이라고 생각하는 사람은 비판적 사고가 많이 부족합니다.성능과 투명성을 STL에서 더 잘 된 몇 가지 좋은 것과 교환합니다.

여기 최신 정보가 있습니다.개발자가 실수를 깨달은 것 같습니다.

g_mem_is_system_malloc는 버전 2.46 이후로 사용되지 않으므로 새로 작성된 코드에서 사용하지 마십시오.

GLib은 항상 시스템 malloc을 사용하므로 이 함수는 항상 TRUE를 반환합니다.

g_malloc()에서 사용하는 할당자가 시스템의 malloc 구현인지 확인합니다.malloc()로 할당된 TRUE 메모리를 반환하면 g_malloc()로 할당된 메모리와 교환하여 사용할 수 있습니다.이 기능은 GLIB 기반이 아닌 API에 의해 반환되는 할당된 메모리의 추가 복사본을 방지하는 데 유용합니다.

https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-mem-is-system-malloc

언급URL : https://stackoverflow.com/questions/2240154/why-use-glib-functions