On a vu l’importance des listes d’initialisation mais il est un point important dont il faut se souvenir: les variables ne sont pas n\u00e9cessairement initialis\u00e9es dans l’ordre o\u00f9 elles sont dans la liste d’initialisation. En fait, l’ordre d’initialisation d\u00e9pend de l’ordre dans lequel elles sont d\u00e9clar\u00e9es.<\/p>\n
\r\nclass A\r\n{\r\n public:\r\n A() : a(10), b(20) {}\r\n private:\r\n int b;\r\n int a;\r\n};\r\n<\/pre>\nDans la classe ci-dessus, b<\/em> est initialis\u00e9 le premier et a<\/em> ensuite, conform\u00e9ment \u00e0 l’ordre de d\u00e9claration. Dans ce cas-ci, cela n’a pas d’importance que b<\/em> soit initialis\u00e9 avant a<\/em> mais ce n’est pas toujours vrai.<\/p>\n\r\nclass A\r\n{\r\n public:\r\n A(size_t len) : length(len), buf(new char[length]) {}\r\n private:\r\n char* buf;\r\n size_t length;\r\n};\r\n<\/pre>\nIci, buf<\/em> est initialis\u00e9 avant length<\/em> et cela pose un probl\u00e8me puisque buf<\/em> doit \u00eatre initialis\u00e9 en utilisant length<\/em> qui n’est pas encore initialis\u00e9. Utiliser new<\/em> avec un argument non-initialis\u00e9 est un comportement ind\u00e9fini. En clair, c’est un bug de votre programme.<\/p>\n","protected":false},"excerpt":{"rendered":"On a vu l’importance des listes d’initialisation mais il est un point important dont il faut se souvenir: les variables ne sont pas n\u00e9cessairement initialis\u00e9es dans l’ordre o\u00f9 elles sont dans la liste d’initialisation. En fait, l’ordre d’initialisation d\u00e9pend de l’ordre dans lequel elles sont d\u00e9clar\u00e9es. class A { public: A() : a(10), b(20) {} […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[4],"tags":[],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t