Keep Learning Everyday: 9月 2017

2017年9月21日星期四

cross compiler arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別

http://fanli7.net/a/caozuoxitong/Linux/20140810/525891.html

一. 什麼是ABI和EABI
1) ABI: 二進制應用程序接口(Application Binary Interface (ABI) for the ARM Architecture)
      在計算機中，應用二進制接口描述了應用程序（或者其他類型）和操作系統之間或其他應用程序的低級接口.
      ABI涵蓋了各種細節，如：
      數據類型的大小、布局和對齊;
      調用約定（控制着函數的参數如何傳送以及如何接受返回值），例如，是所有的参數都通過棧傳遞，還是部分参數通過寄存器傳遞；哪個寄存器用於哪個函數参數；通過棧傳遞的第一個函數参數是最先push到棧上還是最後；
      系統調用的編碼和一個應用如何向操作系統進行系統調用；
      以及在一個完整的操作系統ABI中，目標文件的二進制格式、程序庫等等。
      一個完整的ABI，像Intel二進制兼容標准 (iBCS) ，允許支持它的操作系統上的程序不經修改在其他支持此ABI的操作體統上運行。
      ABI不同於應用程序接口（API），API定義了源代碼和庫之間的接口，因此同样的代碼可以在支持這個API的任何系統中編譯，ABI允許編譯好的目標代碼在使用兼容ABI的系統中無需改動就能運行。

2) EABI: 嵌入式ABI
      嵌入式應用二進制接口指定了文件格式、數據類型、寄存器使用、堆積組織優化和在一個嵌入式軟件中的参數的標准約定。
      開發者使用自己的匯編語言也可以使用EABI作为與兼容的編譯器生成的匯編語言的接口。
      支持EABI的編譯器創建的目標文件可以和使用類似編譯器產生的代碼兼容，這样允許開發者鏈接一個由不同編譯器產生的庫。
      EABI與關於通用計算機的ABI的主要區別是應用程序代碼中允許使用特權指令，不需要動態鏈接（有時是禁止的），和更緊湊的堆棧幀組織用來節省內存。廣泛使用EABI的有Power PC和ARM.

二. gnueabi相關的兩個交叉編譯器: gnueabi和gnueabihf
在debian源裏這兩個交叉編譯器的定義如下:
      gcc-arm-linux-gnueabi - The GNU C compiler for armel architecture
      gcc-arm-linux-gnueabihf - The GNU C compiler for armhf architecture
可見這兩個交叉編譯器适用於armel和armhf兩個不同的架構, armel和armhf這兩種架構在對待浮點運算采取了不同的策略(有fpu的arm才能支持這兩種浮點運算策略)

其實這兩個交叉編譯器只不過是gcc的選項-mfloat-abi的默認值不同. gcc的選項-mfloat-abi有三種值soft,softfp,hard(其中後兩者都要求arm裏有fpu浮點運算單元,soft與後兩者是兼容的，但softfp和hard兩種模式互不兼容)：
soft : 不用fpu進行浮點計算，即使有fpu浮點運算單元也不用,而是使用軟件模式。
softfp : armel架構(對應的編譯器为gcc-arm-linux-gnueabi)采用的默認值，用fpu計算，但是傳参數用普通寄存器傳，這样中斷的時候，只需要保存普通寄存器，中斷負荷小，但是参數需要轉換成浮點的再計算。
hard : armhf架構(對應的編譯器gcc-arm-linux-gnueabihf)采用的默認值，用fpu計算，傳参數也用fpu中的浮點寄存器傳，省去了轉換, 性能最好，但是中斷負荷高。

把以下測試使用的c文件內容保存成mfloat.c：
#include <stdio.h>
int main(void)
{
                  double a,b,c;
                  a = 23.543;
                  b = 323.234;
                  c = b/a;
                  printf("the 13/2 = %f\n", c);
                  printf("hello world !\n");
                  return 0;
}

1)使用arm-linux-gnueabihf-gcc編譯，使用“-v”選項以獲取更詳細的信息:
# arm-linux-gnueabihf-gcc -v mfloat.c
COLLECT_GCC_OPTIONS='-v' '-march=armv7-a' '-mfloat-abi=hard' '-mfpu=vfpv3-d16' '-mthumb'
-mfloat-abi=hard，可看出使用hard硬件浮點模式。

2)使用arm-linux-gnueabi-gcc編譯:
# arm-linux-gnueabi-gcc -v mfloat.c
COLLECT_GCC_OPTIONS='-v' '-march=armv7-a' '-mfloat-abi=softfp' '-mfpu=vfpv3-d16' '-mthumb'
-mfloat-abi=softfp，可看出使用softfp模式。

三. 拓展閱讀
下文闡述了ARM代碼編譯時的軟浮點(soft-float)和硬浮點(hard-float)的編譯以及鏈接實現時的不同。從VFP浮點單元的引入到軟浮點(soft-float)和硬浮點(hard-float)的概念

VFP (vector floating-point)
      從ARMv5開始，就有可選的 Vector Floating Point (VFP) 模塊，當然最新的如 Cortex-A8, Cortex-A9 和 Cortex-A5 可以配置成不帶VFP的模式供芯片廠商選擇。
      VFP經過若幹年的發展，有VFPv2 (一些 ARM9 / ARM11)、 VFPv3-D16（只使用16個浮點寄存器，默認为32個）和VFPv3+NEON (如大多數的Cortex-A8芯片) 。對於包含NEON的ARM芯片，NEON一般和VFP公用寄存器。

硬浮點Hard-float
      編譯器將代碼直接編譯成發射给硬件浮點協處理器（浮點運算單元FPU）去執行。FPU通常有一套額外的寄存器來完成浮點参數傳遞和運算。
      使用實際的硬件浮點運算單元FPU當然會帶來性能的提升。因为往往一個浮點的函數調用需要幾個或者幾十個時钟周期。

軟浮點 Soft-float
      編譯器把浮點運算轉換成浮點運算的函數調用和庫函數調用，沒有FPU的指令調用，也沒有浮點寄存器的参數傳遞。浮點参數的傳遞也是通過ARM寄存器或者堆棧完成。
      現在的Linux系統默認編譯選擇使用hard-float，即使系統沒有任何浮點處理器單元，這就會產生非法指令和異常。因而一般的系統鏡像都采用軟浮點以兼容沒有VFP的處理器。

armel ABI和armhf ABI
      在armel中，關於浮點數計算的約定有三種。以gcc为例，對應的-mfloat-abi参數值有三個：soft,softfp,hard。
      soft是指所有浮點運算全部在軟件層實現，效率當然不高，會存在不必要的浮點到整數、整數到浮點的轉換，只适合於早期沒有浮點計算單元的ARM處理器；
      softfp是目前armel的默認設置，它將浮點計算交给FPU處理，但函數参數的傳遞使用通用的整型寄存器而不是FPU寄存器；
      hard則使用FPU浮點寄存器將函數参數傳遞给FPU處理。
      需要注意的是，在兼容性上，soft與後兩者是兼容的，但softfp和hard兩種模式不兼容。
      默認情況下，armel使用softfp，因此將hard模式的armel單獨作为一個abi，稱之为armhf。
      而使用hard模式，在每次浮點相關函數調用時，平均能節省20個CPU周期。對ARM這样每個周期都很重要的體系結構來說，這样的提升無疑是巨大的。
      在完全不改變源碼和配置的情況下，在一些應用程序上，使用armhf能得到20%——25%的性能提升。對一些嚴重依賴於浮點運算的程序，更是可以達到300%的性能提升。

Soft-float和hard-float的編譯選項
      在CodeSourcery gcc的編譯参數上，使用-mfloat-abi=name來指定浮點運算處理方式。-mfpu=name來指定浮點協處理的類型。
      可選類型如fpa，fpe2，fpe3，maverick，vfp，vfpv3，vfpv3-fp16，vfpv3-d16，vfpv3-d16-fp16，vfpv3xd，vfpv3xd-fp16，neon，neon-fp16，vfpv4，vfpv4-d16，fpv4-sp-d16，neon-vfpv4等。
      使用-mfloat-abi=hard (等價於-mhard-float) -mfpu=vfp來選擇編譯成硬浮點。使用-mfloat-abi=softfp就能兼容帶VFP的硬件以及soft-float的軟件實現，運行時的連接器ld.so會在執行浮點運算時對於運算單元的選擇，
      是直接的硬件調用還是庫函數調用，是執行/lib還是/lib/vfp下的libm。-mfloat-abi=soft （等價於-msoft-float）直接調用軟浮點實現庫。

在ARM RVCT工具鏈下，定義fpu模式：
   --fpu softvfp
   --fpu softvfp+vfpv2
   --fpu softvfp+vfpv3
   --fpu softvfp+vfpv_fp16
   --fpu softvfp+vfpv_d16
   --fpu softvfp+vfpv_d16_fp16.

定義浮點運算類型
   --fpmode ieee_full : 所有單精度float和雙精度double的精度都要和IEEE標准一致，具體的模式可以在運行時動態指定；
   --fpmode ieee_fixed ：舍入到最接近的實現的IEEE標准，不帶不精確的異常；
   --fpmode ieee_no_fenv ：舍入到最接近的實現的IEEE標准，不帶異常；
   --fpmode std ：非規格數flush到0、舍入到最接近的實現的IEEE標准，不帶異常；
   --fpmode fast ：更積極的優化，可能會有一點精度損失。

2017年9月14日星期四

[轉] 內核的likely()/unlikely和glib的G_LIKELY/G_UNLIKELY

內核中的 likely() 與 unlikely()

在 2.6 內核中，隨處可以見到 likely() 和 unlikely() 的身影，那麼為什麼要用它們？它們之間有什麼區別？

首先要明確：

if(likely(value)) 等價於 if(value)

if(unlikely(value)) 也等價於 if(value)

也就是說 likely() 和 unlikely() 從閱讀和理解代碼的角度來看，是一樣的！！！

這兩個宏在內核中定義如下：

#define likely(x) __builtin_expect((x),1)
#define unlikely(x) __builtin_expect((x),0)

__builtin_expect() 是 GCC (version >= 2.96）提供給程序員使用的，目的是將「分支轉移」的信息提供給編譯器，這樣編譯器可以對代碼進行優化，以減少指令跳轉帶來的性能下降。

__builtin_expect((x),1) 表示 x 的值為真的可能性更大；
__builtin_expect((x),0) 表示 x 的值為假的可能性更大。

也就是說，使用 likely() ，執行 if 後面的語句的機會更大，使用unlikely()，執行else 後面的語句的機會更大。
例如下面這段代碼，作者就認為 prev 不等於 next 的可能性更大，

if (likely(prev != next)) {
next->timestamp = now;
...
} else {
...;
}

通過這種方式，編譯器在編譯過程中，會將可能性更大的代碼緊跟著起面的代碼，從而減少指令跳轉帶來的性能上的下降。

下面以兩個例子來加深這種理解：

第一個例子： example1.c

int testfun(int x)
{
if(__builtin_expect(x, 0)) {
^^^--- We instruct the compiler, "else" block is more probable
x = 5;
x = x * x;
} else {
x = 6;
}
return x;
}

在這個例子中，我們認為 x 為0的可能性更大

編譯以後，通過 objdump 來觀察彙編指令，在我的 2.4 內核機器上，結果如下：

# gcc -O2 -c example1.c
# objdump -d example1.o

Disassembly of section .text:

00000000 <testfun>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 8b 45 08 mov 0x8(%ebp),%eax
6: 85 c0 test %eax,%eax
8: 75 07 jne 11 <testfun+0x11>
a: b8 06 00 00 00 mov $0x6,%eax
f: c9 leave
10: c3 ret
11: b8 19 00 00 00 mov $0x19,%eax
16: eb f7 jmp f <testfun+0xf>

可以看到，編譯器使用的是 jne （不相等跳轉）指令，並且 else block 中的代碼緊跟在後面。

8: 75 07 jne 11 <testfun+0x11>
a: b8 06 00 00 00 mov $0x6,%eax

第二個例子： example2.c

int testfun(int x)
{
if(__builtin_expect(x, 1)) {
^^^ --- We instruct the compiler, "if" block is more probable
x = 5;
x = x * x;
} else {
x = 6;
}
return x;
}

在這個例子中，我們認為 x 不為 0 的可能性更大

編譯以後，通過 objdump 來觀察彙編指令，在我的 2.4 內核機器上，結果如下：

# gcc -O2 -c example2.c
# objdump -d example2.o

Disassembly of section .text:

00000000 <testfun>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 8b 45 08 mov 0x8(%ebp),%eax
6: 85 c0 test %eax,%eax
8: 74 07 je 11 <testfun+0x11>
a: b8 19 00 00 00 mov $0x19,%eax
f: c9 leave
10: c3 ret
11: b8 06 00 00 00 mov $0x6,%eax
16: eb f7 jmp f <testfun+0xf>

這次編譯器使用的是 je （相等跳轉）指令，並且 if block 中的代碼緊跟在後面。

8: 74 07 je 11 <testfun+0x11>
a: b8 19 00 00 00 mov $0x19,%eax

G_LIKELY和G_UNLIKELY

在GTK+2.0源碼中有很多這樣的宏：G_LIKELY和G_UNLIKELY。比如下面這段代碼：

if (G_LIKELY (acat == 1))       /* allocate through magazine layer */
      {
        ThreadMemory *tmem = thread_memory_from_self();
        guint ix = SLAB_INDEX (allocator, chunk_size);
        if (G_UNLIKELY (thread_memory_magazine1_is_empty (tmem, ix)))
          {
            thread_memory_swap_magazines (tmem, ix);
            if (G_UNLIKELY (thread_memory_magazine1_is_empty (tmem, ix)))
              thread_memory_magazine1_reload (tmem, ix);
          }
        mem = thread_memory_magazine1_alloc (tmem, ix);
      }

在源碼中，宏G_LIKELY和G_UNLIKELY 是這麼定義的：

#define G_LIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 1))
  #define G_UNLIKELY(expr) (__builtin_expect (_G_BOOLEAN_EXPR(expr), 0))

宏_G_BOOLEAN_EXPR的作用是把expr轉換為0和1，即真假兩種。要理解宏G_LIKELY和G_UNLIKELY ，很明顯必須理解__builtin_expect。__builtin_expect是GCC(version>=2.9)引進的宏，其作用就是幫助編譯器判斷條件跳轉的預期值，避免跳轉造成時間亂費。拿上面的代碼來說：

if (G_LIKELY (acat == 1)) //表示大多數情況下if裡面是真，程序大多數直接執行if裡面的程序

而

if (G_UNLIKELY (thread_memory_magazine1_is_empty (tmem, ix)))//表示大多數情況if裡面為假，程序大多數直接執行else裡面的程序

可能大家看到還是一頭霧水，看下面一段就會明白其中的樂趣啦；

//test_builtin_expect.c 
#define LIKELY(x) __builtin_expect(!!(x), 1)
#define UNLIKELY(x) __builtin_expect(!!(x), 0)

int test_likely(int x)
{
 if(LIKELY(x))
 {
    x = 5;
 }
 else
 {
    x = 6;
 }
  
 return x;
}

int test_unlikely(int x)
{
 if(UNLIKELY(x))
 {
    x = 5;
 }
 else
 {
    x = 6;
 }
  
 return x;
}

[lammy@localhost test_builtin_expect]$ gcc -fprofile-arcs -O2 -c test_builtin_expect.c 
[lammy@localhost test_builtin_expect]$ objdump -d test_builtin_expect.o

test_builtin_expect.o:       file format elf32-i386

Disassembly of section .text:

00000000 <test_likely>:
     0: 55                      push     %ebp
     1: 89 e5                   mov      %esp,%ebp
     3: 8b 45 08                mov      0x8(%ebp),%eax
     6: 83 05 38 00 00 00 01  addl     $0x1,0x38
     d: 83 15 3c 00 00 00 00  adcl     $0x0,0x3c
  14: 85 c0                   test     %eax,%eax
  16: 74 15                   je       2d <test_likely+0x2d>//主要看這裡
  18: 83 05 40 00 00 00 01  addl     $0x1,0x40
  1f: b8 05 00 00 00          mov      $0x5,%eax
  24: 83 15 44 00 00 00 00  adcl     $0x0,0x44
  2b: 5d                      pop      %ebp
  2c: c3                      ret      
  2d: 83 05 48 00 00 00 01  addl     $0x1,0x48
  34: b8 06 00 00 00          mov      $0x6,%eax
  39: 83 15 4c 00 00 00 00  adcl     $0x0,0x4c
  40: 5d                      pop      %ebp
  41: c3                      ret      
  42: 8d b4 26 00 00 00 00  lea      0x0(%esi,%eiz,1),%esi
  49: 8d bc 27 00 00 00 00  lea      0x0(%edi,%eiz,1),%edi

00000050 <test_unlikely>:
  50: 55                      push     %ebp
  51: 89 e5                   mov      %esp,%ebp
  53: 8b 55 08                mov      0x8(%ebp),%edx
  56: 83 05 20 00 00 00 01  addl     $0x1,0x20
  5d: 83 15 24 00 00 00 00  adcl     $0x0,0x24
  64: 85 d2                   test     %edx,%edx
  66: 75 15                   jne      7d <test_unlikely+0x2d>//主要看這裡
  68: 83 05 30 00 00 00 01  addl     $0x1,0x30
  6f: b8 06 00 00 00          mov      $0x6,%eax
  74: 83 15 34 00 00 00 00  adcl     $0x0,0x34
  7b: 5d                      pop      %ebp
  7c: c3                      ret      
  7d: 83 05 28 00 00 00 01  addl     $0x1,0x28
  84: b8 05 00 00 00          mov      $0x5,%eax
  89: 83 15 2c 00 00 00 00  adcl     $0x0,0x2c
  90: 5d                      pop      %ebp
  91: c3                      ret      
  92: 8d b4 26 00 00 00 00  lea      0x0(%esi,%eiz,1),%esi
  99: 8d bc 27 00 00 00 00  lea      0x0(%edi,%eiz,1),%edi

000000a0 <_GLOBAL__I_65535_0_test_likely>:
  a0: 55                      push     %ebp
  a1: 89 e5                   mov      %esp,%ebp
  a3: 83 ec 08                sub

2017年9月13日星期三

GObject的物件屬性

https://imtx.me/archives/186.html

9、GObject的物件屬性

Feb 25, 2008

GObject既然是物件，肯定有屬性。既然有屬性，肯定有獲取和設置的辦法。GObject在這方面非常靈活，除具備一般物件導向程式的共性外，GObject的批量設置屬性的方法非常不錯。

-----

原文： http://library.gnome.org/devel/gobject/2.14/gobject-properties.html

GObject的其中一個漂亮特性就是它那為物件屬性準備的通用get/set機制。當一個物件被產生實體以後，物件的類初始化處理將用g_object_class_install_property來註冊物件的屬性（由gobject.c中實現）。

理解物件屬性是如何工作的最好就是看下面的例子：

/************************************************/

/* Implementation */

/************************************************/

enum {

MAMAN_BAR_CONSTRUCT_NAME = 1,

MAMAN_BAR_PAPA_NUMBER,

};

static void

maman_bar_instance_init (GTypeInstance *instance,

gpointer g_class)

{

MamanBar *self = (MamanBar *)instance;

}

static void

maman_bar_set_property (GObject *object,

guint property_id,

const GValue *value,

GParamSpec *pspec)

{

MamanBar *self = (MamanBar *) object;

switch (property_id) {

case MAMAN_BAR_CONSTRUCT_NAME: {

g_free (self->priv->name);

self->priv->name = g_value_dup_string (value);

g_print ("maman: %s\n",self->priv->name);

}

break;

case MAMAN_BAR_PAPA_NUMBER: {

self->priv->papa_number = g_value_get_uchar (value);

g_print ("papa: %u\n",self->priv->papa_number);

}

break;

default:

/* We don't have any other property... */

G_OBJECT_WARN_INVALID_PROPERTY_ID(object,property_id,pspec);

break;

}

static void

maman_bar_get_property (GObject *object,

guint property_id,

GValue *value,

GParamSpec *pspec)

{

MamanBar *self = (MamanBar *) object;

switch (property_id) {

case MAMAN_BAR_CONSTRUCT_NAME: {

g_value_set_string (value, self->priv->name);

}

break;

case MAMAN_BAR_PAPA_NUMBER: {

g_value_set_uchar (value, self->priv->papa_number);

}

break;

default:

/* We don't have any other property... */

G_OBJECT_WARN_INVALID_PROPERTY_ID(object,property_id,pspec);

break;

}

static void

maman_bar_class_init (gpointer g_class,

gpointer g_class_data)

{

GObjectClass *gobject_class = G_OBJECT_CLASS (g_class);

MamanBarClass *klass = MAMAN_BAR_CLASS (g_class);

GParamSpec *pspec;

gobject_class->set_property = maman_bar_set_property;

gobject_class->get_property = maman_bar_get_property;

pspec = g_param_spec_string ("maman-name",

"Maman construct prop",

"Set maman's name",

"no-name-set" /* default value */,

G_PARAM_CONSTRUCT_ONLY | G_PARAM_READWRITE);

g_object_class_install_property (gobject_class,

MAMAN_BAR_CONSTRUCT_NAME,

pspec);

pspec = g_param_spec_uchar ("papa-number",

"Number of current Papa",

"Set/Get papa's number",

0 /* minimum value */,

10 /* maximum value */,

2 /* default value */,

G_PARAM_READWRITE);

g_object_class_install_property (gobject_class,

MAMAN_BAR_PAPA_NUMBER,

pspec);

}

/************************************************/

/* Use */

/************************************************/

GObject *bar;

GValue val = {0,};

bar = g_object_new (MAMAN_TYPE_SUBBAR, NULL);

g_value_init (&val, G_TYPE_CHAR);

g_value_set_char (&val, 11);

g_object_set_property (G_OBJECT (bar), "papa-number", &val);

上面的例子看起來應該是簡單的，但是很多事情發生了：

g_object_set_property先確保相應名稱的屬性已經在bar的class_init處理函數中被註冊。如果是的話，它依次調用類繼承關係中的object_set_property，從底至頂，基礎類型用來找到註冊了這個屬性的類。接著它嘗試轉換使用者提供的GValue到屬性所關聯的GValue。

如果使用者提供了一個有符號的字元GValue，就像這裡所示，如果物件的屬性被註冊為一個無符號的整型，g_value_transform將會試著轉換輸入的有符號的字元到一個無符號的整型。當然，轉換是否成功取取決於可用的轉換函數。實際上，如果需要的時候，總會有相關的轉換函數可以用。

在轉型以後，GValue將被g_param_value_validata來驗證，以確保使用者保存在GValue中的資料吻合由屬性的GParamSpea所描述的字元特性。在這裡，我們在class_init裡提供的GParamSpec有一個驗證函數來確保GValue包含了一個代表最小和最大邊界的GParamSpec。在上面的例子中，用戶端的GValue並沒有尊重規範（它設置為了11，而最大值是10）。因為這樣，所了g_object_set_property函數將返回一個錯誤。

如果用戶的GValue已經被設置成了一個可用的值，g_object_set_property將處理一下呼叫至物件的set_property的類方法。在這裡，因為我們在Foo的實現代碼中並沒有重載這個函數，代碼路徑將會跳到foo_set_property在收到g_object_class_install_property存儲了GParamSpec的param_id後。

一時已經用物件的set_property類方法來設置好屬性以後，代碼路徑將調用g_object_nofity_queue_thaw使返回到g_object_set_property 。這個函數確保“notify”信號”已經在物件實例完成改變屬性後被發出，除非通知台已經被g_object_free_notify所凍潔。

g_object_thaw_nofity可以被用來重新啟用通過“notify”信號的屬性修改的通知中心。這是非常重要的，記住當屬性被改變時通知中心是否被凍結，“notify”信號將會當在屬性改變的一睡意由通知中心所發出：沒有屬性改變會因“notify”所信號。只有通過通知中心的凍結機制才能使信號發身被延誤。

這聽起來像是一個無聊的任務每次設置GValues當我想需要一個屬性時。實際上我們僅僅很少這樣做。g_object_set_property和g_object_get_property一般是用來語言綁定的。對應用程式來說，有一個更簡單的方法，在下面描述。

同時修改多個屬性

我想這很有趣，我們可以通過g_object_set和g_object_set_valist函數來同時設置多個屬性值。用戶端代碼可以被重寫為：

MamanBar *foo;

foo = /* */;

g_object_set (G_OBJECT (foo),

"papa-number", 2,

"maman-name", "test",

NULL);

這個節省了我們管理用g_object_set_property來處理GValue的時間。在被修改時這個代碼同樣會觸發每個屬性。

當然，_get的版本同樣是存在的：g_object_get和g_object-get_valist可以用來一次性得到很多屬性。

這些高級的方法有一個缺點──它們不提供一個返回值。在使用它們時，你需要注意這些參數類型和範圍。（暫時不會了）

These high level functions have one drawback - they don't provide a return result. One should pay attention to the argument types and ranges when using them. A know source of errors is to e.g. pass a gfloat instead of a gdouble and thus shifting all subsequent parameters by four bytes. Also forgetting the terminating NULL will lead to unexpected behaviour.

如果你認真看這章的話，現在你應該已經知道了g_object_new，g_object_newv和g_object_new_valist是如何工作的：它們解析使用者提供的變數數目和參數並當物件成功的創建以後，用這些參數調用g_object_set。當然，“notify”信號同樣會在每個屬性改變後發射。

訂閱：文章 (Atom)

Keep Learning Everyday

2017年9月21日星期四

cross compiler arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別

2017年9月14日星期四

[轉] 內核的likely()/unlikely和glib的G_LIKELY/G_UNLIKELY

內核中的 likely() 與 unlikely()

G_LIKELY和G_UNLIKELY

2017年9月13日星期三

GObject的物件屬性

關於我自己

網誌存檔

2017年9月21日 星期四

cross compiler arm-linux-gnueabi 和 arm-linux-gnueabihf 的區別

2017年9月14日 星期四

[轉] 內核的likely()/unlikely和glib的G_LIKELY/G_UNLIKELY

內核中的 likely() 與 unlikely()

G_LIKELY和G_UNLIKELY

2017年9月13日 星期三

GObject的物件屬性

2017年9月21日星期四

2017年9月14日星期四

2017年9月13日星期三